[U-Boot] [PATCH 00/19] riscv: Adding RISC-V CPU and timer driver

Bin Meng bmeng.cn at gmail.com
Mon Dec 3 08:04:36 UTC 2018


Hi Anup,

On Mon, Dec 3, 2018 at 3:59 PM Anup Patel <anup at brainfault.org> wrote:
>
> On Tue, Nov 13, 2018 at 1:47 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > This adds DM drivers to support RISC-V CPU and timer.
> >
> > The U-Boot RISC-V SBI support is still working in progress.
> > Some patches in this series like adding CSR numbers, exception
> > numbers, are prerequisites for the SBI implementation, but it
> > does no harm to include them as part of this series.
> >
> > This series is dependent on Lukas's riscv series @
> > http://patchwork.ozlabs.org/project/uboot/list/?series=74999
> >
> > This series is available at u-boot-x86/riscv-working for testing.
> >
> >
> > Bin Meng (18):
> >   dm: cpu: Add timebase frequency to the platdata
> >   riscv: qemu: Create a simple-bus driver for the soc node
> >   cpu: Add a RISC-V CPU driver
> >   riscv: Add a SYSCON driver for Core Local Interruptor
> >   timer: Add driver for RISC-V privileged architecture defined timer
> >   riscv: kconfig: Allow platform to specify Kconfig options
> >   riscv: Enlarge the default SYS_MALLOC_F_LEN
> >   riscv: qemu: Probe cpus during boot
> >   riscv: Add CSR numbers
> >   riscv: Add exception codes for xcause register
> >   riscv: Do some basic architecture level cpu initialization
> >   riscv: Move trap handler codes to mtrap.S
> >   riscv: Fix context restore before returning from trap handler
> >   riscv: Return to previous privilege level after trap handling
> >   riscv: Adjust the _exit_trap() position to come before handle_trap()
> >   riscv: Pass correct exception code to _exit_trap()
> >   riscv: Refactor handle_trap() a little for future extension
> >   riscv: Allow U-Boot to run on hart 0 only
> >
>
> I see that this series tries to setup infrastructure for
> implementing SBI runtime servies.
>
> You might want to consider OpenSBI library, will be
> eventually available.
> (Refer, https://linuxplumbersconf.org/event/2/contributions/196/attachments/127/159/Atish_SBI.pdf)
>
> If every bootloader starts implementing SBI runtime
> services then there will be lot of fragmentation and SOC
> vendors will have to support SBI in variety of bootloaders.

Agreed. In fact Atish contacted me offline some time ago about
contributing in OpenSBI. Definitely I think that's the right approach,
so that I am not sending SBI implementation of my own for U-Boot.

Regards,
Bin


More information about the U-Boot mailing list