The data cache invalidation function for c9xx CPUs uses `dcache.cipa`
instruction. According to T-Head extension specification[1] section
3.1.5, this instruction also performs a cache clean along with the
invalidation.
On top of being incorrect, this leads to a serious issue on the
designware ethernet driver, where stalled cache may get flushed each
time we handle a new received packet[2]. As a result, received packet
are randomly corrupted with old cached data. This can easily be
reproduced by sending an ARP request to the device during a TFTP
transfer. The last TFTP block is treated as the ARP reply we just sent,
which makes U-Boot hang on the block.
Always use `dcache.ipa` instruction to invalidate dcache. Replace
existing usages of `dcache.ipa` with our implementation.
Note that this fix is slightly intrusive as it changes the cache
invalidation behavior in all drivers. However, I have not noticed any
side-effect during my tests.
[1] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
[2] 918a8c89e0/drivers/net/designware.c (L475)
This commit extends the sandbox to implement a dummy
extension_board_scan() function and enables the extension command in
the sandbox configuration. It then adds a test that checks the proper
functionality of the extension command by applying two Device Tree
overlays to the sandbox Device Tree.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[trini: Limit to running on sandbox]
Signed-off-by: Tom Rini <trini@konsulko.com>
The following description is copied from the equivalent patch for the
Linux Kernel proposed by Aurelien Jarno:
>From version 2.38, binutils default to ISA spec version 20191213. This
means that the csr read/write (csrr*/csrw*) instructions and fence.i
instruction has separated from the `I` extension, become two standalone
extensions: Zicsr and Zifencei. As the kernel uses those instruction,
this causes the following build failure:
arch/riscv/cpu/mtrap.S: Assembler messages:
arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Christian Stewart <christian@paral.in>
Reviewed-by: Rick Chen <rick@andestech.com>
