Rock64 Review

[z4v4l]

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.

[stuartiannaylor]

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.

No they don't and maybe read up about ATF, why and what it does.

https://www.slideshare.net/linaroorg/arm...rmv8alcu13
https://chromium.googlesource.com/extern...-design.md

[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.

[stuartiannaylor]

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.

[MarkHaysHarris777]

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.

uefi  might be on its way;

... but I would not hold my breath...   can't even get uboot to reliably boot from SPI yet;  and there are some other issues.  But what is on the way at least in terms of Rock64 is a boot loader on nor SPI flash so that the hardware specific stuff is modularized and kept separate from the software stuff;  looking forward to that.

[z4v4l]

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.

[MarkHaysHarris777]

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.

thanks for the clarification.

[stuartiannaylor]

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.

Apols my presumption I had been wondering as it seemed an unusual stance "Its got too much Nor" its not often a consumer gripe.

https://github.com/ms-iot/RPi-UEFI
I had presumed you expected similar and yeah I did get the wrong end of the stick, being so Intel orientated it was prob odds on that Arm would offer an alternative, they have created a framework and offered both @ BL3.

TKaiser on the Cnx mentioned the ATF and that EUFI is possible and I was the same with ATF? Whats that but after reading it and getting totally confused I settled on its cool that its possible to be U-Boot or UEFI with this thing called Arm Trusted Firmware.

Hoping I can dodge https://github.com/ARM-software/arm-trusted-firmware but its all there with support for :-

This release also contains the following platform support:

• 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
  
  
  

ARM Trusted Firmware Design
https://github.com/ARM-software/arm-trus...design.rst