Hi Alex, On 6 September 2016 at 03:09, Alexander Graf <ag...@suse.de> wrote: > On 09/06/2016 03:05 AM, Simon Glass wrote: >> >> Hi Alex, >> >> On 5 September 2016 at 04:51, Alexander Graf <ag...@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@ff170000: 0 >>>>> Using default environment >>>>> >>>>> In: serial@ff000000 >>>>> Out: serial@ff000000 >>>>> Err: serial@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.
Yes, this field really should be removed. As the comment says it's a hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to specify the block device instead of a struct udevice *. It came up recently on a patch you sent also which is why I am so against using it. That said, I'm not sure why it is unset. The path should be: sdhci_bind() mmc_bind() blk_create_devicef() blk_create_device() which sets: desc->bdev = dev; [snip] Regards, SImon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot