-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure while programming bare metal example in User Secure Boot Mode 2 #7
Comments
Some updates on my issue. I just found in document mpfs-bootmodes-readme.txt (located on my system at c:\Microchip\SoftConsole-v2021.1\extras\mpfs\mpfs-bootmodes-readme.txt) what seems to be an explanation for my problem. In the "Known issues/limitations" section of that document, it is stated that the sNVM Master Key (SMK) is NOT automatically generated by mpfsBootmodeProgrammer, and that error 801F (the same I got) would be returned if no SMK key was previously generated for the target. So I made the following changes to my design in liberoSoC (which is freshly generated from the 2021.11 Reference Design):
Here's what SmartDebug shows after that change: That leaves me with sNVM pages 14..200 available for use. After having re-generated the Design Initialization Data, regenerated the bitstreams then programmed the board with those changes, I went back to the SoftConsole:
But even with these changes I get the same error as before at programming time. Here is the content of the debugLog.txt file:
Thanks for your time |
Another update to my issue which I kind of partly solved. I managed to get mpfsBootmodeProgrammer to successfully program the test application in User Secure Boot mode (mode 2). Steps were:
The log of the SoftConsole launcher is now:
So, it seems it was not necessary to worry about the sNVM Master Key (SMK) in the end, which seems to have been automatically handled or generated at some point, unlike what the documentation was suggesting. Anyway. Now, the issue is that the test application ("mpfs-gpio-interrupt") does not seem to run upon rebooting the board. I can successfully run it in Debug mode (in non-secure boot mode 1) and see its effect (LED1 is blinking). But when the same program, compiled in LIM-Release build configuration and programmed in the User Secure Boot mode 2, nothing happens (LED1 does not blink). Could it be that the "mpfs-gpio-interrupt" example is not meant to be runnable with that boot mode ? Still, the presence of a linker file for the LIM memory model (located at polarfire-soc-bare-metal-examples\driver-examples\mss\mss-gpio\mpfs-gpio-interrupt\src\platform\platform_config_reference\linker\mpfs-lim.ld) makes me believe that it is supposed to work. Any ideas ? |
Still answering myself, as I made some progress. I managed to get gdb to attach to the running target, and noticed that the process on hart E51 was stuck in a trap (infinite loop in trap_from_machine_code() function). I did reset the target from within gdb, and went in instruction stepping mode in order to find out what the trap origin was. It turns out the issue is caused by the DDR initialization (optional but enabled by default). If commented out the line #define DDR_SUPPORT in file mss_sw_config.h, re-compiled the application, and it ran as expected after that (LED1 blinking in User Secure Boot Mode 2, that is). Could anybody confirm that situation and/or comment on that behaviour ? |
On the USK settings you figure it out, but just in case some other users will find this issue, then the online SoftConsole documentation should be slightly easier to read than the readme TXT files: |
Apologies for the delay. |
Thanks for replying. I'm not sure to get your answer though. My understanding is that, in User Secure Boot Mode 2, the HSS is NOT used; it's just the System Controller that copies my code from the sNVM to the LIM, then wakes up the MSS Complex. Am I not getting this right ? |
Hi, Yes, you are correct, there is no HSS involvement. I am not sure why the DDR init is failing when this program is loaded using mode2. Let me investigate, I will respond early next week. |
Hi, On this issue I believe there was an issue with the DDR settings in the mpfs-gpio-interrupt program. Can you check with the latest mpfs-gpio-interrupt release. Thanks |
Hello, I am getting the same Error "Bitstream or data is corrupted or noisy: ERROR_CODE: 801F" on "PolarFire SoC Icicle Kit". You can also find the „debugLog.txt“ within this post. PS: I have tried the solutions of @nearly-big-endian, but unfortunately they did not work in my case. I would be really happy, if you could help or provide me a documentation. There is no information or documentation that shows which configurations or steps need to be done in order to boot the device in Boot Mode = 2 (User Secure Boot). Thanks in advance! |
Are you absolutely sure that you have initialised the sNVM Master Key (SMK) as required for boot mode 2 to work and be programmable from SoftConsole? |
Hello,
I am currently assessing the available secure boot modes of the Polarfire, and did the following test in SoftConsole:
The result is that fpgenprog did fail with error "Bitstream or data is corrupted or noisy. ERROR_CODE: 801F"
Do you have an idea of what would cause that issue ?
My environment is:
Thanks,
Last lines of "mpfs-gpio-interrupt" project build log:
"Polarfire Soc program user secure boot mode 2" execution log:
The text was updated successfully, but these errors were encountered: