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.
  Reply
#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
  Reply
#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
  Reply
#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.
  Reply
#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! )
  Reply
#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
  Reply
#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! )
  Reply
#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
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Rock64 for video surveillance martinschm 6 308 09-19-2019, 01:56 AM
Last Post: Jozek
  ROCK64 not booting TheGiolly 10 292 09-09-2019, 06:57 AM
Last Post: Rocklobster
  Rock64 v3 - POE P1V 3 428 08-18-2019, 05:51 AM
Last Post: mcerveny
  Rock64 board seems defective, how to confirm? Josk 1 108 08-15-2019, 08:24 PM
Last Post: tllim
  Purchase Rock64 V3? richardk 6 550 08-03-2019, 12:56 PM
Last Post: mcerveny
  Rock64 running OMV, how to setup RTL8812AU WiFi? electrosam 2 144 07-16-2019, 04:03 PM
Last Post: ayufan
  Rock64 random freezes BTB 3 229 07-01-2019, 10:17 AM
Last Post: Luke
Sad Rock64 Seafile Installation klaus_nase 2 172 06-27-2019, 09:11 AM
Last Post: klaus_nase
  rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? hunderteins 5 410 06-22-2019, 12:36 PM
Last Post: redfish
  Another non-booting ROCK64 SuburbanDad 13 702 06-19-2019, 01:48 AM
Last Post: mcerveny

Forum Jump:


Users browsing this thread: 1 Guest(s)