On 11. 05. 20 16:06, Benedikt Grassl wrote: > Hi, > > with commit 942b5fc0 the 8-bit data bus seems to work fine in U-Boot. > However, I have one situation where I get transfer errors lateron in > Linux. At the moment I suspect that this is rather a problem of the > Linux driver, but I would like to make sure here first. > My ZynqMP has an eMMC flash connected to SD0 and an SD-card to SD1. When > I boot the device from SD-card and load a kernel ITB (tested both 4.14 > and 5.4), I immediately get errors when writing to the eMMC flash in > Linux: > > print_req_error: I/O error, dev mmcblk0, sector 2048 > Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write > mmc0: Got data interrupt 0x00000002 even though no data operation was in > progress. > mmc0: sdhci: ============ SDHCI REGISTER DUMP =========== > mmc0: sdhci: Sys addr: 0x00000400 | Version: 0x00001002 > mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000400 > mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000033 > mmc0: sdhci: Present: 0x1ff70000 | Host ctl: 0x0000003d > mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080 > mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 > mmc0: sdhci: Timeout: 0x00000006 | Int stat: 0x00000000 > mmc0: sdhci: Int enab: 0x02ff000b | Sig enab: 0x02ff000b > mmc0: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000 > mmc0: sdhci: Caps: 0x75ecc881 | Caps_1: 0x00002007 > mmc0: sdhci: Cmd: 0x00000c1a | Max curr: 0x00000000 > mmc0: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0x36475026 > mmc0: sdhci: Resp[2]: 0x49533031 | Resp[3]: 0x00000900 > mmc0: sdhci: Host ctl2: 0x0000008b > mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000 > mmc0: sdhci: ============================================ > > Interestingly, I can work-around this by just typing "mmc info" in the > U-Boot console. As soon as some interaction with mmc0 happens in U-Boot > , this problem disappears (i.e. anything that relies on the mmc layer > to issue transfers to the eMMC flash). > This did not happen before, when only a 4-bit data bus was supported. > Also the latest commit e44c2bc on the Xilinx U-boot git repository does > not solve this problem.
Yes we found that 1.8v dt property requires partial revert of your patch because logic in u-boot code is problematic and needs to be fixed. > From my understanding, the Linux driver should be independent of the > initialization done in U-Boot, right? > Does anyone have an idea or a comment to this? Did I miss anything? yes both should be independent. I have no idea what it is wrong in this case but definitely something to look at. Thanks, Michal
