[SeaBIOS] [PATCHv6 00/16] boot order specification
gleb at redhat.com
Tue Nov 30 15:59:36 CET 2010
On Mon, Nov 29, 2010 at 08:55:09PM -0500, Kevin O'Connor wrote:
> On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote:
> > >>If scsi card has optionrom with only one bcv then Seabios can determine
> > >>its boot order from device path, so why not provide user with this
> > >>option today?
> > >It's unclear to me how SeaBIOS is supposed to do that.
> > Try to keep track of which bcv/bev belongs to which pci device? It
> > should surely work for devices supported by seabios natively.
> No issues for any device with native support. I'm okay with the
> proposed syntax.
> > SeaBIOS should also know which device's rom registered which entry.
> It doesn't today, but that shouldn't be an issue to add.
> > It might become tricky though in case there are multiple identical
> > devices are present, say two e1000 cards, where the first rom could
> > register entries for both cards ...
> Right - here's where things get complicated.
I don't see how it can be solved at all given that bev->productname
doesn't have any structure so it can't be parsed back to device's pci
> > >Maybe we can compromise here - if the user selects booting from a
> > >device, and qemu sees there is a rom for that device, then qemu can
> > >specify two boot options:
> > >
> > >/pci at i0cf8/ethernet at 4/ethernet-phy at 0
> > >/pci at i0cf8/rom at 4
> > >
> > >SeaBIOS will ignore the first entry, and act on the second entry.
> > SeaBIOS should be able to operate just fine with the first entry.
> > "ethernet at 4" means "the nic at bus address 4". As this is a PCI bus
> > "4" is the pci address. So SeaBIOS would just look what entries it
> > has for "00:04.0", run the rom, and ignore the "/ethernet-phy at 0"
> > part as it can't handle it.
> Right - I'm not happy about trying to parse out openbios device
> descriptors though. The natural flow (as I see it) is for seabios to
> find all the boot methods in the system and then see which ones have
> been requested to be prioritized. Trying to do fuzzy matching of
> found device to requested device just seems like an unnecessary pain
> >When booting via rom it can either just pick
> > the first entry unconditionally (probably good enougth in 99% of the
> > cases) or do some guesswork based on the order the entries are
> > registered.
> I guess that's the crux of the matter - I'd rather not do guessing in
> the firmware. The emulator is in a much better position to do
> heuristics and guessing - if nothing else, the emulator can allow the
> user to pass it in on the command-line.
Actually Seabios is in a much better position to do this heuristics
since only at runtime all IPLs are knows. What heuristics you think
emulator can implement?
> > >BTW, how are PCI locations specified in these paths? They should have
> > >a (bus, dev, fn) - your examples only seem to show dev. How are the
> > >other parts specified?
> > fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
> > Bus is specified via location in the tree, i.e. you'll see the
> > bridge for the secondary pci bus in the path, like this:
> > /pci at i0cf8/bridge at 7/ethernet at 3/...
> > (not sure it is actually named 'bridge' in the openfirmware specs though).
More information about the SeaBIOS