Dear Simon Glass,
In message CAPnjgZ2KVHV6JCvOjiQBrXFCfHMeWfEfj9bLHFw_Qyf5_7dj8Q@mail.gmail.com you wrote:
To be honest, I think gd should only be a temporary structure used to carry specific data through the initialisation process up to the point BSS becomes available. With the 'early malloc' patches in the pipeline, it might even be possible to malloc the gd structure early and then when BSS is available, copy the data into the final global data structure in BSS. I think that would be complicated by functions that need to use gd both before and after BSS becomes available.
I mostly agree, but that sounds like an exercise in removing fields from the gd one by one in the source code. The bit I am not sure of is whether it is useful for gd to hang around post relocation to provide access to the data that was decided on early in boot (after all, the position in memory of gd changes post relocation, so why maintain two structures for the same info?).
Sure. If you look back how this developed, then initially there was only struct bd_info. Then it turned out that it costs too much of code size (and performance, actually) to pass around the same struct as parameter to about each and every functiuon, so I invented GD - wit the intention to drop it as soon as writable global data becomes available, i. e. after relocation. I even think the first versions worked that way. Only later that code code optimized because it seemed easier to keep this struct and be able to use the same code before and after relocation. And open Pandora's box was...
Best regards,
Wolfgang Denk