From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Thu, 11 Mar 2021 13:44:05 +0100 Subject: [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot#### In-Reply-To: References: <20210305222303.2866284-1-ilias.apalodimas@linaro.org> <20210305222303.2866284-2-ilias.apalodimas@linaro.org> <3b72f7c0-5fc5-5dc9-c93f-43c40de9bdd4@gmx.de> <3c7bca26-b4d6-88c5-611a-aaca1f224d39@gmx.de> <70AA1ED8-9F73-4D50-891A-1FCB855F7094@gmx.de> <09eb1814-05fe-2b97-af85-a6843082cac7@gmx.de> Message-ID: <2a3425ba-87f1-8ff3-83a1-df2cc8d5e75a@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11.03.21 13:39, Ilias Apalodimas wrote: > Hi Heinrich, > > [...] >>>> No, the structure is added in cmd/efidebug.c code. >>>> It's created with efi_dp_append_instance() on >>>> - const struct efi_initrd_dp id_dp >>>> - file path of initrd >>>> >>>> which will create: >>>> kernel path,end(0xff), >>>> VenMedia(), end(0x01), >> >> This end node is superfluous. > > Why?i It's not defined in any standard (in fact these patches will be used for > the USWG proposal), it's making our lives a lot easier during parsing, since > you only need to get the next instance for the *entire* device path. > On the other hand if you mix and match them, you'll have to skip the first > entry with dp->len and then start using code to get the next instance. Similar > logic applies to appending the instance obviously. Since you now how have to > account for your 'special' first node, which isn't that special to begin with. > > So why exactly is it superflous? Because you can get the next initrd without > having to parse an end of instace? Well that's the case for the initrd's as > well then .... > On the contrary I think it makes the entire device path look more generic, > since each node is separated by an end of instance, no matter what the > contents are. We use the VenMedia() node to identify a multi-part device tree containing one or multiple initrd. An end node does not convey any additional information. The first initrd device path can start directly behind the VenMedia() node. This saves space for non-volatile variables which is limited. Best regards Heinrich > > Thanks > /Ilias > >> >> Best regards >> >> Heinrich >> >>>> initrd1, end(0x01), >>>> initrd2, end(0xff) >>>> >>>> I know I originally proposed the one you have, but it seemed cleaner >>>> adding >>>> an extra instance between VenMedia and the first initrd. >>>> >>>>> >>>>> Please, document the structure. >>>>> >>>> >>>> Sure >>>> >>>>> Best regards >>>>> >>>>> Heinrich >>>> >>>> Thanks >>>> /Ilias >>> >>