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.a...@aisec.fraunhofer.de> wrote: > > > > On Wed, 2018-09-05 at 09:28 +0800, Rick Chen wrote: > > > > > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > > > > > Sent: Wednesday, September 05, 2018 5:53 AM > > > > > To: bmeng...@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.a...@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. > > > > 1. u-boot SPL starts in machine mode and jumps to bbl > > 2. bbl starts u-boot proper in supervisor mode > > 3. 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot