[U-Boot] ZynqMP breakage
Alexander Graf
agraf at suse.de
Tue Sep 6 11:09:40 CEST 2016
On 09/06/2016 03:05 AM, Simon Glass wrote:
> Hi Alex,
>
> On 5 September 2016 at 04:51, Alexander Graf <agraf at suse.de> wrote:
>> On 08/19/2016 08:45 AM, Michal Simek wrote:
>>> On 16.8.2016 20:39, Alexander Graf wrote:
>>>> Hi Michal,
>>>>
>>>> I just tried to run the latest u-boot master + a few patches to implement
>>>> generic PSCI RTS support on zynqmp and got this:
>>>>
>>>> e
>>>> U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200) Xilinx
>>>> ZynqMP ZCU102
>>>>
>>>> I2C: ready
>>>> DRAM: 4 GiB
>>>> EL Level: EL2
>>>> MMC: sdhci at ff170000: 0
>>>> Using default environment
>>>>
>>>> In: serial at ff000000
>>>> Out: serial at ff000000
>>>> Err: serial at ff000000
>>>> Bootmode: SD_MODE1
>>>> SCSI: SATA link 0 timeout.
>>>> Target spinup took 0 ms.
>>>> AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
>>>> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
>>>> scanning bus for devices...
>>>> "Synchronous Abort" handler, esr 0x96000004
>>>> ELR: 7ff42d20
>>>> LR: 7ff3ff10
>>>> x0 : 0000000000000000 x1 : 0000000000000000
>>>> x2 : 0000000000000001 x3 : 000000007df1aa80
>>>> x4 : aaaaaaaaaaaaaaaa x5 : 0000000000000001
>>>> x6 : 0000000000000200 x7 : 0000000000000004
>>>> x8 : 000000007ff9f800 x9 : 0000000000000008
>>>> x10: 000000007ff9f8f0 x11: 0000000000000000
>>>> x12: 00000000ffffffff x13: 00000000ffffffff
>>>> x14: 000000007ff8242f x15: 000000007ff82435
>>>> x16: 000000007ff84388 x17: 000000007ff84388
>>>> x18: 000000007df1ade8 x19: 000000007df1aa80
>>>> x20: 000000007ff92cb8 x21: 000000007ff9f800
>>>> x22: 000000007ff9f000 x23: 0000000000000078
>>>> x24: 000000007ff9f8f0 x25: 0000000000000000
>>>> x26: 000000007ff9f800 x27: 000000007ff9f000
>>>> x28: 000000007ff9fb00 x29: 000000007df1aca0
>>>>
>>>> Resetting CPU ...
>>>>
>>>> resetting …
>>>>
>>>> Is this a known problem?
>>> Is this issue with usb?
>>> I have usb off on zcu102 that's why if this usb issue
>>> I am not aware about it.
>>
>> After a bit of digging, turns out it's CONFIG_BLK. If I disable that things
>> work again (albeit without mmc access, since that one requires CONFIG_BLK
>> now).
> I don't have a zynqmp device, so cannot test with that unfortunately.
Well, QEMU supports zcu102 emulation in the latest version, so you could
use that to emulate the board:
$ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m
2G -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0
However, I don't see the data abort with the emulated device, only with
actual hardware. Probably because real hardware is more upset about
reading from address 0 ;). But I can provoke the oops even in QEMU if I
unmap the first page from the memory map using the patch below.
The oops happens in blk_dread because block_dev->bdev is NULL.
Alex
diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c
b/arch/arm/cpu/armv8/zynqmp/cpu.c
index b0f1295..0878025 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -18,9 +18,9 @@ DECLARE_GLOBAL_DATA_PTR;
static struct mm_region zynqmp_mem_map[] = {
{
- .virt = 0x0UL,
- .phys = 0x0UL,
- .size = 0x80000000UL,
+ .virt = 0x1000UL,
+ .phys = 0x1000UL,
+ .size = 0x80000000UL - 0x1000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
More information about the U-Boot
mailing list