Jump to content

U-Boot -> UEFI


Recommended Posts

Some early foundations for UEFI. It has to be properly developed, board vendors must upgrade to recent u-boots which are not a simple and cheap task. Next, we have to break something that works and exchange with a technology which gives more but is it already matured? Will old kernels boot? Will all kernels boot? I don't expect much activities in next one year in this area.

Link to comment
Share on other sites

I don't think it's a viable approach, or useful. UEFI is supposed to be an entire platform firmware, from the very initial state to the loading OS and even supplying "runtime services" capable of running inside the OS. So implementers should just implement it as it is, making a firmware complying with this standard if they want to be "UEFI". When they start to make it "on top" of something other and absolutely different, it results in one thing - a crappy bloated montrous ugliness, that nobody likes. The same applies to ARM's ATF. Instead of making UEFI some later non-secure bl33 "on top" or whatever, turning this into unnecessary overdeveloped stupid and annoying bloat, which duplicates internally functions tens of times, they might just inocorporate their security thingy into UEFI. It's "extensible" firmware interface, bitches! It lets you add to it anything you want. in a consistent and standard and unified way. Which is the best approach for everybody. For example ATF mght have been done as a set of protocols (for Dxe), interfaces (for Pei) and as a part of the Sec phase. The idea is it's already there, just fill it with yours, don't layer it "on top" of your own invented bicycle. But but.

 

I see the uboot's approach here as a "gimp stick" and am not impressed and don't think it would be broadly used. Rather vendors finally manage themselves to finally port Tianocore on their SoCs. Allwinner for example has something looking like this.

 

Anyway, I wanted to say yet, humbly, :D that I have chosen as a joy for myself, to try to create my own UEFI implementation for a couple of mips and arm boards. Not for "servers", but for these tiny SBCs. Of course it's a spare time enthusiastic work, moving very slowly. But if it succeeds I'll tell about it. :)

Link to comment
Share on other sites

Igor, jernejvalant

 

   Thanks for sharing your thoughts. here is dive into manging ARM boot system complexity issues.  sleeping on it overnight, I concur with Valant's perspective.  

Proposed roadmap towards ending up with less long run boot system cruft:

1. our first generic ARM system virgin SD-card boot challenge concerns unifying the various SD-card master boot record offset entry points execute a unified code image. Accomplishing a full unification, such that all SOC's can boot from the very same SD_card image may be near impossible, as suggested in the "UEFI on Top of U-Boot" paper mentioned prior.  this may be made even more challenging if different (ARMv7 vs. ARMv8) SOC's, initiate there execution using a different instruction set or execution mode.  

   Neither u-boot or BareBox have attempted to fully resolve the need for unification relating to a multiplicity of partition table formats, boot code image formats, various entry points,  ARMv7, ARMv8 and (GPU in the case of raspberry pi) instruction sets.   While a partial unification of these various ARM SOC boot paradigms may be possible..  The closest we are may be able to come to unifying the need to handle this multiplicity of board specific SD_card boot images, may involve modifying the SD_card image flashing application such that it would have the capability to merge board specific boot code with an otherwise fully unified, generic, (possibly BtrFS based) ARMbian OS image.   While accomplishing this flash image time code merge may be a challenge,  taking this approach could help to resolve some of the issues related to the growing number of ARM SOC boot paradigmes.   

   On the other hand, I have yet to find any actual instance of a real "mutual exclusion", that could not be overcome by way of custom crafted master boot record / GPT FAT file system image..   That is: most of these boot formats have some level of flexibility in there layout.   the only thing that may be more difficult might be if the same code entry point were used with a pair of mutually exclusive instruction sets.... or am I missing something here?

      

2.  (Optionally) provision the first SD_card partition as a (v?)FAT file system.  I propose that this FAT partition would NOT be involved in the initial (BtrFS based boot process)  but instead to ease initial configuration and UEFI migration issues..   more on this later.  

 

3.  provide BtrFS, boot,  Snapshot and Rollback support for (possibly multiple) BtrFS boot images.

see: http://git.denx.de/?p=u-boot.git;a=commit;h=b6ee860b87d8accedfb7a1fd5414f7c483603234  

and: https://gitlab.labs.nic.cz/search?utf8=✓&search=btrfs&group_id=&project_id=254&search_code=true&repository_ref=master

 

4.  place primary system_config, device_tree vars within this larger BtrFS file partition possibly under /boot/..  to easy legacy migration issues,  provide the capability of explicit deference by way of cross file system symbolic linking, such that these files can, if preferred, exist on the (optional, UEFI) FAT partition instead possibly mounted @ /UEFI/..,  where they can be more easy modified (possibly by a MS_Win machine) before the SD-card image is booted.   for those who are falling in love with UEFI (not me, as I am not happy that UEFI can retain active code beyond boot, and thus provide a home for the lurking of root kits)..

   the BtrFS based boot could then pass control to a UEFI boot system placed within this FAT partition..  I think this option would be good to have, but I am suggest that our longer term boot system roadmap may want to explore utilizing just BtrFS...  prepare for the day we might leave a FAT partition behind.

    that is: Primary boot control / trust would be placed with the SD_card's BtrFS file system image where system Snapshots and Rollback can also be utilized also with (possibly multiple) boot images.  

 

5.  System security: support signing / verification of initial bootstrap image, BtrFS,  and any UEFI images.    

 

6.  longer run: provide for SD-card BtrFS file system access from MS_windows machines.

see:  https://github.com/maharmstone/btrfs 

integrate BtrFS access capability along with a system_config_editor into SD_card image creation programs such as Etcher.

 

    Taking this approach makes it very easy remove this legacy FAT file boot system cruft from future systems.

       Hope this helps ARMbian's longer term boot system roadmap discussion get off to a good start.

          -Peter
 

   

Edited by Peter Lindener
Is the "mutual exclusion" real?
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines