06-12-2016, 10:56 AM
(06-12-2016, 06:40 AM)z4v4l Wrote: You don't have to learn all Uefi internals and compile it in order to add your driver. or a test application. or an OS loader. And the main thing - writing such a driver for Uefi is easier than extending uboot. Because it has a well defined driver model and the core gives you a very rich set of services to facilitate your work.Yeah, that's a nice fairy tale. You still need to be able to debug the drivers, that's where the things usually become ugly
Quote:Let's be honest, the maximum you have on a particular board now is an ability to boot from SD/eMMC. And possibly through TFTP. And board vendors obviously are struggling to add in uboot something yet (like USB boot), despite these features are often requested. Easiness of multiboot and from any media on uboot exists only theoretically, the same as my Uefi implementation.Huh? Of course U-Boot supports booting from SD cards, USB sticks, SATA, Ethernet (both TFTP and PXE), USB OTG and pretty much every other possible option. Instead of speculating, just get some Allwinner board with an older SoC and you will see it yourself. Or read about it here: http://git.denx.de/?p=u-boot.git;a=blob;...DME.distro
The Pine64 board is a bit special case, because it is the first Allwinner 64-bit SoC. That's why it needs more work (also partially because we surely want to have UEFI working on AArch64 too). But the Allwinner A64 and Pine64 support in U-Boot is progressing nicely (some initial support is already there!) and we are likely only a few months away until it is in a perfectly usable shape.