[U-Boot] passing info from SPL to U-Boot

[Simon Glass]

Hi Wolfgang,

On Sun, 17 Mar 2019 at 20:01, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ05B7qB0JJn6=cStyW6tj_i5jBZQwEAxTDF-fMp8NHeOQ at mail.gmail.com> you wrote:
> >
> > > First, we have GD, which exists since the dawn of U-Boot, which was
> > > intended to pass data between boot stages (by then, before and after
> > > relocation), but apparently it has never been used for passing
> > > information between SPL and U-Boot proper.
> >
> > That's right. It is always zeroed these days at the start of each
> > phase. So I think work is needed if we want to use this.
>
> Yes, of course.  I just want to make sure we have agreement in which
> direction we should move.

Yes that's the main thing.
>
>
> > Also I don't think we can assume that gd stays in the same place
> > through all phases of U-Boot. Probably we can keep it in the same
> > place in TPL, SPL and U-Boot pre-relocation, then move it to SDRAM
> > during relocation.
>
> Correct - it has never been a requirement that GD remains in place -
> just that the pointer that is being passed points to valid data.
> The currentimplementation already allows to move the GD from some
> restricted resource (like on-chip-RAM or cache) to SDRAM as soon as
> it becomes available.

OK, make sense. We should make sure it is documented when this work is done.

>
>
> > > Then you added the bloblist thingy.  It's not really clear what it's
> ...
> > This is designed for things that need to past structs between phases.
> > For example, verified boot may start processing in TPL and then pass
> > information to SPL and then to U-Boot proper. This may involve quite a
> > bit of info, so it is in a C structure. It isn't really suitable to
> > put this entire structure in gd IMO, since that struct is pretty
> > small.
>
> So what is your recommendation?  Shall we use GD and bloblists side
> by side?  Shall the GD just contain the lob list pointer?

I think that makes sense but I suspect things will become clearer over
time. GD already has a bloblist pointer, but it is reinited in every
phase. We can fix that once the GD pass-through is implemented.

>
> Or shall we move all things have been thrown (without much thought,
> as it seems) into GD to smaller structs and convert to blobs, so the
> GD pointer actually becomes a pointer to the blob list (which would
> increase code and executin time, I'm afraid).
>
> What is your recommendation?

A scan of GD suggests that everything there is pretty small, generally
a ulong or a pointer. I suppose if we had rarely access stuff we could
package it up and put it in a bloblist, but I don't see a lot of
benefit to that. As you say, there is a cost. So I'd suggest leaving
GD as it is for now.

>
> > The version, magic and checksum are to ensure that the data is not
> > corrupted by mistake, which as you know can happen very easily with
> > fixed-position data structures. The search is pretty quick once the
> > checksum is done, just running through a few pointers. I suppose we
> > could make the checksum optional.
>
> But still it is another increase in code size - as is, for accessing
> a field in GD we just dereference a pointer which is already in a
> register; for a blob list, we need to call (at least) a function...

Yes GD is much more efficient.

One thing to note with bloblist is that changing anything in it makes
it invalid for the next phase, until the checksum is recalculated
(which happens at the end of each phase).

>
> > > An then there is commit b0edea3c27 with the spl_handoff thing.  I
> ...
> > That actually uses the bloblist, putting an SPL struct in there,
> > intended to hold things like the SDRAM config or boot options
> > discovered in SPL. At present we have a few ad-hoc ways of
>
> Again: this is exactly what GD was intended for - now we have more
> than one implementation and should decide what to do...

Right but here I think we have a use case. For example, if exynos
wants to store its RAM config from SPL and pass it to U-Boot, that
might be 100 bytes. Also it means putting arch-specific stuff in GD.
Perhaps bloblist is a better place for that.

>
> > > And finally there is bootstage with it's own mechanism of
> > > information passing.
> >
> > Yes, and this is ad-hoc too. I would like to move it to bloblist.
>
> So bloblist would be the way to go for GD, too?

No, I mean that bootstage data should go in a bloblist. I don't think
we should get rid of GD.

>
> > > Can we not unify these, and use one common method, please?
> >
> > I think we might end up with gd (once this work is done) and bloblist.
> > For now I feel that bloblist has a purpose but let's see how it goes
> > with the gd work.
>
> Why do we need GD _and_ bloblist?   I would like to have one
> solution only.

Well, my thinking is that GD is actually a set of pointers, with the
actual data stored elsewhere. The nice thing about bloblist is that it
is a contiguous block of a set size, which holds data used by
different parts of U-Boot (e.g. could be drivers, arch-specific code,
vboot, features like android boot, EFI, etc.). Some of the pointers in
GD could move to bloblist, like bootstage as already discussed.

But if you want one solution, then it has to be GD I think. Perhaps we
can defer this until the GD work is done and we have a few more users?

Regards,
Simon