Re: EFI_LOAD_FILE2 for initrd standardization
Hi Ard, > wrote: > > > > Hi Samer, > > > > Thanks for having a look at this > > > > On Mon, Mar 01, 2021 at 08:44:00PM +, Samer El-Haj-Mahmoud wrote: > > > > > > > > > > -Original Message- > > > > From: Heinrich Schuchardt > > > > Sent: Monday, March 1, 2021 2:39 PM > > > > To: Ilias Apalodimas ; Grant Likely > > > > > > > > Cc: Boot Architecture Mailman List > > > > ; Samer > > > > El-Haj-Mahmoud ; Ard Biesheuvel > > > > ; Leif Lindholm > > > > Subject: Re: EFI_LOAD_FILE2 for initrd standardization > > > > > > > > > ... > > > > > > > > > > > The UEFI spec knows two types of separators for device paths. Both have > > > > type > > > > 0x7F (End of Hardware Device Path) but differ by the sub-type: > > > > > > > > Sub-Type 0xff – End Entire Device Path > > > > Sub-Type 0x01 – End Instance of a Device Path > > > > > > > > Field EFI_LOAD_OPTION.FilePathList[] is described in the UEFI spec as > > > > follows: > > > > > > > > "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." > > > > > > > > It is not immediately clear if the separators between the array > > > > elements are of > > > > sub-type 0xff or 0x01. The description in the UEFI spec should be > > > > reworked for > > > > more clarity. > > > > > > > > > > Agree that this is not clear, and could be interpreted either way. And > > > yes, agree the UEFI spec needs a clarification > > > > > > > > > > The current EDK II coding requires that the device path identifying the > > > > UEFI > > > > binary (i.e. FilePathList[0] is terminated by a sub-type 0xff end node. > > > > > > > > > > The EDK2 code seems to be incomplete, with a "TODO" to support the > > > FilePathList[]. In fact, the code calls it "FilePath" to be clear that it > > > is assuming a single DevicePath (which means a 0xFF sub-type termination) > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg%2FLibrary%2FUefiBootManagerLib%2FBmLoadOption.c#L199 > > > > > > Searching the code further, I see there is support for parsing > > > multi-instance device path (separated by > > > END_INSTANCE_DEVICE_PATH_SUBTYPE, or 0x1) in things like > > > UefiDevicePathLib , parsing code, etc... But it does not seem to be > > > supported at all in the UEFI Boot Manager implemented in EDK2 > > > > > > > > > > The UEFI variable ConDev is decribed as "The device path of all > > > > possible console > > > > input devices". The spec does not refer to it as an array of device > > > > paths. > > > > > > > > > > Looking at EDK2, ConXDev are treated as multi-instance devices, with > > > ConPlatformDxe using AppendDevicePathInstance() and > > > GetNextDevicePathInstance() to construct / navigate the multiple-instances > > > > > > The spec should have defined these as a "multi-instance device path of > > > all possible console X devices". See my notes below on multi-instance DP. > > > > > > > > > > So it seems that the UEFI spec editors mean by array of device paths > > > > that an > > > > element of the array is separated by sub-type 0xff. Each individual > > > > array element > > > > may be a collection of device paths instances separated by 0x01 > > > > sub-type end > > > > nodes. > > > > > > > > > > I am leaning towards this conclusion as well. This is further supported > > > by the following evidence: > > > > > > > Yes that's exactly what I thought as well and that's what option (2) was > > trying to describe on my first mail. > > > > What I had in there was: > > Loaded Image device path - end node - VenMedia - Initrd DP - end instance - > > (repeat) - Initrd DP - end node - other DPs > > > > > > > > * EFI_DEVICE_PATH_UTILITIES_PROTOCOL has a function called > > > IsDevicePathMultiInstance() along with walker functions > > > AppendDevicePathInstance(
Re: EFI_LOAD_FILE2 for initrd standardization
On Tue, 2 Mar 2021 at 00:31, Ilias Apalodimas wrote: > > Hi Samer, > > Thanks for having a look at this > > On Mon, Mar 01, 2021 at 08:44:00PM +, Samer El-Haj-Mahmoud wrote: > > > > > > > -Original Message- > > > From: Heinrich Schuchardt > > > Sent: Monday, March 1, 2021 2:39 PM > > > To: Ilias Apalodimas ; Grant Likely > > > > > > Cc: Boot Architecture Mailman List ; > > > Samer > > > El-Haj-Mahmoud ; Ard Biesheuvel > > > ; Leif Lindholm > > > Subject: Re: EFI_LOAD_FILE2 for initrd standardization > > > > > > ... > > > > > > > > The UEFI spec knows two types of separators for device paths. Both have > > > type > > > 0x7F (End of Hardware Device Path) but differ by the sub-type: > > > > > > Sub-Type 0xff – End Entire Device Path > > > Sub-Type 0x01 – End Instance of a Device Path > > > > > > Field EFI_LOAD_OPTION.FilePathList[] is described in the UEFI spec as > > > follows: > > > > > > "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." > > > > > > It is not immediately clear if the separators between the array elements > > > are of > > > sub-type 0xff or 0x01. The description in the UEFI spec should be > > > reworked for > > > more clarity. > > > > > > > Agree that this is not clear, and could be interpreted either way. And yes, > > agree the UEFI spec needs a clarification > > > > > > > The current EDK II coding requires that the device path identifying the > > > UEFI > > > binary (i.e. FilePathList[0] is terminated by a sub-type 0xff end node. > > > > > > > The EDK2 code seems to be incomplete, with a "TODO" to support the > > FilePathList[]. In fact, the code calls it "FilePath" to be clear that it > > is assuming a single DevicePath (which means a 0xFF sub-type termination) > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg%2FLibrary%2FUefiBootManagerLib%2FBmLoadOption.c#L199 > > > > Searching the code further, I see there is support for parsing > > multi-instance device path (separated by END_INSTANCE_DEVICE_PATH_SUBTYPE, > > or 0x1) in things like UefiDevicePathLib , parsing code, etc... But it does > > not seem to be supported at all in the UEFI Boot Manager implemented in EDK2 > > > > > > > The UEFI variable ConDev is decribed as "The device path of all possible > > > console > > > input devices". The spec does not refer to it as an array of device paths. > > > > > > > Looking at EDK2, ConXDev are treated as multi-instance devices, with > > ConPlatformDxe using AppendDevicePathInstance() and > > GetNextDevicePathInstance() to construct / navigate the multiple-instances > > > > The spec should have defined these as a "multi-instance device path of all > > possible console X devices". See my notes below on multi-instance DP. > > > > > > > So it seems that the UEFI spec editors mean by array of device paths that > > > an > > > element of the array is separated by sub-type 0xff. Each individual array > > > element > > > may be a collection of device paths instances separated by 0x01 sub-type > > > end > > > nodes. > > > > > > > I am leaning towards this conclusion as well. This is further supported by > > the following evidence: > > > > Yes that's exactly what I thought as well and that's what option (2) was > trying to describe on my first mail. > > What I had in there was: > Loaded Image device path - end node - VenMedia - Initrd DP - end instance - > (repeat) - Initrd DP - end node - other DPs > > > > > * EFI_DEVICE_PATH_UTILITIES_PROTOCOL has a function called > > IsDevicePathMultiInstance() along with walker functions > > AppendDevicePathInstance(), GetNextDevicePathInstance(). The description of > > these functions make it clear that the intention is to treat 0x01 as a > > separator between multiple instances of device paths in a multi-instance > > device path structure, with 0xff as the final end of DP indicator. For > > example, AppendDevicePathInstance() is defined as: > > > > " This function creates a new device path by appending a copy of the > > specified device path instance to a copy of the specified device
Re: EFI_LOAD_FILE2 for initrd standardization
Hi Samer, Thanks for having a look at this On Mon, Mar 01, 2021 at 08:44:00PM +, Samer El-Haj-Mahmoud wrote: > > > > -Original Message- > > From: Heinrich Schuchardt > > Sent: Monday, March 1, 2021 2:39 PM > > To: Ilias Apalodimas ; Grant Likely > > > > Cc: Boot Architecture Mailman List ; > > Samer > > El-Haj-Mahmoud ; Ard Biesheuvel > > ; Leif Lindholm > > Subject: Re: EFI_LOAD_FILE2 for initrd standardization > > > ... > > > > > The UEFI spec knows two types of separators for device paths. Both have type > > 0x7F (End of Hardware Device Path) but differ by the sub-type: > > > > Sub-Type 0xff – End Entire Device Path > > Sub-Type 0x01 – End Instance of a Device Path > > > > Field EFI_LOAD_OPTION.FilePathList[] is described in the UEFI spec as > > follows: > > > > "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." > > > > It is not immediately clear if the separators between the array elements > > are of > > sub-type 0xff or 0x01. The description in the UEFI spec should be reworked > > for > > more clarity. > > > > Agree that this is not clear, and could be interpreted either way. And yes, > agree the UEFI spec needs a clarification > > > > The current EDK II coding requires that the device path identifying the UEFI > > binary (i.e. FilePathList[0] is terminated by a sub-type 0xff end node. > > > > The EDK2 code seems to be incomplete, with a "TODO" to support the > FilePathList[]. In fact, the code calls it "FilePath" to be clear that it is > assuming a single DevicePath (which means a 0xFF sub-type termination) > https://github.com/tianocore/edk2/blob/master/MdeModulePkg%2FLibrary%2FUefiBootManagerLib%2FBmLoadOption.c#L199 > > Searching the code further, I see there is support for parsing multi-instance > device path (separated by END_INSTANCE_DEVICE_PATH_SUBTYPE, or 0x1) in things > like UefiDevicePathLib , parsing code, etc... But it does not seem to be > supported at all in the UEFI Boot Manager implemented in EDK2 > > > > The UEFI variable ConDev is decribed as "The device path of all possible > > console > > input devices". The spec does not refer to it as an array of device paths. > > > > Looking at EDK2, ConXDev are treated as multi-instance devices, with > ConPlatformDxe using AppendDevicePathInstance() and > GetNextDevicePathInstance() to construct / navigate the multiple-instances > > The spec should have defined these as a "multi-instance device path of all > possible console X devices". See my notes below on multi-instance DP. > > > > So it seems that the UEFI spec editors mean by array of device paths that an > > element of the array is separated by sub-type 0xff. Each individual array > > element > > may be a collection of device paths instances separated by 0x01 sub-type end > > nodes. > > > > I am leaning towards this conclusion as well. This is further supported by > the following evidence: > Yes that's exactly what I thought as well and that's what option (2) was trying to describe on my first mail. What I had in there was: Loaded Image device path - end node - VenMedia - Initrd DP - end instance - (repeat) - Initrd DP - end node - other DPs > > * EFI_DEVICE_PATH_UTILITIES_PROTOCOL has a function called > IsDevicePathMultiInstance() along with walker functions > AppendDevicePathInstance(), GetNextDevicePathInstance(). The description of > these functions make it clear that the intention is to treat 0x01 as a > separator between multiple instances of device paths in a multi-instance > device path structure, with 0xff as the final end of DP indicator. For > example, AppendDevicePathInstance() is defined as: > > " This function creates a new device path by appending a copy of the > specified device path instance to a copy of the specified device path in an > allocated buffer. The end-of-device-path device node is moved after the end > of the appended device node and a new end-of-device-path-instance node is > inserted between." > > > * In EFI_USER_INFO , there are user info policy types that leverage the > device path definitions (such as EFI_USER_INFO_ACCESS_FORBID_LOAD), and they > are clear on distinguishing the term "multi-instance device path" from a > "series of UEFI device paths": > > "The record is a series of normal UEFI device paths (not multi-instance > device pa
Re: EFI_LOAD_FILE2 for initrd standardization
On 3/1/21 9:44 PM, Samer El-Haj-Mahmoud wrote: -Original Message- From: Heinrich Schuchardt Sent: Monday, March 1, 2021 2:39 PM To: Ilias Apalodimas ; Grant Likely Cc: Boot Architecture Mailman List ; Samer El-Haj-Mahmoud ; Ard Biesheuvel ; Leif Lindholm Subject: Re: EFI_LOAD_FILE2 for initrd standardization ... The UEFI spec knows two types of separators for device paths. Both have type 0x7F (End of Hardware Device Path) but differ by the sub-type: Sub-Type 0xff – End Entire Device Path Sub-Type 0x01 – End Instance of a Device Path Field EFI_LOAD_OPTION.FilePathList[] is described in the UEFI spec as follows: "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." It is not immediately clear if the separators between the array elements are of sub-type 0xff or 0x01. The description in the UEFI spec should be reworked for more clarity. Agree that this is not clear, and could be interpreted either way. And yes, agree the UEFI spec needs a clarification The current EDK II coding requires that the device path identifying the UEFI binary (i.e. FilePathList[0] is terminated by a sub-type 0xff end node. The EDK2 code seems to be incomplete, with a "TODO" to support the FilePathList[]. In fact, the code calls it "FilePath" to be clear that it is assuming a single DevicePath (which means a 0xFF sub-type termination) https://github.com/tianocore/edk2/blob/master/MdeModulePkg%2FLibrary%2FUefiBootManagerLib%2FBmLoadOption.c#L199 Searching the code further, I see there is support for parsing multi-instance device path (separated by END_INSTANCE_DEVICE_PATH_SUBTYPE, or 0x1) in things like UefiDevicePathLib , parsing code, etc... But it does not seem to be supported at all in the UEFI Boot Manager implemented in EDK2 The UEFI variable ConDev is decribed as "The device path of all possible console input devices". The spec does not refer to it as an array of device paths. Looking at EDK2, ConXDev are treated as multi-instance devices, with ConPlatformDxe using AppendDevicePathInstance() and GetNextDevicePathInstance() to construct / navigate the multiple-instances The spec should have defined these as a "multi-instance device path of all possible console X devices". See my notes below on multi-instance DP. So it seems that the UEFI spec editors mean by array of device paths that an element of the array is separated by sub-type 0xff. Each individual array element may be a collection of device paths instances separated by 0x01 sub-type end nodes. I am leaning towards this conclusion as well. This is further supported by the following evidence: * EFI_DEVICE_PATH_UTILITIES_PROTOCOL has a function called IsDevicePathMultiInstance() along with walker functions AppendDevicePathInstance(), GetNextDevicePathInstance(). The description of these functions make it clear that the intention is to treat 0x01 as a separator between multiple instances of device paths in a multi-instance device path structure, with 0xff as the final end of DP indicator. For example, AppendDevicePathInstance() is defined as: " This function creates a new device path by appending a copy of the specified device path instance to a copy of the specified device path in an allocated buffer. The end-of-device-path device node is moved after the end of the appended device node and a new end-of-device-path-instance node is inserted between." * In EFI_USER_INFO , there are user info policy types that leverage the device path definitions (such as EFI_USER_INFO_ACCESS_FORBID_LOAD), and they are clear on distinguishing the term "multi-instance device path" from a "series of UEFI device paths": "The record is a series of normal UEFI device paths (not multi-instance device paths)." * The "multi-instance" usage also shows up in the language of LocateDevicePath() So if the spec intended for FilePathList[] to use the 0x1 separator, they should have used the term "multi-instance" device path, which is not the case. In the device path spec a sentence could be added as follows: "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. *Each array element is terminated by a sub-type 0xff, End Entire Device Path node.*" Yes. Or could simply say: "A packed array of UEFI device paths (not multi-instance device paths). The first element of the array is a device Each array element except index 0 may be a multi-instance device path. path that describes the device and location of the Image for this load option." Either way, we can do a "code first" ECR in the UEFI spec. I say code first to ensure that it remains in public domain, and not blo
RE: EFI_LOAD_FILE2 for initrd standardization
> -Original Message- > From: Heinrich Schuchardt > Sent: Monday, March 1, 2021 2:39 PM > To: Ilias Apalodimas ; Grant Likely > > Cc: Boot Architecture Mailman List ; Samer > El-Haj-Mahmoud ; Ard Biesheuvel > ; Leif Lindholm > Subject: Re: EFI_LOAD_FILE2 for initrd standardization ... > > The UEFI spec knows two types of separators for device paths. Both have type > 0x7F (End of Hardware Device Path) but differ by the sub-type: > > Sub-Type 0xff – End Entire Device Path > Sub-Type 0x01 – End Instance of a Device Path > > Field EFI_LOAD_OPTION.FilePathList[] is described in the UEFI spec as > follows: > > "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." > > It is not immediately clear if the separators between the array elements are > of > sub-type 0xff or 0x01. The description in the UEFI spec should be reworked for > more clarity. > Agree that this is not clear, and could be interpreted either way. And yes, agree the UEFI spec needs a clarification > The current EDK II coding requires that the device path identifying the UEFI > binary (i.e. FilePathList[0] is terminated by a sub-type 0xff end node. > The EDK2 code seems to be incomplete, with a "TODO" to support the FilePathList[]. In fact, the code calls it "FilePath" to be clear that it is assuming a single DevicePath (which means a 0xFF sub-type termination) https://github.com/tianocore/edk2/blob/master/MdeModulePkg%2FLibrary%2FUefiBootManagerLib%2FBmLoadOption.c#L199 Searching the code further, I see there is support for parsing multi-instance device path (separated by END_INSTANCE_DEVICE_PATH_SUBTYPE, or 0x1) in things like UefiDevicePathLib , parsing code, etc... But it does not seem to be supported at all in the UEFI Boot Manager implemented in EDK2 > The UEFI variable ConDev is decribed as "The device path of all possible > console > input devices". The spec does not refer to it as an array of device paths. > Looking at EDK2, ConXDev are treated as multi-instance devices, with ConPlatformDxe using AppendDevicePathInstance() and GetNextDevicePathInstance() to construct / navigate the multiple-instances The spec should have defined these as a "multi-instance device path of all possible console X devices". See my notes below on multi-instance DP. > So it seems that the UEFI spec editors mean by array of device paths that an > element of the array is separated by sub-type 0xff. Each individual array > element > may be a collection of device paths instances separated by 0x01 sub-type end > nodes. > I am leaning towards this conclusion as well. This is further supported by the following evidence: * EFI_DEVICE_PATH_UTILITIES_PROTOCOL has a function called IsDevicePathMultiInstance() along with walker functions AppendDevicePathInstance(), GetNextDevicePathInstance(). The description of these functions make it clear that the intention is to treat 0x01 as a separator between multiple instances of device paths in a multi-instance device path structure, with 0xff as the final end of DP indicator. For example, AppendDevicePathInstance() is defined as: " This function creates a new device path by appending a copy of the specified device path instance to a copy of the specified device path in an allocated buffer. The end-of-device-path device node is moved after the end of the appended device node and a new end-of-device-path-instance node is inserted between." * In EFI_USER_INFO , there are user info policy types that leverage the device path definitions (such as EFI_USER_INFO_ACCESS_FORBID_LOAD), and they are clear on distinguishing the term "multi-instance device path" from a "series of UEFI device paths": "The record is a series of normal UEFI device paths (not multi-instance device paths)." * The "multi-instance" usage also shows up in the language of LocateDevicePath() So if the spec intended for FilePathList[] to use the 0x1 separator, they should have used the term "multi-instance" device path, which is not the case. > In the device path spec a sentence could be added as follows: > > "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. > *Each array element is terminated by a sub-type 0xff, End Entire Device Path > node.*" > Yes. Or could simply say: "A packed array of UEFI device paths (not multi-instance 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." Either way, we can do a "code first
Re: EFI_LOAD_FILE2 for initrd standardization
Hi Grant, On Fri, Feb 19, 2021 at 05:28:59PM +, Grant Likely wrote: > > > On 18/02/2021 11:15, Heinrich Schuchardt wrote: > > > [...] > > > 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/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. > > Attempting to paraphrase; does this mean the VenMedia component would be > used to identify the file type? i.e., use one GUID for initrd, and > another for DTB? Or is that worked out another way? Yea exactly (in all 3 implementations). The difference in the 3 different proposals is how to interpret that VenMedia device path to identify all the device paths that refer to that specific GUID. Regards /Ilias > > g. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EFI_LOAD_FILE2 for initrd standardization
On 18/02/2021 11:15, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/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. Attempting to paraphrase; does this mean the VenMedia component would be used to identify the file type? i.e., use one GUID for initrd, and another for DTB? Or is that worked out another way? g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EFI_LOAD_FILE2 for initrd standardization
On 18.02.21 17:27, Simon Glass wrote: > Hi Heinrich, > > On Thu, 18 Feb 2021 at 04:15, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/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. It is better readable then a hex string and conforms to the output format defined by the UEFI spec. Just use 'efibootmgr -v' to display your Boot variables in Linux or use the UEFI shell command 'dh' to display handles and you will find the same format. When defining the boot variable with efibootmgr you use a Unix style path and in U-Boot we use something like mmc 0:1 /vmlinux. Best regards Heinrich ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EFI_LOAD_FILE2 for initrd standardization
Hi Heinrich, On Thu, 18 Feb 2021 at 04:15, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EFI_LOAD_FILE2 for initrd standardization
On Thu, Feb 18, 2021 at 02:23:02PM +0100, Heinrich Schuchardt wrote: > On 2/18/21 1:11 PM, Ilias Apalodimas wrote: > > On Thu, Feb 18, 2021 at 12:15:30PM +0100, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd2) > > > > > > The device path end nodes of sub-type 0x01 are rendered as commas. > > > > That interpretation is a bit different from what I have. > > The separation between initrd files is denoted by the end of instance, not > > the > > end node with end of a device path (Sub-Type 0xFF). > I explicitly wrote sub-type *0x01*. Yes and that's exactly what I am pointing out on the sentence above. The real point in on the sentence right after that and the interpretation of the EFI spec. > > > The EFI spec says > > "Each element in the array is variable length, and ends at the device path > > end > > structure" so I assume we can use either? I initially thought it meant > > Sub-Type = 0xFF. > > > > > > > > With 1 and 2 this would show a readable output like above. > > > With 3 you will just see a
Re: EFI_LOAD_FILE2 for initrd standardization
On 2/18/21 1:11 PM, Ilias Apalodimas wrote: On Thu, Feb 18, 2021 at 12:15:30PM +0100, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd2) The device path end nodes of sub-type 0x01 are rendered as commas. That interpretation is a bit different from what I have. The separation between initrd files is denoted by the end of instance, not the end node with end of a device path (Sub-Type 0xFF). I explicitly wrote sub-type *0x01*. The EFI spec says "Each element in the array is variable length, and ends at the device path end structure" so I assume we can use either? I initially thought it meant Sub-Type = 0xFF. 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. Not really. The whole point is that you'll have a single VenMedia indicating the start of the initrd device paths. Those are not separated by the end node (0xFF), but by the end of instance. Once you see an end node it's not an initrd filepath anymore. So you dont really need the number of elements in there. Both in suggestions 1 and 2 individual initrd device paths are separated by end nodes of sub-type 0x01. You make the assumption that nothing follows the last initrd path. But we may want to add additional device paths, e.g. for the device-tree. This is why we should not assume that an end node of sub-type 0xFF follows the last initrd device-patch. Best regards Heinrich In any case (1) is easier to code as well, since it practically allows you to append a DP,
Re: EFI_LOAD_FILE2 for initrd standardization
On Thu, Feb 18, 2021 at 12:15:30PM +0100, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd2) > > The device path end nodes of sub-type 0x01 are rendered as commas. That interpretation is a bit different from what I have. The separation between initrd files is denoted by the end of instance, not the end node with end of a device path (Sub-Type 0xFF). The EFI spec says "Each element in the array is variable length, and ends at the device path end structure" so I assume we can use either? I initially thought it meant Sub-Type = 0xFF. > > 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. Not really. The whole point is that you'll have a single VenMedia indicating the start of the initrd device paths. Those are not separated by the end node (0xFF), but by the end of instance. Once you see an end node it's not an initrd filepath anymore. So you dont really need the number of elements in there. In any case (1) is easier to code as well, since it practically allows you to append a DP, instead of search - append instance - copy the remaining DP, which will makje our lives easier. Regards /Ilias > > With 1 you can individually determine
Re: EFI_LOAD_FILE2 for initrd standardization
+1 On Thu, 18 Feb 2021 at 12:15, Heinrich Schuchardt 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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/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
Re: EFI_LOAD_FILE2 for initrd standardization
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,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/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
Re: EFI_LOAD_FILE2 for initrd standardization
Hi Francois, On Thu, Feb 18, 2021 at 11:31:42AM +0100, François Ozog wrote: > On Thu, 18 Feb 2021 at 10:04, Ilias Apalodimas > wrote: > [...] > > 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. > > > > this is from "10.3.2.4 Vendor Device Path" in UEFI spec right ? Yes that's what I had in mind [...] Regards /Ilias ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: EFI_LOAD_FILE2 for initrd standardization
On Thu, 18 Feb 2021 at 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. > > this is from "10.3.2.4 Vendor Device Path" in UEFI spec right ? 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 > > > 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
EFI_LOAD_FILE2 for initrd standardization
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 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
