From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Tue, 6 Sep 2016 11:09:40 +0200 Subject: [U-Boot] ZynqMP breakage In-Reply-To: References: <4aa95205-728e-f9b3-b8b4-10384632373b@xilinx.com> <57CD4E28.9020007@suse.de> Message-ID: <57CE87D4.4020905@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/06/2016 03:05 AM, Simon Glass wrote: > Hi Alex, > > On 5 September 2016 at 04:51, Alexander Graf 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 }, {