Rock64 Review
#21
of course, arm had to invent their own wheel, many wheels, and give them weird names, a lot of them, the whole hyerarchy. Big Grin 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. Smile 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.
ANT - my hobby OS for x86 and ARM.
#22
(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. Big Grin 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. Smile 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
#23
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. Big Grin
ANT - my hobby OS for x86 and ARM.
#24
(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. Big Grin

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.
#25
(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. Big Grin

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.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
#26
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. Smile
ANT - my hobby OS for x86 and ARM.
#27
(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. Smile

thanks for the clarification.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
#28
(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. Smile

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


Possibly Related Threads…
Thread Author Replies Views Last Post
  Rock64 No Audio @ Debian 12 dmitrymyadzelets 1 112 03-18-2024, 06:56 AM
Last Post: diederik
  Rock64 bricked shawwwn 7 5,448 03-17-2024, 12:22 PM
Last Post: dmitrymyadzelets
  Rock64 won't boot luminosity7 10 3,863 03-16-2024, 08:33 AM
Last Post: dmitrymyadzelets
  Rock64 doesn't boot dstallmo 1 254 03-16-2024, 08:29 AM
Last Post: dmitrymyadzelets
  How well does Rock64 deal with HDR and Atmos on Kodi? drvlikhell 3 1,770 04-29-2023, 04:24 AM
Last Post: newestssd
  OpenWRT on the Rock64 CanadianBacon 12 7,790 04-24-2023, 12:40 PM
Last Post: arunkhan
  Rock64 board not working, no HDMI no Ethernet. EDited 3 3,396 01-17-2023, 02:31 PM
Last Post: Flagtrax
  ROCK64 v3 can it boot from USB? Tsagualsa 4 1,973 11-29-2022, 11:31 AM
Last Post: Macgyver
  rock64 v3 spiflash Macgyver 0 703 11-28-2022, 02:18 PM
Last Post: Macgyver
  my rock64 dosen't work rookie_267 0 904 10-07-2022, 07:50 PM
Last Post: rookie_267

Forum Jump:


Users browsing this thread: 2 Guest(s)