Fw_printenv fails because of mmc mapping

Technical Support
, ,
1

Hello,
We are using the BSP3.0LTS in combination with the mainline kernel 5.4.61. We noticed that the fw_printenv command fails with:

$ fw_printenv
Cannot open /dev/mmcblk0boot0: No such file or directory

We guess its because our Linux system defines the eMMC as mmc2 instead of mmc0 as u-boot and TEZI:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk2p2  7.8G  1.9G  5.6G  25% /
devtmpfs        954M     0  954M   0% /dev
tmpfs          1008M     0 1008M   0% /dev/shm
tmpfs          1008M   73M  935M   8% /run
tmpfs          1008M     0 1008M   0% /sys/fs/cgroup
tmpfs          1008M     0 1008M   0% /tmp
tmpfs          1008M   28K 1008M   1% /var/volatile

This is the corresponding dmesg:

dmesg | grep mmc
[    2.732056] mmc0: Missing autocal timeout 3v3-pad drvs
[    2.737199] mmc0: Missing autocal timeout 3v3-pad drvs
[    2.742357] mmc0: Missing autocal timeout 1v8-pad drvs
[    2.747497] mmc0: Missing autocal timeout 1v8-pad drvs
[    2.765907] mmc0: Missing autocal timeout 3v3-pad drvs
[    2.771073] mmc0: Missing autocal timeout 3v3-pad drvs
[    2.776214] mmc0: Missing autocal timeout 1v8-pad drvs
[    2.781372] mmc0: Missing autocal timeout 1v8-pad drvs
[    2.794830] mmc0: Missing autocal timeout 3v3-pad drvs
[    2.800001] mmc0: Missing autocal timeout 3v3-pad drvs
[    2.805142] mmc0: Missing autocal timeout 1v8-pad drvs
[    2.810301] mmc0: Missing autocal timeout 1v8-pad drvs
[    3.158160] mmc0: Missing autocal timeout 3v3-pad drvs
[    3.163355] mmc0: Missing autocal timeout 3v3-pad drvs
[    3.168498] mmc0: Missing autocal timeout 1v8-pad drvs
[    3.173746] mmc0: Missing autocal timeout 1v8-pad drvs
[    3.187570] mmc0: Invalid maximum block size, assuming 512 bytes
[    3.364314] mmc0: Internal clock never stabilised.
[    3.369135] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[    3.375583] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00000303
[    3.382095] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[    3.388557] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
[    3.395041] mmc0: sdhci: Present:   0x01fb00f0 | Host ctl: 0x00000000
[    3.401509] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000000
[    3.407970] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000401
[    3.414506] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[    3.420987] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00fc0003
[    3.434147] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[    3.444125] mmc0: sdhci: Caps:      0x376fd080 | Caps_1:   0x10002f77
[    3.450626] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
[    3.457082] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[    3.463544] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[    3.470069] mmc0: sdhci: Host ctl2: 0x00000000
[    3.474537] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x0000000000000000
[    3.481719] mmc0: sdhci: ============================================
[    3.640402] mmc0: Internal clock never stabilised.
[    3.645212] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[    3.651705] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00000303
[    3.658160] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[    3.664625] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
[    3.671093] mmc0: sdhci: Present:   0x01fb00f0 | Host ctl: 0x00000000
[    3.677553] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000000
[    3.684042] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000401
[    3.690503] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[    3.696950] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00fc0003
[    3.703411] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[    3.709873] mmc0: sdhci: Caps:      0x376fd080 | Caps_1:   0x10002f77
[    3.716317] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
[    3.722783] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[    3.729293] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[    3.735738] mmc0: sdhci: Host ctl2: 0x00000000
[    3.740207] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x0000000000000000
[    3.747342] mmc0: sdhci: ============================================
[    3.767015] mmc0: SDHCI controller on 700b0000.sdhci [700b0000.sdhci] using ADMA 64-bit
[    3.780619] mmc1: Missing autocal timeout 3v3-pad drvs
[    3.785761] mmc1: Missing autocal timeout 3v3-pad drvs
[    3.790919] mmc1: Missing autocal timeout 1v8-pad drvs
[    3.796060] mmc1: Missing autocal timeout 1v8-pad drvs
[    3.808442] mmc1: Invalid maximum block size, assuming 512 bytes
[    3.849708] mmc1: SDHCI controller on 700b0400.sdhci [700b0400.sdhci] using ADMA 64-bit
[    3.858308] mmc2: Missing autocal timeout 3v3-pad drvs
[    3.863502] mmc2: Missing autocal timeout 3v3-pad drvs
[    3.868643] mmc2: Missing autocal timeout 1v8-pad drvs
[    3.873801] mmc2: Missing autocal timeout 1v8-pad drvs
[    3.886030] mmc2: Invalid maximum block size, assuming 512 bytes
[    3.919150] mmc2: SDHCI controller on 700b0600.sdhci [700b0600.sdhci] using ADMA 64-bit
[    4.032273] mmc2: new HS200 MMC card at address 0001
[    4.038968] mmcblk2: mmc2:0001 S0J56X 14.8 GiB 
[    4.044721] mmcblk2boot0: mmc2:0001 S0J56X partition 1 31.5 MiB
[    4.051835] mmcblk2boot1: mmc2:0001 S0J56X partition 2 31.5 MiB
[    4.058064] mmcblk2rpmb: mmc2:0001 S0J56X partition 3 4.00 MiB, chardev (247:0)
[    4.069526]  mmcblk2: p1 p2 p3

How can we fix this issue? The image was installed via TEZI and mmc0 was defined as installation target. Do we need to change the device tree somehow? Thanks in advance.

2

No, this likely really was still an issue back then. You would need to adjust the following file from mmcblk0boot0 to mmcblk2boot0:

https://git.toradex.com/cgit/meta-toradex-tegra.git/tree/recipes-bsp/u-boot/files/tegra124m/fw_env.config?h=thud#n14

Much later we transitioned to using libubootenv with proper symlinks which fixed this once and for all.

https://git.toradex.com/cgit/meta-toradex-distro.git/tree/conf/distro/include/tdx-base.inc?h=dunfell-5.x.y#n76

https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/apalis-tk1/99-toradex.rules?h=dunfell-5.x.y#n2

https://git.toradex.com/cgit/meta-toradex-tegra.git/tree/recipes-bsp/u-boot/files/tegra124/fw_env.config?h=dunfell-5.x.y#n14

3

Changing the first file would make fw_printenv work again i guess. However, what would be the recommended way to always use mmc0 as “main” storage? Somehow this is the case in TEZI and it was the same in the old BSP2.8?

4

HI @qojote

The issue of fw_printenv is solved in Bsp 5.2.0+build.7.

Why do you want to use mmc0 as main storage?

Best regards,
Jaski

5

Hi @jaski.tx ,
The TEZI installation package specifies mmc0 as installation target. We are reusing this image for our update mechanism and now this location specification mismatches. It seems that the TEZI kernel/dtb somehow configures the eMMC to be mmc0. We want to be consistent with that.

6

Yeah, actually the partition scheme for Toradex Easy Installer and the reference image cannot be the same, since Toradex Easy installer is using a FIT image on one Partition and the reference image is having two partitions (boot and rootfs).

Best regards,
Jaski

7

We do not want to have the same partitioning for our image like TEZI. Instead we want to have the identical enumeration. The TEZI json scipt specifies mmc0 as target for bootfs and rootfs but when the image is booted the system assumes to be on mmc2. In BSP2.8 everything was fine. Background info: We added an initramfs to our kernel that interpretes the TEZI images by its own, but as the mmc enumeration mismatches the TEZI script this action fails. Same goes for the u-boot which expects its environment on mmc0 - so fw_printenv fails. Patching the fw_printenv to point to mmc2 only conceals the problem. BR

8

Hi @qojote

You are right. I see that starting for Bsp 3.0 mainline kernel with Toradex Easy Installer 2.x, the internal emmC changed from mmc0 to mmc2. The only solution I saw is either use the correct combination as downstream kernel with Toradex Easy Installer 1.8 or mainline kernel with Toradex Easy Installer version > 2.0 or patch fw_printenv.

Best regards,
Jaski