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?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
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:
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.
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.
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.
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.
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:
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?
@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.