Re: mmc: Read eMMC partition access bits before card reset
On Monday 12 June 2023 14:11:41 Tom Rini wrote: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-ka...@kernel.org/ > > > > > > AFAICT, this patch has some open issues still. > > > > There were suggestion to make (that new kconfig option) enabled for > > everything. But nobody respond if it is possible to have it > > unconditionally enabled for every one board. Hence new config option in > > that patch was introduced. > > Yes, the feedback was to change things so that the behavior is the > default, since it looks like what we're doing now is wrong. Sorry, but from the discussion I have not deduced this fact. Instead from long silence it looks like that we cannot do any global change and so config option was proposed there. > And you have > access to a few platforms to test things on to see if it breaks other > platforms, Unfortunately I do not have any other platform which is booting XIP booting, which could be affected by that patch. > and then putting it in to -next or early in the merge cycle > on master would shake out any other problems with the approach. So if > you're still interested in that platform, please make it a generic > change or report back where it does fail so we can see what's going on > elsewhere. Making the init_sequence_f table even more difficult to read > is something we do want to avoid. > > -- > Tom
Re: mmc: Read eMMC partition access bits before card reset
On Sat, Jun 24, 2023 at 11:26:42AM +0200, Pali Rohár wrote: > On Monday 12 June 2023 14:11:41 Tom Rini wrote: > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-ka...@kernel.org/ > > > > > > > > AFAICT, this patch has some open issues still. > > > > > > There were suggestion to make (that new kconfig option) enabled for > > > everything. But nobody respond if it is possible to have it > > > unconditionally enabled for every one board. Hence new config option in > > > that patch was introduced. > > > > Yes, the feedback was to change things so that the behavior is the > > default, since it looks like what we're doing now is wrong. > > Sorry, but from the discussion I have not deduced this fact. Instead > from long silence it looks like that we cannot do any global change and > so config option was proposed there. I thought it was clearer, sorry for the confusion. > > And you have > > access to a few platforms to test things on to see if it breaks other > > platforms, > > Unfortunately I do not have any other platform which is booting XIP > booting, which could be affected by that patch. Well, making the change for everyone would effect the platforms you have, and is what I'm asking you to test. I don't know that there is any other platform that has the specific case you're describing. -- Tom signature.asc Description: PGP signature
Re: mmc: Read eMMC partition access bits before card reset
On Mon, 12 Jun 2023 14:11:41 -0400 Tom Rini wrote: > On Mon, Jun 12, 2023 at 07:39:20PM +0200, Pali Rohár wrote: > > On Monday 12 June 2023 11:22:12 Stefan Roese wrote: > > > Hi Pali, > > > > > > (added Peng for PowerPC and Jaehoon for MMC to Cc) > > > > > > On 6/11/23 15:03, Pali Rohár wrote: > > > > > > > > > > > > > > Pali, I will try to pull these not applied patches - if there are not > > > > > issues of course. Could you please send me a list of these patches so > > > > > that I can take look? Please note that I will probably not be able to > > > > > work on this this week. But next week should be possible. > > > > > > > > > > Thanks, > > > > > Stefan > > > > > > > > Hello! > > > > > > > > These patches are on the list for year: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-p...@kernel.org/ > > > > > > > > > > This patch fails with multiple problems. Reason is, that it's very "old" > > > and many of the Kconfig stuff was changed, which is of course not your > > > fault. Still, I'm not in the right position to make these changes I'm > > > afraid. > > > > > > Peng, this patch is now assigned to you in patchwork. Could you please > > > also take a look? And if Pali (or someone else) sends an updated > > > version, could you please make sure that it's reviewed (and applied if > > > no issues arise) in due time? > > > > Updated version was already sent but again no response... > > https://patchwork.ozlabs.org/project/uboot/patch/20220817205622.26644-1-p...@kernel.org/ > > > > I was expecting Marek Behún to follow up and take this as he's the one > that volunteered to take over one of the powerpc custodian trees and > push this through. I've replied now with more feedback. Please also look at my reply at https://lists.denx.de/pipermail/u-boot/2023-June/520031.html To recapitulate - Pali worked on this over a year ago, he has done quite a lot of work - it wasn't accepted at the time due to how some things changed in U-Boot - things regarding the conversion of CONFIG_ options, which Pali disagreed with since some of it was done in a wrong way. He wanted those changes to be reverted whole - I promised Pali to work it out, once I had time to look into it. I expected to be able to do it in october / november. Unfortunately I wasn't able to, things have been quite hectic since then (I was working on my diploma thesis and afterwards when I returned to work, more pressing things took precedence) Thus I quite understand why Pali is frustrated, since he has done the work over a year ago. I am awfully sorry about this :-( By no means I have forgotten about this. We at Turris still want to work on this, since we are still interested in maintaining Turris 1.x. We are currently in the process of hiring new kernel developers, and so hopefully I will be able to work on this issue soon. Marek
Re: mmc: Read eMMC partition access bits before card reset
On Mon, Jun 12, 2023 at 07:39:20PM +0200, Pali Rohár wrote: > On Monday 12 June 2023 11:22:12 Stefan Roese wrote: > > Hi Pali, > > > > (added Peng for PowerPC and Jaehoon for MMC to Cc) > > > > On 6/11/23 15:03, Pali Rohár wrote: > > > > > > > > > > Pali, I will try to pull these not applied patches - if there are not > > > > issues of course. Could you please send me a list of these patches so > > > > that I can take look? Please note that I will probably not be able to > > > > work on this this week. But next week should be possible. > > > > > > > > Thanks, > > > > Stefan > > > > > > Hello! > > > > > > These patches are on the list for year: > > > https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-p...@kernel.org/ > > > > This patch fails with multiple problems. Reason is, that it's very "old" > > and many of the Kconfig stuff was changed, which is of course not your > > fault. Still, I'm not in the right position to make these changes I'm > > afraid. > > > > Peng, this patch is now assigned to you in patchwork. Could you please > > also take a look? And if Pali (or someone else) sends an updated > > version, could you please make sure that it's reviewed (and applied if > > no issues arise) in due time? > > Updated version was already sent but again no response... > https://patchwork.ozlabs.org/project/uboot/patch/20220817205622.26644-1-p...@kernel.org/ I was expecting Marek Behún to follow up and take this as he's the one that volunteered to take over one of the powerpc custodian trees and push this through. I've replied now with more feedback. > > > https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-ka...@kernel.org/ > > > > AFAICT, this patch has some open issues still. > > There were suggestion to make (that new kconfig option) enabled for > everything. But nobody respond if it is possible to have it > unconditionally enabled for every one board. Hence new config option in > that patch was introduced. Yes, the feedback was to change things so that the behavior is the default, since it looks like what we're doing now is wrong. And you have access to a few platforms to test things on to see if it breaks other platforms, and then putting it in to -next or early in the merge cycle on master would shake out any other problems with the approach. So if you're still interested in that platform, please make it a generic change or report back where it does fail so we can see what's going on elsewhere. Making the init_sequence_f table even more difficult to read is something we do want to avoid. -- Tom signature.asc Description: PGP signature
Re: mmc: Read eMMC partition access bits before card reset
On Monday 12 June 2023 11:22:12 Stefan Roese wrote: > Hi Pali, > > (added Peng for PowerPC and Jaehoon for MMC to Cc) > > On 6/11/23 15:03, Pali Rohár wrote: > > > > > > Pali, I will try to pull these not applied patches - if there are not > > > issues of course. Could you please send me a list of these patches so > > > that I can take look? Please note that I will probably not be able to > > > work on this this week. But next week should be possible. > > > > > > Thanks, > > > Stefan > > > > Hello! > > > > These patches are on the list for year: > > https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-p...@kernel.org/ > > This patch fails with multiple problems. Reason is, that it's very "old" > and many of the Kconfig stuff was changed, which is of course not your > fault. Still, I'm not in the right position to make these changes I'm > afraid. > > Peng, this patch is now assigned to you in patchwork. Could you please > also take a look? And if Pali (or someone else) sends an updated > version, could you please make sure that it's reviewed (and applied if > no issues arise) in due time? Updated version was already sent but again no response... https://patchwork.ozlabs.org/project/uboot/patch/20220817205622.26644-1-p...@kernel.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-ka...@kernel.org/ > > AFAICT, this patch has some open issues still. There were suggestion to make (that new kconfig option) enabled for everything. But nobody respond if it is possible to have it unconditionally enabled for every one board. Hence new config option in that patch was introduced. > > https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-p...@kernel.org/ > > This one is now in next. I've updated here the patchwork status. Perfect! Finally some response here. > > And these patches waiting for two months: > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-p...@kernel.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-p...@kernel.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-p...@kernel.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-p...@kernel.org/ > > Jaehoon, could you please take a look at these MMC related patches? And > if no issues arise, pull them into next? > > > For other issues I added you to CC. > > Thanks, > Stefan
Re: mmc: Read eMMC partition access bits before card reset
Hi Pali, (added Peng for PowerPC and Jaehoon for MMC to Cc) On 6/11/23 15:03, Pali Rohár wrote: Pali, I will try to pull these not applied patches - if there are not issues of course. Could you please send me a list of these patches so that I can take look? Please note that I will probably not be able to work on this this week. But next week should be possible. Thanks, Stefan Hello! These patches are on the list for year: https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-p...@kernel.org/ This patch fails with multiple problems. Reason is, that it's very "old" and many of the Kconfig stuff was changed, which is of course not your fault. Still, I'm not in the right position to make these changes I'm afraid. Peng, this patch is now assigned to you in patchwork. Could you please also take a look? And if Pali (or someone else) sends an updated version, could you please make sure that it's reviewed (and applied if no issues arise) in due time? https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-ka...@kernel.org/ AFAICT, this patch has some open issues still. https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-p...@kernel.org/ This one is now in next. I've updated here the patchwork status. And these patches waiting for two months: https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/ https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-p...@kernel.org/ https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-p...@kernel.org/ https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-p...@kernel.org/ https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-p...@kernel.org/ Jaehoon, could you please take a look at these MMC related patches? And if no issues arise, pull them into next? For other issues I added you to CC. Thanks, Stefan
Re: mmc: Read eMMC partition access bits before card reset
On Thursday 25 May 2023 14:57:32 Stefan Roese wrote: > Hi Tony, > Hi Pali, > > On 5/18/23 22:55, Tony Dinh wrote: > > Hi Stefan, > > > > On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote: > > > > > > Hi Pali, > > > > > > On 5/17/23 00:30, Pali Rohár wrote: > > > > On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > > > > > On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > > > > > > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > > > > > > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > > > > > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > > > > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > > > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > > > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali > > > > > > > > > > > > > > Rohár wrote: > > > > > > > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, > > > > > > > > > > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell > > > > > > > > > > > > > > > > > related patches: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits > > > > > > > > > > > > > > > > before card reset > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access > > > > > > > > > > > > > > > > partitions" says that all reset > > > > > > > > > > > > > > > > events will restore the access bits in > > > > > > > > > > > > > > > > PARTITION_CONFIG CSD register to > > > > > > > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So read partition access bits from > > > > > > > > > > > > > > > > PARTITION_CONFIG CSD register before > > > > > > > > > > > > > > > > issuing card reset. This allows > > > > > > > > > > > > > > > > SPL/U-Boot to get information which eMMC > > > > > > > > > > > > > > > > partition was in use before SPL/U-Boot > > > > > > > > > > > > > > > > was booted. For some platforms this > > > > > > > > > > > > > > > > is the way how to determinate boot > > > > > > > > > > > > > > > > partition from which BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May > > > > > > > > > > > > > > > > 03 2023 - 13:10:10 -0400) > > > > > > > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd > > > > > > > > > > > > > > > > inhibit to clear > > > > > > > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as > > > > > > > > > > > > > > > > needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only > > > > > > > > > > > > > > > idea is to hide this code > > > > > > > > > > > > > > > behind CONFIG symbol and enable it only for > > > > > > > > > > > > > > > mvebu. For example by this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD > > > > > > > > > > > > > > cards? The failure I > > > > > > > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this > > > > > > > > > > > > > stage we do not know if > > > > > > > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > > > > > > > > > > > > > Martin, can you check if booting from SD card is > > > > > > > > > > > > > working fine on mvebu > > > > > > > > > > > > > clearfog? > > > > > > > > > > > > > > > >
Re: mmc: Read eMMC partition access bits before card reset
Hi Tony, Hi Pali, On 5/18/23 22:55, Tony Dinh wrote: Hi Stefan, On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote: Hi Pali, On 5/17/23 00:30, Pali Rohár wrote: On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: On Sunday 07 May 2023 12:45:11 Tom Rini wrote: On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: On Sunday 07 May 2023 10:40:44 Tom Rini wrote: On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: On Sunday 07 May 2023 09:54:52 Tom Rini wrote: On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: Hi Tom, please pull this next batch of mostly Marvell related patches: NAK. With commit: commit 461fa17970de418a93832f734a595031c0b72128 Author: Pali Rohár Date: Thu Apr 13 22:57:48 2023 +0200 mmc: Read eMMC partition access bits before card reset eMMC specification in section "Access partitions" says that all reset events will restore the access bits in PARTITION_CONFIG CSD register to default User Data Area value (0b000). So read partition access bits from PARTITION_CONFIG CSD register before issuing card reset. This allows SPL/U-Boot to get information which eMMC partition was in use before SPL/U-Boot was booted. For some platforms this is the way how to determinate boot partition from which BootROM loaded SPL. Signed-off-by: Pali Rohár My am335x_evm now fails to boot with: U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) Trying to boot from MMC1 omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed with error: -110 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I can provide more details / test patches as needed. -- Tom I do not know what to do with this... The only idea is to hide this code behind CONFIG symbol and enable it only for mvebu. For example by this: Well, maybe the problem is we're trying this on uSD cards? The failure I reported was uSD and not eMMC. Maybe it is that reason. Problem is that at this stage we do not know if card is SD or MMC. Martin, can you check if booting from SD card is working fine on mvebu clearfog? I see a failure with this commit on rpi_3_32b, also from uSD boot. This time it's: Loading Environment from FAT... fsm 0, hsts fsm 0, hsts ... once in U-Boot itself. Going to the commit prior to the above one and the board is fine again. -- Tom Immediately after that "problematic code" is card reset function. So another reason for failure is that card reset functionality does not work correctly on your board / platform. Well, we're at two different platforms and controllers that this change breaks things on, so I'm not sure where the fault is exactly. My mx6cuboxi is still fine booting from uSD. Another TI platform from the same general era as am335x fails the same way (not a surprise), amlogic libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are also fine with this. So maybe the Kconfig is fine, but we just want default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms that work are not ARCH_OMAP2PLUS). -- Tom And do you see this problem in SPL or in proper U-Boot? If omap2plus is problematic then I can do tests on Nokia N900 or at its qemu emulated version (to which can be attached gdb). But Nokia N900 is without SPL. OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it tries uSD. In this case, full U-Boot also fails: Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear ** Bad device specification mmc 0 ** Note that N900 in QEMU passes, but I suspect that's a matter of the emulator not being faithful to some undocumented bug/feature of the chipset and that it would also fail like this on real HW or that we aren't relying on MMC in such a way that the QEMU tests actually report failure. When I booted the above, it was not a lock-up since we can continue on in this case, rather than failure to load U-Boot itself. -- Tom Ok, I have tested it on Nokia N900 HW and interesting is that SD card is also working fine. But its initialization is slower and prints warning: omap_hsmmc_send_cmd: timeout waiting on cmd inhibit to clear Ok, so what with it? Seems like this change is a real bad idea to introduce on ARCH_OMAP2PLUS platforms, and probably ARCH_BCM283X too, so rework with a Kconfig option that defaults to on except for the above as I suggested? -- Tom Ok, patch is on the list... I'm curious if patch stay here on the list more than one year like some other... I mean, since I asked you to spin a
Re: mmc: Read eMMC partition access bits before card reset
Hi Stefan, On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote: > > Hi Pali, > > On 5/17/23 00:30, Pali Rohár wrote: > > On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > >> On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > >>> On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > >> On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > >>> On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > >> On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > >>> On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > >> Hi Tom, > >> > >> please pull this next batch of mostly Marvell related patches: > > > > NAK. With commit: > > commit 461fa17970de418a93832f734a595031c0b72128 > > Author: Pali Rohár > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > mmc: Read eMMC partition access bits before card reset > > > > eMMC specification in section "Access partitions" says > > that all reset > > events will restore the access bits in PARTITION_CONFIG > > CSD register to > > default User Data Area value (0b000). > > > > So read partition access bits from PARTITION_CONFIG CSD > > register before > > issuing card reset. This allows SPL/U-Boot to get > > information which eMMC > > partition was in use before SPL/U-Boot was booted. For > > some platforms this > > is the way how to determinate boot partition from which > > BootROM loaded SPL. > > > > Signed-off-by: Pali Rohár > > > > My am335x_evm now fails to boot with: > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > 13:10:10 -0400) > > Trying to boot from MMC1 > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > spl: mmc init failed with error: -110 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > I can provide more details / test patches as needed. > > > > -- > > Tom > > I do not know what to do with this... The only idea is to hide > this code > behind CONFIG symbol and enable it only for mvebu. For example > by this: > >>> > >>> Well, maybe the problem is we're trying this on uSD cards? The > >>> failure I > >>> reported was uSD and not eMMC. > >> > >> Maybe it is that reason. Problem is that at this stage we do not > >> know if > >> card is SD or MMC. > >> > >> Martin, can you check if booting from SD card is working fine on > >> mvebu > >> clearfog? > >> > >>> I see a failure with this commit on > >>> rpi_3_32b, also from uSD boot. This time it's: > >>> Loading Environment from FAT... fsm 0, hsts > >>> fsm 0, hsts > >>> ... > >>> > >>> once in U-Boot itself. Going to the commit prior to the above > >>> one and > >>> the board is fine again. > >>> > >>> -- > >>> Tom > >> > >> Immediately after that "problematic code" is card reset function. > >> So > >> another reason for failure is that card reset functionality does > >> not > >> work correctly on your board / platform. > > > > Well, we're at two different platforms and controllers that this > > change > > breaks things on, so I'm not sure where the fault is exactly. My > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > the > > same general era as am335x fails the same way (not a surprise), > > amlogic > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > platforms are > > also fine with this. So maybe the Kconfig is fine, but we just want > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > platforms > > that work are not ARCH_OMAP2PLUS). > > > > -- > > Tom > > And do you see this problem in SPL
Re: mmc: Read eMMC partition access bits before card reset
Hi Pali, On 5/17/23 00:30, Pali Rohár wrote: On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: On Sunday 07 May 2023 12:45:11 Tom Rini wrote: On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: On Sunday 07 May 2023 10:40:44 Tom Rini wrote: On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: On Sunday 07 May 2023 09:54:52 Tom Rini wrote: On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: Hi Tom, please pull this next batch of mostly Marvell related patches: NAK. With commit: commit 461fa17970de418a93832f734a595031c0b72128 Author: Pali Rohár Date: Thu Apr 13 22:57:48 2023 +0200 mmc: Read eMMC partition access bits before card reset eMMC specification in section "Access partitions" says that all reset events will restore the access bits in PARTITION_CONFIG CSD register to default User Data Area value (0b000). So read partition access bits from PARTITION_CONFIG CSD register before issuing card reset. This allows SPL/U-Boot to get information which eMMC partition was in use before SPL/U-Boot was booted. For some platforms this is the way how to determinate boot partition from which BootROM loaded SPL. Signed-off-by: Pali Rohár My am335x_evm now fails to boot with: U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) Trying to boot from MMC1 omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed with error: -110 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I can provide more details / test patches as needed. -- Tom I do not know what to do with this... The only idea is to hide this code behind CONFIG symbol and enable it only for mvebu. For example by this: Well, maybe the problem is we're trying this on uSD cards? The failure I reported was uSD and not eMMC. Maybe it is that reason. Problem is that at this stage we do not know if card is SD or MMC. Martin, can you check if booting from SD card is working fine on mvebu clearfog? I see a failure with this commit on rpi_3_32b, also from uSD boot. This time it's: Loading Environment from FAT... fsm 0, hsts fsm 0, hsts ... once in U-Boot itself. Going to the commit prior to the above one and the board is fine again. -- Tom Immediately after that "problematic code" is card reset function. So another reason for failure is that card reset functionality does not work correctly on your board / platform. Well, we're at two different platforms and controllers that this change breaks things on, so I'm not sure where the fault is exactly. My mx6cuboxi is still fine booting from uSD. Another TI platform from the same general era as am335x fails the same way (not a surprise), amlogic libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are also fine with this. So maybe the Kconfig is fine, but we just want default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms that work are not ARCH_OMAP2PLUS). -- Tom And do you see this problem in SPL or in proper U-Boot? If omap2plus is problematic then I can do tests on Nokia N900 or at its qemu emulated version (to which can be attached gdb). But Nokia N900 is without SPL. OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it tries uSD. In this case, full U-Boot also fails: Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear ** Bad device specification mmc 0 ** Note that N900 in QEMU passes, but I suspect that's a matter of the emulator not being faithful to some undocumented bug/feature of the chipset and that it would also fail like this on real HW or that we aren't relying on MMC in such a way that the QEMU tests actually report failure. When I booted the above, it was not a lock-up since we can continue on in this case, rather than failure to load U-Boot itself. -- Tom Ok, I have tested it on Nokia N900 HW and interesting is that SD card is also working fine. But its initialization is slower and prints warning: omap_hsmmc_send_cmd: timeout waiting on cmd inhibit to clear Ok, so what with it? Seems like this change is a real bad idea to introduce on ARCH_OMAP2PLUS platforms, and probably ARCH_BCM283X too, so rework with a Kconfig option that defaults to on except for the above as I suggested? -- Tom Ok, patch is on the list... I'm curious if patch stay here on the list more than one year like some other... I mean, since I asked you to spin a new patch and you posted a patch on top of the previously rejected one, someone will need to pick it up and fold it
Re: mmc: Read eMMC partition access bits before card reset
On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card > > > > > > > > > > > > reset > > > > > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" > > > > > > > > > > > > says that all reset > > > > > > > > > > > > events will restore the access bits in > > > > > > > > > > > > PARTITION_CONFIG CSD register to > > > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG > > > > > > > > > > > > CSD register before > > > > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > > > > information which eMMC > > > > > > > > > > > > partition was in use before SPL/U-Boot was booted. > > > > > > > > > > > > For some platforms this > > > > > > > > > > > > is the way how to determinate boot partition from > > > > > > > > > > > > which BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 > > > > > > > > > > > > - 13:10:10 -0400) > > > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to > > > > > > > > > > > > clear > > > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to > > > > > > > > > > > hide this code > > > > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For > > > > > > > > > > > example by this: > > > > > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? > > > > > > > > > > The failure I > > > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do > > > > > > > > > not know if > > > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine > > > > > > > > > on mvebu > > > > > > > > > clearfog? > > > > > > > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > > > > fsm 0, hsts > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the > > > > > > > > > > above one and > > > > > > > > > > the board is fine again. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > Immediately after that "problematic code" is card reset > > > > > > > > > function. So > > > > > > > > > another reason for failure is that card reset functionality > > > > > > > > > does not > > > > > > > > > work correctly on your board / platform. > > > > > > > > > > > > > > > > Well, we're at two different platforms and controllers that > > > > > > > > this change > > > > > > > > breaks things on, so I'm not sure where the fault is exactly. > > > > > > > >
Re: mmc: Read eMMC partition access bits before card reset
On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" > > > > > > > > > > > says that all reset > > > > > > > > > > > events will restore the access bits in > > > > > > > > > > > PARTITION_CONFIG CSD register to > > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG > > > > > > > > > > > CSD register before > > > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > > > information which eMMC > > > > > > > > > > > partition was in use before SPL/U-Boot was booted. > > > > > > > > > > > For some platforms this > > > > > > > > > > > is the way how to determinate boot partition from > > > > > > > > > > > which BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > > > > 13:10:10 -0400) > > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to > > > > > > > > > > > clear > > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to > > > > > > > > > > hide this code > > > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For > > > > > > > > > > example by this: > > > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? > > > > > > > > > The failure I > > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do > > > > > > > > not know if > > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine > > > > > > > > on mvebu > > > > > > > > clearfog? > > > > > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > > > fsm 0, hsts > > > > > > > > > ... > > > > > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the > > > > > > > > > above one and > > > > > > > > > the board is fine again. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Tom > > > > > > > > > > > > > > > > Immediately after that "problematic code" is card reset > > > > > > > > function. So > > > > > > > > another reason for failure is that card reset functionality > > > > > > > > does not > > > > > > > > work correctly on your board / platform. > > > > > > > > > > > > > > Well, we're at two different platforms and controllers that this > > > > > > > change > > > > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > > > > mx6cuboxi is still fine booting from uSD. Another TI platform > > > > > > > from the > > > > > > > same general era as am335x fails the same way (not a surprise), > > > > > > > amlogic > > > > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > > >
Re: mmc: Read eMMC partition access bits before card reset
On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says > > > > > > > > > > that all reset > > > > > > > > > > events will restore the access bits in PARTITION_CONFIG > > > > > > > > > > CSD register to > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > > > > register before > > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > > information which eMMC > > > > > > > > > > partition was in use before SPL/U-Boot was booted. For > > > > > > > > > > some platforms this > > > > > > > > > > is the way how to determinate boot partition from which > > > > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > > > 13:10:10 -0400) > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to > > > > > > > > > > clear > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to > > > > > > > > > hide this code > > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For > > > > > > > > > example by this: > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > > > > failure I > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not > > > > > > > know if > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine on > > > > > > > mvebu > > > > > > > clearfog? > > > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > > fsm 0, hsts > > > > > > > > ... > > > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above > > > > > > > > one and > > > > > > > > the board is fine again. > > > > > > > > > > > > > > > > -- > > > > > > > > Tom > > > > > > > > > > > > > > Immediately after that "problematic code" is card reset function. > > > > > > > So > > > > > > > another reason for failure is that card reset functionality does > > > > > > > not > > > > > > > work correctly on your board / platform. > > > > > > > > > > > > Well, we're at two different platforms and controllers that this > > > > > > change > > > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > > > > > the > > > > > > same general era as am335x fails the same way (not a surprise), > > > > > > amlogic > > > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > > > > > platforms are > > > > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > > > > > platforms > > > > > > that work are not ARCH_OMAP2PLUS). > > > > > > > > > >
Re: mmc: Read eMMC partition access bits before card reset
On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > Author: Pali Rohár > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says > > > > > > > > > that all reset > > > > > > > > > events will restore the access bits in PARTITION_CONFIG > > > > > > > > > CSD register to > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > > > register before > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > information which eMMC > > > > > > > > > partition was in use before SPL/U-Boot was booted. For > > > > > > > > > some platforms this > > > > > > > > > is the way how to determinate boot partition from which > > > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > > 13:10:10 -0400) > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Tom > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to hide > > > > > > > > this code > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For example > > > > > > > > by this: > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > > > failure I > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not > > > > > > know if > > > > > > card is SD or MMC. > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine on > > > > > > mvebu > > > > > > clearfog? > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > fsm 0, hsts > > > > > > > ... > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above > > > > > > > one and > > > > > > > the board is fine again. > > > > > > > > > > > > > > -- > > > > > > > Tom > > > > > > > > > > > > Immediately after that "problematic code" is card reset function. So > > > > > > another reason for failure is that card reset functionality does not > > > > > > work correctly on your board / platform. > > > > > > > > > > Well, we're at two different platforms and controllers that this > > > > > change > > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > > > > the > > > > > same general era as am335x fails the same way (not a surprise), > > > > > amlogic > > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms > > > > > are > > > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > > > > platforms > > > > > that work are not ARCH_OMAP2PLUS). > > > > > > > > > > -- > > > > > Tom > > > > > > > > And do you see this problem in SPL or in proper U-Boot? > > > > > > > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > > > > qemu emulated version (to which can be attached gdb). But Nokia N900 is > > > > without SPL. > > > > > > > > > OK, so on am335x_evm
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > Author: Pali Rohár > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says that > > > > > > > > all reset > > > > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > > > > register to > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > > register before > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > information which eMMC > > > > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > > > > platforms this > > > > > > > > is the way how to determinate boot partition from which > > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > 13:10:10 -0400) > > > > > > > > Trying to boot from MMC1 > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > -- > > > > > > > > Tom > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to hide > > > > > > > this code > > > > > > > behind CONFIG symbol and enable it only for mvebu. For example by > > > > > > > this: > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > > failure I > > > > > > reported was uSD and not eMMC. > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not know > > > > > if > > > > > card is SD or MMC. > > > > > > > > > > Martin, can you check if booting from SD card is working fine on mvebu > > > > > clearfog? > > > > > > > > > > > I see a failure with this commit on > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > fsm 0, hsts > > > > > > ... > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above one > > > > > > and > > > > > > the board is fine again. > > > > > > > > > > > > -- > > > > > > Tom > > > > > > > > > > Immediately after that "problematic code" is card reset function. So > > > > > another reason for failure is that card reset functionality does not > > > > > work correctly on your board / platform. > > > > > > > > Well, we're at two different platforms and controllers that this change > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > mx6cuboxi is still fine booting from uSD. Another TI platform from the > > > > same general era as am335x fails the same way (not a surprise), amlogic > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > > > > that work are not ARCH_OMAP2PLUS). > > > > > > > > -- > > > > Tom > > > > > > And do you see this problem in SPL or in proper U-Boot? > > > > > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > > > qemu emulated version (to which can be attached gdb). But Nokia N900 is > > > without SPL. > > > > > > OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it > > tries uSD. In this case, full U-Boot also fails: > > Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on > > cmd inhibit to clear > > ** Bad device specification mmc 0 ** > > > > Note that N900 in QEMU passes, but I suspect that's a matter of the > > emulator not being faithful to
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > > > > > NAK. With commit: > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > Author: Pali Rohár > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says that > > > > > > > all reset > > > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > > > register to > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > register before > > > > > > > issuing card reset. This allows SPL/U-Boot to get information > > > > > > > which eMMC > > > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > > > platforms this > > > > > > > is the way how to determinate boot partition from which > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > 13:10:10 -0400) > > > > > > > Trying to boot from MMC1 > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > > spl: mmc init failed with error: -110 > > > > > > > SPL: failed to boot from all boot devices > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > -- > > > > > > > Tom > > > > > > > > > > > > I do not know what to do with this... The only idea is to hide this > > > > > > code > > > > > > behind CONFIG symbol and enable it only for mvebu. For example by > > > > > > this: > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > failure I > > > > > reported was uSD and not eMMC. > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not know if > > > > card is SD or MMC. > > > > > > > > Martin, can you check if booting from SD card is working fine on mvebu > > > > clearfog? > > > > > > > > > I see a failure with this commit on > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > fsm 0, hsts > > > > > ... > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above one and > > > > > the board is fine again. > > > > > > > > > > -- > > > > > Tom > > > > > > > > Immediately after that "problematic code" is card reset function. So > > > > another reason for failure is that card reset functionality does not > > > > work correctly on your board / platform. > > > > > > Well, we're at two different platforms and controllers that this change > > > breaks things on, so I'm not sure where the fault is exactly. My > > > mx6cuboxi is still fine booting from uSD. Another TI platform from the > > > same general era as am335x fails the same way (not a surprise), amlogic > > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > > > that work are not ARCH_OMAP2PLUS). > > > > > > -- > > > Tom > > > > And do you see this problem in SPL or in proper U-Boot? > > > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > > qemu emulated version (to which can be attached gdb). But Nokia N900 is > > without SPL. > > > OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it > tries uSD. In this case, full U-Boot also fails: > Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on > cmd inhibit to clear > ** Bad device specification mmc 0 ** > > Note that N900 in QEMU passes, but I suspect that's a matter of the > emulator not being faithful to some undocumented bug/feature of the > chipset and that it would also fail like this on real HW or that we > aren't relying on MMC in such a way that the QEMU tests actually report > failure. When I booted the above, it was not a lock-up since we can > continue on in this case, rather than
Re: mmc: Read eMMC partition access bits before card reset
On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > > > NAK. With commit: > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > Author: Pali Rohár > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > eMMC specification in section "Access partitions" says that all > > > > > > reset > > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > > register to > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > register before > > > > > > issuing card reset. This allows SPL/U-Boot to get information > > > > > > which eMMC > > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > > platforms this > > > > > > is the way how to determinate boot partition from which BootROM > > > > > > loaded SPL. > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 > > > > > > -0400) > > > > > > Trying to boot from MMC1 > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > spl: mmc init failed with error: -110 > > > > > > SPL: failed to boot from all boot devices > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > -- > > > > > > Tom > > > > > > > > > > I do not know what to do with this... The only idea is to hide this > > > > > code > > > > > behind CONFIG symbol and enable it only for mvebu. For example by > > > > > this: > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The failure I > > > > reported was uSD and not eMMC. > > > > > > Maybe it is that reason. Problem is that at this stage we do not know if > > > card is SD or MMC. > > > > > > Martin, can you check if booting from SD card is working fine on mvebu > > > clearfog? > > > > > > > I see a failure with this commit on > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > Loading Environment from FAT... fsm 0, hsts > > > > fsm 0, hsts > > > > ... > > > > > > > > once in U-Boot itself. Going to the commit prior to the above one and > > > > the board is fine again. > > > > > > > > -- > > > > Tom > > > > > > Immediately after that "problematic code" is card reset function. So > > > another reason for failure is that card reset functionality does not > > > work correctly on your board / platform. > > > > Well, we're at two different platforms and controllers that this change > > breaks things on, so I'm not sure where the fault is exactly. My > > mx6cuboxi is still fine booting from uSD. Another TI platform from the > > same general era as am335x fails the same way (not a surprise), amlogic > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > > also fine with this. So maybe the Kconfig is fine, but we just want > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > > that work are not ARCH_OMAP2PLUS). > > > > -- > > Tom > > And do you see this problem in SPL or in proper U-Boot? > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > qemu emulated version (to which can be attached gdb). But Nokia N900 is > without SPL. OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it tries uSD. In this case, full U-Boot also fails: Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear ** Bad device specification mmc 0 ** Note that N900 in QEMU passes, but I suspect that's a matter of the emulator not being faithful to some undocumented bug/feature of the chipset and that it would also fail like this on real HW or that we aren't relying on MMC in such a way that the QEMU tests actually report failure. When I booted the above, it was not a lock-up since we can continue on in this case, rather than failure to load U-Boot itself. -- Tom signature.asc Description: PGP signature
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > NAK. With commit: > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > Author: Pali Rohár > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > eMMC specification in section "Access partitions" says that all > > > > > reset > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > register to > > > > > default User Data Area value (0b000). > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD register > > > > > before > > > > > issuing card reset. This allows SPL/U-Boot to get information > > > > > which eMMC > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > platforms this > > > > > is the way how to determinate boot partition from which BootROM > > > > > loaded SPL. > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 > > > > > -0400) > > > > > Trying to boot from MMC1 > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > spl: mmc init failed with error: -110 > > > > > SPL: failed to boot from all boot devices > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > -- > > > > > Tom > > > > > > > > I do not know what to do with this... The only idea is to hide this code > > > > behind CONFIG symbol and enable it only for mvebu. For example by this: > > > > > > Well, maybe the problem is we're trying this on uSD cards? The failure I > > > reported was uSD and not eMMC. > > > > Maybe it is that reason. Problem is that at this stage we do not know if > > card is SD or MMC. > > > > Martin, can you check if booting from SD card is working fine on mvebu > > clearfog? > > > > > I see a failure with this commit on > > > rpi_3_32b, also from uSD boot. This time it's: > > > Loading Environment from FAT... fsm 0, hsts > > > fsm 0, hsts > > > ... > > > > > > once in U-Boot itself. Going to the commit prior to the above one and > > > the board is fine again. > > > > > > -- > > > Tom > > > > Immediately after that "problematic code" is card reset function. So > > another reason for failure is that card reset functionality does not > > work correctly on your board / platform. > > Well, we're at two different platforms and controllers that this change > breaks things on, so I'm not sure where the fault is exactly. My > mx6cuboxi is still fine booting from uSD. Another TI platform from the > same general era as am335x fails the same way (not a surprise), amlogic > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > also fine with this. So maybe the Kconfig is fine, but we just want > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > that work are not ARCH_OMAP2PLUS). > > -- > Tom And do you see this problem in SPL or in proper U-Boot? If omap2plus is problematic then I can do tests on Nokia N900 or at its qemu emulated version (to which can be attached gdb). But Nokia N900 is without SPL.
Re: mmc: Read eMMC partition access bits before card reset
On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > NAK. With commit: > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > Author: Pali Rohár > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > eMMC specification in section "Access partitions" says that all > > > > reset > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > register to > > > > default User Data Area value (0b000). > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD register > > > > before > > > > issuing card reset. This allows SPL/U-Boot to get information which > > > > eMMC > > > > partition was in use before SPL/U-Boot was booted. For some > > > > platforms this > > > > is the way how to determinate boot partition from which BootROM > > > > loaded SPL. > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 > > > > -0400) > > > > Trying to boot from MMC1 > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > spl: mmc init failed with error: -110 > > > > SPL: failed to boot from all boot devices > > > > ### ERROR ### Please RESET the board ### > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > -- > > > > Tom > > > > > > I do not know what to do with this... The only idea is to hide this code > > > behind CONFIG symbol and enable it only for mvebu. For example by this: > > > > Well, maybe the problem is we're trying this on uSD cards? The failure I > > reported was uSD and not eMMC. > > Maybe it is that reason. Problem is that at this stage we do not know if > card is SD or MMC. > > Martin, can you check if booting from SD card is working fine on mvebu > clearfog? > > > I see a failure with this commit on > > rpi_3_32b, also from uSD boot. This time it's: > > Loading Environment from FAT... fsm 0, hsts > > fsm 0, hsts > > ... > > > > once in U-Boot itself. Going to the commit prior to the above one and > > the board is fine again. > > > > -- > > Tom > > Immediately after that "problematic code" is card reset function. So > another reason for failure is that card reset functionality does not > work correctly on your board / platform. Well, we're at two different platforms and controllers that this change breaks things on, so I'm not sure where the fault is exactly. My mx6cuboxi is still fine booting from uSD. Another TI platform from the same general era as am335x fails the same way (not a surprise), amlogic libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are also fine with this. So maybe the Kconfig is fine, but we just want default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms that work are not ARCH_OMAP2PLUS). -- Tom signature.asc Description: PGP signature
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > Hi Tom, > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > NAK. With commit: > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > Author: Pali Rohár > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > eMMC specification in section "Access partitions" says that all reset > > > events will restore the access bits in PARTITION_CONFIG CSD register > > > to > > > default User Data Area value (0b000). > > > > > > So read partition access bits from PARTITION_CONFIG CSD register > > > before > > > issuing card reset. This allows SPL/U-Boot to get information which > > > eMMC > > > partition was in use before SPL/U-Boot was booted. For some platforms > > > this > > > is the way how to determinate boot partition from which BootROM > > > loaded SPL. > > > > > > Signed-off-by: Pali Rohár > > > > > > My am335x_evm now fails to boot with: > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) > > > Trying to boot from MMC1 > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > spl: mmc init failed with error: -110 > > > SPL: failed to boot from all boot devices > > > ### ERROR ### Please RESET the board ### > > > > > > I can provide more details / test patches as needed. > > > > > > -- > > > Tom > > > > I do not know what to do with this... The only idea is to hide this code > > behind CONFIG symbol and enable it only for mvebu. For example by this: > > Well, maybe the problem is we're trying this on uSD cards? The failure I > reported was uSD and not eMMC. Maybe it is that reason. Problem is that at this stage we do not know if card is SD or MMC. Martin, can you check if booting from SD card is working fine on mvebu clearfog? > I see a failure with this commit on > rpi_3_32b, also from uSD boot. This time it's: > Loading Environment from FAT... fsm 0, hsts > fsm 0, hsts > ... > > once in U-Boot itself. Going to the commit prior to the above one and > the board is fine again. > > -- > Tom Immediately after that "problematic code" is card reset function. So another reason for failure is that card reset functionality does not work correctly on your board / platform.
Re: mmc: Read eMMC partition access bits before card reset
On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > Hi Tom, > > > > > > please pull this next batch of mostly Marvell related patches: > > > > NAK. With commit: > > commit 461fa17970de418a93832f734a595031c0b72128 > > Author: Pali Rohár > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > mmc: Read eMMC partition access bits before card reset > > > > eMMC specification in section "Access partitions" says that all reset > > events will restore the access bits in PARTITION_CONFIG CSD register to > > default User Data Area value (0b000). > > > > So read partition access bits from PARTITION_CONFIG CSD register before > > issuing card reset. This allows SPL/U-Boot to get information which eMMC > > partition was in use before SPL/U-Boot was booted. For some platforms > > this > > is the way how to determinate boot partition from which BootROM loaded > > SPL. > > > > Signed-off-by: Pali Rohár > > > > My am335x_evm now fails to boot with: > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) > > Trying to boot from MMC1 > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > spl: mmc init failed with error: -110 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > I can provide more details / test patches as needed. > > > > -- > > Tom > > I do not know what to do with this... The only idea is to hide this code > behind CONFIG symbol and enable it only for mvebu. For example by this: Well, maybe the problem is we're trying this on uSD cards? The failure I reported was uSD and not eMMC. I see a failure with this commit on rpi_3_32b, also from uSD boot. This time it's: Loading Environment from FAT... fsm 0, hsts fsm 0, hsts ... once in U-Boot itself. Going to the commit prior to the above one and the board is fine again. -- Tom signature.asc Description: PGP signature
