[U-Boot] [U-Boot, v7, 2/2] arm: move gd handling outside of C code

[Stephen Warren]

On 01/14/2016 12:45 PM, Tom Rini wrote:
> On Thu, Jan 14, 2016 at 12:27:02PM -0700, Stephen Warren wrote:
>> On 01/14/2016 12:11 PM, Tom Rini wrote:
>>> On Thu, Jan 14, 2016 at 11:35:39AM -0700, Stephen Warren wrote:
>>>> On 01/14/2016 06:20 AM, Tom Rini wrote:
>>>>> On Wed, Nov 25, 2015 at 05:56:33PM +0100, Albert ARIBAUD wrote:
>>>>>
>>>>>> As of gcc 5.2.1 for Thumb-1, it is not possible any
>>>>>> more to assign gd from C code, as gd is mapped to r9,
>>>>>> and r9 may now be saved in the prolog sequence, and
>>>>>> restored in the epilog sequence, of any C functions.
>>>>>>
>>>>>> Therefore arch_setup_gd(), which is supposed to set
>>>>>> r9, may actually have no effect, causing U-Boot to
>>>>>> use a bad address to access GD.
>>>>>>
>>>>>> Fix this by never calling arch_setup_gd() for ARM,
>>>>>> and instead setting r9 in arch/arm/lib/crt0.S, to
>>>>>> the value returned by board_init_f_alloc_reserve().
>>>>>>
>>>>>> Signed-off-by: Albert ARIBAUD <albert.u.boot at aribaud.net>
>>>>>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>>>>
>>>>> Applied to u-boot/master, thanks!
>>>>
>>>> FYI, this commit causes U-Boot to fail (crash or hang during very
>>>> early startup with zero UART output) on at least an NVIDIA Jetson
>>>> TX1 (p2371-2180) board. Reverting just this in u-boot/master solves
>>>> the issue. I have not tested other boards or looked at the code
>>>> itself yet.
>>>
>>> Is that one of the systems where we have an ARM9 and then a Cortex-A?
>>> FWIW, my pandaboard is up in Fedora currently.  I'm trying to do some
>>> boot testing on what I have more often and then a bigger round of
>>> unboxing and testing at -rc1/release time.
>>
>> This board is AArch64. There's no SPL or dual-architecture U-Boot on
>> this system; a boot CPU runs the boot ROM and and NVIDIA binary
>> bootloader which loads U-Boot from disk and sets up the main CPU,
>> then the main ARM CPU essentially jumps straight into the main
>> U-Boot binary.
>
> Oh, it's one of the aarch64 ones, OK.  Yeah, I need to get some for that
> architecture in my setup.  It's annoyingly complex to get hikey flashed
> but I can get my hands on a dragonboard soon, so once that's in I'll be
> using that.

FWIW, I've also now validated that the issue doesn't affect at least one 
of the 32-bit boards I have (Jetson TK1, which does have the 
dual-architecture SPL-vs-main U-Boot build).