Hi Lukas,
On Wed, Sep 5, 2018 at 5:37 PM Auer, Lukas lukas.auer@aisec.fraunhofer.de wrote:
On Wed, 2018-09-05 at 10:34 +0800, Bin Meng wrote:
Hi Rick,
On Wed, Sep 5, 2018 at 9:27 AM Rick Chen rickchen36@gmail.com wrote:
From: Auer, Lukas [mailto:lukas.auer@aisec.fraunhofer.de] Sent: Wednesday, September 05, 2018 5:53 AM To: bmeng.cn@gmail.com Cc: Rick Jian-Zhi Chen(陳建志); u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board
support
On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
Hi Lukas,
On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas lukas.auer@aisec.fraunhofer.de wrote: > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote: > > This adds QEMU RISC-V 'virt' board target support, with
the hope
> > of helping people easily test U-Boot on RISC-V. > > > > The QEMU virt machine models a generic RISC-V virtual
machine
> > with support for the VirtIO standard networking and
block
> > storage devices. > > It has CLINT, PLIC, 16550A UART devices in addition to
VirtIO
> > and it also uses device-tree to pass configuration
information
> > to guest software. It implements RISC-V privileged
architecture
> > spec v1.10. > > > > Both 32-bit and 64-bit builds are supported. Support is
pretty
> > much preliminary, only booting to U-Boot shell with the
UART
> > driver on a single core. Booting Linux is not supported
yet.
> > > > For your information and to avoid duplicate work, I am
working on
> a patch set that improves RISC-V support in u-boot. I am
currently
> able to boot Linux on a multi-core setup in QEMU, but they
are not
> quite ready to submit yet. >
This is great! My next step is to work on virtio driver
support in
U-Boot as qemu-riscv virt machine has these devices but we
don't
have corresponding drivers in U-Boot. Then I will try to
boot Linux
after that. Good to hear you already boot Linux with qemu-
riscv!
Have you already supported virtio drivers in your port? If
yes, I
will just hold on and wait for your patch series :-)
Hi Bin,
Support for the virtio devices would be great! I don't support
them in
my port, I can only boot a kernel image from RAM. I only have a driver for the clint0 (core local interrupt
controller),
which I need for software interrupts to other cores and as a
timer.
Software interrupts also work over the supervisor binary
interface
(SBI), which allows u-boot to run in supervisor mode with bbl
running
in machine mode to handle the SBI calls.
Hi Bin and Auer
I have already boot bbl run in S-mode and riscv-linux in M-mode via u-boot from SD card or FLASH. It mean after booting riscv-linux, u-boot will be dead. And no matter about kernel. Please refer to doc/README.ae350
Thanks for pointing out the doc for ae350. I just read it, and have one question. There is a chapter in that doc "Boot bbl and riscv- linux via U-Boot on QEMU", yet I don't see what QEMU command is invoked. Can you please clarify? AFAIK mainline QEMU does not have support to ae350 board. Also there is no instructions on how bbl was built. Is that the mainline bbl that can work on every riscv board? I doubt that.
May I figure out more clearly what are you going to do ? What are you going to do is let u-boot run in S-mode and boot bbl and riscv-linux in M-mode, right ?
I want to use U-Boot to directly boot Linux, but seems Lukas is using bbl for SBI implementation.
Hi Bin,
I don't really need bbl to run u-boot. I use it for Linux, which expects the SBI to be present.
It mean after booting bbl and riscv-linux, u-boot will still alive and handle SBI calls and somethings in S-mode.
Or u-boot is going to replace the role of bbl ?
That's my plan. I don't see a need to use bbl which is quite feature limited.
That's a good idea! At the very least, all the device initialization in bbl should be moved into u-boot. I do think a bootloader-independent SBI implementation makes sense though. That way all bootloaders can use the same implementation, which should make adding new SBI calls easier.
But I doubt we can have a generic SBI implementation. At least the console I/O SBI call can vary from board to board due to different UART devices are used.
Regards, Bin