From mboxrd@z Thu Jan 1 00:00:00 1970 From: Auer, Lukas Date: Thu, 6 Sep 2018 22:21:56 +0000 Subject: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support In-Reply-To: References: <1535615675-24819-1-git-send-email-bmeng.cn@gmail.com> <1535615675-24819-13-git-send-email-bmeng.cn@gmail.com> <6fb3819e163d08050ad3af5fa88504e24ce5b2af.camel@aisec.fraunhofer.de> <5e025fe2b8e7d9ed34c41cd11bb74601783b74b7.camel@aisec.fraunhofer.de> <752D002CFF5D0F4FA35C0100F1D73F3F6BCBA74D@ATCPCS16.andestech.com> <8d4cfe377f00861ba9cd9bf92accb0a8ab7ee5c1.camel@aisec.fraunhofer.de> Message-ID: <9da936b3847fb9c6a75f3bae0a47cda32e370bc4.camel@aisec.fraunhofer.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Bin, On Thu, 2018-09-06 at 11:15 +0800, Bin Meng wrote: > Hi Lukas, > > On Wed, Sep 5, 2018 at 5:37 PM Auer, Lukas > 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 > > > wrote: > > > > > > > > > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de] > > > > > > Sent: Wednesday, September 05, 2018 5:53 AM > > > > > > To: bmeng.cn at gmail.com > > > > > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at 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 > > > > > > > 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 hm yes, you are right that wouldn't really work. At the same time, console I/O in the SBI is probably not that important. It would be good to have a proper specification for the SBI / machine mode firmware. At the moment there is only the documentation on Github [1]. As far as I know, the instruction emulation in bbl is also not specified anywhere. Thanks, Lukas [1]: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md