Re-partitioning; Adding swap partition; Using GPT partitions
completeness and compliance is defined not by the ability to boot some linux distribution, but what percentage of functionality defined in the specification as the requirement is implemented and how properly it is implemented. uboot doesn't even have UEFI Boot Manager*, I don't know does it understand UEFI environment variables, device paths? without this, installation of a UEFI aware OS is impossible. linux is a bad example here, honestly, it doesn't have a normal UEFI OS loader, and I suspect, - barely uses UEFI at all, that so called "efi stub" just calls ExitBootServices() as soon as possible and that is all - with this it's hard to get how UEFI implementation is full in uboot.
* - the fact, you can feed it with BOOTAA64.EFI on a removable medium and it will run it, is way not enough to call it UEFI. it should support the whole Boot Manager environment, with its look and feel mostly left for the implementer fantasy or its lack, but with the support of "boot options" and the specified mechanisms and all the variables needed for this. when a UEFI application, the OS installer, asks to create such a boot option and the Boot Manager makes it, and that option contains a "device path" - a chain of device protocol instances, assigning the hardware path for the firmware to find the boot device in question up to the file system and file. does uboot implement all that? does it provide all the Boot Services? Runtime Services? these are just a core of the requirements, they are much broader, there is a lot of protocols needed to be supported as well.
@Arwen, the trusted firmware part may be open source, it's that ATF stuff from ARM. as of NDA for ROM code, I don't know, but you can contact them, there is a person at rockchip, responsible for opensource, he responds to emails (the email, posted somewhere at opensource.rock-chips.com).
* - the fact, you can feed it with BOOTAA64.EFI on a removable medium and it will run it, is way not enough to call it UEFI. it should support the whole Boot Manager environment, with its look and feel mostly left for the implementer fantasy or its lack, but with the support of "boot options" and the specified mechanisms and all the variables needed for this. when a UEFI application, the OS installer, asks to create such a boot option and the Boot Manager makes it, and that option contains a "device path" - a chain of device protocol instances, assigning the hardware path for the firmware to find the boot device in question up to the file system and file. does uboot implement all that? does it provide all the Boot Services? Runtime Services? these are just a core of the requirements, they are much broader, there is a lot of protocols needed to be supported as well.
@Arwen, the trusted firmware part may be open source, it's that ATF stuff from ARM. as of NDA for ROM code, I don't know, but you can contact them, there is a person at rockchip, responsible for opensource, he responds to emails (the email, posted somewhere at opensource.rock-chips.com).
ANT - my hobby OS for x86 and ARM.