On Tue, Apr 29, 2025 at 08:33:16AM -0600, Simon Glass wrote: > Hi Raymond, > > On Mon, 28 Apr 2025 at 08:41, Raymond Mao <raymond....@linaro.org> wrote: > > > > Hi Simon, > > > > On Thu, 17 Apr 2025 at 14:16, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > This series adds a standard way of passing information between different > > > firmware phases. This already exists in U-Boot at a very basic level, in > > > the form of a bloblist containing an spl_handoff structure, but the intent > > > here is to define something useful across projects. > > > > > > The need for this is growing as firmware fragments into multiple binaries > > > each with its own purpose. Without any run-time connection, we must rely > > > on build-time settings which are brittle and painful to keep in sync. > > > > > > This feature is named 'standard passage' since the name is more unique > > > than many others that could be chosen, it is a passage in the sense that > > > information is flowing from one place to another and it is standard, > > > because that is what we want to create. > > > > > > The implementation is mostly a pointer to a bloblist in a register, with > > > an extra register to point to a devicetree, for more complex data. This > > > should cover all cases (small memory footprint as well as complex data > > > flow) and be easy enough to implement on all architectures. > > > > > > The emphasis is on enabling open communcation between binaries, not > > > enabling passage of secret, undocumented data, although this is possible > > > in a private environment. > > > > > > This series is available at u-boot-dm/pass-working > > > > > > > First of all, can you group those patches which are necessary for > > refactoring the "passage" concept into a smaller series for an easy > > review? > > What do you mean by refactoring? I don't believe my series has much > value unless it actually brings in 'standard passage' and everything > that goes with that, e.g. the validation and documentation. > > > > > Actually as I mentioned in our previous discussions, I don't agree to > > add a OF_BLOBLIST as this is duplicated with "BLOBLIST + > > BLOBLIST_PASSAGE_MANDATORY (aka PASSAGE_IN in the context of your > > patch - I am not sure the reason you prefer to rename it - do we have > > any other passage approaches other than using bloblist? And do you > > have any considerations to allow a fallback or not in case passage > > failures?)" > > This is how I would like it to work, i.e. that one specifically > chooses OF_BLOBLIST. This split of bloblib and whether or not it is > mandatory is just confusing. > > > > > Secondly I prefer to keep the register convention code as a xferlist > > library that can be used for arm arches other than split them into > > different low level assemblies. In case of any firmware handoff > > specification update, we just need to maintain this library. > > I don't agree with that, sorry. This should be a standard feature of > U-Boot. It is easier to update three 'store' instructions in the > assembler than to figure out what is going on with the xferlist > functions. They are really just an obfuscation from the Arm point of > view, the only current implementer of the spec. > > I have tried my series with your QEMU things but it doesn't work. So I > went back to try your original instructions with your series and it > didn't work either. Would it be possible for you to get the pending > patches in the other projects submitted and then send me an update re > the instructions? I would like to get the environment running again, > but there are too many moving parts at present.
What I want to highlight here and now is that vexpress_fvp_bloblist also uses standard passage and can be added to CI now: https://patchwork.ozlabs.org/project/uboot/patch/20250422193657.512324-1-tr...@konsulko.com/ I will apply this later today I think. -- Tom
signature.asc
Description: PGP signature
