Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
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
Thank you for your patches, it's great to see better support for RISC-V in u-boot! I will add a few comments based on what I have learned so far from working with u-boot on RISC-V.
It's a good start. RISC-V is pretty new and needs more developers :-)
Exactly :)
Thanks, Lukas
Rick Chen rickchen36@gmail.com 於 2018年9月5日 週三 上午9:28寫道：
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
Sorry ! Correct some descriptions about S-mode and M-mode I have already boot bbl run in M-mode and riscv-linux in S-mode via u-boot from SD card or FLASH.
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
Thank you for your patches, it's great to see better support for RISC-V in u-boot! I will add a few comments based on what I have learned so far from working with u-boot on RISC-V.
It's a good start. RISC-V is pretty new and needs more developers :-)
Exactly :)
Thanks, Lukas
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.
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.
Regards, Bin
Bin Meng bmeng.cn@gmail.com 於 2018年9月5日 週三 上午10:34寫道：
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.
There are some teammates who are responsible for bbl, riscv-linux, u-boot, qemu individually. As I know they just pull source from mainline and have relative hooks for ax25-ae350. I am in charge of booting kernel via u-boot. And drivers (timer, serial, spi flash, smc flash, sd, mac, rtc, wdt,i2c, sound, lcd) verification on u-boot and kernel. That is why I am pending u-boot for a while.
When I finish booting riscv-linux via u-boot function. Then I have pushed them to u-boot upstream. And describe simply the build and run flow in doc/README.ae350. As I know, the implementations about bbl and qemu still not been pushed to upstream yet. Maybe I can ask them how about the upstream schedule !
Hope this can answer your question !
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.
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.
Sounds great ! Very looking forward to this achievement !
Rick
Regards, Bin
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.
Thanks, Lukas
Regards, Bin
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
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 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
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
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.
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
bbl is still active once Linux has booted and is used there for its SBI implementation. Hope this helps.
Thanks, Lukas
Thank you for your patches, it's great to see better support
for
RISC-V in u-boot! I will add a few comments based on what I
have
learned so far from working with u-boot on RISC-V.
It's a good start. RISC-V is pretty new and needs more
developers
:-)
Exactly :)
Thanks, Lukas
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.
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
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
participants (3)
-
Auer, Lukas -
Bin Meng -
Rick Chen