From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Date: Wed, 21 May 2014 16:34:38 +0100 Subject: [U-Boot] Booting armv8 kernel on uboot In-Reply-To: <20140521152853.GC1752@bill-the-cat> References: <1400661995829-180377.post@n7.nabble.com> <20140521094038.GC17827@leverpostej> <20140521152853.GC1752@bill-the-cat> Message-ID: <20140521153438.GI17827@leverpostej> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.