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.b...@aribaud.net>
Reviewed-by: Simon Glass <s...@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.
For more precise details, see:
ftp://download.nvidia.com/tegra-public-appnotes/t210-nvtboot-flow.html
or a bunch of stuff accessible from the following for more background:
ftp://download.nvidia.com/tegra-public-appnotes/index.html
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
