Hi Tom, On Wed, 30 Apr 2025 at 08:29, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Apr 30, 2025 at 07:55:01AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 29 Apr 2025 at 11:11, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Mon, Apr 28, 2025 at 10:41:25AM -0400, Raymond Mao 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? > > > > > > > > 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?)" > > > > > > As preamble, I am actively working to push the changes for > > > vexpress_fvp_bloblist to be available in CI and so provide an easier > > > testing path. > > > > > > At the high level, I don't see what the difference is between "BLOBLIST > > > + BLOBLIST_PASSAGE_MANDATORY" and "BLOBLIST + OF_BLOBLIST" or "BLOBLIST > > > + whatever v4 of this series ends up showing". Everyone seems wildly in > > > agreement that if the prior stage is supposed to give us information > > > then it must have done so. > > > > > > One of the long running "jokes" in computer science about naming being > > > one of the hardest problems applies here, too. > > > > I want to use OF_BLOBLIST as it clearly indicates that the devicetree > > comes from a bloblist. The BLOBLIST_PASSAGE_MANDATORY thing is a > > work-around to try to avoid having OF_BLOBLIST. > > Or: > Other people want to use BLOBLIST_PASSAGE_MANDATORY as it clearly > indicates that the standard passage will be present and so include the > devicetree and any other required logs/blobs/content. The OF_BLOBLIST > thing is a work-around to try and avoid having > BLOBLIST_PASSAGE_MANDATORY. > > It's a naming problem and I don't care as long as we end up with an > implementation that's useful. And *that* is where my list of what > bloblist needs to have, in the end, comes from.
My approach does the same thing, but allows my x86 boards to work without all the confusion. It shows fdt coming from 'standard passage' when it is. > > > > > 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. > > > > > > Yes, if things can be written in a C file, they should be in a C file, > > > not assembler. > > > > In this case I disagree and if you look at the x86 code, this kind of > > approach is just not sensible. Please take a look at the contortions > > of xferlist_from_boot_arg(). It was written for one architecture only, > > yet purports to be a general API. My approach is simpler. Also, if > > save_boot_args() is implemented by the board, then standard passage > > will be broken for that board. It's a weak function! > > I don't see why this has to be in assembly and not C, no. And it's a > weak function because it doesn't yet exist on other architectures and > everyone hates #if. We just don't need it, though. If you would like this to work on x86, it needs to go. > > > More generally, please decide if you are willing to let me maintain > > bloblist. > > Can you be given substantive feedback? Or is only trivial feedback > allowed? I'm happy to discuss it on a call, but if you insist on BLOBLIST_PASSAGE_MANDATORY, then it is going to be tricky. The OF_BLOBLIST thing has consumed far too much time. If you want Linaro to maintain bloblist, please just say so. I had thought you were OK with my taking that on again. Regards, SImon
