Hi Bin,
On Thu, 2018-09-06 at 11:14 +0800, Bin Meng wrote:
Hi Lukas,
On Wed, Sep 5, 2018 at 5:35 PM Auer, Lukas lukas.auer@aisec.fraunhofer.de wrote:
On Wed, 2018-09-05 at 09:28 +0800, Rick Chen 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
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 ? 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 ?
Rick
Hi Rick,
Not exactly, my current boot flow is as follows.
- u-boot SPL starts in machine mode and jumps to bbl
- bbl starts u-boot proper in supervisor mode
- u-boot boots the kernel
If this is QEMU virt target, there is no need to boot from SPL then U-Boot proper.
That's true. My goal was to load bbl without having to embed either u-boot or Linux in it. That boot flow is similar to armv8, where ARM trusted firmware can be loaded by SPL. With an SBI implementation in u-boot this is not required of course. I think I'll simplify my boot flow for now and remove SPL. Either u-boot or Linux must then be embedded into bbl until we have our own SBI implementation.
Thanks, Lukas
bbl is still active once Linux has booted and is used there for its SBI implementation. Hope this helps.
Yes, I am not quite convinced why Linux kernel was designed this way. This is something like x86's SMM or EFI runtime services...
Regards, Bin