Skip to content

Conversation

@Holt-Sun
Copy link
Contributor

Summary

Add CACHE64 devicetree binding and init-only driver for NXP RT5xx/RW6xx SoCs.

Replaces hard-coded cache initialization with DT-based configuration, allowing board-specific cache policy tuning.

Changes

  • New nxp,cache64 binding and driver
  • Enable CACHE64 on frdm_rw612, rd_rw612_bga, mimxrt595_evk
  • Remove legacy soc.c cache init
  • Update cache documentation

Tested on RW612/RT595 EVK boards.

Add a devicetree binding for the NXP CACHE64 controller and policy
selector used with FlexSPI/XSPI external memory.

The nxp,cache64 binding describes:

A single region shared by CACHE64_CTRL and CACHE64_POLSEL
A windows array encoding FlexSPI/XSPI AHB windows
A regions array encoding cache boundaries and policies
An optional enable-write-buffer property

Signed-off-by: Holt Sun <[email protected]>
@Holt-Sun
Copy link
Contributor Author

@Albort12138

Add an initialization-only driver for the NXP CACHE64 controller
found on RT5xx and RW6xx SoCs. This driver configures cache policy
regions and enables the cache during early boot without exposing
the generic cache management API.

Key features:
- Configures CACHE64 POLSEL region boundaries and policies from DT
- Supports non-cacheable, write-through, and write-back policies
- Optional write buffer enablement
- Runs at PRE_KERNEL_1 level for XIP support
- Uses CONFIG_CACHE_INIT_ONLY for init-only operation

The driver reads region configuration from devicetree and programs
the CACHE64_POLSEL registers accordingly. It then invalidates and
enables the cache.

Signed-off-by: Holt Sun <[email protected]>
Add CACHE64 controller devicetree nodes to RT5xx and RW6xx SoC
dtsi files and immediately enable them on affected boards with
appropriate region configurations.

Board-specific cache configurations:
- frdm_rw612: WB for 64MB NOR XIP, WT for 8MB PSRAM
- rd_rw612_bga: WB for 64MB NOR XIP, WT for 8MB PSRAM
- mimxrt595_evk: WT for 64MB NOR XIP, WB for 64MB PSRAM

Remove legacy hard-coded cache initialization from
soc/nxp/imxrt/imxrt5xx/cm33/soc.c as cache configuration is now
handled by the CACHE64 driver based on devicetree.

This change is atomic (adding SoC nodes + enabling on boards +
removing legacy init in one commit) to maintain bisectability.
The old cache initialization is removed only when the new driver
is active.

Signed-off-by: Holt Sun <[email protected]>
Document the new CONFIG_CACHE_INIT_ONLY option that allows
SoC-specific cache controller initialization without enabling
the generic cache management API.

Add explanation of:
- What init-only cache drivers are and when to use them
- How they differ from full cache management API

Signed-off-by: Holt Sun <[email protected]>
@Holt-Sun Holt-Sun force-pushed the enable-cache64-and-polsel-driver-in-cache branch from 6b3ce6b to c1022d9 Compare December 14, 2025 09:02
@sonarqubecloud
Copy link

@Holt-Sun
Copy link
Contributor Author

@Albort12138

@Albort12138
Copy link
Contributor

Hi @nashif, could you please help review this PR?
We encountered a scenario where the cache only needs to be initialized, without requiring any cache management APIs. We believe this functionality should still reside in the cache folder. However, the current implementation only includes the cache device driver when the Kconfig macro CACHE_MANAGEMENT is enabled.
To address this, @Holt-Sun introduced a new Kconfig macro, CACHE_ONLY_INIT, in this PR to support cases where only initialization is needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of creating a separate Kconfig file for each cache implementation, we could introduce a single Kconfig.mcux to include all MCUX cache implementations—similar to what we already do in other device drivers: https://github.com/zephyrproject-rtos/zephyr/blob/cb93f97bd63207211d92f7c5a0ffd8d5e270dd42/drivers/adc/Kconfig.mcux


Example 1: Single boundary (2 regions)
regions = <0x01000000 2>;
- Region 0: 0x00000000-0x00FFFFFF -> Write-back (16MB)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The meaning of the first item is confusing—it seems to represent the offset of the region’s end address.
I suggest changing the format to:
<startAddr size policy>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants