Hi Lukas,
On Tue, Nov 13, 2018 at 10:45 PM Auer, Lukas lukas.auer@aisec.fraunhofer.de wrote:
Hi Bin,
On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
This adds U-Boot syscon driver for RISC-V Core Local Interruptor (CLINT). The CLINT block holds memory-mapped control and status registers associated with software and timer interrupts.
3 APIs are provided for U-Boot to implement Supervisor Binary Interface (SBI) as defined by the RISC-V privileged architecture spec v1.10.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Would it make sense to also abstract the functions provided by the CLINT more? The reason why I am asking is because the CLINT is (unfortunately) not specified as part of RISC-V. It is developing into a de facto standard since other platforms are following SiFive's implementation, but there is nothing that would prevent them from implementing something else.
I think your observation is correct about CLINT. Rick, does Andes's RISC-V processor also follow SiFive's CLINT model?
Two immediate examples I can think of would be mtime and the IPI implementation. Many SoC vendors will likely already have a suitable timer IP block for mtime. I can imagine that they would choose to re- use their memory map instead of following that of the CLINT. For the IPI implementation there is already an alternative, the SBI. If U-Boot should be able to run in supervisor mode, it would be helpful to support both the SBI and the CLINT interface.
I am not sure I followed you here. This driver provides 3 APIs: riscv_send_ipi() is for IPI, and the other 2 are for mtime/mtimecmp.
So what we would need is some kind of API for the functionality provided by the CLINT. For the multi-core support (I will try to send out a series soon) I am re-using the IRQ uclass ID (it is only used in arch code) to define a irq-uclass for RISC-V, which handles everything with IPIs. The CLINT0 and SBI are then just different driver implementing the uclass.
This is just an idea right now, what do you think?
Regards, Bin