qemu-coreboot scsi not working as expected

[aroobam]

Hi,
I am new to the Heads project and trying to get things working on qemu before jumping to the actual hardware ( I have the x630 in mind ).
I was able to build with "make BOARD=qemu-coreboot" and got the file "build/qemu-coreboot/coreboot.rom".
Then I try to run it in qemu with command line parameters as follows:
sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=./linuxboot.rom --serial /dev/tty -device virtio-scsi-pci,id=scsi-hd -drive if=none,file=cirros-0.4.0-x86_64-disk.img,id=disk,format=qcow2,boot=on,cache=writeback -device scsi-hd,drive=disk

The coreboot loads and gets to the boot menu. At this point I select option "y-default boot"
It says "mounting /dev/sda1 on /boot failed: No such file or directory".

I am expecting the cirrusOS image to be mounted as a scsi drive inside coreboot and OS to boot from that. Is this a valid expectation?

I see lspci list the device.
I do not see lsscsi list anything.
There is no sda entries under /dev
I do not see any scsi name drivers under /lib/modules

Am I trying to do something not supported? How do I go forward? Any pointers to documents, links, or if anyone has faced and solved this please help.

Thanks in advance.

[tlaurion]

make sure that controller is present under qemu Linux config. Also vtpm is not yet supported under qemu board as per opened ticket. Qemu is there to validate scripts changes and image building, but is not fully functional AFAIK. Update this ticket if you need more help. I think it's time to duplicate qemu board config to qemu-notpm until someone gets the glue together to support virtual TPM and other required Linux config options to better test what is needed.

…

On October 31, 2019 3:01:47 PM UTC, aroobam ***@***.***> wrote: Hi, I am new to the Heads project and trying to get things working on qemu before jumping to the actual hardware ( I have the x630 in mind ). I was able to build with "make BOARD=qemu-coreboot" and got the file "build/qemu-coreboot/coreboot.rom". Then I try to run it in qemu with command line parameters as follows: sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=./linuxboot.rom --serial /dev/tty -device virtio-scsi-pci,id=scsi-hd -drive if=none,file=cirros-0.4.0-x86_64-disk.img,id=disk,format=qcow2,boot=on,cache=writeback -device scsi-hd,drive=disk The coreboot loads and gets to the boot menu. At this point I select option "y-default boot" It says "mounting /dev/sda1 on /boot failed: No such file or directory". I am expecting the cirrusOS image to be mounted as a scsi drive inside coreboot and OS to boot from that. Is this a valid expectation? I see lspci list the device. I do not see lsscsi list anything. There is no sda entries under /dev I do not see any scsi name drivers under /lib/modules Am I trying to do something not supported? How do I go forward? Any pointers to documents, links, or if anyone has faced and solved this please help. Thanks in advance. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #32

-- Sent from /e/ Mail

[aroobam]

Disclaimer: I am a BIOS guy, relatively new to Linux and Qemu. Please excuse stupid basic questions.
When you say "controller present under qemu Linux config" you mean the SCSI controller is emulated in Qemu? Doesn't the parameter "-device virtio-scsi-pci" do that? If there is something more to be done, just let me know, like "check qemu doc", I will dig deeper.
I see a device class 0100 under lspci. This comes up only when I add the virtio-scsi device parameters on qemu launch. So it looks like the environment can see a storage device on the pci bus. Somehow a scsi driver is not available or I am not doing something to get the scsi driver going?

[aroobam]

Also, from your comments on qemu fully not supported, does it mean all the others working on linuxboot are jumping straight into the hardware and flashing their servers? I saw steps to flash x630 etc. Doing a proper server build packs the drivers required and everything works fine? Scary to imagine a blind dive into the abyss :-)

[tlaurion]

Sorry.

What I meant is that the qemu board (under board directory) links to a coreboot and a Linux config, proper to qemu emulated devices.

If the SCSI controller is not supported under the qemu Linux config, it won't be properly managed by absence of Linux drivers.

Make sure the SCSI driver is supported in Linux config.

Have you seen the emulating page of this wiki? Porting page would also shed some light.

I'm not a qemu guy either. All I'm saying here is that emulated/hardware drivers needs to be packed under Linux configuration for the board, and included in the root Makefile to be included in the rom to properly initialize desired board hardware. Else it is seen, but not taken charged of.

[osresearch]

Also, the SCSI devices won't show up until the libata.ko, libahci.ko and ahci.ko modules are installed with insmod.

[aroobam]

Hi Team,
I got some linux images that are working fine in USB mode. Full graphics support. See full command line below.
However, there are a few other images, like cirros, freedos, wheezy raspbian, dsl etc. that do not work, but say something wrong and fallback to recovery prompt.
Both the working images are qcow2. Some of the failing images are qcow2 and some are dd.img and some are .iso
So, I am guessing there is some kind of handshake/detect/identify happening that some images support and some don't? Is this a valid thought? I feel like I wasted time with a non-working image; or do we claim that all images "should" work?

Another problem, which I think is the next one for me to tackle, is getting these images work in SCSI mode. When I attach them to QEMU as a virtio-scsi-pci or virtio-blk-pci, and try boot mode default (y) they fall back to recovery prompt. Then I do a insmod of libata,libahci and ahci.ko and can see them under /dev and also lsscsi lists them. But how do I boot off them once I do this? I tried "generic-init" but it again reinits and detaches the drivers. Should I go back and rebuild the heads coreboot image and do some linux config magic to load the above insmod ko objects during startup? If that is the path to take, I need to get hold of a linux person who can help me with this. I am asking because I want to steal someone else's time only if that is a valid disturbance!

Thanks,
Madhan.

My successfully working usb images:

sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,file=./coreboot.rom -vga cirrus --serial /dev/tty -usb -drive id=usbflash,format=qcow2,file=debian_squeeze_amd64_standard.qcow2,if=none,boot=on,cache=writeback -device usb-storage,drive=usbflash -m 1024

sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,file=./coreboot.rom -vga cirrus --serial /dev/tty -usb -drive id=usbflash,format=qcow2,file=debian_squeeze_amd64_desktop.qcow2,if=none,boot=on,cache=writeback -device usb-storage,drive=usbflash -m 1024

sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,file=./coreboot.rom -vga cirrus --serial /dev/tty -usb -drive id=usbflash,format=qcow2,file=kali-2.0-light-amd64.qcow2.qcow2,if=none,boot=on,cache=writeback -device usb-storage,drive=usbflash -m 1024

[tlaurion]

@aroobam Should be added to linuxboot/heads#516 linuxboot/heads#701