Re: [edk2] CSM and keyboard handling

Subject: Re: [edk2] CSM and keyboard handling

From: Andrew Fish <>

To: David Woodhouse <>

Date: 2013-01-22 01:28:37

On Jan 21, 2013, at 4:43 PM, David Woodhouse  wrote:

> On Tue, 2013-01-22 at 00:29 +0000, Li, Elvin wrote:
>> You can make a try to implement such CSM16 to return back to EFI,
>> GenericLegacyBoot()
>> thus returns EFI_DEVICE_UNSUPPORTED, but it is BDS which initially
>> calls "LegacyBios->LegacyBoot ()" to launch legacy boot, you can add
>> error handling after LegacyBoot () returns and reconnect EFI drivers
>> and go to next boot options.
> Thanks. I'll maybe try to deal with that later, as well as the question
> of what I should be doing if an option ROM calls INT 16h for keyboard
> services during a Legacy16DispatchOprom call, before we've taken over
> the hardware.
> For now I'm trying to work out how the various bootable devices are
> supposed to end up in the BBS table. I'm so confused I can't even
> formulate coherent questions about it for now, so I'll keep staring at
> the code... :)
> The entries for different IDE hard drives in the BBS_TABLE that we hand
> to the CSM appear to be *identical*. The only way to tell them apart is
> that they appear in a fixed location. The primary IDE master is always
> BBS_TABLE[2], primary slave is [3], secondary master is [4] and
> secondary slave is [5]. Is the CSM really supposed to know which device
> is which *just* because of its position in the table? The PCI b/d/f are
> obviously the same for all four IDE devices. Is there not an 'index' or
> 'lun' field which identifies different disks attached to the same
> controller? I might be able to infer it for the basic IDE disks, but
> what if I have a SCSI controller and the user elects to boot the device
> at LUN 5? How would the CSM know?

OK having a big flashback to last millennium .....

The BBS device either  a BAID (known to the CSM), BCV (PCI ROM that hooks INT 13), or a BEV (just boot like a network card). There is an IPL table that contains BAID and BEV entries, and a BCV table that maps who gets to be C:. So these are the two knobs you have to work with. 

The EFI Device Path maps into the common structure used for the IPL and BCV table that is defined in the BBS spec:


An identification number that describes what type of device this is. 00h = Reserved
01h = Floppy
02h = Hard disk

03h = CD-ROM
04h = PCMCIA
05h = USB device
06h = Embedded network 07h..7Fh = Reserved

80h = BEV device
81h..FEh = Reserved
FFh = Unknown

The BAIDs may also show up the BCV table. 

So I think in your case you just want to have an EFI device path that maps to C: So maybe the BBS_TABLE is really just the BCV table? The PnP Expansion Header for the ROM has BCV/BEV info and a product string. So I think the UI is to just show the string to the user. There is no semantic knowledge of what is behind the BCV. 

Deep breadth and back to EFI for me....



> Not that SCSI controllers *do* appear there, of course. And neither does
> virtio, as I just mentioned.
> And we only invoke the iPXE ROM on the network card *after* the user has
> seen the boot menu (without that option), so the user never gets to
> choose that.
> I think I need some more coffee...
> -- 
> dwmw2

Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
edk2-devel mailing list