-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/03/12 17:19, Simon Glass wrote: > Hi Graeme, > > On Mon, Dec 3, 2012 at 2:02 PM, Graeme Russ <graeme.r...@gmail.com> > wrote: >> Hi Tom, Simon, Wolfgang, >> >> On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini <tr...@ti.com> wrote: >>> On Tue, Nov 20, 2012 at 06:06:30AM -0800, Simon Glass wrote: >>>> Hi Wolfgang, >>>> >>>> On Mon, Nov 19, 2012 at 11:25 PM, Wolfgang Denk <w...@denx.de> >>>> wrote: >>>>> Dear Simon Glass, >>>>> >>>>> In message >>>>> <1353100842-20126-1-git-send-email-...@chromium.org> you >>>>> wrote: >>>>>> The previous generic board series hit a snag in that we >>>>>> needed generic code to access some of the >>>>>> architecture-specific fields in global_data. >>> [snip] >>>>> - The change makes the code less readable. Reading >>>>> "gd->arch." instead of plain "gd->" is no improvements, but >>>>> rather vice versa. If we really go this way, this should be >>>>> improved. >>>> >>>> Yes it would be nice. Are you suggesting some sort of macro, >>>> or something else? >>> >>> Wolfgang? "global data, architecture specific goo, ..." reads >>> fine and helpful to me, honestly. >> >> I've mentioned this before - I think gd is being abused. To me, >> gd should contain only data members that are explicitly required >> prior to SDRAM being initialised and BSS being available. It has >> become a bit of a 'well I need this variable everywhere, I'll >> dump it in gd'. >> >> 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?).
At the high level, yes, such a cleaning of gd and perhaps even a re-evaluation of what kind of "global data" structure we need to keep around for the whole run time is warranted. And the gd->arch->foo would be a good place to start looking for shouldn't be in gd at all candidates. But that's not a blocker, to me, for this series, since it will help show the problems. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQvThOAAoJENk4IS6UOR1WWowQALLMLDuRC+YnfTDy0AMPhMCo iasdqmyQRBBKXU/3o3D6EbOiiYxmmwrWEElJ6E1L3MiJknHz+P0vXJ0ec3DOo1BR 2B7hTMZewiDPGnJ7oREQAFXL2pW1hWKkYPwy/EQwz7RLncKM5+lAfwyuc4c2BFSH oRYEKglQYCj/VO0H85vuS6BrBKrhdUOzq0AHebaxUnxPX0ZsBCqDesYjxViWVKZy 5Hw3ukqQYFTjl4P3/Ss9IcPkctbp/LWtRpq+vCNLuNee6UHuICz0Ws5wRySsoMpw AE14EfVXn+N0QsMzm5fWQtCoXDe2J0+UD5qUXnMBUjf3VvlA0OnosHkYl/jOeuu0 oumHcf/YfHvoJpGDuwf2potshB5dlhzLRi4p86Gm/EPpL53zeqKvNJZJEmH70JPd tKGEMN3RKwPUKzjM8TmaNlGl4HOlxnG4u3qe0DQsAB4rz39z86J/GS0xPzXcuDXO MFOx+R6bpDtHk6I8YoqiERAReS20ppVi6ktMOUYpysdJjlyIqQ9qUvZChdm7Xx/J 7H7KW3W12z09k+IbexX4Bmv/2m+HNeeN1NgiD10erzFrLxeXZgxSoJ7P+II07aOm tv483hTErPR0kPS4/oHrfxg1SGEQfCP9c9020RFspVl8ZcoRIuPam8H1RO+Hlzxl Jhw9kwC54Dlcrthbk9/F =3MpI -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot