On Tue, Mar 12, 2019 at 02:42:02PM +0100, Wolfgang Denk wrote: > Dear Tom, > > In message <20190312121957.GI4690@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
