[U-Boot] [PATCH] Revert "ARM: SPL: do not set gd again"

[Simon Glass]

Hi Tom,

On 11 November 2014 14:57, Tom Rini <trini at ti.com> wrote:
> On Mon, Nov 10, 2014 at 03:13:44PM -0700, Simon Glass wrote:
>> +Albert
>>
>> Hi Tom,
>>
>> On 16 September 2014 18:47, Tom Rini <trini at ti.com> wrote:
>> >
>> > On Tue, Sep 16, 2014 at 08:27:23PM -0400, Tom Rini wrote:
>> >
>> > > At the high level, the problem is that we set gd multiple times (and
>> > > still do, even after the commit we're reverting).  We set important
>> > > parts of gd to the copy which is not above stack but rather in the data
>> > > section.  For the release, we're going to revert this change and for the
>> > > next release we shall correct things to only, really, set gd once to an
>> > > appropriate location and ensure that comments about it are correct too.
>> > >
>> > > This reverts commit f0c3a6c4ad09210d5d4aeafe87685ee75e5683d6.
>> > >
>> > > Acked-by: Albert Aribaud <albert.u.boot at aribaud.net>
>> > > Signed-off-by: Tom Rini <trini at ti.com>
>> >
>> > Applied to u-boot/master, thanks!
>>
>> Is this going to be un-reverted? I will need this done to apply the
>> driver model SPL series.
>
> So I've got am335x working again locally and now I'm trying to see if we
> need to introduce a SoC-specific board_init_f for SPL here or not or if
> I can shove save_omap_boot_params() into spl_board_init() and add
> preloader_console_init rather generically to the ARM board_init_f SPL
> function.  Once I've got this clean enough I need to dust off some
> davinci and omap3 targets, do similar changes and then see if Hans was
> right about why my olimex Allwinner board was behaving badly, and if so,
> test the changes there too.  That'll cover most of the ARM boards that
> re-set gd themselves when they can't with the above change
> re-introduced.

OK thanks. I might pull in some of the non-dependent patches in the meantime.

Regards,
Simon