From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 14 Jan 2016 13:48:51 -0700 Subject: [U-Boot] [U-Boot, v7, 2/2] arm: move gd handling outside of C code In-Reply-To: <20160114194555.GO3359@bill-the-cat> References: <1448470593-23998-2-git-send-email-albert.u.boot@aribaud.net> <20160114132044.GE3359@bill-the-cat> <5697EA7B.8000204@wwwdotorg.org> <20160114191158.GM3359@bill-the-cat> <5697F686.7010707@wwwdotorg.org> <20160114194555.GO3359@bill-the-cat> Message-ID: <569809B3.20606@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>>> Reviewed-by: Simon Glass >>>>> >>>>> 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).