arch/risc-v/eic7700x: Maintain the data cache through the L3 controller. - #20064
Open
Fishwaldo wants to merge 1 commit into
Open
arch/risc-v/eic7700x: Maintain the data cache through the L3 controller.#20064Fishwaldo wants to merge 1 commit into
Fishwaldo wants to merge 1 commit into
Conversation
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>
Fishwaldo
requested review from
anchao,
eren-terzioglu,
lupyuen and
pussuw
as code owners
September 6, 2026 12:46
xiaoxiang781216
approved these changes
Sep 6, 2026
acassis
approved these changes
Sep 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_*_dcacheinterface 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:
up_invalidate_dcache()asserts, or a shared end block written back duringa transfer lands on top of what the device delivered
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 wholehierarchy 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 -Werrorforeic7700-evb:nsh, and booted on the ESWINEIC7700 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..HEADpasses.