rick@andestech.com 於 2018年11月14日 週三 下午3:35寫道：

...

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?

Hi Ben

As I know the mtime is the same as SiFive, but ipi is different. They all implemented via IP block instead of CSR.

And the following base definition seem to be fixed as some kind of HW implement. Maybe it can be more flexible.

/* MSIP registers */ #define MSIP_REG(base, hart) ((ulong)(base) + (hart) * 4) /* Timer compare register */ #define MTIMECMP_REG(base, hart) ((ulong)(base) + 0x4000 + (hart) * 8) /* Timer register */ #define MTIME_REG(base) ((ulong)(base) + 0xbff8)

Andes's ipi memory map plic0: interrupt-controller@e4000000 { compatible = "riscv,plic0"; #address-cells = <2>; #interrupt-cells = <2>; interrupt-controller; reg = <0x0 0xe4000000 0x0 0x2000000>; riscv,ndev=<71>; interrupts-extended = <&CPU0_intc 11 &CPU0_intc 9>; };

Andes's mt memory map plmt0@e6000000 { compatible = "riscv,plmt0"; interrupts-extended = <&CPU0_intc 7>; reg = <0x0 0xe6000000 0x0 0x100000>; }; };

It is obviously to be found that their base is different here.

Rick

...

...

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