(ARCHIVED) Ubuntu Xenial Image (BSP Kernel)

[longsleep]

I was thinking about that whole business with "relying on Allwinner's old BSP with missing sourcefiles" and the need for an Android workaround (or has that been sorted out?).

Yes - though this is always the case (after all it is an Allwinner SoC). The situation can improve when community members put countless hours into reverse engineering proprietary code and improving the little what was made available. Mainlining Kernel support for A64 was started by @apritzel and i got rid out the Android booting by backporting from mainline U-Boot. See http://linux-sunxi.org/Linux_mainlining_effort for the past, current and upcoming work by the linux-sunxi community. You can help even when you are not a developer by gathering details and information about things and updating the wiki.

I can't claim that I've read everything about the recent Linux development for Pine but I have gotten the impression that there are still some obstacles in the way of getting a proper (/maintainable and easily patched) kernel based on a more recent Linux mainline kernel and a more straightforward booting/image-packing approach than faking an Android image to boot a "normal" Linux installation?

This depends what you expect. It is perfectly fine to use the Pine64 as server to build cheap clusters for arm and arm64 workloads. Other things which involve the even more proprietary things like accelerated graphics or video decoding will only happen if someone puts countless hours into figuring things out. Best approach is to join #linux-sunxi in IRC on freenode.net and offer help.

Regarding the 720P question,have I understood it correctly that it should be achieved either by:
compiling a slightly different image from scratch (probably above my head) which would then boot into 720P by default
or
applying some configuration changes in the uEnv.txt config-file, add a second version of the existing device tree and rebooting the Pine (which would make the kernel boot with a slightly modified device tree)?

Sounds like the uEnv.txt is an "easier" approach for a Linux-noob like me?

But I am assuming that the uEnv.txt and device tree (.dtb file?) are easily accesible and that the "slightly modified .dtb" part isn't that hard if someone writes a how-to. 

Yes. Both are easily accessable. Though this is not something i will spend time on. If anyone comes up with a good patch set to the default U-Boot environment for this i will be happy to merge it.

Is there any chance at all to make the SoC perform some sort of "auto-detect" sequence (try 1080P, if that fails try 720P instead) or is that sort of thing just a boot-time single shot kind of deal implied by the SoC?
Since it wasn't mentioned as a viable option by you guys I assume that once you're booted up you can't just change the HDMI mode on the fly?

Probably yes. Install the fbset command which can do that. Parameters are not user friendly though, but with some efford it is easy to figure out. I did not try though and it might not behave properly