[U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure

[Graeme Russ]

Hi Tom,

On Tue, Dec 4, 2012 at 10:39 AM, Tom Rini <trini at 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.russ at gmail.com>
>> wrote:
>>> Hi Tom, Simon, Wolfgang,
>>>
>>> On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini <trini at 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 <wd at denx.de>
>>>>> wrote:
>>>>>> Dear Simon Glass,
>>>>>>
>>>>>> In message
>>>>>> <1353100842-20126-1-git-send-email-sjg at 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.