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:
This is also the same issue from the private ticket. Reply in either place... Or the other thread. Wherever.
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.
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.
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
I have posted the outputs from the "collect_debug_info_win" script in the following ticket.
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.
Ok. I will destroy another board to run this test. I will post the results in the ticket as soon as I'm done.
Data has been uploaded to ticket https://en-support.renesas.com/ticket/370636
One more board for the dead pile.
I posted new information to the ticket. When using the secureboot loader from OTP, my application cannot access a custom partition on flash. Note: this is all working fine without the secureboot stuff. So the bootloader from OTP is causing the partition table to not be loaded correctly. Other partitions work (as evidence by the fact that the system boots) but my custom partition is not loaded.
Note: as I said in the ticket, this is a SYMPTOM of the problem, not it's cause, but I hope it will help determine the cause.
I created a new ticket with one very simple question that will greatly help this troubleshooting process. Please review:
I actually just realized you never answered my original question about the #define dg_configEXEC_MODE and #define dg_configCODE_LOCATION.
The question was NOT about MY application. The question was about the BLE_SUOTA_LOADER!
There are two configurations for the ble_suota_loader. Please advice on what the settings should be for the following:
1) BLE_SUOTA_LOADER "QSPI" BUILD:
#define dg_configEXEC_MODE = ??????????????????????????????????
#define dg_configCODE_LOCATION = ???????????????????????????????
2) BLE_SUOTA_LOADER "OTP_SECURE" BUILD:
Also, in your previous post you said the problem is likely in my configurations. I posted the config files for my application, the ble_suota_loader QSPI, and ble_suota_loader OTP_Secure into the ticket en-support.renesas.com/.../370636. It would be great if you could look at them as well.
Let me try to do a recap and answer some of my own questions here.
1) What was the main problem keeping secureboot from working?
A) The demo "ble_suota_loader" project config file for OTP (custom_config_otp_secure.h) has no entries for flash configuration or partition table. These both need to be added to the config file if you are not using the default FLASH chip, or if you have any changes to the default partition table. If that's the case, you need to specifically define both of those things in the OTP bootloader config file. In the chain of OTP bootloader, secondary bootloader, and application settings, the OTP bootloader is apparently the place where the system pulls your FLASH settings and partition table from. It is unknown if the flash and partition table definitions in any of the other config file places actually have any effect when using the OTP secureboot suota loader.
2) OP questions about dg_configEXEC_MODE and dg_configCODE_LOCATION for the OTP Secure build of the ble_suota_loader project.
A) My working configuration uses the following settings for custom_config_otp_secure.h
Note: No guarantees these are the settings you should be using for whatever you are making. Be Careful experimenting with this. Getting something wrong with OTP bootloader breaks stuff.
3) Bonus PSA1: If you are going to use the secureboot OTP bootloader, DO NOT write anything custom to the beginning of OTP (like an IRK key for example), despite what anyone tells you. The beginning of OTP is where the secureboot bootloader goes.
For my particular system uses from 0x07F80000 to about 0x07F87610 in OTP for the bootloader, but I would suggest using the SmartSnippets Toolbox to confirm where your bootloader stops.
4) Bonus PSA2: The secure_suota_initial_flash_jtag script does multiple actions in one go. It creates and writes the secure application image to flash, burns the OTP bootloader, burns the OTP secureboot keys, and then writes 0xAA in the PRODUCT_READY and SECURE_DEVICE OTP registers. I highly recommend modifying this script so you can do those actions individually and separately. Being able to write the secureboot keys WITHOUT writing the OTP bootloader and setting the secure_device flag was very important to troubleshooting these issues.
5) Bonus PSA3: After running the secure_suota_initial_flash_jtag script, which sets the PRODUCT_READY and SECURE_DEVICE OTP registers, you still have access to JTAG enabled. That's great if your system doesn't work and you need to try to debug it, but not so great if you were under the impression that script prepared your product for it's final configuration. JTAG needs to be disabled in another step. I don't think this process is described anywhere for actually trying to release a product despite being mentioned as important in the secureboot tutorial.
Here is the JTAG Enable address from the toolbox: