Risc-V, qemu, and initrd

Risc-V, qemu, and initrd

[Guenter Roeck]

Hi folks,

I tried to boot the latest Linux kernel with qemu from https://github.com/riscv/riscv-qemu.git,
branch qemu-2.13-for-upstream.

My command line is something like

     riscv64-softmmu/qemu-system-riscv64 -machine virt -m 512M -bios bbl -kernel vmlinux \
         -nographic -monitor none -initrd rootfs.cpio -append "rdinit=/sbin/init"

Unfortunately this doesn't work; the image crashes, complaining about a missing
root file system.

Loking into the kernel source, I found arch/riscv/kernel/setup.c:setup_initrd().
Debugging shows that initrd_start and initrd_end is set correctly in
drivers/of/fdt.c:early_init_dt_check_for_initrd(), but overwritten with the value
of __initramfs_start / __initramfs_size in setup_initrd(). This doesn't make
sense to me, since populate_rootfs() tries to populate the root file system
from both __initramfs_start and initrd_start.

Has anyone else noticed this problem ? Any idea what I need to do to load an
initrd with the -initrd option of qemu ?

Thanks,
Guenter

Risc-V, qemu, and initrd

[Atish Patra]

On 6/20/18 11:12 PM, Guenter Roeck wrote:
> Hi folks,
> 
> I tried to boot the latest Linux kernel with qemu from https://github.com/riscv/riscv-qemu.git,
> branch qemu-2.13-for-upstream.
> 

Did you try the upstream kernel? That doesn't boot directly. You need 
some additional patches which you can find here.

https://github.com/riscv/riscv-linux/tree/riscv-all


> My command line is something like
> 
>       riscv64-softmmu/qemu-system-riscv64 -machine virt -m 512M -bios bbl -kernel vmlinux \
>           -nographic -monitor none -initrd rootfs.cpio -append "rdinit=/sbin/init"
>

AFAIK, qemu -kernel argument expects the bbl file which as vmlinux 
embedded in it. At least that's what the makefile from freedom-u-sdk says:

https://github.com/sifive/freedom-u-sdk/blob/master/Makefile

Regards,
Atish

> Unfortunately this doesn't work; the image crashes, complaining about a missing
> root file system.
> 
> Loking into the kernel source, I found arch/riscv/kernel/setup.c:setup_initrd().
> Debugging shows that initrd_start and initrd_end is set correctly in
> drivers/of/fdt.c:early_init_dt_check_for_initrd(), but overwritten with the value
> of __initramfs_start / __initramfs_size in setup_initrd(). This doesn't make
> sense to me, since populate_rootfs() tries to populate the root file system
> from both __initramfs_start and initrd_start.
> 
> Has anyone else noticed this problem ? Any idea what I need to do to load an
> initrd with the -initrd option of qemu ?
> 
> Thanks,
> Guenter
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 

Risc-V, qemu, and initrd

[Andreas Schwab]

On Jun 20 2018, Guenter Roeck <linux@roeck-us.net> wrote:

> Loking into the kernel source, I found arch/riscv/kernel/setup.c:setup_initrd().
> Debugging shows that initrd_start and initrd_end is set correctly in
> drivers/of/fdt.c:early_init_dt_check_for_initrd(), but overwritten with the value
> of __initramfs_start / __initramfs_size in setup_initrd(). This doesn't make
> sense to me, since populate_rootfs() tries to populate the root file system
> from both __initramfs_start and initrd_start.
>
> Has anyone else noticed this problem ? Any idea what I need to do to load an
> initrd with the -initrd option of qemu ?

Try removing the offending lines in setup_initrd.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Risc-V, qemu, and initrd

[Guenter Roeck]

On Thu, Jun 21, 2018 at 04:30:55PM +0200, Andreas Schwab wrote:
> On Jun 20 2018, Guenter Roeck <linux@roeck-us.net> wrote:
> 
> > Loking into the kernel source, I found arch/riscv/kernel/setup.c:setup_initrd().
> > Debugging shows that initrd_start and initrd_end is set correctly in
> > drivers/of/fdt.c:early_init_dt_check_for_initrd(), but overwritten with the value
> > of __initramfs_start / __initramfs_size in setup_initrd(). This doesn't make
> > sense to me, since populate_rootfs() tries to populate the root file system
> > from both __initramfs_start and initrd_start.
> >
> > Has anyone else noticed this problem ? Any idea what I need to do to load an
> > initrd with the -initrd option of qemu ?
> 
> Try removing the offending lines in setup_initrd.
> 
I did. The resulting image hangs (I tried v4.17.2 and v4.18-rc1).
However, I can boot the latest image from the risc-v repository
to shell after commenting out the code in setup_initrd().

This is with qemu -M virt. The other machine types in qemu fail with
"rom: address overlap" errors. I didn't try to track down the reason.

Thanks,
Guenter

Risc-V, qemu, and initrd

[Christoph Hellwig]

On Thu, Jun 21, 2018 at 07:48:21AM -0700, Guenter Roeck wrote:
> I did. The resulting image hangs (I tried v4.17.2 and v4.18-rc1).

The upstream kernel is missing support for irq controllers and timers,
so I don't think it can boot on anything.

Here is my branch that allows me to boot qemu with 4.18-rc:

	http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-linux-4.18

Risc-V, qemu, and initrd

[Guenter Roeck]

On Thu, Jun 21, 2018 at 07:52:17AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 21, 2018 at 07:48:21AM -0700, Guenter Roeck wrote:
> > I did. The resulting image hangs (I tried v4.17.2 and v4.18-rc1).
> 
> The upstream kernel is missing support for irq controllers and timers,
> so I don't think it can boot on anything.
> 
Hmm ... not as bad as a car with no engine, but getting close.

> Here is my branch that allows me to boot qemu with 4.18-rc:
> 
> 	http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-linux-4.18

Yes, that boots if I disable setup_initrd(). I am still puzzled about the
purpose of setup_initrd() - it effectively disables external initrd,
initrd built into the kernel via CONFIG_INITRAMFS_SOURCE works just fine
without it, and no other architecture has similar code. Can/should it be
removed ?

Thanks,
Guenter

Risc-V, qemu, and initrd

[Guenter Roeck]

Hi Christoph,

On Thu, Jun 21, 2018 at 07:52:17AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 21, 2018 at 07:48:21AM -0700, Guenter Roeck wrote:
> > I did. The resulting image hangs (I tried v4.17.2 and v4.18-rc1).
> 
> The upstream kernel is missing support for irq controllers and timers,
> so I don't think it can boot on anything.
> 
> Here is my branch that allows me to boot qemu with 4.18-rc:
> 
> 	http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-linux-4.18

Are you able to boot anything but -M virt ? If yes, can you send me the
necessary command line parameters ?

Thanks,
Guenter

Risc-V, qemu, and initrd

[Christoph Hellwig]

On Thu, Jun 21, 2018 at 10:33:14AM -0700, Guenter Roeck wrote:
> Are you able to boot anything but -M virt ? If yes, can you send me the
> necessary command line parameters ?

Just -m virt.  For the SiFive board emulations a lot more driver
support is required.

Risc-V, qemu, and initrd

[Guenter Roeck]

On Thu, Jun 21, 2018 at 10:55:09AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 21, 2018 at 10:33:14AM -0700, Guenter Roeck wrote:
> > Are you able to boot anything but -M virt ? If yes, can you send me the
> > necessary command line parameters ?
> 
> Just -m virt.  For the SiFive board emulations a lot more driver
> support is required.

Ok. At least it is a start. Have you managed to connect a hard drive ?
I was only able to get it to work with initrd.

Thanks,
Guenter

Risc-V, qemu, and initrd

[Christoph Hellwig]

On Thu, Jun 21, 2018 at 03:08:59PM -0700, Guenter Roeck wrote:
> On Thu, Jun 21, 2018 at 10:55:09AM -0700, Christoph Hellwig wrote:
> > On Thu, Jun 21, 2018 at 10:33:14AM -0700, Guenter Roeck wrote:
> > > Are you able to boot anything but -M virt ? If yes, can you send me the
> > > necessary command line parameters ?
> > 
> > Just -m virt.  For the SiFive board emulations a lot more driver
> > support is required.
> 
> Ok. At least it is a start. Have you managed to connect a hard drive ?
> I was only able to get it to work with initrd.

Yes, I use virtio-blk.  Here is my qemu command line:

/opt/qemu-riscv/bin/qemu-system-riscv64 \
        -nographic \
        -machine virt \
        -kernel bbl \
        -append "root=/dev/vda ro console=ttyS0" \
        -drive file=../../busybear-linux/busybear.bin,format=raw,id=hd0 \
        -device virtio-blk-device,drive=hd0 \
        -netdev user,id=net0, \
        -device virtio-net-device,netdev=net0

Risc-V, qemu, and initrd

[Guenter Roeck]

On Thu, Jun 21, 2018 at 10:38:05PM -0700, Christoph Hellwig wrote:
> On Thu, Jun 21, 2018 at 03:08:59PM -0700, Guenter Roeck wrote:
> > On Thu, Jun 21, 2018 at 10:55:09AM -0700, Christoph Hellwig wrote:
> > > On Thu, Jun 21, 2018 at 10:33:14AM -0700, Guenter Roeck wrote:
> > > > Are you able to boot anything but -M virt ? If yes, can you send me the
> > > > necessary command line parameters ?
> > > 
> > > Just -m virt.  For the SiFive board emulations a lot more driver
> > > support is required.
> > 
> > Ok. At least it is a start. Have you managed to connect a hard drive ?
> > I was only able to get it to work with initrd.
> 
> Yes, I use virtio-blk.  Here is my qemu command line:
> 
> /opt/qemu-riscv/bin/qemu-system-riscv64 \
>         -nographic \
>         -machine virt \
>         -kernel bbl \
>         -append "root=/dev/vda ro console=ttyS0" \
>         -drive file=../../busybear-linux/busybear.bin,format=raw,id=hd0 \
>         -device virtio-blk-device,drive=hd0 \
>         -netdev user,id=net0, \
>         -device virtio-net-device,netdev=net0
> 

Yes, that worked. For some reason I had tried to use virtio-scsi-device.

With your Linux kernel ToT, after removing setup_initrd(), and with qemu
built from riscv/qemu-2.13-for-upstream, my testing now reports:

Building virt:defconfig:initrd ... running .... passed
Building virt:defconfig:rootfs ... running .... passed

Let's hope that upstream Linux soon gets to a point where I can activate
those tests.

Thanks a lot!

Guenter