Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Macpaul, On Tue, Nov 15, 2011 at 11:34 AM, Macpaul Lin macp...@gmail.com wrote: HI Lei Wen, 2011/11/14 Lei Wen adrian.w...@gmail.com: Hi Macpaul, It seems some socs always treat cmd8 as failed...? I think it is reasonable to add a quirk configuration surround the judgement of cmd8 execution, so that even it is failed anyway, it could still go on with the following cmd sequence. If this quirk is not defined, and return behavior is still kept. What do you think for this? Thanks, Lei For easily to discuss about this problem, I've stripped the part from SD specification 3.0 as you mentioned. Figure 6.1 http://i.imgur.com/bmoAX.jpg Figure 6.2 http://i.imgur.com/7fxdx.jpg As you can see, after the power ramp up to 74 clocks (1msec), the CMD0 can be send to the card. So it seems your controller will do power ramp up (dynamic clock gating?) only after the CMD0 has been send? Is this correct? However, it is weird and seem not followed the specification. Yes, our controller use dynamic control gating for clock. The clock is not sample out while no command send out. Since only SD 2.0 cards can adopted with CMD8, other cards older than SD 2.0 should treat CMD8 as timeout (I guess). So CMD8 might be important for us to distinguish the command sequence. Sending CMD8 many times might really introduce problem for other cards. I realize now we at least cannot directly return err if the cmd8 is not succeed. Please submit a patch to fix it. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Lei Wen, 2011/11/15 Lei Wen adrian.w...@gmail.com: Hi Macpaul, Figure 6.1 http://i.imgur.com/bmoAX.jpg Figure 6.2 http://i.imgur.com/7fxdx.jpg As you can see, after the power ramp up to 74 clocks (1msec), the CMD0 can be send to the card. So it seems your controller will do power ramp up (dynamic clock gating?) only after the CMD0 has been send? Is this correct? However, it is weird and seem not followed the specification. Yes, our controller use dynamic control gating for clock. The clock is not sample out while no command send out. I realize now we at least cannot directly return err if the cmd8 is not succeed. Please submit a patch to fix it. Thanks, Lei It seems your hardware doesn't follow the rule that specification described and made compatibility problem to other platform, includes the existing platforms. I think you'd better report it to your hardware designer which is a hardware bug need to be fixed. And, I think you can send a quick fix patch like the #ifdef as you've mention to workaround for your hardware only if you cannot find a common solution right now. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Macpaul, On Mon, Nov 14, 2011 at 2:36 PM, Macpaul Lin macp...@gmail.com wrote: Hi Lei Wen, 2011/11/14 Lei Wen adrian.w...@gmail.com: Hi Macpaul, I see... It seems some socs always treat cmd8 as failed...? I think it is reasonable to add a quirk configuration surround the judgement of cmd8 execution, so that even it is failed anyway, it could still go on with the following cmd sequence. If this quirk is not defined, and return behavior is still kept. What do you think for this? Thanks, Lei I've not check this with the SD phy specification. The command process should be backward compatible between 3.0 and 1.0. Could you please provide this more detail with the specification? For example, could you please provide what section in the specification and how the state machine in MMC card should be operated. Then we can check it more detail and see if the solution is reasonable. The 74 clock requirement is mentioned in both sd[1] and mmc spec[2]. [1] page 91, section 6.4.1 power up, SD specification, part 1, Physical layer Simplificated Specification, version 2.0 [2] page 54, section 7.3.1 Card reset to pre-idle state, JESD84-A44 Moreover, if you could provide where the Linux code is related to the problem and how dose Linux deal with this problem will be good, also. For linux, it would direcly clear the HIGH SPEED flag for following mmc_send_app_op_cond(). Linux v3.2-rc1: drivers/mmc/core/sd.c: line 712 As you said in patch, some card strictly obey the 74 clocks rule, could you provide the information of the card that you're using? The card we met trouble on is SanDisk 8GB class4 sd card. Add #ifdef to the code is a quick solution, but I think the we need to figure out if there is other method to help on 74 clock adoptable on more general case. -- Best regards, Macpaul Lin Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
HI Lei Wen, 2011/11/14 Lei Wen adrian.w...@gmail.com: Hi Macpaul, It seems some socs always treat cmd8 as failed...? I think it is reasonable to add a quirk configuration surround the judgement of cmd8 execution, so that even it is failed anyway, it could still go on with the following cmd sequence. If this quirk is not defined, and return behavior is still kept. What do you think for this? Thanks, Lei For easily to discuss about this problem, I've stripped the part from SD specification 3.0 as you mentioned. Figure 6.1 http://i.imgur.com/bmoAX.jpg Figure 6.2 http://i.imgur.com/7fxdx.jpg As you can see, after the power ramp up to 74 clocks (1msec), the CMD0 can be send to the card. So it seems your controller will do power ramp up (dynamic clock gating?) only after the CMD0 has been send? Is this correct? However, it is weird and seem not followed the specification. Since only SD 2.0 cards can adopted with CMD8, other cards older than SD 2.0 should treat CMD8 as timeout (I guess). So CMD8 might be important for us to distinguish the command sequence. Sending CMD8 many times might really introduce problem for other cards. The 74 clock requirement is mentioned in both sd[1] and mmc spec[2]. [1] page 91, section 6.4.1 power up, SD specification, part 1, Physical layer Simplificated Specification, version 2.0 [2] page 54, section 7.3.1 Card reset to pre-idle state, JESD84-A44 The card we met trouble on is SanDisk 8GB class4 sd card. I don't have this card on hand. I only have Samsung and Trenscend cards (SD2.0, SD1.10 / class4 or class10). Is this SanDisk card also a SD 1.10 cards? Add #ifdef to the code is a quick solution, but I think the we need to figure out if there is other method to help on 74 clock adoptable on more general case. It seems you can only add #ifdef related to your controller (which means, do not add #ifdef as default to all other controllers.) Have you tried to fix it with more delay after sending CMD0? While mmc_go_idle have udelay(2000), which is 2ms, maybe writing a wrapper (command filter) function in your driver to force it wait longer after CMD0 has been send will be better. However it might lead a little bit drawback for the driver performance. But I think it won't be too much, only an if statement is enough. Thus you won't affect the behavior of the mmc software stack, and also will be more trivial to avoid adding #ifdef for special controller. Just a suggestion, hope other people could give comments. :-) -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
HI Lei Wen, 2011/11/12 Macpaul Lin macp...@gmail.com: Hi Lei Wen, 2011/11/12 Lei Wen adrian.w...@gmail.com: Hi Pali, I have got 3 times retry fail on CMD8 also with FTSDC010 in recent, too. But I'm not sure where the problem is and hasn't start to check bisect with the commits. It works really fine before. That's why I asked Andy to stop review the performance improvement of FTSDC010. Maybe we'll need to check it again where the affect is started.-- Best regards, Macpaul Lin I have done the testing of the commit related to mmc generic stack of Lei Wen's commit. The problem indeed occur when we add 3 retry to CMD8. After reverting this patch with the origin ftsdc010 driver (which is in master branch alredy), all works fine again. The following is the command flow with origin mmc stack. When I'm using card which version is SD 1.10, the CMD8 will timeout directly then card identification will continue. cmd 0 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0004 cmd 8 cmd: 55 cmd: 41 cmd: 55... If we add 3 retry to CMD8, the card will reply timeout 3 times than stop. It won't go to CMD55. cmd: 0 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Macpaul, On Mon, Nov 14, 2011 at 2:14 PM, Macpaul Lin macp...@gmail.com wrote: HI Lei Wen, 2011/11/12 Macpaul Lin macp...@gmail.com: Hi Lei Wen, 2011/11/12 Lei Wen adrian.w...@gmail.com: Hi Pali, I have got 3 times retry fail on CMD8 also with FTSDC010 in recent, too. But I'm not sure where the problem is and hasn't start to check bisect with the commits. It works really fine before. That's why I asked Andy to stop review the performance improvement of FTSDC010. Maybe we'll need to check it again where the affect is started.-- Best regards, Macpaul Lin I have done the testing of the commit related to mmc generic stack of Lei Wen's commit. The problem indeed occur when we add 3 retry to CMD8. After reverting this patch with the origin ftsdc010 driver (which is in master branch alredy), all works fine again. The following is the command flow with origin mmc stack. When I'm using card which version is SD 1.10, the CMD8 will timeout directly then card identification will continue. cmd 0 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0004 cmd 8 cmd: 55 cmd: 41 cmd: 55... If we add 3 retry to CMD8, the card will reply timeout 3 times than stop. It won't go to CMD55. cmd: 0 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 cmd: 8 ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 I see... It seems some socs always treat cmd8 as failed...? I think it is reasonable to add a quirk configuration surround the judgement of cmd8 execution, so that even it is failed anyway, it could still go on with the following cmd sequence. If this quirk is not defined, and return behavior is still kept. What do you think for this? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Lei Wen, 2011/11/14 Lei Wen adrian.w...@gmail.com: Hi Macpaul, I see... It seems some socs always treat cmd8 as failed...? I think it is reasonable to add a quirk configuration surround the judgement of cmd8 execution, so that even it is failed anyway, it could still go on with the following cmd sequence. If this quirk is not defined, and return behavior is still kept. What do you think for this? Thanks, Lei I've not check this with the SD phy specification. The command process should be backward compatible between 3.0 and 1.0. Could you please provide this more detail with the specification? For example, could you please provide what section in the specification and how the state machine in MMC card should be operated. Then we can check it more detail and see if the solution is reasonable. Moreover, if you could provide where the Linux code is related to the problem and how dose Linux deal with this problem will be good, also. As you said in patch, some card strictly obey the 74 clocks rule, could you provide the information of the card that you're using? Add #ifdef to the code is a quick solution, but I think the we need to figure out if there is other method to help on 74 clock adoptable on more general case. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Pali, On Sat, Nov 12, 2011 at 7:17 AM, Pali Rohár pali.ro...@gmail.com wrote: Hello, after commit 02f3029f1810b99869254d0cf0a71946a008a728 mmc: retry the cmd8 to meet 74 clocks requirement in the spec internal eMMC memory on Nokia N900 in u-boot not working. If I comment code if (err) return err; added by this commit, eMMC working fine. More info: mmc_send_if_cond from drivers/mmc/mmc.c is calling function mmc_send_cmd in drivers/mmc/omap_hsmmc.c which returning TIMEOUT from line 278: if ((mmc_stat IE_CTO) != 0) return TIMEOUT; -- Pali Rohár pali.ro...@gmail.com It is strange that your card would still get failed to send CMD8 after 3 times retry. Does omap mmc controller has some mechanism of mmc dynamic clock gating? I would suggest you to investigate why the emmc cannot response to CMD8 first. If not, I think we could make this err return code included in a ifdef to workaround your issue. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
