[RFC PATCH v3 0/2] Proposing custom CSR handling logic

Ruinland Chuan-Tzu Tsai posted 2 patches 2 days, 8 hours ago
Failed in applying to current master (apply log)
target/riscv/andes_cpu_bits.h  | 113 ++++++++++++++++++++++++
target/riscv/cpu.c             |  37 ++++++++
target/riscv/cpu.h             |  29 ++++++-
target/riscv/cpu_bits.h        |   3 +
target/riscv/csr.c             |  46 ++++++++--
target/riscv/csr_andes.inc.c   | 153 +++++++++++++++++++++++++++++++++
target/riscv/custom_cpu_bits.h |   3 +
7 files changed, 375 insertions(+), 9 deletions(-)
create mode 100644 target/riscv/andes_cpu_bits.h
create mode 100644 target/riscv/csr_andes.inc.c
create mode 100644 target/riscv/custom_cpu_bits.h

[RFC PATCH v3 0/2] Proposing custom CSR handling logic

Posted by Ruinland Chuan-Tzu Tsai 2 days, 8 hours ago
From: Ruinaldn ChuanTzu Tsai <ruinland@andestech.com>

The changes from V2 :
* Making custom CSR operation table become registerable.
* Re-use the riscv_csrrw() code instead of ducplication.
* Splitting custom CPU bits into seperated files.
* Splitting the AX25 CPU from the feature patch
* Adding custom/vendor value "holder."
    In previous patche

- - - -

Sorry for the late update. COVID really hit us hard lately.

I really appreciate the comments and suggestions from Bin and Alistair, and I
am very willing to answer the doubts.

For the questions regarding the hash table for CSR operations, that is because
we might have heterogeneous architecture with harts having diffrent CSR
extensions/features.
For instance, there are FLUSH32 and FLUSH64 CSR on the application cores
on the U54-MC and U74-MC series from SiFive, yet for the monitor cores (S51 and
S7), there are no such custom/vendor CSRs. Though I cannot disclose too much
for the time being, we Andes Technology have similar design choice on our
platforms; and thus, a mechanism for dynamically registering CSR operation
functions will become a substrate for further extension.

And one day if those CSRs become standardized, ones can easily pull-and-plug
the structures into `csr_ops` table.

The write_stub() is useful and necessary if such a CSR conducts some hardware 
behaviors which are hard to implement in QEMU's world view, such as cache
policies or something would fail-over in user's code, for instance, the
I/O feature probing code. And that's why we keep it inside our toolbox.

Adding TINFO is a bit in the twilight zone. It's officially documented in the
RISC-V Debug Spec, yet we Andes has our own customization (which might
come out of the shadow one day) on it and thus we decice to add the csrno in
the general parts (cpu_bits.h) and add the handling function in csr_andes.inc.c
for our further development.

For now, this patch with previously submitted Andes AE350 board support 
https://mail.gnu.org/archive/html/qemu-riscv/2021-03/msg00096.html 
could execute mainline U-boot (proper) and OpenSBI (with test payload)
successfully.


Cordially yours,
Ruinland ChuanTzu Tsai


Ruinaldn ChuanTzu Tsai (2):
  Adding Andes AX25 CPU model
  Adding preliminary custom/vendor CSR handling mechanism

 target/riscv/andes_cpu_bits.h  | 113 ++++++++++++++++++++++++
 target/riscv/cpu.c             |  37 ++++++++
 target/riscv/cpu.h             |  29 ++++++-
 target/riscv/cpu_bits.h        |   3 +
 target/riscv/csr.c             |  46 ++++++++--
 target/riscv/csr_andes.inc.c   | 153 +++++++++++++++++++++++++++++++++
 target/riscv/custom_cpu_bits.h |   3 +
 7 files changed, 375 insertions(+), 9 deletions(-)
 create mode 100644 target/riscv/andes_cpu_bits.h
 create mode 100644 target/riscv/csr_andes.inc.c
 create mode 100644 target/riscv/custom_cpu_bits.h

-- 
2.31.1