On 01.05.2018 11:05, Martin Lund wrote:
> Hi Manju,
>
>
> Ok, I've updated u-boot-mkimage to use the 2018.1 recipe from
> meta-petalinux by copying the files to the meta-xilinx layer.
>
>
> Then when building arm-trusted-firmware it triggered a rebuild to update
> u-boot-mkimage which resulted in an updated atf-uboot.ub. I notice that
> u-boot-xlnx does not depend on u-boot-mkimage.
>
>
> However, it did not solve the issue - I still see the following error:
>
>
> U-Boot SPL 2018.01 (May 01 2018 - 09:26:36)
> EL Level: EL3
> Trying to boot from MMC1
> reading u-boot.bin
> reading atf-uboot.ub
> reading atf-uboot.ub
> fdt_root: FDT_ERR_BADMAGIC
> "Synchronous Abort" handler, esr 0x02000000
> ELR: fffea008
> LR: fffc14e8
> x0 : 0000000030c50830 x1 : 0000000000000000
> x2 : 0000000000000000 x3 : 0000000000000000
> x4 : 00000000fffea000 x5 : 0000000000000001
> x6 : 00000000000003c9 x7 : 0000000000000000
> x8 : 00000000ffff7c90 x9 : 0000000000000002
> x10: 000000000a200023 x11: 0000000000000002
> x12: 0000000000000002 x13: 00000000000008f8
> x14: 0000000000000000 x15: 00000000fffc0cd0
> x16: 290c820384080c00 x17: b023822044851147
> x18: 00000000ffff7e90 x19: 00000000ffff7e48
> x20: 00000000fffdc228 x21: 0000000000000000
> x22: 00000000fffd7ee8 x23: 00000000ffff7e30
> x24: 00000000fffd7ed0 x25: 00000000fffdc000
> x26: 00000000deadbeef x27: 83cf122300800323
> x28: 8201900006090c13 x29: 00000000ffff7db0
>
> Resetting CPU ...
>
> ### ERROR ### Please RESET the board ###
>
>
> Any ideas what else might be broken?
I ran into the same issue a week or two ago.
The problem is that the u-boot SPL thinks it loads a Linux kernel
instead of an ATF BL31.
If you look at the ELR (the address of the faulting instruction) and the
instruction it tries to execute there, you can see that it tries to
access a register which is only acessible in EL3. The only reason why
this might fail is that we are not in EL3.
U-Boot drops the privilege level to EL2 when it loads a Linux kernel
[1][2]. And because it thinks it's loading a Linux kernel it does
exactly that.
So the trick of using the u-boot SPL to load the BL31 as a kernel and
the real u-boot as a DTB doesn't work anymore.
Now it seems we need to tell u-boot that it is actually loading the ARM
trusted firmware by setting the right flags in the u-boot image it loads[3].
I tried it like this:
mkimage -A arm64 -O arm-trusted-firmware -T firmware -C none -a
0xfffea000 -e 0xfffea000 -d arm-trusted-firmware.bin atf.ub
Unfortunately I must still be doing something wrong because it didn't
work. I don't remember exactly how the board behaved and don't have the
setup here right now, but it didn't boot properly.
At this point I gave up and resorted to meta-xilinx-tools with a Xilinx
FSBL again. Especially because I couldn't find anything about how to use
the new ATF loading with a u-boot SPL. The feature is there (at least
for BL31 and BL33, BL32 support is still missing [4]) but not documented
at all. Even if I had managed to execute the BL31, I'm not 100% sure how
to tell it that the BL33 should be the main u-boot. It seems that it
expects a FIT image there.
If somebody knows how to use this, any help would be great.
Ideally I'd like to have it boot a FIT image containing the BL31, BL32
(I'd try to hack support into u-boot for this once the thing boots),
BL33 (main u-boot) and maybe even a kernel + dtb
- Andy
[1]: https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L450
[2]:
https://github.com/u-boot/u-boot/blob/26f9184e094541b672f83f23652e2e737d5d0729/arch/arm/lib/spl.c#L56
[3]: https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L440
[4]:
https://github.com/u-boot/u-boot/blob/f2ee91501892d3280a4c58093ad3a18dccd0b562/common/spl/spl_atf.c
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
