Hi Heinrich, On Thu, 18 Feb 2021 at 04:15, Heinrich Schuchardt <[email protected]> wrote: > > On 18.02.21 10:04, Ilias Apalodimas wrote: > > Hi, > > > > An arch agnostic way was recently added on the kernel, as an alternative > > method > > to load an initrd [1]. The kernel call to the firmware ends up calling the > > protocol with a Device Path End Structure, so the firmware must know which > > initrd to load on the buffer the kernel provides. > > > > The protocol is currently implemented by U-boot and EDK2, which both > > define a way of specifying the initrd to load. We could use this protocol, > > in order to provide vertical distros a way of loading (kernel, initrd) pairs > > without GRUB. In that case we need a common way for firmware > > implementations > > to define and manage the initrd. User space applications that control the > > boot > > flow (e.g efibootmgr), should also be able to change the variable > > accordingly. > > > > Looking at the EFI spec and specifically § 3.1.3 Load Options, we can use > > the > > FilePathList[] of the EFI_LOAD_OPTION, which is described as: > > > > "A packed array of UEFI device paths. The first element of the array is a > > device path that describes the device and location of the Image for this > > load option. The FilePathList[0] is specific to the device type. Other > > device > > paths may optionally exist in the FilePathList, but their usage is OSV > > specific. > > Each element in the array is variable length, and ends at the device path > > end > > structure. Because the size of Description is arbitrary, this data structure > > is not guaranteed to be aligned on a natural boundary. This data structure > > may > > have to be copied to an aligned natural boundary before it is used." > > > > So FilePatrhList[1-n] are available for OS usage. There are 3 ways we could > > implement that. All 3 ways would allow us to specify multiple initrds (and > > we > > could extend the same logic to DTBs, but that's a different discussion). > > They all re-use the same idea, prepend a VenMedia DP, which has a GUID. We > > can > > then use that GUID to identify the filetype and behavior of the device > > paths. > > > > 1. Prepend a VenMedia Device Path in every initrd Device Path. In that case > > FilePathList[] would look like this: > > > > Loaded Image device path - end node - VenMedia - Initrd DP - end node > > - VenMedia - Initrd DP - end node - repeat > > > > 2. Prepend a VenMedia Device Path once. In that case FilePathList[] would > > look > > like this: > > > > Loaded Image device path - end node - VenMedia - Initrd DP - end > > instance - (repeat) - Initrd DP - end node - other DPs > > > > In this case we could use the VenMedia Vendor Defined Data to indicate > > the number > > of device paths that follow, although it's redundant, since each instance > > would > > terminate on the Device Path End Structure. > > > > 3. Use Vendor Defined Data of the VenMedia device path and copy the initrd > > device path(s) in there. In that case the Vendor Defined Data will it self > > be in a device path format with all the initrds we want. > > > > Loaded Image device path - end node - VenMedia - end node - other DPs > > When passing the device path of the boot option to the EDK2 > implementation of > EFI_DEVICE_PATH_TO_TEXT_PROTOCOL.ConvertDevicePathToText(), it will > print out all array elements as comma separated list like > > HD(1,GPT,..,0x2000,0x200000)/File(\EFI\debian\shimaa64.efi),/VenMedia(00000001-0000-0000-0000-000000000000)/HD(2,GPT,..,0x2000,0x200000)/File(\initrd1),/VenMedia(00000001-0000-0000-0000-000000000000)/HD(2,GPT,..,0x2000,0x200000)/File(\initrd2) > > The device path end nodes of sub-type 0x01 are rendered as commas. > > With 1 and 2 this would show a readable output like above.
The above is not readable in my opinion. I really wonder about this path that we are going down. [..] Regards, Simon _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
