Skip to content

arch/risc-v/eic7700x: Maintain the data cache through the L3 controller. - #20064

Open
Fishwaldo wants to merge 1 commit into
apache:masterfrom
Fishwaldo:eic7700x-feature-cache-pr
Open

arch/risc-v/eic7700x: Maintain the data cache through the L3 controller.#20064
Fishwaldo wants to merge 1 commit into
apache:masterfrom
Fishwaldo:eic7700x-feature-cache-pr

Conversation

@Fishwaldo

Copy link
Copy Markdown
Contributor

Summary

The EIC7700X is not cache coherent. No device that moves data on its own
snoops the harts' caches or is snooped by them, so software has to maintain
the cache around every transfer. These cores have no Zicbom, so there is no
instruction that can do it: maintenance is a store to the L3 controller
carrying the physical address of a cache block. This implements the
up_*_dcache interface on top of that.

That store is the only operation the hardware has, and it writes back and
invalidates together, so a block cannot be dropped without being written out
first. Two consequences, documented at the top of the file:

  • a range being invalidated must own whole 64-byte blocks, which
    up_invalidate_dcache() asserts, or a shared end block written back during
    a transfer lands on top of what the device delivered
  • cleaning has no alignment requirement, so a transmit buffer can sit anywhere

The L3 is inclusive of the L1 data cache and back invalidates it, so one store
per block maintains the whole hierarchy with nothing to do per hart. The three
up_*_dcache_all() entry points are a fence for that reason: no whole
hierarchy operation exists, naming every block would be fifteen and a half
million stores, and the harts are coherent with each other so only ordering is
left to do.

Why now

Nothing in tree calls this yet. It is a prerequisite for the EIC7700X eMMC and
SD driver, which follows in its own PR and cannot use its DMA engine without
it, and any future Ethernet or USB driver on this SoC inherits the same rules.
It is split out because it is independent of that driver and reviewable on its
own.

Testing

Built with -Wno-cpp -Werror for eic7700-evb:nsh, and booted on the ESWIN
EIC7700 EVB as part of the integration branch, where the storage driver
exercises it on every transfer: eMMC and SD both enumerate, mount and read.

tools/checkpatch.sh -c -u -m -g master..HEAD passes.

The EIC7700X is not cache coherent.  No device that moves data on its
own snoops the harts' caches or is snooped by them, so a buffer handed
to a device needs the cache maintained around the transfer.  The harts
are coherent with each other; it is DMA that is not.

The RISC-V standard offers no way to do that here: the Zicbom extension
this core does not implement is the portable answer, and there is no
other.  Maintenance is instead a store to the L3 controller carrying the
physical address of a cache block.  That store is the only operation the
hardware offers: it writes back and invalidates together, so a block
cannot be dropped without being written out first.  Everything built on
top is shaped by that, which is why a range being invalidated has to own
whole blocks.

The L3 is inclusive of the L1 data cache and back invalidates it, so one
store per block maintains the whole hierarchy, with nothing to do per
hart.  The block size is 64 bytes, which is what makes the descriptor
rules in the storage and network drivers what they are.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
@github-actions github-actions Bot added Arch: risc-v Issues related to the RISC-V (32-bit or 64-bit) architecture Size: M The size of the change in this PR is medium labels Sep 6, 2026
@github-actions

github-actions Bot commented Sep 6, 2026

Copy link
Copy Markdown

MemBrowse Memory Report

No memory changes detected for:

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

Labels

Arch: risc-v Issues related to the RISC-V (32-bit or 64-bit) architecture Size: M The size of the change in this PR is medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants