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? No. > > 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. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
