Verdin IMX8M-Plus production fails with 1.1B but passes with 1.1A

Hello,

We’ve been using the imx8M-Plus modules in our products without any issues for the past year. However, today our production team informed me that tests are failing with the newly received version 1.1B modules. Prior to this, we were using version 1.1A or earlier without any problems.

Upon investigation, I identified a difference between versions 1.1A and 1.1B, which appears to be causing the issue.

Specifically, in the bootloader (u-boot), we have a mechanism to load an FPGA configuration file into memory and send it to the FPGA using SPI. The system only jumps to the kernel after this configuration step is completed.

The issue occurs when attempting to load the FPGA configuration file into memory using the following command:

ext4load mmc 2:2 0xc0000000 $fpga_file

With version 1.1A (and earlier), the result of this command is:
11466204 bytes read in 46 ms (237.7 MiB/s)

However, with version 1.1B, the following error is returned:
** Reading file would overwrite reserved memory **

Could you kindly provide guidance on what might be causing this issue and what the recommended solution would be?

PS: We use dunfell based BSP 5.7.

Thank you very much for your time and support.

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


It seems like the issue you’re encountering with the Verdin iMX8M Plus version 1.1B modules is related to changes in the memory layout or reserved memory regions in the U-Boot environment. The error message ** Reading file would overwrite reserved memory ** indicates that the memory address 0xc0000000 you are trying to load the FPGA configuration file into is now part of a reserved memory region in the new module version.

Here are a few steps you can take to troubleshoot and resolve this issue:

  1. Check U-Boot Configuration:

    • Verify if there have been any changes in the U-Boot configuration between versions 1.1A and 1.1B. Specifically, look for changes in the memory layout or reserved memory regions.
  2. Adjust Memory Address:

    • Try loading the FPGA configuration file into a different memory address that is not reserved. You can find a suitable address by checking the memory map in U-Boot. For example, you can use the bdinfo command in U-Boot to get information about the available memory regions.
  3. Update Device Tree:

    • Ensure that the device tree used in U-Boot is up-to-date and matches the new module version. There might be changes in the reserved memory regions defined in the device tree.
  4. Consult Release Notes:

    • Check the release notes or errata documents for the Verdin iMX8M Plus version 1.1B. There might be documented changes or known issues that could explain the difference in behavior.
  5. Contact Toradex Support:

    • If the above steps do not resolve the issue, it would be best to contact Toradex technical support for further assistance. Provide them with detailed information about the issue, including the exact U-Boot version and configuration you are using.

Here is an example of how you might adjust the memory address in your command:

ext4load mmc 2:2 0x80000000 $fpga_file

Make sure that the new address 0x80000000 is within the available memory range and not part of any reserved region.

By following these steps, you should be able to identify and resolve the issue with the memory address conflict in the new module version.

Please, also check if these links can help you solve your problem:

Load binary file from eMMC instead of SD card.

If I choose 0xb0000000 instead of 0xc0000000 as a memory area to load the file, it works fine also on 1.1B.

But how can I guarantee that 0xb0000000 will not be reserved in the future as well?
What is the proper way of choosing the memory area to load the file?

Thanks.

I think you can safely use this address as it is in the same region where uboot load the kernel

2 Likes

Hi @Fide !

@RoccoBr’s tip to use the same region where U-Boot loads the Kernel is a good one!

I would just add that instead of using the hardcoded address, it is better to use the U-Boot environment variable, which is kernel_addr. So wherever is the place U-Boot will use to load the Kernel, you will just use the same place.

Talking to @rafael.tx , he pointed out that if the bitstream of your $fpga_file is around the same size of a Kernel using kernel_addr should be good enough. On the other hand, if you know that it is larger, it might be better to use initrd_addr instead since initrd’s size can be fairly larger than the Kernel’s size.

Best regards,

1 Like

Hi @henrique.tx,

I was digging this problem further to understand why the memory layout has changed.

in the u-boot, bdinfo for the v1.1A returns:

arch_number = 0x0000000000000000
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000040000000
-> size     = 0x00000000c0000000 - length: 3 GB
DRAM bank   = 0x0000000000000001
-> start    = 0x0000000100000000
-> size     = 0x0000000040000000 - length: 1 GB
baudrate    = 115200 bps
TLB addr    = 0x00000000ffff0000
relocaddr   = 0x00000000fff12000
reloc off   = 0x00000000bfd12000
irq_sp      = 0x00000000fdbf7290
sp start    = 0x00000000fdbf7290
Early malloc usage: b3f0 / 10000
fdt_blob    = 0x00000000fdbf72a0

The module has 4GB RAM in total as expected.

bdinfo for the v1.1B returns:

arch_number = 0x0000000000000000
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000040000000
-> size     = 0x0000000080000000 - length 2GB only
baudrate    = 115200 bps
TLB addr    = 0x00000000bfff0000
relocaddr   = 0x00000000bff11000
reloc off   = 0x000000007fd11000
irq_sp      = 0x00000000bdbf71d0
sp start    = 0x00000000bdbf71d0
Early malloc usage: b3f0 / 10000
fdt_blob    = 0x00000000bdbf71e0

This one seems it has only 2GB.

See the pictures of the modules that I’m testing.

Could you verify that SN 15287993 v1.1B should have 4GB?

Thanks.

Hi @Fide !

Please check this related topic:

Please let us know if something is not clear :slight_smile:

Best regards,

1 Like

Thank you, upgrading u-boot worked fine.

Hi @Fide !

Thanks for the feedback!

Have a nice week!

Best regards,