[U-Boot] Booting armv8 kernel on uboot

[Vishal Bhoj]

Hi,


On 22 May 2014 18:09, Tom Rini <trini at ti.com> wrote:

> On Thu, May 22, 2014 at 11:18:24AM +0530, Vishal Bhoj wrote:
> > Hi,
> >
> > Thanks for the inputs.
> >
> >
> > On 21 May 2014 21:04, Mark Rutland <mark.rutland at arm.com> wrote:
> >
> > > 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/
> > > >
> > >
> > Included these patches.
> >
> > > > 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).
> > >
> > Can you please share the patches. I am currently booting 3.10 Linaro
> stable
> > kernel which works with ARM's trusted firmware + UEFI. The same kernel
> with
> > the above patches doesn't boot on u-boot. Is there any specific kernel
> tree
> > you suggest I should use which is known to boot on uboot + models ?
> >
> > I have generated uImage with loadaddress as 0x80080000 and tried booting
> > but doesn't boot. Here are the logs:
> > http://pastebin.com/T882rK3P
>
> What are your bootargs?  Can you add in earlyprintk=pl011,0x1c090000
> consolelog=9 ?
>
That helps. I could get some logs. Here is the logs:
http://pastebin.com/eAjWDS8t

I see few things going wrong:
[    0.000000] GIC CPU mask not found - kernel will fail to boot.
----
[  113.978373] swapper/0[1]: undefined instruction: pc=ffffffc000088008
[  113.978454] Code: 00000000 00000000 d4000002 d65f03c0 (d4000003)
[  113.978510] Internal error: Oops - undefined instruction: 0 [#1] SMP
[  113.978553] Modules linked in:
[  113.978610] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.39 #2
[  113.978673] task: ffffffc07dc85440 ti: ffffffc07dc88000 task.ti:
ffffffc07dc88000
[  113.978749] PC is at __invoke_psci_fn_smc+0x0/0x8
[  113.978815] LR is at psci_cpu_on+0x2c/0x54

-----

It looks like kernel is trying to communicate to the ARM's trusted
firmware. I am not an expert, please correct me if this assumption is wrong.


Is there a way to run uboot above ARM trusted firmware ?


> --
> Tom
>