Dear Tom,
In message 20190312140417.GJ4690@bill-the-cat you wrote:
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 think you were misled by Heiko's description. What he really ment was just that the addresses where the boot ROM stored the information about the boot device etc. gets overwriteen when the SPL sets up his stack. This is what Heiko meant when he wrote: "On am437x the bootmode info get overwritten from SPL stack." But at that time the SPL has already loaded this information and maintains it elsewhere.
I am not aware of any other problems. Of course one has to re-think where to place the GD - but this is the same problem as when using the bloblist and spl_handoff data.
I just feel it makes a lot of sense to use an existing mechanism across all the boot stages SPL -> ( TPL -> ) U-Boot before relocation -> U-Boot after relocation, instead of implementing several different hooks for the same purpose.
[And yes, it might be also time to clean up GD from a lot of mess that has accumulated there over the last decade. I doubt many of these data are really needed there. But that's another topic, IMO.]
Best regards,
Wolfgang Denk