Hi guys,
I just tried to build the current SVN checkout (852) and apparently something tried to boot from CD-ROM which fails when I use the -kernel option.
agraf@lychee:/home/agraf/release/qemu> ./ppc64-softmmu/qemu-system-ppc64 -kernel /home/agraf/release/kvm/vmlinux -initrd /boot/initrd -append "console=ttyPZ0 root=/dev/hda3" -nographic -snapshot /SLES11/debian_lenny_powerpc_small.qcow -L ~/ppc64/bios -enable-kvm -m 512 Could not open option rom 'vgabios.bin': No such file or directory Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory C>> annot manage 'OHCI USB controller' PCI device type 'usb':
106b 3f (c 3 10)
============================================================= OpenBIOS 1.0 [Aug 17 2010 14:41] Configuration device id QEMU version 1 machine id 3 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
Trying cd:,\:tbxi... Trying cd:,\ppc\bootinfo.txt...
[bctrl in enter_forth jumps to address 0]
If additionally I pass in a CD-ROM image, everything is fine:
agraf@lychee:/home/agraf/release/qemu> ./ppc64-softmmu/qemu-system-ppc64 -kernel /home/agraf/release/kvm/vmlinux -initrd /boot/initrd -append "console=ttyPZ0 root=/dev/hda3" -nographic -snapshot /SLES11/debian_lenny_powerpc_small.qcow -L ~/ppc64/bios -enable-kvm -m 512 -cdrom /SLES11/debian_etch_powerpc_small.qcow Could not open option rom 'vgabios.bin': No such file or directory Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory C>> annot manage 'OHCI USB controller' PCI device type 'usb':
106b 3f (c 3 10)
============================================================= OpenBIOS 1.0 [Aug 17 2010 14:41] Configuration device id QEMU version 1 machine id 3 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
Trying cd:,\:tbxi... Trying cd:,\ppc\bootinfo.txt...
[ppc] Kernel already loaded (0x01000000 + 0x00d3574c) (initrd 0x02800000 + 0x005d5ea6) [ppc] Kernel command line: console=ttyPZ0 root=/dev/hda3
OF stdout device is: /pci@f0000000/mac-io@e/escc@13000/ch-b@13000 Preparing to boot Linux version 2.6.35-38620-g0195a22-dirty (agraf@lychee) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #338 SMP Tue Aug 17 14:00:18 CEST 2010 [...]
Does anyone have an idea what's going on?
Alex
Does anyone have an idea what's going on?
Alex
Have you been following the discussion on cdrom vs. cdrom:f (or whatever partition the CD-ROM boots from)? One of the recent changes necessitates specifying the partition instead of just cdrom. I'm pretty sure Mark is working on fixing this, but there was some challenge to it.
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Nick Couchman wrote:
Have you been following the discussion on cdrom vs. cdrom:f (or whatever partition the CD-ROM boots from)? One of the recent changes necessitates specifying the partition instead of just cdrom. I'm pretty sure Mark is working on fixing this, but there was some challenge to it.
-Nick
Actually this isn't quite right; at least Solaris 9 needs an explicit slice given on the boot command line in order for the bootblock to load correctly. When auto-boot is enabled (as by default) then this is now the default.
It's only when you turn off autoboot (as you would typically do for debugging) that you need to remember to give a specific slice.
HTH,
Mark.
Actually this isn't quite right; at least Solaris 9 needs an explicit slice given on the boot command line in order for the bootblock to load correctly. When auto-boot is enabled (as by default) then this is now the default.
It's only when you turn off autoboot (as you would typically do for debugging) that you need to remember to give a specific slice.
Ah...sorry to add to the confusion!
:-)
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On Tue, Aug 17, 2010 at 3:35 PM, Alexander Graf agraf@csgraf.de wrote:
Hi guys,
I just tried to build the current SVN checkout (852) and apparently something tried to boot from CD-ROM which fails when I use the -kernel option.
agraf@lychee:/home/agraf/release/qemu> ./ppc64-softmmu/qemu-system-ppc64 -kernel /home/agraf/release/kvm/vmlinux -initrd /boot/initrd -append "console=ttyPZ0 root=/dev/hda3" -nographic -snapshot /SLES11/debian_lenny_powerpc_small.qcow -L ~/ppc64/bios -enable-kvm -m 512 Could not open option rom 'vgabios.bin': No such file or directory Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory C>> annot manage 'OHCI USB controller' PCI device type 'usb':
106b 3f (c 3 10)
============================================================= OpenBIOS 1.0 [Aug 17 2010 14:41] Configuration device id QEMU version 1 machine id 3 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
Trying cd:,\:tbxi... Trying cd:,\ppc\bootinfo.txt...
[bctrl in enter_forth jumps to address 0]
If additionally I pass in a CD-ROM image, everything is fine:
agraf@lychee:/home/agraf/release/qemu> ./ppc64-softmmu/qemu-system-ppc64 -kernel /home/agraf/release/kvm/vmlinux -initrd /boot/initrd -append "console=ttyPZ0 root=/dev/hda3" -nographic -snapshot /SLES11/debian_lenny_powerpc_small.qcow -L ~/ppc64/bios -enable-kvm -m 512 -cdrom /SLES11/debian_etch_powerpc_small.qcow Could not open option rom 'vgabios.bin': No such file or directory Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory C>> annot manage 'OHCI USB controller' PCI device type 'usb':
106b 3f (c 3 10)
============================================================= OpenBIOS 1.0 [Aug 17 2010 14:41] Configuration device id QEMU version 1 machine id 3 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
Trying cd:,\:tbxi... Trying cd:,\ppc\bootinfo.txt...
[ppc] Kernel already loaded (0x01000000 + 0x00d3574c) (initrd 0x02800000 + 0x005d5ea6) [ppc] Kernel command line: console=ttyPZ0 root=/dev/hda3
OF stdout device is: /pci@f0000000/mac-io@e/escc@13000/ch-b@13000 Preparing to boot Linux version 2.6.35-38620-g0195a22-dirty (agraf@lychee) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #338 SMP Tue Aug 17 14:00:18 CEST 2010 [...]
Does anyone have an idea what's going on?
If there is no disk, kernel will be executed. I'd suspect breakage from r828.
Blue Swirl wrote:
Does anyone have an idea what's going on?
If there is no disk, kernel will be executed. I'd suspect breakage from r828.
Yeah, that's probably right. What should happen now is that the arch_init() function for each architecture should set up the NVRAM variables based upon the QEMU firmware configuration and the Forth will do the rest.
However, since the boot() function gets called before (encode-bootpath) then this could cause an issue. My dev cycles are fairly limited at the moment, but I think the following is the right solution:
- At the moment, only NVRAM variables are set in arch_init(). A few lines of code need to be added to place the kernel command line (QEMU's -append) into /chosen/bootargs
- Ensure that kernel boot only (i.e. no Forth) is attempted in any of the arch-specific boot() functions
- Change the boot word in forth/admin/userboot.fs so that (encode-bootpath) is called just before $load
HTH,
Mark.
Alexander Graf wrote:
Does anyone have an idea what's going on?
Alex
Hi Alex,
I've just committed a fix which enables us to attempt a kernel boot before attempting a normal "load & go" boot which I think should solve this.
I did also notice in arch/ppc/qemu/main.c that a kernel boot is only attempted if the QEMU boot device is set to 'm' - surely this check should be removed, and a kernel boot attempted unconditionally as long as all the sanity tests in check_preloaded_kernel() pass?
ATB,
Mark.
On 21.08.2010, at 12:28, Mark Cave-Ayland wrote:
Alexander Graf wrote:
Does anyone have an idea what's going on? Alex
Hi Alex,
I've just committed a fix which enables us to attempt a kernel boot before attempting a normal "load & go" boot which I think should solve this.
Wow, thanks a lot! Unfortunately suse is offline right now, so I can't try it out. But once I get access to my dev box again, I'll let you know! :)
I did also notice in arch/ppc/qemu/main.c that a kernel boot is only attempted if the QEMU boot device is set to 'm' - surely this check should be removed, and a kernel boot attempted unconditionally as long as all the sanity tests in check_preloaded_kernel() pass?
I think that would make sense, yeah.
Alex
-
Alexander Graf -
Blue Swirl -
Mark Cave-Ayland -
Nick Couchman