AlmAck opened a new pull request, #20005:
URL: https://github.com/apache/nuttx/pull/20005
## Summary
The nRF5340 application core comes out of reset with its flash cache
disabled and nothing in the tree turns it on. `nrf53_start()` does call
`nrf53_enable_icache()`, but that drives NVMC `ICACHECNF` and is gated on
`NRF53_FLASH_PREFETCH`, which `depends on NRF53_NETCORE` so it is not
even compiled for an application core build.
The nRF5340 places the application core cache in a separate CACHE
peripheral at `0x50001000`. `NRF53_CACHE_BASE` is already defined in
`hardware/nrf53_memorymap_cpuapp.h`, but there was no register header and
no enable. This adds both, behind a new `NRF53_CACHE` option
(`depends on NRF53_APPCORE`, `default y`).
New Kconfig option, a new register header, one write at startup, and a
bypass/invalidate around the two progmem operations. The option defaults to
n, matching ARMV7M_ICACHE and ARMV8M_ICACHE/DCACHE, so that upgrading does not
silently change the behaviour of an existing configuration.
### Cache coherency with the progmem driver
Per the nRF5340 Product Specification, *CACHE Instruction and data
cache*:
> Both instruction and data accesses towards flash memory or XIP code
> regions are cached.
The cache does not observe NVMC programming, so enabling it has a
consequence for `arch/arm/src/nrf53/nrf53_flash.c`:
* `up_progmem_eraseblock()` verifies via `up_progmem_ispageerased()`,
which reads the whole page, populating cache lines over exactly the
region being programmed.
* `up_progmem_write()` reads back every word it writes to verify it.
A line held from before the operation would satisfy those read-backs, so
the verify could pass or fail on stale data. This patch therefore
bypasses the cache for the duration of an erase or a write and
invalidates it before re-enabling, so the verify sees the array and
later readers do too.
`nrf53_flash.c` is built only when `NRF53_PROGMEM` is selected, which is
not the default.
## Testing
Host: Linux x86_64, arm-none-eabi GCC 14.
Board: nrf5340-dk, cpuapp, at 64 MHz.
Measured with `apps/benchmarks/scbench` before and after the patch, same
binary otherwise:
| | before | after |
|---|---|---|
| protected-build syscall round trip | 64.1 us | 29.6 us |
| userspace sem wait + post pair | 4.75 us | 1.95 us |
Both a flat build and a `CONFIG_BUILD_PROTECTED` build were exercised.
The application (LVGL rendering to an SPI display, LittleFS on QSPI NOR,
BLE active) behaves identically apart from being faster; flash is not
written during normal operation, so no coherency issue arises.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
