Rock64 Review

[z4v4l]

I got it, from your other post it's seen that you think both uboot and UEFI are a part of ATF (BL3). No that's not exactly true. this is the situation where they have been unnecessarily made as those. but it is overcomplicated and bloated. ATF is just an ARM implementation of their own standard. Neither uboout nor UEFI are a part of it. It results in an unndeed duplication and clumsiness, because ARM obviously pushes their standard considering anything else a subordinate and none of importance, not paying attention to what has been already done. For example UEFI (I don't know much about the uboot structure, anything I saw there, shows rather lack of any), has its own model, which could incorporate this ARM architecture feature of splitting into Secure/Non-secure worlds. So arm might say to fw writers (or to themsleves), make an UEFI (based on the PI specification or not) implementation with Secure/Non-secure split in mind. But, ARM obviously didn't pay any attention to this, so in their freshly invented "wheel", UEFI ended up being just a late sub-stage in their lengthy overdesigned chain. despite UEFI is a full blown standard for making firmware that doesn't need any bloated arch specific gimp sticks as ATF. in theory, you can use your own secure world part of the FW. if you cannot gain access to the Secure part, then you are forced to rely on ATF, since every SoC vendor won't bother themselves with anything other than just grabbing ATF. well. still it's duplication, because it's several incompatible standards joint together on the "make it to just work" basis, no wonder why thoughts to put 16MB NOR chips arise with SBC makers.