Tool/software:
OptiFlash, XIP, OTFA, eFuse
- Is it possible to partition the OSPI flash memory such as some part of it is accessible by OptiFlash/XIP and the other is free to be used by software? Ideally, we want to use the same OSPI Flash for storing both the firmwares and a filesystem, and we assume that the caching performed by OptiFlash (by RL2) over the flash could be a detriment if it acts on the part of flash holding the filesystem. At best, this would degrade code execution from flash because the cache would contain sectors from the filesystem; at worst, it would cause problems using the filesystem unless we do careful cache maintenance operations on RL2 when accessing the filesystem.
- Under TRM section "13.3.2.2.7.1.2 Features Not Supported", there is a mention of "OTFA does NOT allow concurrent active Read and Writes, it must be idle before you switch times (sic)". What does it entail for performance, in the scenario discussed above with a filesystem in the same OSPI flash?
- When using any encryption mode with MAC (ex: AES-GCM) for encrypting the external flash, some memory is used to store the MACs. Conversely, the OTFA performs automatic memory address translation (as stated in "13.3.2.2.8.5 Memory Address Translation") to fetch the data. The result is that the real address of the data is further down from what the requested address from the CPU is. We assume that for flash erase operation, the software must perform the address translation itself in order to ensure that the data written will be within the erased sectors. IS that assumption correct?
- Is the AES core used by OTFA dedicated to OptiFlash? We want to know if using both the HSM security services and OTFA can be done concurrently without performance issues, or any issues for that matter.
- From the memory map, we can see that the eFuse region is at 0x53600000 and is 1KB in size. However, presumably, some bits of it are used to configure several boot settings such as DUAL_CORE_BOOT_ENABLE, DUAL_CORE_SWITCH_DISABLE, a software version, trim values for Power OK modules etc. How many bits are being used by the hardware and RBL/HSM? Can the software make use of some parts of the eFuse area to store keys and other immutable data?
ROM bootloader
- In section "5.5 Redundant boot support", there's a note saying that the "[successfully] booted flash Image offset Address is available at the address 0000x84100 (sic)". We infer that upon successful boot from OSPI, at that address, which is in R5SS0_CORE0_TCMB_RAM, we can read four bytes that are either [00 00 00 00], [00 00 02 00], [00 00 04 00] or [00 00 06 00] (little endian values of 0, 0x20000, 0x40000, 0x60000) depending on the region that was used for booting. Is this understanding accurate?
- In the same section, the note also says that the max image size for SBL is 256KB with redundant image support. However, the addresses listed in the table above (5-11) are 128KB apart. From that, we understand that when using SBL images of 128K and less, 4 copies can be used, but when using >128KB images, only two copies are available. Is this conclusion correct?
Regards
