From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Tue, 4 Dec 2012 10:45:18 +1100 Subject: [U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure In-Reply-To: <50BD384F.7030201@ti.com> References: <1353100842-20126-1-git-send-email-sjg@chromium.org> <20121120072517.295652003D0@gemini.denx.de> <20121203145414.GE15777@bill-the-cat> <50BD384F.7030201@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On Tue, Dec 4, 2012 at 10:39 AM, Tom Rini 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 >> wrote: >>> Hi Tom, Simon, Wolfgang, >>> >>> On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini 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 >>>>> wrote: >>>>>> Dear Simon Glass, >>>>>> >>>>>> In message >>>>>> <1353100842-20126-1-git-send-email-sjg@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.