On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote:
On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
You're thinking in terms of which device to boot, which does make this difficult. However, it's equally valid to think in terms of which boot method to invoke, which makes this easy.
It is not. Because boot methods are enumerated by a guest at runtime. Qemu knows absolutely nothing about them. I am thinking in terms of devices because this is the only thing I have in qemu.
As before, a safe heuristic would be to request a rom boot for any device with a pci rom that the user requests to boot from.
Note, your original proposal included a boot method: /rom@genroms/linuxboot.bin I'm asking to extend this to be able to include roms on PCI devices.
We could tell the coreboot user to edit the "bootorder" file and add "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax of the name is not important).
But how user should knows that second rom (I think you mean "second BCV") on pci device 4.0 will boot from the new scsi cdrom that he just connected? How can he tell that it should put second BCV there and not third or fifth without running Seabios first and looking at F12 menu?
Exactly - look at the F12 menu. (Or, for bonus points, one could write a program that scans roms on the booted coreboot system, presents the user with a menu, and then writes the requested boot method to "bootorder".)
Being able to specify which boot method is a requirement for me. It doesn't have to be pretty, but it does have to be possible.
BTW to create proper EDD entry for SCSI boot device BIOS also needs too map BCV to id:lun. How it can be done?
It's the responsibility of the rom to build the EDD info. I don't know if all roms do this - I don't believe it's possible to get at the EDD info until after the drive has been mapped (ie, too late to use it for boot ordering).
How can we get to EDD info after device is mapped?
Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that the 0x13 irq and handle the request (or jump to the bios handler for drives it doesn't know about).
Can we use "disconnect vector" to connect device temporarily get EDD and then disconnect?
I understand. However, we'll still need to support arbitrary rom based BEVs and BCVs, so the use case is still important.
We can't do something that is impossible.
You've used this word "impossible" a few times - I'm afraid I don't know what it means.
For coreboot Seabios should implement what BBS spec says i.e enumerate all BCVs, present boot menu to the user, record number of BCVs and user's choice on non-volatile storage (CMOS).
Bleh - there's no need for that. Much more reliable is to record the device path for builtin devices or the boot method (device path of rom, plus bev/bcv instance) for rom based boots.