From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Tue, 6 Sep 2016 15:40:20 +0200 Subject: [U-Boot] ZynqMP breakage In-Reply-To: References: <4aa95205-728e-f9b3-b8b4-10384632373b@xilinx.com> <57CD4E28.9020007@suse.de> <57CE87D4.4020905@suse.de> <57CEBCB0.3070708@suse.de> Message-ID: <3040de7f-55bd-7e96-e79e-7e499ad3ee9c@xilinx.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 6.9.2016 14:57, Simon Glass wrote: > Hi Alex, > > On 6 September 2016 at 06:55, Alexander Graf wrote: >> On 09/06/2016 02:52 PM, Simon Glass wrote: >>> >>> Hi Alex, >>> >>> On 6 September 2016 at 03:09, Alexander Graf wrote: >>>> >>>> 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. >>> >>> 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