Message ID | 57CE87D4.4020905@suse.de |
---|---|
State | RFC |
Headers | show |
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@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
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@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] 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
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@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] > > > 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
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@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] >> >> >> 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
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@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] >>> >>> >>> 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
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@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] >>>> >>>> >>>> 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
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 }, {