* [U-Boot] ZynqMP breakage @ 2016-08-16 18:39 Alexander Graf 2016-08-19 6:45 ` Michal Simek 0 siblings, 1 reply; 11+ messages in thread From: Alexander Graf @ 2016-08-16 18:39 UTC (permalink / raw) To: u-boot 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? Alex ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-08-16 18:39 [U-Boot] ZynqMP breakage Alexander Graf @ 2016-08-19 6:45 ` Michal Simek 2016-09-05 10:51 ` Alexander Graf 0 siblings, 1 reply; 11+ messages in thread From: Michal Simek @ 2016-08-19 6:45 UTC (permalink / raw) To: u-boot 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. Thanks, Michal ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-08-19 6:45 ` Michal Simek @ 2016-09-05 10:51 ` Alexander Graf 2016-09-06 1:05 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Alexander Graf @ 2016-09-05 10:51 UTC (permalink / raw) To: u-boot 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). Alex ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-05 10:51 ` Alexander Graf @ 2016-09-06 1:05 ` Simon Glass 2016-09-06 9:09 ` Alexander Graf 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2016-09-06 1:05 UTC (permalink / raw) To: u-boot Hi Alex, On 5 September 2016 at 04:51, Alexander Graf <agraf@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. Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 1:05 ` Simon Glass @ 2016-09-06 9:09 ` Alexander Graf 2016-09-06 12:52 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Alexander Graf @ 2016-09-06 9:09 UTC (permalink / raw) To: u-boot On 09/06/2016 03:05 AM, Simon Glass wrote: > Hi Alex, > > On 5 September 2016 at 04:51, Alexander Graf <agraf@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 }, { ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 9:09 ` Alexander Graf @ 2016-09-06 12:52 ` Simon Glass 2016-09-06 12:55 ` Alexander Graf 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2016-09-06 12:52 UTC (permalink / raw) To: u-boot Hi Alex, On 6 September 2016 at 03:09, Alexander Graf <agraf@suse.de> wrote: > On 09/06/2016 03:05 AM, Simon Glass wrote: >> >> Hi Alex, >> >> On 5 September 2016 at 04:51, Alexander Graf <agraf@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. 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 12:52 ` Simon Glass @ 2016-09-06 12:55 ` Alexander Graf 2016-09-06 12:57 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Alexander Graf @ 2016-09-06 12:55 UTC (permalink / raw) To: u-boot On 09/06/2016 02:52 PM, Simon Glass wrote: > Hi Alex, > > On 6 September 2016 at 03:09, Alexander Graf <agraf@suse.de> wrote: >> On 09/06/2016 03:05 AM, Simon Glass wrote: >>> Hi Alex, >>> >>> On 5 September 2016 at 04:51, Alexander Graf <agraf@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. > 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] The special case about ZynqMP is that it has 2 storage backends, one that uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI controller). I guess something goes wrong with the latter. Alex ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 12:55 ` Alexander Graf @ 2016-09-06 12:57 ` Simon Glass 2016-09-06 13:40 ` Michal Simek 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2016-09-06 12:57 UTC (permalink / raw) To: u-boot Hi Alex, On 6 September 2016 at 06:55, Alexander Graf <agraf@suse.de> wrote: > On 09/06/2016 02:52 PM, Simon Glass wrote: >> >> Hi Alex, >> >> On 6 September 2016 at 03:09, Alexander Graf <agraf@suse.de> wrote: >>> >>> On 09/06/2016 03:05 AM, Simon Glass wrote: >>>> >>>> Hi Alex, >>>> >>>> On 5 September 2016 at 04:51, Alexander Graf <agraf@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. >> >> 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] > > > The special case about ZynqMP is that it has 2 storage backends, one that > uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI > controller). I guess something goes wrong with the latter. OK, well it would be good to convert it. It certainly won't work without it and I'm a little surprised that it compiles :-) Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 12:57 ` Simon Glass @ 2016-09-06 13:40 ` Michal Simek 2016-09-06 14:23 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Michal Simek @ 2016-09-06 13:40 UTC (permalink / raw) To: u-boot Hi, On 6.9.2016 14:57, Simon Glass wrote: > Hi Alex, > > On 6 September 2016 at 06:55, Alexander Graf <agraf@suse.de> wrote: >> On 09/06/2016 02:52 PM, Simon Glass wrote: >>> >>> Hi Alex, >>> >>> On 6 September 2016 at 03:09, Alexander Graf <agraf@suse.de> wrote: >>>> >>>> On 09/06/2016 03:05 AM, Simon Glass wrote: >>>>> >>>>> Hi Alex, >>>>> >>>>> On 5 September 2016 at 04:51, Alexander Graf <agraf@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. >>> >>> 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] >> >> >> The special case about ZynqMP is that it has 2 storage backends, one that >> uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI >> controller). I guess something goes wrong with the latter. > > OK, well it would be good to convert it. It certainly won't work > without it and I'm a little surprised that it compiles :-) probably good time to convert it. Driver itself has only sata init sequence and then it is just compatible with ahci. That's why conversion should be pretty easy. Simon: Which driver should I use as inspiration for conversion? Thanks, Michal ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 13:40 ` Michal Simek @ 2016-09-06 14:23 ` Simon Glass 2016-09-08 14:01 ` Michal Simek 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2016-09-06 14:23 UTC (permalink / raw) To: u-boot Hi Michal, On 6 September 2016 at 07:40, Michal Simek <michal.simek@xilinx.com> wrote: > Hi, > > On 6.9.2016 14:57, Simon Glass wrote: >> Hi Alex, >> >> On 6 September 2016 at 06:55, Alexander Graf <agraf@suse.de> wrote: >>> On 09/06/2016 02:52 PM, Simon Glass wrote: >>>> >>>> Hi Alex, >>>> >>>> On 6 September 2016 at 03:09, Alexander Graf <agraf@suse.de> wrote: >>>>> >>>>> On 09/06/2016 03:05 AM, Simon Glass wrote: >>>>>> >>>>>> Hi Alex, >>>>>> >>>>>> On 5 September 2016 at 04:51, Alexander Graf <agraf@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. >>>> >>>> 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] >>> >>> >>> The special case about ZynqMP is that it has 2 storage backends, one that >>> uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI >>> controller). I guess something goes wrong with the latter. >> >> OK, well it would be good to convert it. It certainly won't work >> without it and I'm a little surprised that it compiles :-) > > probably good time to convert it. Driver itself has only sata init > sequence and then it is just compatible with ahci. That's why conversion > should be pretty easy. > > Simon: Which driver should I use as inspiration for conversion? I looked at sata a while back, so here are a few ideas... Existing sata.h functions should be #ifdef'd out - init_sata() should be handled by the driver probe() method - hopefully sata_stop() can be handled by driver remove() method - the block device can handle read and write - we probably need sata methods for scan and reset There is also ahci.h. There is a sata_sandbox.c driver which you could convert to DM, perhaps with a new DM_SATA option (like DM_MMC). Regards, Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ZynqMP breakage 2016-09-06 14:23 ` Simon Glass @ 2016-09-08 14:01 ` Michal Simek 0 siblings, 0 replies; 11+ messages in thread From: Michal Simek @ 2016-09-08 14:01 UTC (permalink / raw) To: u-boot Hi Simon, On 6.9.2016 16:23, Simon Glass wrote: > Hi Michal, > > On 6 September 2016 at 07:40, Michal Simek <michal.simek@xilinx.com> wrote: >> Hi, >> >> On 6.9.2016 14:57, Simon Glass wrote: >>> Hi Alex, >>> >>> On 6 September 2016 at 06:55, Alexander Graf <agraf@suse.de> wrote: >>>> On 09/06/2016 02:52 PM, Simon Glass wrote: >>>>> >>>>> Hi Alex, >>>>> >>>>> On 6 September 2016 at 03:09, Alexander Graf <agraf@suse.de> wrote: >>>>>> >>>>>> On 09/06/2016 03:05 AM, Simon Glass wrote: >>>>>>> >>>>>>> Hi Alex, >>>>>>> >>>>>>> On 5 September 2016 at 04:51, Alexander Graf <agraf@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. >>>>> >>>>> 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] >>>> >>>> >>>> The special case about ZynqMP is that it has 2 storage backends, one that >>>> uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI >>>> controller). I guess something goes wrong with the latter. >>> >>> OK, well it would be good to convert it. It certainly won't work >>> without it and I'm a little surprised that it compiles :-) >> >> probably good time to convert it. Driver itself has only sata init >> sequence and then it is just compatible with ahci. That's why conversion >> should be pretty easy. >> >> Simon: Which driver should I use as inspiration for conversion? > > I looked at sata a while back, so here are a few ideas... > > Existing sata.h functions should be #ifdef'd out > > - init_sata() should be handled by the driver probe() method > - hopefully sata_stop() can be handled by driver remove() method > - the block device can handle read and write > - we probably need sata methods for scan and reset > > There is also ahci.h. > > There is a sata_sandbox.c driver which you could convert to DM, > perhaps with a new DM_SATA option (like DM_MMC). I have sent RFC for moving ceva driver to DM with some core changes. There will be probably a need to test it on platform which is capable to connect more HDDs to make sure that everything is correct. Thanks, Michal ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-09-08 14:01 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-08-16 18:39 [U-Boot] ZynqMP breakage Alexander Graf 2016-08-19 6:45 ` Michal Simek 2016-09-05 10:51 ` Alexander Graf 2016-09-06 1:05 ` Simon Glass 2016-09-06 9:09 ` Alexander Graf 2016-09-06 12:52 ` Simon Glass 2016-09-06 12:55 ` Alexander Graf 2016-09-06 12:57 ` Simon Glass 2016-09-06 13:40 ` Michal Simek 2016-09-06 14:23 ` Simon Glass 2016-09-08 14:01 ` Michal Simek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox