Hi Tom, On Tue, Dec 4, 2012 at 10:39 AM, Tom Rini <tr...@ti.com> wrote: > -----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.
I agree. While gd->arch does look a bit 'ugly', it immediately unlocks the path forward to unifying the init loop. The x86 board.c would be a good start (IMNSHO) by simply making the init sequence arrays extern. >From there we can tackle what really needs to be in gd and what can simply be run of the mill global variables. I think most of what is under gd->arch may just 'fall out' Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot