I’m porting U-Boot v2021.10 for my custom RISC-V board. Previously, I was using v2021.04-rc5. However, with the introduction of Binman in v2021.07, I’ve implemented Binman for my board in v2021.10.
Issue:
After building U-Boot v2021.10 with Binman, I’m facing an SBI trap error when booting u-boot-spl.bin and u-boot.itb. Interestingly, using u-boot-spl.bin from v2021.04-rc5 and u-boot.itb from v2021.10 works.
Problem:
When using u-boot-spl.bin from v2021.10, I encounter an SPL trap issue.
Questions:
What changes in Binman (v2021.07 onwards) could be causing this issue?
How can I resolve the SPL trap error with u-boot-spl.bin from v2021.10?
Configuration:
U-Boot version: v2021.10
Board: Custom RISC-V board
Binman implementation: Custom
Any guidance or suggestions would be greatly appreciated.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hi Vitthal,
It sounds like you’re encountering an issue with the SPL (Secondary Program Loader) when using U-Boot v2021.10 with Binman on your custom RISC-V board. Here are some steps and considerations that might help you resolve the issue:
1. Changes in Binman (v2021.07 onwards)
Binman was introduced to handle the creation of firmware images in a more flexible and modular way. Some changes that might affect your setup include:
Image Layout: Binman allows for more complex image layouts, which might introduce differences in how the SPL and U-Boot proper are packed and loaded.
Device Tree Overlays: Ensure that any device tree overlays or configurations are correctly applied in the new version.
Configuration Files: Check if there are any new or deprecated configuration options in the binman configuration files.
2. Resolving the SPL Trap Error
Here are some steps to debug and potentially resolve the SPL trap error:
a. Compare Configurations
Compare the SPL configurations (.config files) between v2021.04-rc5 and v2021.10. Look for any differences that might affect the SPL.
Check Binman Configuration: Ensure that the binman configuration is correctly set up for your board. This includes checking the binman entries in your board’s configuration files.
b. Debugging SPL
Enable Debugging: Enable debugging in the SPL to get more detailed logs. This can be done by setting CONFIG_SPL_DEBUG=y in your U-Boot configuration.
Check SBI Implementation: Since you’re encountering an SBI trap, ensure that the SBI (Supervisor Binary Interface) implementation is compatible with the changes in U-Boot v2021.10.
c. Cross-Version Compatibility
Cross-Version Testing: As you mentioned, using u-boot-spl.bin from v2021.04-rc5 with u-boot.itb from v2021.10 works. This suggests that the issue might be isolated to the SPL. Try to isolate the changes in the SPL between these versions.
d. Review Commit History
Review Commits: Look at the commit history for U-Boot between v2021.04-rc5 and v2021.10, focusing on changes related to SPL and Binman. This might give you clues about what has changed and what might be causing the issue.
e. Community and Documentation
Community Forums: Check U-Boot mailing lists and forums for any similar issues reported by others. Sometimes, issues are known and have been discussed or resolved by the community.
Documentation: Review the U-Boot documentation for any notes on changes or migration steps when moving to a version with Binman.
Conclusion
The issue you’re facing seems to be related to changes in how the SPL is built and loaded with Binman in U-Boot v2021.10. By comparing configurations, enabling debugging, and reviewing changes, you should be able to pinpoint the cause of the SPL trap error. If the issue persists, providing detailed logs and configurations on community forums might help get more specific advice.
I hope this helps, and good luck with your porting efforts!
Best regards,
[Your Name]
Please, also check if these links can help you solve your problem:
"I understand that you’re seeking support for U-Boot on a custom RISC-V board, but please note that Toradex’s community solely focuses on Toradex-specific hardware and software products.
For questions, problems, or contributions related to U-Boot, you can send a message to the U-Boot mailing list at <u-boot@lists.denx.de> . An archive of previous discussions is available at The U-Boot Archives.
After the initial setup, we proceeded to flash using eMMC. We applied an eMMC patch to the U-Boot source and completed a build. Once the build was successful, we created a GPT partition using u-boot-spl. Then, using the dd command, we flashed a higher version of .gpt and u-boot.itb.
However, during testing, the SPL console did not appear, and the system hung. To troubleshoot, I tried various binaries, including an older GPT version combined with the newer SPL version. This combination worked successfully, which led me to suspect an issue with the SPL.
When booting from RAM, I had modified the hart entry address from 0x800e0b4 to 0x800e0c0, which allowed the boot process to succeed. I am considering whether a similar change is necessary here.
However, since the .gpt file creation should be managed by the ROM code, and no console output appears, I suspect the issue might be unrelated to the hart entry address.
