[U-Boot] Booting armv8 kernel on uboot

[Mark Rutland <mark.rutland@arm.com>]

On Wed, May 21, 2014 at 04:28:53PM +0100, Tom Rini wrote:
> On Wed, May 21, 2014 at 10:40:38AM +0100, Mark Rutland wrote:
> > On Wed, May 21, 2014 at 09:46:35AM +0100, Vishal Bhoj wrote:
> > > Hi ,
> > 
> > Hi,
> > 
> > > I have added mmc driver into the vexpress64 board file for uboot and tested
> > > it on FVP base model. I tried booting a kernel on that but it is aborting
> > > with the following message:
> > > Final value for argc=3
> > >    Loading Kernel Image ... OK
> > >    kernel loaded at 0x00080000, end = 0x00827024
> > > using: FDT
> > >    reserving fdt memory region: addr=80000000 size=10000
> > > ## initrd_high = 0xffffffffffffffff, copy_to_ram = 1
> > >    ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
> > > ## device tree at 0000000090008000 ... 000000009000a850 (len=22609 [0x5851])
> > >    Loading Device Tree to 000000009fffa000, end 000000009ffff850 ... OK
> > > Initial value for argc=3
> > > Final value for argc=3
> > > ## Transferring control to Linux (at address 80000)...
> > > Starting kernel ...
> > > 
> > > "Synchronous Abort" handler, esr 0x02000000
> > 
> > That ESR_ELx value means Unknown/uncategorized. It would be fantastic if
> > U-Boot would tell us what EL it's branching to the kernel at as a matter
> > of course -- it's not really possible to debug from logs otherwise.
> > 
> > Which EL are you loading the kernel at?
> 
> So, this I suspect is one of the problems I was trying to describe to
> you back at ELC which turned out to be loading things at the very wrong
> address (0x80000 rather than 0x80080000).

That would certainly explain it. From the lines above stating that the
kernel had been loaded to 0x80000 I assumed that memory had been
configured there.

> 
> Vishal, cay you apply:
> http://patchwork.ozlabs.org/patch/345746/
> http://patchwork.ozlabs.org/patch/345748/
> http://patchwork.ozlabs.org/patch/345749/
> http://patchwork.ozlabs.org/patch/345747/
> 
> I need to do a v2 still to address some feedback, and then also say we
> require Mark's recent series to add an image size field (and other
> cleanups) and make use of that (and the rest of the series
> changes/clarifications).

I'll try to get a v2 out on my series shortly, it'd be nice to have as
soon as possible. :)

Cheers,
Mark.