Jetson Nano warm resets fail with u-boot (no partition table) errors

,

Hello Nvidia,

I’m wanting to boot from sdmmc3 on our custom carrier board but u-boot is having issues specifically with UHS micro sd cards across soft/warm reboots. I’m looking for a uboot patch that matches the kernel patch-> Kernel 9875882.diff.zip . This patch was originally posted here

Background:

I have a custom carrier board with the extra SD card slot (sdmmc3) supported. It doesn’t have “card detect” or a load switch / SDMMC_VDD_EN gpio for power (ie. its always-on).

I have followed the instructions copied from Here that states:

Blockquote

  1. The basic device tree change for enabling sdmmc3
    https://forums.developer.nvidia.com/t/microsd-card-not-detected-on-jetson-nano-production-module/80776/14 27
  2. If you notice the mmc speed is slow, please try this patch.
    https://forums.developer.nvidia.com/t/slow-sd-card-access-speed-read-write-with-jetson-nano-production-module/111749/31 13
  3. Some other forum users notice if tring warm boot, the speed becomes slow again. Turns out this patch is also needed in kernel
    https://forums.developer.nvidia.com/t/jetson-nano-sd-card-enters-back-to-high-speed-mode-instead-of-uhs-mode-after-soft-reboot/119041/4 21
  4. Also, for those who do not have SDMMC_VDD_EN gpio on their carrier board, then need to add “nvidia,vmmc-always-on” under sdhci device tree too.

Blockquote

I hit the tuning issue and the warm reset issue and followed the above suggestions to resolve, including applying the kernel warm reboot patch.
SD (for storage only) is now fully functional and supports multiple card speeds even across warm reboots.

Problem:

Now that I can use sdmmc3 for extra storage, I would like to add support for booting from it.

0002-u-boot-tegra-Enabled-jet-carrier-board-s-sd-card-slo.patch (3.4 KB)

In the attached patch I changed mmc1 from 700b0000 to 700b0400 to use sdmmc3, added it to bootable devices, patched pin_mux_mmc to enable ld06 instead of ld02, and then made the relevant u-boot device tree changes.

For non uhs cards, everything works great! I can boot from sd card when detected, emmc when sd card is not detected, and warm reboots work just fine.

For uhs cards I’m hitting the same “warm boot” problem from above that was patched in the kernel. The kernel patch basically detects that the uhs card is already configured and in the 1.8v state when the kernel is attempting to initialize the controller and adjusts for this (ie. ignores invalid cmd response when requesting 1.8v support from sdhci and continues with the uhs initialization).

Is there a uboot specific patch already to resolve warm reboots of uhs cards?

If not, is there a way to manipulate the max77620 ld06 port to simulate card removal and reinsertion?

Please advise.

Thank you.

Extra Details:

Warm resets with uhs cards (formatted for booting) look like this:

– uboot detects the sdcard and attempts to read from it
– uboot spits out error ->tegra_mmc_send_cmd_bounced: error during transfer: 0x00208001
– uboot spits out partition error several times → ** No partition table - mmc 1 **
– uboot falls back to booting from emmc
– kernel detects sd card and “recovers” via earlier discussed patch.
– machine finishes booting from emmc and user can mount sd card without error.

DEBUG:

U-Boot 2020.04 (Apr 05 2011 - 23:00:00 +0000)

SoC: tegra210
Model: NVIDIA Jetson Nano Developer Kit
Board: NVIDIA P3450-0002
DRAM: 4 GiB
MMC: sdhci@700b0400: 1, sdhci@700b0600: 0
Loading Environment from MMC… OK
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
Searching for mmc 1 APP
Found valid partition a, 3 attempts remaining
Scanning mmc 1:0x1…
tegra_mmc_send_cmd_bounced: error during transfer: 0x00208001
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
** No partition table - mmc 1 **
Searching for mmc 1 APP_b
No valid slot found, resetting counts
Saving Environment to MMC… Writing to MMC(0)… OK
switch to partitions #0, OK
mmc0(part 0) is current device
Searching for mmc 0 APP
Found valid partition a, 3 attempts remaining
Scanning mmc 0:0x1…

Sorry that there is no existing solution for this.

Are you sure this only happened to UHS-I card? I mean all the UHSI card would hit this?

I agree, all cards that drop to 1.8v would probably hit this.

Should I focus on porting the kernel patch “logic” to u-boot?
Should I focus on patching the kernel to return the card reader to a known state before rebooting?
Is there a way to recover from this by interacting with max77620 → ld06?

I don’t think I fully understand what difficulties I’m going to encounter and which ones are dead ends.

Thanks.

I don’t quite understand what is exact scenario you hit this error. Could you elaborate why you keep saying warm reboot here?

Sure…

When I literally remove power… and then apply power to boot the device… I consider this a “cold boot”.
When I hit the reset button on the carrier board, I consider this a “hard reset”.

When I type “reboot” from the command line… I consider this to be a “soft reset” and when the device finishes unloading and resetting you will see a “warm boot”.

In other words, a “warm boot” is when the device boots and tries to initialize hardware that could be already in a configured state from the previous boot. It would be up to the kernel to reset hardware back to an un-configured state or the boot loader must handle initializing hardware that was already configured.

I think (still learning the specifics) that currently, a cold boot from u-boot’s perspective powers the io lines to 3.3v, then detects card presence, then detects card capabilities, discovers its uhs and lowers the io lines to 1.8v to start reading and writing. This works great.

On a warm boot / soft reset, u-boot fails to correctly reset or initialize the card and ends up in a weird state.
I’m able to stop at the u-boot prompt and do mmc dev 1, mmc part, mmc info, and it appears to be happy with the inserted card. However, as soon as it continues with the initialization, it fails and starts throwing errors. U-boot is unable to init the sdhci hardware if its was already in a configured state.

I’m currently looking for a max77620 spec to see if setting ld06 requires different behavior if the max77620 was already configured and running. I don’t think I understand this PMIC behavior enough to rule it out.

Also, if I stop the warm boot at the u-boot prompt, remove the sd card and then reinsert… u-boot is happy and everything works as expected.

Ok, so only warm boot case would hit this issue.

Could you share the schematic of your board design?

Unfortunately at this time I can not.

However, I can say that that the card slot is powered at 3.3v by a mechanism that can not be switched (on/off).
Also, the i/o lines are coming out of the Nano which appear to be powered by max7760 PMIC on ld06.

It also appears that u-boot attempts to reset the sdcard. So I’m not sure why the card is still “remembering” the previous state.

Have you found out why only warm boot case hit this issue?
Any result can be shared?

Thanks

My team and I have decided to add a switch to the card slot’s power line so I can toggle the power to the card at boot. I have verified that this workaround resolves the issue.

My current theory is that the micro chip on the physical mircosd card is in a unique state that “by design” expects the user to remove the card (or cycle power) before going through initialization again.

You can see this in the kernel patch mentioned above. In the patch, the card is responding with errors when asked if it supports 1.8v (even though its currently running in 1.8v mode), and the patch ignores the errors and continues anyways.
I believe there is a way to patch u-boot to workaround the same error responses.

I’ll update this post if I get a chance to look into this more at a later date.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.