+1 On Thu, 18 Feb 2021 at 12:15, Heinrich Schuchardt <xypron.g...@gmx.de> 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. > With 3 you will just see a hex-string. > > This excludes 3 for me. > > If 2 does not add the number of initrds, it cannot be determined if a > following array element starting with a VenMedia() node is an initrd or > has a completely different meaning. > > With 1 you can individually determine for each element its meaning by > looking at the first node. > > Therefore I prefer 1. > > Best regards > > Heinrich > > > > > > > Any preference on these? > > Is one of them closer to the EFI spec, so we could go ahead and try to > > standardize some of the GUIDs of the VenMedia? > > > > > > [1] https://lkml.org/lkml/2020/2/16/105 > > > > Regards > > /Ilias > > > > _______________________________________________ > boot-architecture mailing list > boot-architecture@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
