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

[Tom Rini]

On Tue, Mar 12, 2019 at 02:42:02PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20190312121957.GI4690 at bill-the-cat> you wrote:
> > 
> > > Yes, doable ... but the question is more, do we really want to read
> > > such infos twice, instead reading them in SPL and passing them from
> > > SPL to U-Boot ?
> >
> > Probably so, yes.  Since we're talking about SPL and a "lots of
> > features, medium sized SRAM" SoC where we've had to carefully tweak
> > configs before to get all desired features within the limits.  If you've
> > bled into SRAM_SCRATCH_SPACE_ADDR range you may run into other problems
> > too.
> 
> I think you misunderstand.
> 
> Heiko is not asking for any new data,  We are already using the 
> struct global_data in SPL.  And actually this is also where Simon
> added the pointers for the bloblist and the spl_handoff data.
> 
> The question is - why do we actually _need_ this spl_handoff, why
> don;t we just make sure the global_data is passed from SPL (to TPL
> and from there) to U-oot proper?
> 
> We already have reserved this memory, we already have all needed
> information, so why not just passing this on instead of throwing it
> away?
> 
> this will not grow data size, and it will not require any additional
> code size compared to the spl_handoff stuff, which then would be no
> longer needed (if I understnad the code correctly).

To answer that, no, I don't suppose there's a problem with auditing the
code to make sure that we can pass in gd, rather than U-Boot proper
assuming it's the first thing to touch gd, if configured.  But that to
me is a different ball of wax.  On this SoC, if you're at the point
where you're trampling over the defined scratch space that is used for
other things that need scratch space, you may have other problems too.
I would swear the EEPROM reading stuff makes use of that but I suspect
your platform doesn't bother with that path at all.  The other thing
that may bite you is the stuff around hw_data.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190312/94cc1e10/attachment.sig>