Network not working on u-boot built from source for apalis imx6 BSP 6.8.0

Technical Support
, , , , ,
1

I followed instructions to build u-boot from source for apalis imx6 BSP 6.8.0 and network is not working.

I tested building u-boot from source for apalis imx6 BSP 7.5.0 and network is working.

U-boot boots correctly on both BSPs.

I did not flash an environment, so u-boot throws an error when it tries to load it from the MMC:

BSP 7.5.0: “Loading Environment from MMC… Reading from MMC(0)… *** Warning - bad CRC, us”
BSP 6.8.0: “Loading Environment from MMC… *** Warning - bad CRC, using default environment”

I think u-boot uses its hardcoded default environment.

I don’t think the network problem is associated with the missing environment, since on BSP 7.5.0 it works anyways.

I am testing network with the “dhcp” command from u-boot. On BSP 7.5.0 the dhcp server sees the requests from u-boot and assigns it an IP. On BSP 6.8.0 no requests are sent.

I am also capturing packets with wireshark and I see request packets on BSP 7.5.0 but I see no packets at all from BSP 6.8.0.

I have also tested u-boot BSP 6.x.y on several apalis imx6 SoMs, and it seems the issue only happens on SoMs with the KSZ9131RNXI transceiver.

  • Apalis iMX6D 1GB IT V1.1A (KSZ9131RNXI transceiver): Network NOT WORKING
  • Apalis iMX6Q 2GB IT V1.1C (KSZ9031RNXIC transceiver): Network WORKING
  • Apalis iMX6D 1GB IT V1.1B (KSZ9031RNXIC transceiver): Network WORKING
  • Apalis iMX6D 1GB IT V1.1C (KSZ9131RNXI transceiver): Network NOT WORKING

Is this a known issue? What is causing the problem? Is there a solution?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Your issue is indeed related to the KSZ9131RNXI Gigabit Ethernet transceiver and is a known compatibility issue with older BSP versions.

Root Cause

The problem occurs because the KSZ9131RNXI transceiver requires specific driver support that was not available in BSP 6.x.y versions (1). According to the Product Change Notification documentation, the Gigabit Ethernet Transceiver change from KSZ9031RNXIC to KSZ9131RNXI is supported from BSP 3 (3.0b4.254) onwards, and if you are using earlier BSP versions, the new Gigabit Ethernet Transceiver will not work without a patch (1).

Module Revision History Analysis

Your test results align perfectly with the documented hardware changes:

  • Apalis iMX6D 1GB IT V1.1A: Uses KSZ9031RNXIC (working) (2)
  • Apalis iMX6D 1GB IT V1.1B: Uses KSZ9031RNXIC (working) (2)
  • Apalis iMX6D 1GB IT V1.1C: Uses KSZ9131RNXI (not working on BSP 6.x.y) (2)
  • Apalis iMX6Q 2GB IT V1.1C: Uses KSZ9031RNXIC (working) (2)

The V1.1C versions introduced the KSZ9131RNXI transceiver as documented in the revision history (2).

Solution

Since you’ve confirmed that BSP 7.5.0 works correctly with the KSZ9131RNXI transceiver, the recommended solution is to migrate to BSP 7.x.y or newer. The documentation specifically recommends that customers take the opportunity to migrate to newer BSP LTS releases, benefiting from all optimizations, including Linux Kernel updates and security fixes (1).

Why BSP 7.5.0 Works

BSP 7.x.y includes the necessary driver support and device tree configurations for the KSZ9131RNXI transceiver. The KSZ9131 is an updated version of the KSZ9031 that resolves several errata of the KSZ9031, including issues with passing Ethernet compliance tests (3).

Alternative Approach

If you must continue using BSP 6.x.y, you would need to backport the KSZ9131RNXI driver support and device tree configurations from the newer BSP versions, but this is not recommended as it requires significant development effort and testing.

The most practical solution is to use BSP 7.x.y for modules with the KSZ9131RNXI transceiver.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello @martinM !

The network failure on BSP 6.x.y is specific to SoMs carrying the KSZ9131RNXI Ethernet transceiver, and is caused by missing driver support for that PHY in the U-Boot version shipped with BSP 6.x.y. BSP 7.x.y added the necessary KSZ9131 driver and device tree configuration, which is why networking works there out of the box.

Rather than patching U-Boot directly outside of Yocto, the correct and maintainable approach is to create a custom meta-layer within your BSP 6.x.y Yocto build and use a u-boot-toradex_%.bbappend recipe to apply the KSZ9131 driver on top of the BSP 6.x.y U-Boot sources.

Toradex’s official guide for working with custom recipes is here: Customize an Image | Toradex Developer Center

May I ask: is there a specific reason you need to remain on BSP 6? Knowing your constraints will help us give you the most targeted guidance for the backport, and since it is working on BSP 7 the easier approach would be to simply use BSP 7.

4

Hello @joaom.tx

Ok that makes sense.

We are not using U-Boot with Linux, we are using it with another OS. We followed these instructions: Build U-Boot From Source Code | Toradex Developer Center. We need to build U-Boot to enable the first stage of secure boot and since we are not using it with LInux we thought that building it with Yocto would generate a lot of unnecessary overhead. In our case, that we only need to build U-Boot by itself, do you still recommend creating a custom meta-layer to patch the BSP 6.x.y U-Boot with the KSZ9131 driver?

May I ask: is there a specific reason you need to remain on BSP 6? Knowing your constraints will help us give you the most targeted guidance for the backport, and since it is working on BSP 7 the easier approach would be to simply use BSP 7.

The only reason is we had already prepared and tested everything with BSP 6.x.y (on old hardware) and moving to the BSP 7.x.y would mean repeating the work and tests. We are considering it.

Thanks for your reply.

5

Thanks for the clarification, that changes things. Since you’re building U-Boot standalone, directly patching the source tree is the right approach here; the meta-layer recommendation only applies when U-Boot is built within Yocto.

You can backport the KSZ9131 driver from BSP 7.x.y into BSP 6.x.y, but it is definitely more work than it’s worth: you’d need to diff the two U-Boot trees, identify all relevant changes across the PHY driver, Kconfig entries, and device tree sources, and then validate the patch against your secure boot setup.

Given that BSP 7.x.y solves this out of the box and you’re still at a stage that this can be considered, migrating will likely save more effort in the long run than maintaining a custom patch on BSP 6.x.y.

6

João Victor Couto de Oliveira Martins, Mar 9, 2026, 13:21

Hello

João Victor Couto de Oliveira Martins
Toradex