Background:
I'm starting a new forum thread here because I don't want to waste one response (and another day) from you guys telling me not to reply to an old thread.... But this is essentially the continuation of this thread here:
https://community.renesas.com/wireles-connectivity/f/bluetooth-low-energy/22161/what-is-the-right-configuration-for-secure-boot-loader-in-otp
This is also the same issue from the private ticket. Reply in either place... Or the other thread. Wherever.
Issue:
This issue essentially never got a resolution on the forum (in the previous linked thread). I have similar questions about the "correct" config for the OTP build considering my project was working fine with the QSPI build, but fails in new and strange ways with the OTP_SECURE build.
The ble_suota_loader project has two config files. One for _QSPI, and one for _OTP_SECURE.
The custom_config_qspi.h has the following config:
#define dg_configEXEC_MODE MODE_IS_CACHED#define dg_configCODE_LOCATION NON_VOLATILE_IS_FLASH
The custom_config_otp_secure.h has the following config:
#define dg_configEXEC_MODE MODE_IS_MIRRORED#define dg_configCODE_LOCATION NON_VOLATILE_IS_NONE
Neither of these are what Thomas pointed out from the documentation "3.4.3 BootROM sequence".
My ultimate goal is to have my program run Exactly as it does with the _QSPI config, but with the secureboot loader from OTP. I just want your secureboot process to work.
Questions:
1) Why are these sections of the memory config different in the QSPI and OTP versions? Is that a requirement for OTP_SECURE that they are different or can they be the same? Is there a "RIGHT" answer to what these values should be for the OTP_SECURE config? If it's dependent on what I'm doing in my program, how do I determine what the "Right" answer is for my program?
2) Once loaded, I want my program to behave functionally EXACTLY the same when using the OTP_SECURE bootloader version as it does in the QSPI version. How do I make that happen? Should these config files be the same?
3) The QSPI config file defines the info about the FLASH chip and the partition table, but the OTP config does not. Should the OTP bootloader config file also include information about the FLASH chip and partition table information ?
4) How do you test the OTP_SECURE version of the bootloader without actually loading it into OTP (and ruining another dev board when it inevitably doesn't work because there isn't enough documentation to get it running without a lot of guess and check work)?
5) If the OTP_SECURE bootloader config file has one set of settings for these dg_configEXEC_MODE and dg_configCODE_LOCATION variables, but my actual program image has a different set of settings, what happens? Does the OTP_SECURE bootloader settings get changed once it passes off control to the user application, or does the Bootloader settings stay enabled forever?
It appears that I now have a functional system including the secureboot stuff.
Thank you Ben and Panos (and Jon) for your help with this.
Let me try to do a recap and answer some of my own questions here…
Hi Nathan,Thank you for posting your question online.We are actively working into these questions and we will respond in the private ticket you have raised. Kind Regards,OV_Renesas
Ping. Happy Friday.
Hello everyone. I was hoping for some help here but the private ticket you sent me just told me to "read the tutorials" again. We are so far beyond that. You know very well that is not helpful. I asked very specific questions that you have not even attempted to address.
Now it's the weekend and I won't get any help again until Monday. I made it very clear that I have production boards waiting to program. Because the OTP is the issue here, I destroy a board each time something doesn't work. The documentation is no help here. Your support here on this issue is also no help.
What does it take to get some help with this?
Hi Nathan,
Sorry for the delay. We'll be looking into this shortly.
I did not have time to dive too deep in your question, but a basic answer is the QSPI build should work in the same way whether you run it with the secure boot or not. The secure boot is basically checking the image is legitimate and after that boots your image. In theory, it should be pretty straight forward. if it does not boot, it's something is wrong with your configuration.
The custom_config_qspi.h for your application should be:
#define dg_configEXEC_MODE MODE_IS_CACHED
Hey Ben,
I can't state enough how much I appreciate your help here. Thank you.
My application is already set up for "MODE_IS_CACHED". I'm not sure if this line of questions here about exec_mode is actually what's going on, but I was getting desperate and I'm looking for any reason now why things aren't working. This is one difference that I noticed.
If you wanted to work in the ticket, I have the configs for both bootloaders and my application config files posted there. To be clear, my program actually is booting with secureboot bootloader, but it's behavior is totally different (and very buggy) when using the secure boot system. Without secureboot everything is solid.
I noticed that two of the systems that appear to consistently not be working with secureboot.
1) SDK function OTP access (see the ticket 369939). I had to change my OTP access function to use direct pointer access instead of the "hw_otpc_fifo_read() function, which stopped working with secureboot. SDK OTP reads using the above function hang forever on "while (HW_OTP_REG_GETF(STAT,FWORDS)==0);"
2) The other thing is that QSPI FLASH access from my custom partition isn't working. I'm using a 16MByte FLASH and I have a large user data storage partition at the end of my partition table. SDK reads to this partition appear to be hanging and never return when using secureboot.
Both of these things are working fine without secureboot. Hopefully this is helpful in determining what's going on.
Hi Nathan, please check Ticket #369939
Regards,
PM_Renesas
I have posted the outputs from the "collect_debug_info_win" script in the following ticket.
en-support.renesas.com/.../370636
The testing Panos requested on the ticket is going to destroy another board and I question if it will actually provide any new information. Please review my response there and let me know what you think. Given your analysis that the data dumps showed no difference in the running state, as I mentioned in the ticket I feel like the problem is likely in the configurations.
On the ticket, I have reattached the config files for my application and the ble_suota_loader OTP and QSPI loaders. Please review these config files and let me know if you see any settings that would cause functional differences during operation when using the OTP or QSPI bootloaders. Note: Again, using the QSPI bootloader everything works. Using the OTP bootloader, things are broken. What is the difference?
We did compare the registers and no obvious differences popped up. We see differences in trim registers values. The obvious answer would be the working and non-working dumps were done from different devices.
My understanding is you can load a working firmware in the RAM of a device burnt with the OTP loader. We would like to dump the registers from this device. The idea is to rule out the issue is coming from a corrupted trim in one of the register.