(08-22-2017, 06:42 PM)z4v4l Wrote: of course, arm had to invent their own wheel, many wheels, and give them weird names, a lot of them, the whole hyerarchy. but with respect to UEFI, all that pre-pre-init "teh security" thing is a SEC phase, which hands control off to the UEFI.
You actually double my question, because it's either UEFI or uboot or whateverboot, but not all together. because whereas all those secure world blobs do is that "they are signed, trusted, yay!", UEFI or uboot do the real initialization work, choose an OS to boot, interact with a user to let them brick configure the boot option and board etc.

(08-22-2017, 09:07 PM)z4v4l Wrote: 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.

(08-22-2017, 09:40 PM)stuartiannaylor Wrote:

(08-22-2017, 09:07 PM)z4v4l Wrote: 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.

Not everything is a PI and ARM are part of a much larger scale of things. I think we might be talking of distributed architecture that doesn't even resemble much of what we have today.
I am not all that bothered as the Rock64 has a 16MB nor that can be partitioned and be flexible to have the situation we have.
Yeah we are going to get UEFI and if that is via ATF or not I am not bothered as its a headache to read but have a feeling its much more than what seems to be your comprehension.
 I am not that sure maybe you are right but yeah UEFI is on the way.

(08-22-2017, 11:17 PM)z4v4l Wrote: just in case, by "PI", i meant the Platform Initialization from the UEFI forum, it's a somewhat funny specification on how to do a UEFI specification implementation.

(08-22-2017, 11:17 PM)z4v4l Wrote: just in case, by "PI", i meant the Platform Initialization from the UEFI forum, it's a somewhat funny specification on how to do a UEFI specification implementation.

• HiKey and HiKey960 boards
  
  
• MediaTek MT6795 and MT8173 SoCs
  
  
• NVidia T132, T186 and T210 SoCs
  
  
• QEMU emulator
  
  
• RockChip RK3328, RK3368 and RK3399 SoCs
  
  
• Socionext UniPhier SoC family
  
  
• Xilinx Zynq UltraScale + MPSoC