* arasan-sdhci eMMC Problem 'command timeout' @ 2022-10-06 13:03 michael.graichen 2022-10-06 13:13 ` Ahmad Fatoum 2022-10-06 13:28 ` Yann Sionneau 0 siblings, 2 replies; 7+ messages in thread From: michael.graichen @ 2022-10-06 13:03 UTC (permalink / raw) To: barebox Hey, I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. while the uSD Card seams to work fine i'm getting the error arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 from the eMMC. arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 mmc1: detected SD card version 2.0 mmc1: registered mmc1 both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. The MMC is from type MTFC8G but Linux detects it as [ 2.012122] mmc0: new high speed MMC card at address 0001 [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. Best Regards Michael ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arasan-sdhci eMMC Problem 'command timeout' 2022-10-06 13:03 arasan-sdhci eMMC Problem 'command timeout' michael.graichen @ 2022-10-06 13:13 ` Ahmad Fatoum 2022-10-07 14:13 ` AW: " michael.graichen 2022-10-06 13:28 ` Yann Sionneau 1 sibling, 1 reply; 7+ messages in thread From: Ahmad Fatoum @ 2022-10-06 13:13 UTC (permalink / raw) To: michael.graichen, barebox Hello, On 06.10.22 15:03, michael.graichen@hotmail.com wrote: > Hey, > > I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. > while the uSD Card seams to work fine i'm getting the error > > arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 > arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 > arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 > arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 > arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 > > from the eMMC. Please try adding no-sd to your eMMC device tree node and try again. I don't know why it's necessary, because falling back to MMC after SD fails is normal operation on all other hosts. I don't have the hardware, but I've seen that the recently added device trees that use the arasan, set this in barebox for the eMMC node. > > arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 > mmc1: detected SD card version 2.0 > mmc1: registered mmc1 > > both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. > The MMC is from type MTFC8G but Linux detects it as > > [ 2.012122] mmc0: new high speed MMC card at address 0001 > [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB > [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no > [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB > [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB > [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) > > Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. If it's indeed resolved by no-sd, this sound like a good occasion to dig deeper into the SDHCI. ;) Let me know if that works for you. Cheers, Ahmad > > Best Regards > Michael > > > > > > > > > > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 7+ messages in thread
* AW: arasan-sdhci eMMC Problem 'command timeout' 2022-10-06 13:13 ` Ahmad Fatoum @ 2022-10-07 14:13 ` michael.graichen 2022-10-07 14:21 ` Ahmad Fatoum 0 siblings, 1 reply; 7+ messages in thread From: michael.graichen @ 2022-10-07 14:13 UTC (permalink / raw) To: Ahmad Fatoum, barebox, Yann Sionneau Hey, thanks for your advices. Adding "no-sd" really solved it. Best Regards Michael ________________________________________ Von: Ahmad Fatoum <a.fatoum@pengutronix.de> Gesendet: Donnerstag, 6. Oktober 2022 15:13 An: michael.graichen@hotmail.com; barebox@lists.infradead.org Betreff: Re: arasan-sdhci eMMC Problem 'command timeout' Hello, On 06.10.22 15:03, michael.graichen@hotmail.com wrote: > Hey, > > I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. > while the uSD Card seams to work fine i'm getting the error > > arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 > arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 > arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 > arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 > arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 > > from the eMMC. Please try adding no-sd to your eMMC device tree node and try again. I don't know why it's necessary, because falling back to MMC after SD fails is normal operation on all other hosts. I don't have the hardware, but I've seen that the recently added device trees that use the arasan, set this in barebox for the eMMC node. > > arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 > mmc1: detected SD card version 2.0 > mmc1: registered mmc1 > > both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. > The MMC is from type MTFC8G but Linux detects it as > > [ 2.012122] mmc0: new high speed MMC card at address 0001 > [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB > [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no > [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB > [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB > [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) > > Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. If it's indeed resolved by no-sd, this sound like a good occasion to dig deeper into the SDHCI. ;) Let me know if that works for you. Cheers, Ahmad > > Best Regards > Michael > > > > > > > > > > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AW: arasan-sdhci eMMC Problem 'command timeout' 2022-10-07 14:13 ` AW: " michael.graichen @ 2022-10-07 14:21 ` Ahmad Fatoum 0 siblings, 0 replies; 7+ messages in thread From: Ahmad Fatoum @ 2022-10-07 14:21 UTC (permalink / raw) To: michael.graichen, barebox, Yann Sionneau On 07.10.22 16:13, michael.graichen@hotmail.com wrote: > > Hey, > > thanks for your advices. Adding "no-sd" really solved it. Good to know. Keep in mind that's just a work-around though. I highly encourage you to debug it... :D Cheers, Ahmad > > Best Regards > Michael > > > ________________________________________ > Von: Ahmad Fatoum <a.fatoum@pengutronix.de> > Gesendet: Donnerstag, 6. Oktober 2022 15:13 > An: michael.graichen@hotmail.com; barebox@lists.infradead.org > Betreff: Re: arasan-sdhci eMMC Problem 'command timeout' > > Hello, > > On 06.10.22 15:03, michael.graichen@hotmail.com wrote: >> Hey, >> >> I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. >> while the uSD Card seams to work fine i'm getting the error >> >> arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 >> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 >> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 >> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 >> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 >> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 >> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 >> >> from the eMMC. > > Please try adding no-sd to your eMMC device tree node and try again. > I don't know why it's necessary, because falling back to MMC after > SD fails is normal operation on all other hosts. I don't have the > hardware, but I've seen that the recently added device trees that > use the arasan, set this in barebox for the eMMC node. > >> >> arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 >> mmc1: detected SD card version 2.0 >> mmc1: registered mmc1 >> >> both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. >> The MMC is from type MTFC8G but Linux detects it as >> >> [ 2.012122] mmc0: new high speed MMC card at address 0001 >> [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB >> [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no >> [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB >> [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB >> [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) >> >> Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. > > If it's indeed resolved by no-sd, this sound like a good occasion to dig > deeper into the SDHCI. ;) > > Let me know if that works for you. > > Cheers, > Ahmad > > >> >> Best Regards >> Michael >> >> >> >> >> >> >> >> >> >> >> > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arasan-sdhci eMMC Problem 'command timeout' 2022-10-06 13:03 arasan-sdhci eMMC Problem 'command timeout' michael.graichen 2022-10-06 13:13 ` Ahmad Fatoum @ 2022-10-06 13:28 ` Yann Sionneau 2023-01-03 22:06 ` Ahmad Fatoum 1 sibling, 1 reply; 7+ messages in thread From: Yann Sionneau @ 2022-10-06 13:28 UTC (permalink / raw) To: barebox Hello Michael, The driver is polling for completion of the commands (8 for the first error, 55 for the second). While doing this polling, an error was raised by the SDHCI controller. The nature of the error is reported in the register SDHCI_INT_ERROR (reg offset 0x32) Only the LSB (bit 0) is set. This bit means "Command Timeout Error". I copy paste the SDHC simplified specification version 4.20: " This bit is set only if no response is returned within 64 SD clock cycles from the end bit of the command. If the Host Controller detects a CMD line conflict, in which case Command CRC Error shall also be set as shown in Table 2-26, this bit shall be set without waiting for 64 SD clock cycles because the command will be aborted by the Host Controller. " So it seems either the eMMC stops answering, or it's too slow. Or ... the controller thinks it's too slow and the "timeout" could be a false positive. To check for false positive : * check the tmclk frequency, it's a clock which is an input of the sdhc controller in the Soc: see your SoC documentation for that on how the sdhc controller is integrated. * check the Timeout Control Register content (register 0x2E). Try to force a higher value (for instance max value is 0xe) * Check that CAPABILITIES1_R (register 0x40) fields TOUT_CLK_UNIT (bit 7) and TOUT_CLK_FREQ (bits [5:0]) that are reported by the controller corresponds correctly to the real value of the tmclk clock that is feeded to the controller by the SoC. You can try to hook-up a logic analyser to your eMMC bus to have a look at what's happening. Try to lower the max frequency of the bus before doing so, so that the logic analyzer extra capacitance does not mess too much with the bus signaling. Another lead to investigate is to have a look at which QUIRKS are enabled by the Linux driver to make the controller work in your case: https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-arasan.c Maybe Linux enables some quirks that could be needed to also "enable" in the Barebox driver? Regards, Yann On 10/6/22 15:03, michael.graichen@hotmail.com wrote: > Hey, > > I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. > while the uSD Card seams to work fine i'm getting the error > > arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 > arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 > arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 > arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 > arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 > > from the eMMC. > > arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 > mmc1: detected SD card version 2.0 > mmc1: registered mmc1 > > both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. > The MMC is from type MTFC8G but Linux detects it as > > [ 2.012122] mmc0: new high speed MMC card at address 0001 > [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB > [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no > [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB > [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB > [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) > > Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. > > Best Regards > Michael > > > > > > > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arasan-sdhci eMMC Problem 'command timeout' 2022-10-06 13:28 ` Yann Sionneau @ 2023-01-03 22:06 ` Ahmad Fatoum 2023-01-04 9:27 ` Yann Sionneau 0 siblings, 1 reply; 7+ messages in thread From: Ahmad Fatoum @ 2023-01-03 22:06 UTC (permalink / raw) To: Yann Sionneau, barebox, Michael Graichen Hello Yann, On 06.10.22 15:28, Yann Sionneau wrote: > Hello Michael, > > The driver is polling for completion of the commands (8 for the first error, 55 for the second). > > While doing this polling, an error was raised by the SDHCI controller. > > The nature of the error is reported in the register SDHCI_INT_ERROR (reg offset 0x32) > > Only the LSB (bit 0) is set. > > This bit means "Command Timeout Error". > > I copy paste the SDHC simplified specification version 4.20: > > " > > This bit is set only if no response is returned within 64 SD clock cycles from > the end bit of the command. If the Host Controller detects a CMD line > conflict, in which case Command CRC Error shall also be set as shown in > Table 2-26, this bit shall be set without waiting for 64 SD clock cycles > because the command will be aborted by the Host Controller. > > " > > So it seems either the eMMC stops answering, or it's too slow. Turns out these are SD-Card specific commands and the timeout is expected and should've been passed along as -ETIMEDOUT, so MCI core can fall back to MMC setup instead of SD. I ran into this getting my eMMC working with the SDHCI on the RK3399 and just sent out a patch to resolve this. Cheers, Ahmad > > Or ... the controller thinks it's too slow and the "timeout" could be a false positive. > > To check for false positive : > > * check the tmclk frequency, it's a clock which is an input of the sdhc controller in the Soc: see your SoC documentation for that on how the sdhc controller is integrated. > > * check the Timeout Control Register content (register 0x2E). Try to force a higher value (for instance max value is 0xe) > > * Check that CAPABILITIES1_R (register 0x40) fields TOUT_CLK_UNIT (bit 7) and TOUT_CLK_FREQ (bits [5:0]) that are reported by the controller corresponds correctly to the real value of the tmclk clock that is feeded to the controller by the SoC. > > You can try to hook-up a logic analyser to your eMMC bus to have a look at what's happening. Try to lower the max frequency of the bus before doing so, so that the logic analyzer extra capacitance does not mess too much with the bus signaling. > > Another lead to investigate is to have a look at which QUIRKS are enabled by the Linux driver to make the controller work in your case: https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-arasan.c > > Maybe Linux enables some quirks that could be needed to also "enable" in the Barebox driver? > > Regards, > > Yann > > On 10/6/22 15:03, michael.graichen@hotmail.com wrote: >> Hey, >> >> I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. >> while the uSD Card seams to work fine i'm getting the error >> >> arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 >> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 >> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 >> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 >> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 >> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 >> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 >> >> from the eMMC. >> >> arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 >> mmc1: detected SD card version 2.0 >> mmc1: registered mmc1 >> >> both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. >> The MMC is from type MTFC8G but Linux detects it as >> >> [ 2.012122] mmc0: new high speed MMC card at address 0001 >> [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB >> [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no >> [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB >> [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB >> [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) >> >> Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. >> >> Best Regards >> Michael >> >> >> >> >> >> >> >> >> >> > > > > > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arasan-sdhci eMMC Problem 'command timeout' 2023-01-03 22:06 ` Ahmad Fatoum @ 2023-01-04 9:27 ` Yann Sionneau 0 siblings, 0 replies; 7+ messages in thread From: Yann Sionneau @ 2023-01-04 9:27 UTC (permalink / raw) To: Ahmad Fatoum, barebox, Michael Graichen Hello Ahmad, On 03/01/2023 23:06, Ahmad Fatoum wrote: > Hello Yann, > > On 06.10.22 15:28, Yann Sionneau wrote: >> Hello Michael, >> >> The driver is polling for completion of the commands (8 for the first error, 55 for the second). >> >> While doing this polling, an error was raised by the SDHCI controller. >> >> The nature of the error is reported in the register SDHCI_INT_ERROR (reg offset 0x32) >> >> Only the LSB (bit 0) is set. >> >> This bit means "Command Timeout Error". >> >> I copy paste the SDHC simplified specification version 4.20: >> >> " >> >> This bit is set only if no response is returned within 64 SD clock cycles from >> the end bit of the command. If the Host Controller detects a CMD line >> conflict, in which case Command CRC Error shall also be set as shown in >> Table 2-26, this bit shall be set without waiting for 64 SD clock cycles >> because the command will be aborted by the Host Controller. >> >> " >> >> So it seems either the eMMC stops answering, or it's too slow. > Turns out these are SD-Card specific commands and the timeout is expected and > should've been passed along as -ETIMEDOUT, so MCI core can fall back to MMC > setup instead of SD. Oooh right, ok :) Sorry for the wrong leads! > > I ran into this getting my eMMC working with the SDHCI on the RK3399 and just > sent out a patch to resolve this. Well done! > > Cheers, > Ahmad > >> Or ... the controller thinks it's too slow and the "timeout" could be a false positive. >> >> To check for false positive : >> >> * check the tmclk frequency, it's a clock which is an input of the sdhc controller in the Soc: see your SoC documentation for that on how the sdhc controller is integrated. >> >> * check the Timeout Control Register content (register 0x2E). Try to force a higher value (for instance max value is 0xe) >> >> * Check that CAPABILITIES1_R (register 0x40) fields TOUT_CLK_UNIT (bit 7) and TOUT_CLK_FREQ (bits [5:0]) that are reported by the controller corresponds correctly to the real value of the tmclk clock that is feeded to the controller by the SoC. >> >> You can try to hook-up a logic analyser to your eMMC bus to have a look at what's happening. Try to lower the max frequency of the bus before doing so, so that the logic analyzer extra capacitance does not mess too much with the bus signaling. >> >> Another lead to investigate is to have a look at which QUIRKS are enabled by the Linux driver to make the controller work in your case: https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-arasan.c >> >> Maybe Linux enables some quirks that could be needed to also "enable" in the Barebox driver? >> >> Regards, >> >> Yann >> >> On 10/6/22 15:03, michael.graichen@hotmail.com wrote: >>> Hey, >>> >>> I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq. >>> while the uSD Card seams to work fine i'm getting the error >>> >>> arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0 >>> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 >>> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8 >>> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 >>> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001 >>> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55 >>> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000 >>> >>> from the eMMC. >>> >>> arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1 >>> mmc1: detected SD card version 2.0 >>> mmc1: registered mmc1 >>> >>> both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox. >>> The MMC is from type MTFC8G but Linux detects it as >>> >>> [ 2.012122] mmc0: new high speed MMC card at address 0001 >>> [ 2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB >>> [ 2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no >>> [ 2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB >>> [ 2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB >>> [ 2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0) >>> >>> Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help. >>> >>> Best Regards >>> Michael >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-01-04 9:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-06 13:03 arasan-sdhci eMMC Problem 'command timeout' michael.graichen 2022-10-06 13:13 ` Ahmad Fatoum 2022-10-07 14:13 ` AW: " michael.graichen 2022-10-07 14:21 ` Ahmad Fatoum 2022-10-06 13:28 ` Yann Sionneau 2023-01-03 22:06 ` Ahmad Fatoum 2023-01-04 9:27 ` Yann Sionneau
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox