Migration from rocko to scarthgap

Technical Support
, ,
1

I am migrating my firmware from rocko to scarthgap. But i am facing issues with u-boot and upstream Kernel. The errors are as below:
U-boot-toradex_2024.07:
Loading Environment from MMC… MMC Device 0 not found
*** Warning - No MMC card found, using default environment
MMC Device 0 not found
No MMC card found
MISSING TORADEX CONFIG BLOCK
i am not able to set env from u-boot after savenv it show no mmc found.

Kernel issues:
Failed to start Ethtool configuration for eth0.

Thank you.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for providing the details of your issues during the migration from Rocko to Scarthgap. Let’s address your U-Boot and kernel problems step by step.

1. U-Boot: “MMC Device 0 not found” & “MISSING TORADEX CONFIG BLOCK”

Root Cause:
These messages mean that U-Boot is unable to detect the eMMC storage, so it cannot read the environment or the Toradex config block (which holds crucial information like MAC address).

Recommended Checks:

  • eMMC Hardware Boot Area Configuration:
    Since BSP V2.5b2, U-Boot and the configuration block are stored in the primary eMMC hardware boot area partition (/dev/mmcblk0boot0).
    You should ensure the boot partitions are enabled and configured correctly. From the U-Boot prompt, try:

    mmc list
mmc dev 0
mmc part

    If nothing appears or errors persist, U-Boot may not be recognizing the eMMC.

  • Verify eMMC Boot Partition Settings:
    Check boot partition configurations:

    mmc bootbus 0
mmc partconf 0

    More details here:
    Booting from eMMC Hardware Boot Area Partitions

  • Config Block Migration:
    If you migrated a module with the old layout, make sure the config block was properly carried over to the correct location.

    Details about config block and its migration

  • Power Failures or Corruption:
    Sudden power-offs during migration might have left the eMMC in a corrupted state, leading to detection failures.
    Related Community Discussion

2. Kernel: “Failed to start Ethtool configuration for eth0”

This error likely results from a missing MAC address or interface configuration. Since the MAC is normally loaded from the config block on eMMC, your U-Boot issue is the root cause. Once U-Boot can see the config block, the MAC address will be correct, and this kernel error should disappear.

Summary of Steps to Resolve:

  1. From U-Boot, verify and list the MMC devices. Test access to boot partitions as above.
  2. If eMMC is not visible, review your migration steps for moving the config block and ensure correct U-Boot environment settings.
  3. Check power and eMMC connections if the issue persists after the above.
  4. Once U-Boot detects eMMC and the config block, the Ethtool startup issue in Linux should be resolved automatically.

Extra Links for Reference:

Please try the above and let me know what further details you find after running the suggested U-Boot commands. If you have relevant boot logs or screenshots, sharing those can help narrow down the root cause.

Best regards,
Toradex AI Assistant.

3

Hi @ToradexAI ,

i have tried the following:

mmc list
FSL_SDHC: 1
FSL_SDHC: 2 (eMMC)
Zuse Falcon # mmc dev 1
Card did not respond to voltage select! : -110

thank you.

4

@ToradexAI
Here is what i tried:

mmc list
FSL_SDHC: 1
FSL_SDHC: 2
Zuse Falcon # mmc dev 0
MMC Device 0 not found
no mmc device at slot 0
Zuse Falcon # mmc dev 1
Card did not respond to voltage select! : -110
Zuse Falcon # mmc part
MMC Device 0 not found
no mmc device at slot 0

my Kernel is running successfully. i have only issue with setting environment variables from u-boot 2024.07
Thanks

5

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Hello, thanks for the detailed update!

Based on your output, your system is detecting two MMC controllers (FSL_SDHC: 1 and FSL_SDHC: 2), but neither is functioning as expected:

  • Attempting mmc dev 1 gives the error Card did not respond to voltage select! : -110, which generally means a timeout during MMC initialization.
  • mmc dev 0 reports “MMC Device 0 not found”.

This is a known issue when U-Boot is unable to communicate with the eMMC chip due to an initialization or voltage handshake problem. As a result, U-Boot cannot access the environment or the Toradex config block, so environment changes cannot be saved or made persistent. However, your Linux kernel is able to boot, which means the default environment values embedded in U-Boot are sufficient for booting, but you cannot customize and save changes via saveenv.

Key Points:

  • Changes made with setenv are only valid for the current boot session since saveenv cannot write to non-volatile storage while the eMMC is inaccessible.
  • This issue is typically not a problem in Linux itself, but is U-Boot specific and blocks use of persistent U-Boot environment and some early-boot device features.

Things to Try:

  1. Try the Next Device Index:
    Since FSL_SDHC: 2 is likely your eMMC device, try:

    mmc dev 2

    Sometimes controller numbering changes across BSP versions.

  2. Power Cycle the Board:
    Some users have reported that a full power cycle, rather than just a reset, can restore proper initialization of the eMMC and allow U-Boot to access it:

    • Power off the device completely.
    • Wait a few seconds.
    • Power it on again.
      See: Community reference

  3. Check for Compatibility Between U-Boot and eMMC Layout:
    If you updated U-Boot or changed storage layout/migration steps, ensure that the eMMC layout still matches what U-Boot expects (e.g., config block location and eMMC partitions). Details: Best practices with U-Boot environment variables

  4. Re-Flash U-Boot and Recovery:
    If you migrated from a different BSP/Yocto branch, some offsets or environment settings may be incompatible. Consider re-flashing the bootloader using recovery mode if possible.

Summary:
As long as U-Boot cannot successfully access the eMMC (see the voltage select error), you will not be able to store persistent environment changes. Your system is booting because defaults are sufficient, but persistent custom environment use in U-Boot will not work until that access is restored.

Please try mmc dev 2 and also perform a power cycle, and let me know the result or supply further boot logs if the issue persists.

Links for reference:

Best regards,
Toradex AI Assistant.

6

@ToradexAI
Here is what i got:

mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device

7

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Thank you for your update! This is good news:
The output

mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device

shows that U-Boot is now able to access the eMMC at device index 2.

What does this mean?

  • You should now be able to set and persist U-Boot environment variables using setenv and saveenv.
  • The issue happened because, in your setup, the eMMC device is at index 2 (not 0 or 1). This can change depending on the BSP, U-Boot version, and device tree configuration.

How to proceed:

  1. Set and Save a Test Variable
    In the U-Boot prompt, try:

    setenv test_var hello_world
saveenv

    If successful, there should be no error after saveenv.

  2. Verify Variable is Saved
    Reset the board, then at the U-Boot prompt:

    printenv test_var

    You should see test_var=hello_world.

  3. Set Default MMC Device (optional, for automation)
    If you want U-Boot to default to this eMMC for future sessions, you can adjust your mmcdev environment variable:

    setenv mmcdev 2
saveenv

    Details:
    U-Boot variables and environment

Summary:
Your eMMC was always available as device 2; target it specifically for all mmc-related operations in U-Boot.

Links for more info:

Let me know if saveenv now works, or if you need further assistance.

Best regards,
Toradex AI Assistant.

8

@ToradexAI

mmc list
FSL_SDHC: 1
FSL_SDHC: 2 (eMMC)
Zuse Falcon # mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
Zuse Falcon # setenv mmcdev 2
Zuse Falcon # setenv bootdev 2
Zuse Falcon # saveenv
Saving Environment to MMC… MMC Device 0 not found
No MMC card found
Failed (1)

9

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Thank you for sharing the exact output. This clarifies the root issue:

Even though you can access your eMMC via mmc dev 2, the saveenv command is still trying to write to MMC Device 0.

This happens because the storage location for the U-Boot environment is set at compile time, and it is currently still configured to use MMC Device 0. Changing the current device in the U-Boot shell (with mmc dev 2) does not affect where saveenv writes the environment!

What Can You Do?

1. Change Environment Variables from Linux (Recommended)

Since your Linux kernel boots correctly, you can use the fw_setenv and fw_printenv utilities from Linux to set persistent U-Boot environment variables. These tools write to the location specified in their config file, which should match your platform.

Example:

fw_setenv test_var hello_world

If this works and you see no errors, it means the correct environment location is writable from Linux.

More about using fw-utils:

2. Why Can’t U-Boot Write?

Because the U-Boot build you are running has environment storage (ENV offset/device in source code) set to device 0. This can only be changed by compiling U-Boot with different settings or flashing a new U-Boot binary with corrected storage mapping.

3. Check the fw_env.config File

Make sure /etc/fw_env.config (on Linux) points to the correct device and offset for your eMMC storage. On Colibri/Apalis iMX6, this is often something like:

/dev/mmcblk0boot0 0x400000 0x20000

But double-check for your specific module and BSP.

4. Additional Diagnostics

From U-Boot, you can check:

printenv boot_devnum
printenv boot_devtype

But these will not affect how saveenv works unless the build-time config matches your actual hardware (see U-Boot build-time env config).

Summary

  • U-Boot saveenv still tries to write to MMC Device 0; this is not changed by switching the device in the shell.
  • Use fw-utils from Linux for persistent U-Boot environment changes.
  • To fix saveenv in U-Boot, the U-Boot build must be reconfigured to use MMC device 2 for its environment storage.

Further reading:

Let me know if you have success with fw-utils on Linux, or if you need more detailed guidance!

Best regards,
Toradex AI Assistant.

10

@ToradexAI

what is correct def configuration for apalis-imx6:

CONFIG_ENV_SIZE
CONFIG_ENV_OFFSET

11

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Hello!

Unfortunately, the exact values for CONFIG_ENV_SIZE and CONFIG_ENV_OFFSET for Apalis iMX6 can depend on your U-Boot version and how it was configured, especially since storage layout may shift between board support package (BSP) releases.

Here’s how to find the correct values:

1. Check Your U-Boot Source Tree

  • Look for the apalis_imx6_defconfig or the relevant board configuration header file in include/configs/apalis_imx6.h (or similar).
  • You should see values like:
    #define CONFIG_ENV_SIZE   0x2000    /* Example: 8 KiB */
#define CONFIG_ENV_OFFSET 0x400000  /* Example: 4 MiB */
  • Note: These exact numbers are for illustration only. Always confirm in your version of the U-Boot source.

2. Check Your Running System

  • On Linux, check /etc/fw_env.config. This file is used by fw_setenv and fw_printenv and contains the storage device, offset, and size:
    cat /etc/fw_env.config
    You might see a line like:
    /dev/mmcblk0boot0 0x400000 0x20000
    • The second value is the offset (CONFIG_ENV_OFFSET).
    • The third value is the size (CONFIG_ENV_SIZE).
  • This will show you the currently configured values for your platform.

3. Documentation and Migration Notes

Summary Table (commonly used, but double-check with your BSP):

Parameter Typical Value
CONFIG_ENV_SIZE 0x20000 (128 KiB)
CONFIG_ENV_OFFSET 0x400000 (4 MiB)

Again: Please confirm with your U-Boot defconfig, header files, or your Linux /etc/fw_env.config, as actual deployments may differ.

If you have specific values from your /etc/fw_env.config or the relevant U-Boot header file, share them here and I can confirm for you.

Best regards,
Toradex AI Assistant.

References:

12

Hi @ToradexAI Folks,
I am still facing the same following issue with my custom dts file:

  1. PMIC: failed to get device for PMIC at address 0x8
  2. MMC Device 0 not found
  3. MISSING TORADEX CONFIG BLOCK

I am building it with yocto scarthgap tag 7.1.0. Thank you

13

Dear @farooq,

That is indeed strange behaviour. Generally speaking U-Boot is working, since otherwise the reference image itself would also not work. A suggested way to find out what the issue is, would be to start with the standard build without any other patches. After that you should continuously integrate changes step by step. With this strategy you should be able to see what is breaking your build.
For this I would suggest the following steps:

  • check if the scarthgap reference image works on your module.
  • Build our scarthgap reference image and install it to the module. Does this work?
  • include your pathes step by step to see, from where on the errors occur.
  • (Unfortunately you can not completely rely on copying the old device tree as is and it working without any alterations on the u-boot)

Best regards,
Collin

1 Like