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. > > > 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. > 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? -- Tom
signature.asc
Description: PGP signature
