Re: For comment: draft BIOS use document for the kernel

Re: For comment: draft BIOS use document for the kernel

[Rob Landley]

On Friday 22 June 2001 12:20, Alan Cox wrote:

> int 0x10 service 3 is used during the boot loading sequence to obtain the
> cursor position. int 0x10 service 13 is used to display loading messages
> as the loading procedure continues. int 0x10 AH=0xE is used to display a
> progress bar of '=' characters during the bootstrap

I seem to remember '.' characters, not '='...

> It then uses int 0x10 AH=0x0E in order to print initial progress banners so
> that immediate feedback on the boot status is available. The 0x07 character
> is issued as well as printable characters and is expected to generate a
> bell.

Hmmm...  About when during the boot is this?  (I get a beep from the bios 
long before lilo, and another when the pcmcia stuff detects a card, but 
that's it...)

> usable memory data. It also handles older BIOSes that return AX/BX but not
> AX/BX data.

What does that mean?  (Return garbage in AX/BX?)

> Having sized memory the kernel moves on to set up peripherals. The BIOS
> INT 0x16, AH=0x03 service is invoked in order to set the keyboard repeat
> rate and the video BIOS is the called to set up video modes.

"then called"...

> The kernel tries to identify the video in terms of its generic features.
> Initially it invokes INT 0x10 AH=0x12 to test for the presence of EGA/VGA
> as oppose to CGA/MGA/HGA hardware.

"as opposed to"...

> Having completed video set up the hard disk data for hda and hdb is copied
> from the low memory BIOS area into the kernel tables. INT 0x13 AH-0x15 is
> used to check if a second disk is present.

Second disk or second IDE controller?  (We already copied hdb from low 
memory, are we now confirming it?)

> The kernel invokes the PCI_BIOS_PRESENT function initially, in order to
> test the availability of PCI services in the firmware. Assuming this is
> found them PCIBIOS_FIND_PCI_DEVICE, PCIBIOS_FIND_PCI_CLASS_CODE,
> PCIBIOS_GENERATE_SPECIAL_CYCLE, PCIBIOS_READ/WRITE_CONFIG_BYTE/WORD/DWORD
> calls are issued as the PCI service are configured, along with

either "services are" or "service is"...

> compatibility. One extension the Linux kernel makes to the official rules
> for parsing this table, is that in the presence of PCI/ISA machines it will

That is a totally gratuitous comma.  (Okay, I'm nit-picking.  It can stay if 
you think it can be house-trained, but I'm not feeding it.)


> 4.1	Boot Linux on the system
>
> 4.2	Insert a PCMCIA card, ensure the kernel detects it
>
> 4.3	Remove the PCMCIA card, ensure the kernel detects the change
>
> 4.4	Insert a cardbus card, ensure the kernel detects it
>
> 4.5	Verify the cardbus device is usable
>
> 4.6	Remove the cardbus device, ensure the kernel detects it


I have a 100% reproducable crash on Red Hat 7.1 if I put in a cardbus card, 
apm suspend, resume the system, then pop the cardbus card out.

Kernel panic, every time.  (I assumed it had been fixed in newer versions.  
I've been meaning to look into it, but it works fine with a 16 bit PCMCIA 
card so I just swapped my 100baseT for a 10baseT and everything's fine.

The cardbus card works fine if I put it in and pop it out without suspending, 
and it suspend works fine by itself (Although sound never comes back after an 
APM suspend.  I have to reboot the laptop to get sound back...)

Aht he joys of the Dell inspiron 3500.  Nice big screen, though...

Rob

For comment: draft BIOS use document for the kernel

[Alan Cox]

Linux 2.4 BIOS usage reference


Boot Sequence
-------------

Linux is normally loaded either directly as a bootable floppy image or from
hard disk via a boot loader called lilo. The kernel image is transferred 
into low memory and a parameter block above it. 

When booting from floppy disk the BIOS disk parameter tables are replaced
by a new table set up to allow a maximum sector count of 36 (the track size
for a 2.88Mb ED floppy)

int 0x13, AH=0x02 is issued to to probe and find the disk geometry.
int 0x13, AH=0x00 is used to reset the floppy controller.
int 0x13, AH=0x02 is then issued repeatedly to load tracks of data. The
	boot loader ensures no issued requests cross the track boundaries


int 0x10 service 3 is used during the boot loading sequence to obtain the
cursor position. int 0x10 service 13 is used to display loading messages
as the loading procedure continues. int 0x10 AH=0xE is used to display a
progress bar of '=' characters during the bootstrap


Control is then transferred to the loaded image whether by the floppy boot
loader or other services


Kernel Setup
------------

The initial kernel setup executes in 16bit mode. While in 16bit mode the
kernel calls and caches data from several 16bit calls whose data is not
available in 32bit mode

It then uses int 0x10 AH=0x0E in order to print initial progress banners so
that immediate feedback on the boot status is available. The 0x07 character
is issued as well as printable characters and is expected to generate a
bell.

Memory detection is done as follows, attempting to handle the various
methods that have been available over time

Memory Sizing
-------------

Firstly a call is made to BIOS INT 15  AX=0xE820 in order to read the
E820 map. A maximum of 32 blocks are supported by current kernels. The
'SMAP' signature is required and tested. In addition the SMAP signature
is restored each call, although not required by the specification in order
to handle some know BIOS bugs.

If the E820 call fails then the INT 15 AX=0xE801 service is called and the
results are sanity checked. In particular the code zeroes the CX/DX return 
values in order to detect BIOS implementations that do not set them 
usable memory data. It also handles older BIOSes that return AX/BX but not
AX/BX data.

When service E801 is used the kernel assumes that usable memory extends from
4K to the bottom of the EBDA, and from 1Mbyte to the top of the E801 area.

If neither service is available then INT 0x15 AH=0x88 is invoked in order to
get the memory size, up to 64Mb by the original IBM PC BIOS service.

Peripherals
-----------

Having sized memory the kernel moves on to set up peripherals. The BIOS
INT 0x16, AH=0x03 service is invoked in order to set the keyboard repeat
rate and the video BIOS is the called to set up video modes.

The kernel tries to identify the video in terms of its generic features.
Initially it invokes INT 0x10 AH=0x12 to test for the presence of EGA/VGA
as oppose to CGA/MGA/HGA hardware. 

INT 0x10 AH=0x03 is used to obtain the cursor position, and INT 0x10,
AH=0x0F is used to obtain the video page and the mode. If EGA or VGA
are present the normal BIOS locations of 0x485 and 0x484 are used to obtain
the font size and the screen height.

VESA BIOS video services are used to obtain the amount of video memory 
(INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0 protected mode interface
data if available (INT 0x10, AX=0x4F0A). Users are able to select graphical
video modes (INT 0x10 AX=0x4F02), or if not available the pre VESA mode
setup. The presence of the VESA BIOS is checked by the VESA get mode
information call (INT 0x10 AX=0x4F01)

Special modes will also invoke INT 0x10 AH=0x1200 (Alternate print screen),
INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10 AH=0x1201 (to turn off cursor
emulation) and INT 0x10 AH=0x01 (to set up the cursor).

Having completed video set up the hard disk data for hda and hdb is copied
from the low memory BIOS area into the kernel tables. INT 0x13 AH-0x15 is
used to check if a second disk is present. 

INT 0x15, AH=0xC0 is invoked in order to check for MCA bus machines. If an
MCA systab is available the first block of the table is also saved into
the kernel's own data areas.

INT 0x11 is used to check for a PS/2 mouse. If this function reports that
a PS/2 pointing device is present the kernel will also verify directly with
the PS/2 controller itself that the mouse is attached.


Power Management
----------------

Linux supports APM power management. It will issue APM BIOS service calls in 
order to set up power management, and if present will then issue calls to
the 32bit APM services after boot up.

During boot the kernel issues INT 0x15 AX=0x0530 in order to do an APM BIOS
installation check. It requires that a 32bit capable APM BIOS is present.
Assuming a valid 32bit capable APM BIOS is reported the kernel will then
issue an APM disconnect (INT 0x15 AX=0x5304) followed by a 32bit connect
(INT 0x15 AX=0x5303). 

The kernel then issues an APM installation check again (INT 0x15 AH=0x5300) 
in order to check if the BIOS feature flags have changed now 32bit mode
has been selected. Finally it checks the signature and saves the parameters.

At this point use of 16bit BIOS services cease and the kernel begins talking
directly to the hardware. It enters 32bit mode and transfers execution to
the 32bit kernel proper.


32bit Bootstrap
---------------

The 32bit bootstrap runs mostly independently of BIOS services. It does
however scan for and use certain tables if they are present.

PCI BIOS is used if the user requests it or PCI configuration type 1 and
type 2 are not available on the system. At that point the kernel searches
for the BIOS32 signature and then for the PCI signatures "PCI " and "$PCI"

The kernel invokes the PCI_BIOS_PRESENT function initially, in order to
test the availability of PCI services in the firmware. Assuming this is
found them PCIBIOS_FIND_PCI_DEVICE, PCIBIOS_FIND_PCI_CLASS_CODE, 
PCIBIOS_GENERATE_SPECIAL_CYCLE, PCIBIOS_READ/WRITE_CONFIG_BYTE/WORD/DWORD
calls are issued as the PCI service are configured, along with
PCIBIOS_GET_ROUTING_OPTIONS and PCIBIOS_SET_HW_INT to handle plug and play
devices.

In the majority of systems the kernel will directly invoke type 1 or type 2
configuration. In this situation the kernel will search for a $PIR PCI
IRQ routing table in the BIOS area (0xF0000->0xFFFFF) with a revision of 
0x100 (1.0). 

Multiprocessor Machines
-----------------------

The kernel will also search for an Intel MP 1.1 or MP 1.4 table. If this is
found it is used to obtain the multiprocessor data required to boot the
other processors as well as the APIC information, including IRQ routing
tables. Some older Linux boot loaders would overwrite the EBDA if it was
more than 4K, so the SMP tables are best placed elsewhere for Linux
compatibility. One extension the Linux kernel makes to the official rules
for parsing this table, is that in the presence of PCI/ISA machines it will
probe for and use the EISA ELCR configuration register if it appears to be
present.

If multiprocessor capability is detected then APM BIOS service usage is
disabled except for poweroff. The APM specification and the behaviour of
existing APM BIOS implementations under SMP conditions are at best described
as 'variable'.

VESA BIOS
---------

If the user selects a VESA BIOS console the VESA 32bit BIOS calls for 
screen panning are used in order to scroll the VESA linear frame buffer and
to do colour manipulation. 

Providing the 32 bit VESA BIOS calls are available the kernel calls
function 0x4F07 (pan display) in order to implement scrolling. When using an
8bit console depth the palette reload (0x4F09) function is used to reload
colour tables. In the absence of the 32bit interface the kernel does
software scrolling and assumes the colour registers are VGA compatible 
hardware.

The memory region segment option is not supported. If this is found then
the kernel acts as if 32bit VESA extensions are not available.

PnPBIOS
-------

BIOS plug and play 32bit services are used if present. The functions used
are 0x00 (GET_NUM_SYS_DEV_NODES) , 0x01 (GET_SYS_DEV_NODE), 0x02
(SET_SYS_DEV_NODE). Docking station and ESCD services are not currently
utilised at all. Linux currently makes fairly minimal use of the PnPBIOS
services, simply using them to find certain motherboard device
configurations.

32bit Power Management
----------------------

When 32bit APM services are available the kernel will use APM facilities to
do power management, instead of issuing 'hlt' instructions when idle.

After the initial boot up the APM kernel thread issues APM function
VERSION (0x530E) specifying a maximum version of 1.2. If this fails it
assumes APM 1.0 services. ENGAGE_PM (0x530F) is then issued if the power 
management is currently disengaged. 

The APM task then loops handling pending APM requests once a second.
GET_EVENT (0x530B) is invoked to process pending events. When the kernel
wishes to change power state it will issue SET_STATE (0x5307) in order to
transfer state. 

The idle transition loops will invoke IDLE (0x5305) and BUSY (0x5306) as
appropriate to allow the BIOS to execute its power management policy.

GET_STATUS(0x530A) is issued when user processes request battery status in
order to implement battery monitoring applications. 

SET_STATE is also issued when the display timer expires in the OS. In this
situation the kernel tries to blank the primary display device (0x100) or if
this fails to blank all video devices (0x1ff)

Power Management and BIOS Bugs
------------------------------

The APM BIOS is a complex subsystem and has historically had many bugs, 
particularly in older laptop systems. To handle this the APM BIOS supports a
variety of options to work around problems

Linux will ignore small segment limits provided by the BIOS and always
set the segment limit to 64K. This is necessary as some BIOSes get the
limit values wrong.

Linux will call BIOS functions with a selector of 0x40 pointing to the real
mode address base of 0x40:0. Many BIOS functions rely on this selector being
present even though the specification does not permit the assumption.

Options control whether BIOS functions are invoked with interrupts enabled
or disabled. A correctly functioning APM BIOS should not care but some do.

Options also control whether the power off is issued 32bit or 16bit, with
the kernel transitioning to 16bit before issuing the power off request.

Finally the battery status querying can be disabled to work around a small
number of BIOSes which crash when this function is used from 32bit space.
These options can be keyed from the DMI table scanner, so that, if we are
made aware of BIOSes requiring options set specific ways we can
automatically set the options correctly for that BIOS without user
intervention.

Power Management Assumptions
----------------------------

The Linux 2,4 kernel power management code will restore certain devices
itself but it does rely on the BIOS to correctly save and restore the
following
	o	MTRR registers
	o	AGP configuration
	o	Hard disk parameters - including waking the drive properly
		on a resume

The SMM BIOS code needs to be aware that Linux is not windows. In particular
we have seen problems where the save/restore code for the video BIOS is not
capable of handling any mode not used by windows. 

The Linux kernel makes use of certain advanced features, and while these
should not intrude into the SMM mode some of them are worth mentioning 

	Processor State
		Linux makes use of machine check exceptions, 36bit 
		extensions, MTRR registers, and 4Mbyte pages

	Interrupt Controllers
		Linux will use the APIC when available, including on newer
		single processor machines. SMM code must be aware that the
		IRQ routing may have been configured for this

	PCI
		In some circumstances Linux will assign PCI bus resources
		and potentially renumber and relocate devices. It tries
		where possible to keep the existing BIOS setup


Testing Strategy
----------------

Because Linux makes little use of the BIOS services it is relatively easy to
run a test sequence to get basic validation of APM functionality under
Linux.

The recommended procedure is as follows

1.	Boot Linux on the system
	Verify the system boots
	[Does basic verification of PCI services, boot up 16bit calls]

	Login to the system

1.1	Type 'free'
	Verify the amount of free memory appears correct
	[Verifies memory reporting is working correctly]

1.2	Type 'cat /proc/apm'
	Verify that the machine does not crash
	[Verifies GET_STATUS 32bit call]

1.3	Type 'apm -s'
	The machine should standby

1.4	Wake it and type 'apm -S'
	The machine should suspend

1.5	Verify the BIOS hot-keys for suspend etc work

1.6	Verify the BIOS suspend to disk works if applicable

1.7	Resume the machine and type 'poweroff'

The system should now shutdown

2.	Boot Linux on the system
	Start the graphical user interface

	Repeat steps 1.3 to 1.6 from a terminal window in the GUI

	This verifies that the APM suspend/restore correctly handles 
	the GUI save/restore

	Add the line "vga=0x0311" to the /etc/lilo.conf 
	Rerun lilo

	Repeat step 1.7

3.	Boot the system
	This time the VGA option will try to use VESA BIOS services
	to set a 640x480 16bit mode. 

3.1	Login to the system

3.2	Type 'ls -lR /'

	This will cause the screen pan/scrolling BIOS calls to be tested
	After this has scrolled for a bit hit ^C

3.3	Remove the "vga=0x0311" option from /etc/lilo.conf
	Rerun lilo

	This ensures the setup is correct for any future test run


4. Additional Laptop Test

4.1	Boot Linux on the system

4.2	Insert a PCMCIA card, ensure the kernel detects it

4.3	Remove the PCMCIA card, ensure the kernel detects the change

4.4	Insert a cardbus card, ensure the kernel detects it

4.5	Verify the cardbus device is usable

4.6	Remove the cardbus device, ensure the kernel detects it



Compatibility With Older (2.2) Linux
------------------------------------

Linux 2.2 makes fairly similar BIOS calls to the 2.4 kernel. It does not
support PCI plug and play setup and should generally be configured in the
BIOS as a non plug and play operating system. On machines with large amounts
of memory the earlier 2.2 kernels frequently do not see all of it as they
lack the E820 memory sizing code. 2.2 users should probably be advised to
upgrade to Linux 2.2.19 or higher on such machines.


Future Paths
------------

Intel are currently working on ACPI support for Linux. While much of this is
functional it is not yet stable enough that vendors enable it. Linux does
not require APM services to do minimal power management, nor does it require
PnPBIOS services to function happily. It does however need to know about 
interrupt routing. For minimal Linux compatibility a 'legacy free' BIOS
should probably provide the $PIR table, even if it does not provide non ACPI
versions of other services.

Re: For comment: draft BIOS use document for the kernel

[Timur Tabi]

** Reply to message from Alan Cox <alan@lxorguk.ukuu.org.uk> on Fri, 22 Jun
2001 17:20:33 +0100 (BST)


> Firstly a call is made to BIOS INT 15  AX=0xE820 in order to read the
> E820 map. A maximum of 32 blocks are supported by current kernels. The
> 'SMAP' signature is required and tested. In addition the SMAP signature
> is restored each call, although not required by the specification in order
> to handle some know BIOS bugs.

FYI, in OS/2, the E820 call is made only on machines with a Pentium Pro or
higher, because apparently (and this is my guess) there are some motherboards
out there with older CPUs that don't return a reliable result to the E820 call.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: For comment: draft BIOS use document for the kernel

[Brad Pepers]

> 1.3	Type 'apm -s'
> 	The machine should standby
>
> 1.4	Wake it and type 'apm -S'
> 	The machine should suspend

According to the man pages, "apm -s" does a suspend and "apm -S" does a 
standby.

-- 
Brad Pepers
brad@linuxcanada.com

Re: For comment: draft BIOS use document for the kernel

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Linux 2.4 BIOS usage reference

Pretty decent.  It misses a lot of hardware details that we still
depend on the BIOS to reliably setup for us.

I've got code that does all of this so, setup on a couple of
boards so it should just be a matter of tracking it down and including
it in the documentation.

If there is interest I'll start tracking it down as soon as I have a
free minute.

Eric

Re: For comment: draft BIOS use document for the kernel

[Riley Williams]

Hi Alan.

Brief critique...

 > Linux 2.4 BIOS usage reference

 > Boot Sequence
 > -------------
 >
 > Linux is normally loaded either directly as a bootable floppy
 > image or from hard disk via a boot loader called lilo. The
 > kernel image is transferred into low memory and a parameter
 > block above it.
 >
 > When booting from floppy disk the BIOS disk parameter tables are
 > replaced by a new table set up to allow a maximum sector count
 > of 36 (the track size for a 2.88Mb ED floppy)
 >
 > int 0x13, AH=0x02 is issued to to probe and find the disk geometry.
 > int 0x13, AH=0x00 is used to reset the floppy controller.
 > int 0x13, AH=0x02 is then issued repeatedly to load tracks of
 >	data. The boot loader ensures no issued requests cross the
 >	track boundaries
 >
 > int 0x10 service 3 is used during the boot loading sequence to
 > obtain the cursor position. int 0x10 service 13 is used to
 > display loading messages as the loading procedure continues. int
 > 0x10 AH=0xE is used to display a progress bar of '=' characters
 > during the bootstrap
 >
 > Control is then transferred to the loaded image whether by the
 > floppy boot loader or other services

That looks OK.

 > Kernel Setup
 > ------------
 >
 > The initial kernel setup executes in 16bit mode. While in 16bit
 > mode the kernel calls and caches data from several 16bit calls
 > whose data is not available in 32bit mode
 >
 > It then uses int 0x10 AH=0x0E in order to print initial progress
 > banners so that immediate feedback on the boot status is
 > available. The 0x07 character is issued as well as printable
 > characters and is expected to generate a bell.
 >
 > Memory detection is done as follows, attempting to handle the
 > various methods that have been available over time

That looks OK.

 > Memory Sizing
 > -------------
 >
 > Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read
 > the E820 map. A maximum of 32 blocks are supported by current
 > kernels. The 'SMAP' signature is required and tested. In
 > addition the SMAP signature is restored each call, although not
 > required by the specification in order to handle some know BIOS
 > bugs.
 >
 > If the E820 call fails then the INT 15 AX=0xE801 service is
 > called and the results are sanity checked. In particular the
 > code zeroes the CX/DX return values in order to detect BIOS
 > implementations that do not set them usable memory data.

That looks OK.

 > It also handles older BIOSes that return AX/BX but not AX/BX data.

Please explain that a little more clearly - it means nothing to me.

 > When service E801 is used the kernel assumes that usable memory
 > extends from 4K to the bottom of the EBDA, and from 1Mbyte to
 > the top of the E801 area.
 >
 > If neither service is available then INT 0x15 AH=0x88 is invoked
 > in order to get the memory size, up to 64Mb by the original IBM
 > PC BIOS service.

That looks OK.

 > Peripherals
 > -----------
 >
 > Having sized memory the kernel moves on to set up peripherals.
 > The BIOS INT 0x16, AH=0x03 service is invoked in order to set
 > the keyboard repeat rate and the video BIOS is the called to set
                                                  ^^^
 > up video modes.

Assuming that should be "then", that's fine.

 > The kernel tries to identify the video in terms of its generic
 > features. Initially it invokes INT 0x10 AH=0x12 to test for the
 > presence of EGA/VGA as oppose to CGA/MGA/HGA hardware.
 >
 > INT 0x10 AH=0x03 is used to obtain the cursor position, and INT
 > 0x10, AH=0x0F is used to obtain the video page and the mode. If
 > EGA or VGA are present the normal BIOS locations of 0x485 and
 > 0x484 are used to obtain the font size and the screen height.
 >
 > VESA BIOS video services are used to obtain the amount of video
 > memory (INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0
 > protected mode interface data if available (INT 0x10,
 > AX=0x4F0A). Users are able to select graphical video modes (INT
 > 0x10 AX=0x4F02), or if not available the pre VESA mode setup.
 > The presence of the VESA BIOS is checked by the VESA get mode
 > information call (INT 0x10 AX=0x4F01)

That's fine.

 > Special modes will also invoke INT 0x10 AH=0x1200 (Alternate
 > print screen), INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10
 > AH=0x1201 (to turn off cursor emulation) and INT 0x10 AH=0x01
 > (to set up the cursor).

What do you mean by "Special modes" ?

 > Having completed video set up the hard disk data for hda and hdb
 > is copied from the low memory BIOS area into the kernel tables.
 > INT 0x13 AH-0x15 is used to check if a second disk is present.

Is that only for hda and hdb, or is hdc/hdd checked for as well?

 > INT 0x15, AH=0xC0 is invoked in order to check for MCA bus
 > machines. If an MCA systab is available the first block of the
 > table is also saved into the kernel's own data areas.

That's fine.

 > INT 0x11 is used to check for a PS/2 mouse. If this function
 > reports that a PS/2 pointing device is present the kernel will
 > also verify directly with the PS/2 controller itself that the
 > mouse is attached.

That paragraph could use expanding to explain whether it also checks
for a PS/2 keyboard, and how it deals with systems with the one but
not the other (either way round).

 > Power Management
 > ----------------
 >
 > Linux supports APM power management. It will issue APM BIOS
 > service calls in order to set up power management, and if
 > present will then issue calls to the 32bit APM services after
 > boot up.
 >
 > During boot the kernel issues INT 0x15 AX=0x0530 in order to do
 > an APM BIOS installation check. It requires that a 32bit capable
 > APM BIOS is present. Assuming a valid 32bit capable APM BIOS is
 > reported the kernel will then issue an APM disconnect (INT 0x15
 > AX=0x5304) followed by a 32bit connect (INT 0x15 AX=0x5303).
 >
 > The kernel then issues an APM installation check again (INT 0x15
 > AH=0x5300)  in order to check if the BIOS feature flags have
 > changed now 32bit mode has been selected. Finally it checks the
 > signature and saves the parameters.
 >
 > At this point use of 16bit BIOS services cease and the kernel
 > begins talking directly to the hardware. It enters 32bit mode
 > and transfers execution to the 32bit kernel proper.

 > 32bit Bootstrap
 > ---------------
 >
 > The 32bit bootstrap runs mostly independently of BIOS services.
 > It does however scan for and use certain tables if they are
 > present.
 >
 > PCI BIOS is used if the user requests it or PCI configuration
 > type 1 and type 2 are not available on the system. At that point
 > the kernel searches for the BIOS32 signature and then for the
 > PCI signatures "PCI " and "$PCI"
 >
 > The kernel invokes the PCI_BIOS_PRESENT function initially, in
 > order to test the availability of PCI services in the firmware.
 > Assuming this is found them PCIBIOS_FIND_PCI_DEVICE,
 > PCIBIOS_FIND_PCI_CLASS_CODE, PCIBIOS_GENERATE_SPECIAL_CYCLE,
 > PCIBIOS_READ/WRITE_CONFIG_BYTE/WORD/DWORD calls are issued as
 > the PCI service are configured, along with
 > PCIBIOS_GET_ROUTING_OPTIONS and PCIBIOS_SET_HW_INT to handle
 > plug and play devices.
 >
 > In the majority of systems the kernel will directly invoke type
 > 1 or type 2 configuration. In this situation the kernel will
 > search for a $PIR PCI IRQ routing table in the BIOS area
 > (0xF0000->0xFFFFF) with a revision of 0x100 (1.0).

That makes sense.

 > Multiprocessor Machines
 > -----------------------
 >
 > The kernel will also search for an Intel MP 1.1 or MP 1.4 table.
 > If this is found it is used to obtain the multiprocessor data
 > required to boot the other processors as well as the APIC
 > information, including IRQ routing tables. Some older Linux boot
 > loaders would overwrite the EBDA if it was more than 4K, so the
 > SMP tables are best placed elsewhere for Linux compatibility.
 > One extension the Linux kernel makes to the official rules for
 > parsing this table, is that in the presence of PCI/ISA machines
 > it will probe for and use the EISA ELCR configuration register
 > if it appears to be present.
 >
 > If multiprocessor capability is detected then APM BIOS service
 > usage is disabled except for poweroff. The APM specification and
 > the behaviour of existing APM BIOS implementations under SMP
 > conditions are at best described as 'variable'.

That's fine.

 > VESA BIOS
 > ---------
 >
 > If the user selects a VESA BIOS console the VESA 32bit BIOS
 > calls for screen panning are used in order to scroll the VESA
 > linear frame buffer and to do colour manipulation.
 >
 > Providing the 32 bit VESA BIOS calls are available the kernel
 > calls function 0x4F07 (pan display) in order to implement
 > scrolling. When using an 8bit console depth the palette reload
 > (0x4F09) function is used to reload colour tables. In the
 > absence of the 32bit interface the kernel does software
 > scrolling and assumes the colour registers are VGA compatible
 > hardware.
 >
 > The memory region segment option is not supported. If this is
 > found then the kernel acts as if 32bit VESA extensions are not
 > available.

That makes sense.

 > PnPBIOS
 > -------
 >
 > BIOS plug and play 32bit services are used if present. The
 > functions used are 0x00 (GET_NUM_SYS_DEV_NODES) , 0x01
 > (GET_SYS_DEV_NODE), 0x02 (SET_SYS_DEV_NODE). Docking station and
 > ESCD services are not currently utilised at all. Linux currently
 > makes fairly minimal use of the PnPBIOS services, simply using
 > them to find certain motherboard device configurations.

That makes sense.

 > 32bit Power Management
 > ----------------------
 >
 > When 32bit APM services are available the kernel will use APM
 > facilities to do power management, instead of issuing 'hlt'
 > instructions when idle.
 >
 > After the initial boot up the APM kernel thread issues APM
 > function VERSION (0x530E) specifying a maximum version of 1.2.
 > If this fails it assumes APM 1.0 services. ENGAGE_PM (0x530F) is
 > then issued if the power management is currently disengaged.
 >
 > The APM task then loops handling pending APM requests once a
 > second. GET_EVENT (0x530B) is invoked to process pending events.
 > When the kernel wishes to change power state it will issue
 > SET_STATE (0x5307) in order to transfer state.
 >
 > The idle transition loops will invoke IDLE (0x5305) and BUSY
 > (0x5306) as appropriate to allow the BIOS to execute its power
 > management policy.
 >
 > GET_STATUS(0x530A) is issued when user processes request battery
 > status in order to implement battery monitoring applications.
 >
 > SET_STATE is also issued when the display timer expires in the
 > OS. In this situation the kernel tries to blank the primary
 > display device (0x100) or if this fails to blank all video
 > devices (0x1ff)

That makes sense.

 > Power Management and BIOS Bugs
 > ------------------------------
 >
 > The APM BIOS is a complex subsystem and has historically had
 > many bugs, particularly in older laptop systems. To handle this
 > the APM BIOS supports a variety of options to work around
 > problems
 >
 > Linux will ignore small segment limits provided by the BIOS and
 > always set the segment limit to 64K. This is necessary as some
 > BIOSes get the limit values wrong.
 >
 > Linux will call BIOS functions with a selector of 0x40 pointing
 > to the real mode address base of 0x40:0. Many BIOS functions
 > rely on this selector being present even though the
 > specification does not permit the assumption.
 >
 > Options control whether BIOS functions are invoked with
 > interrupts enabled or disabled. A correctly functioning APM BIOS
 > should not care but some do.
 >
 > Options also control whether the power off is issued 32bit or
 > 16bit, with the kernel transitioning to 16bit before issuing the
 > power off request.
 >
 > Finally the battery status querying can be disabled to work
 > around a small number of BIOSes which crash when this function
 > is used from 32bit space. These options can be keyed from the
 > DMI table scanner, so that, if we are made aware of BIOSes
 > requiring options set specific ways we can automatically set the
 > options correctly for that BIOS without user intervention.

That all makes sense.

 > Power Management Assumptions
 > ----------------------------
 >
 > The Linux 2,4 kernel power management code will restore certain
 > devices itself but it does rely on the BIOS to correctly save
 > and restore the following
 >
 > 	o	MTRR registers
 > 	o	AGP configuration
 > 	o	Hard disk parameters - including waking the drive
 > 		properly on a resume
 >
 > The SMM BIOS code needs to be aware that Linux is not windows.
 > In particular we have seen problems where the save/restore code
 > for the video BIOS is not capable of handling any mode not used
 > by windows.
 >
 > The Linux kernel makes use of certain advanced features, and
 > while these should not intrude into the SMM mode some of them
 > are worth mentioning
 >
 > 	Processor State
 > 		Linux makes use of machine check exceptions, 36bit
 > 		extensions, MTRR registers, and 4Mbyte pages

That all makes sense.

 > 	Interrupt Controllers
 > 		Linux will use the APIC when available, including on newer
 > 		single processor machines. SMM code must be aware that the
 > 		IRQ routing may have been configured for this
 >
 > 	PCI
 > 		In some circumstances Linux will assign PCI bus resources
 > 		and potentially renumber and relocate devices. It tries
 > 		where possible to keep the existing BIOS setup

Those two could use rephrasing to clarify their meaning.

 > Testing Strategy
 > ----------------
 >
 > Because Linux makes little use of the BIOS services it is
 > relatively easy to run a test sequence to get basic validation
 > of APM functionality under Linux.
 >
 > The recommended procedure is as follows
 >
 > 1.	Boot Linux on the system
 > 	Verify the system boots
 > 	[Does basic verification of PCI services, boot up 16bit calls]
 >
 > 	Login to the system
 >
 > 1.1	Type 'free'
 > 	Verify the amount of free memory appears correct
 > 	[Verifies memory reporting is working correctly]
 >
 > 1.2	Type 'cat /proc/apm'
 > 	Verify that the machine does not crash
 > 	[Verifies GET_STATUS 32bit call]
 >
 > 1.3	Type 'apm -s'
 > 	The machine should standby
 >
 > 1.4	Wake it and type 'apm -S'
 > 	The machine should suspend
 >
 > 1.5	Verify the BIOS hot-keys for suspend etc work
 >
 > 1.6	Verify the BIOS suspend to disk works if applicable
 >
 > 1.7	Resume the machine and type 'poweroff'
 >
 > The system should now shutdown

That all appears fine.

 > 2.	Boot Linux on the system
 > 	Start the graphical user interface
 >
 > 	Repeat steps 1.3 to 1.6 from a terminal window in the GUI
 >
 > 	This verifies that the APM suspend/restore correctly handles
 > 	the GUI save/restore
 >
 > 	Add the line "vga=0x0311" to the /etc/lilo.conf
 > 	Rerun lilo
 >
 > 	Repeat step 1.7
 >
 > 3.	Boot the system
 > 	This time the VGA option will try to use VESA BIOS services
 > 	to set a 640x480 16bit mode.
 >
 > 3.1	Login to the system
 >
 > 3.2	Type 'ls -lR /'
 >
 > 	This will cause the screen pan/scrolling BIOS calls to be tested
 > 	After this has scrolled for a bit hit ^C
 >
 > 3.3	Remove the "vga=0x0311" option from /etc/lilo.conf
 > 	Rerun lilo
 >
 > 	This ensures the setup is correct for any future test run

That all appears fine.

 > 4. Additional Laptop Test

First, not all laptops have PCMCIA or CardBus, and second, not all
systems that have those are laptops. Can I suggest...

   4. Additional test for systems with PCMCIA.

...be used instead.

 > 4.1	Boot Linux on the system
 >
 > 4.2	Insert a PCMCIA card, ensure the kernel detects it
 >
 > 4.3	Remove the PCMCIA card, ensure the kernel detects the change
 >
 > 4.4	Insert a cardbus card, ensure the kernel detects it
 >
 > 4.5	Verify the cardbus device is usable
 >
 > 4.6	Remove the cardbus device, ensure the kernel detects it

My only query with that is whether PCMCIA implies CardBus, and what to
do with systems that accept one and not the other.

 > Compatibility With Older (2.2) Linux
 > ------------------------------------
 >
 > Linux 2.2 makes fairly similar BIOS calls to the 2.4 kernel. It
 > does not support PCI plug and play setup and should generally be
 > configured in the BIOS as a non plug and play operating system.

Split into two paragraphs here.

 > On machines with large amounts of memory the earlier 2.2 kernels
 > frequently do not see all of it as they lack the E820 memory
 > sizing code. 2.2 users should probably be advised to upgrade to
 > Linux 2.2.19 or higher on such machines.

Other than splitting where indicated, that's fine.

 > Future Paths
 > ------------
 >
 > Intel are currently working on ACPI support for Linux. While
 > much of this is functional it is not yet stable enough that
 > vendors enable it. Linux does not require APM services to do
 > minimal power management, nor does it require PnPBIOS services
 > to function happily. It does however need to know about
 > interrupt routing. For minimal Linux compatibility a 'legacy
 > free' BIOS should probably provide the $PIR table, even if it
 > does not provide non ACPI versions of other services.

That appears fine.

The only thing I would add to that is either a version number or a
"last changed" date.

Best wishes from Riley.

Re: For comment: draft BIOS use document for the kernel

[D. Stimits]

Alan Cox wrote:
> 
> Linux 2.4 BIOS usage reference
> 
> Boot Sequence
> -------------
> 
> Linux is normally loaded either directly as a bootable floppy image or from
> hard disk via a boot loader called lilo. The kernel image is transferred
> into low memory and a parameter block above it.
> 
> When booting from floppy disk the BIOS disk parameter tables are replaced
> by a new table set up to allow a maximum sector count of 36 (the track size
> for a 2.88Mb ED floppy)
> 
> int 0x13, AH=0x02 is issued to to probe and find the disk geometry.
> int 0x13, AH=0x00 is used to reset the floppy controller.
> int 0x13, AH=0x02 is then issued repeatedly to load tracks of data. The
>         boot loader ensures no issued requests cross the track boundaries
> 
> int 0x10 service 3 is used during the boot loading sequence to obtain the
> cursor position. int 0x10 service 13 is used to display loading messages
> as the loading procedure continues. int 0x10 AH=0xE is used to display a
> progress bar of '=' characters during the bootstrap
> 
> Control is then transferred to the loaded image whether by the floppy boot
> loader or other services
> 

If it is within the realm of the paper, I'd like to know the differences
when booting from an ATAPI cdrom (or the fact that there is no
difference). Or for SCSI cdrom if relevant or useful to the purposes of
the paper.

D. Stimits, stimits@idcomm.com

Re: For comment: draft BIOS use document for the kernel

[Timur Tabi]

** Reply to message from Eric W. Biederman <ebiederm@xmission.com> on 23 Jun
2001 14:26:32 -0600


> Pretty decent.  It misses a lot of hardware details that we still
> depend on the BIOS to reliably setup for us.

You're right, it does.  I think that information should be added.  It's a way
for BIOS programmers to know whether or not their BIOS is missing anything
obvious.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: For comment: draft BIOS use document for the kernel

[Pavel Machek]

Hi!

> > 1.3	Type 'apm -s'
> > 	The machine should standby
> >
> > 1.4	Wake it and type 'apm -S'
> > 	The machine should suspend
> 
> According to the man pages, "apm -s" does a suspend and "apm -S" does a 
> standby.

No, original seems good.

apm -s: suspend to ram
apm -S: suspend to disk

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: For comment: draft BIOS use document for the kernel

[Brad Pepers]

On Saturday 30 June 2001 08:47, Pavel Machek wrote:
> Hi!
>
> > > 1.3	Type 'apm -s'
> > > 	The machine should standby
> > >
> > > 1.4	Wake it and type 'apm -S'
> > > 	The machine should suspend
> >
> > According to the man pages, "apm -s" does a suspend and "apm -S" does a
> > standby.
>
> No, original seems good.
>
> apm -s: suspend to ram
> apm -S: suspend to disk

The apm man pages do not mention suspend to ram vrs suspend to disk but only 
suspend vrs standby as Alan did and they say its the other way around.  So 
are the man pages wrong then?

-- 
Brad Pepers
brad@linuxcanada.com

Re: For comment: draft BIOS use document for the kernel

[Pavel Machek]

Hi!

> > Then how does 1.44 megabytes of data from a floppy disk (that won't
> > fit below 1 megabyte), that is accessed in real-mode, ever get to
> > above 1 megabyte where it can be decompressed?
> 
> The limit is about 508K of compressed image with the floppy boot.

Wrong. 0xeffff is limit for floppy boot. Kernel errorneously thinks it
is 0xfffff, and loops if it is 0xf????. We use int15 to copy it. Take a
look, there are ugly hacks around that.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: For comment: draft BIOS use document for the kernel

[Alan Cox]

> lilo
> grub
> syslinux
> XFree86 (using virtual-8088 to run a video BIOS for a second card?)

Also for monitor identification

> dosemu?
> loadlin?

loadlin does. Dosemu can. It depends how it is configured

The Red Hat installer uses LRMI to do monitor identification by BIOS calls
too. I've not tried to document these users.

> the boot block that reads ext2 (in 1 kB -- damn what a hack)

The Linux8086 minixfs booter is an even better hack - its in C. 

Re: For comment: draft BIOS use document for the kernel

[Alan Cox]

> It's in arch/i386/boot/setup.S, after label bootsect_second.  It's only
> used with bzImage kernels and the floppy bootsector.

I stand corrected. I will add this to the documentation

Alan

Re: For comment: draft BIOS use document for the kernel

[Alan Cox]

> Then how does 1.44 megabytes of data from a floppy disk (that won't
> fit below 1 megabyte), that is accessed in real-mode, ever get to
> above 1 megabyte where it can be decompressed?

The limit is about 508K of compressed image with the floppy boot.

> I think LILO copies each buffer read from a below 1 Megabyte buffer
> (which is the only place the floppy can put its data via the BIOS),
> to above 1 megabyte using the BIOS block-move function.

I can't speak for LILO. I've not tried to document LILO, rather I've tried
to document the kernel. Possibly someone should add LILO documentation to
this.

Alan

Re: For comment: draft BIOS use document for the kernel

[Albert D. Cahalan]

Alan Cox writes:
> [somebody]

>> I could not find any reference to BIOS int 0x15, function 0x87,
>> block-move, used to copy the kernel to above the 1 megabyte
>> real-mode boundary. I think this is still used.
>
> I dont think the kernel has ever used it. The path has always been to
> enter 32bit mode then relocate/uncompress the kernel, then run it

There are several non-kernel BIOS users:

lilo
grub
syslinux
XFree86 (using virtual-8088 to run a video BIOS for a second card?)
dosemu?
loadlin?
the boot block that reads ext2 (in 1 kB -- damn what a hack)

Re: For comment: draft BIOS use document for the kernel

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.95.1010622135228.3929C-100000@chaos.analogic.com>
By author:    "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
>
> On Fri, 22 Jun 2001, Alan Cox wrote:
> 
> > > I could not find any reference to BIOS int 0x15, function 0x87, block-
> > > move, used to copy the kernel to above the 1 megabyte real-mode
> > > boundary. I think this is still used.
> > 
> > I dont think the kernel has ever used it. The path has always been to enter
> > 32bit mode then relocate/uncompress the kernel, then run it
> > 
> 
> Then how does 1.44 megabytes of data from a floppy disk (that won't
> fit below 1 megabyte), that is accessed in real-mode, ever get to
> above 1 megabyte where it can be decompressed?
> 
> I think LILO copies each buffer read from a below 1 Megabyte buffer
> (which is the only place the floppy can put its data via the BIOS),
> to above 1 megabyte using the BIOS block-move function.
> 

This is done by LILO, which isn't part of the kernel.  SYSLINUX, for
example, enters protected mode directly (like the kernel itself does).

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

RE: For comment: draft BIOS use document for the kernel

[Comfort, Dan W]

Typo?

> If the E820 call fails then the INT 15 AX=0xE801 service is called and the
> results are sanity checked. In particular the code zeroes the CX/DX return
> 
> values in order to detect BIOS implementations that do not set them 
> usable memory data. It also handles older BIOSes that return AX/BX but not
> AX/BX data.
> 
> 
	  /set them usable/set the usable/ 

Re: For comment: draft BIOS use document for the kernel

[Brian Gerst]

Alan Cox wrote:
> 
> > I could not find any reference to BIOS int 0x15, function 0x87, block-
> > move, used to copy the kernel to above the 1 megabyte real-mode
> > boundary. I think this is still used.
> 
> I dont think the kernel has ever used it. The path has always been to enter
> 32bit mode then relocate/uncompress the kernel, then run it

It's in arch/i386/boot/setup.S, after label bootsect_second.  It's only
used with bzImage kernels and the floppy bootsector.

--

				Brian Gerst

Re: For comment: draft BIOS use document for the kernel

[Richard B. Johnson]

On Fri, 22 Jun 2001, Alan Cox wrote:

> > I could not find any reference to BIOS int 0x15, function 0x87, block-
> > move, used to copy the kernel to above the 1 megabyte real-mode
> > boundary. I think this is still used.
> 
> I dont think the kernel has ever used it. The path has always been to enter
> 32bit mode then relocate/uncompress the kernel, then run it
> 

Then how does 1.44 megabytes of data from a floppy disk (that won't
fit below 1 megabyte), that is accessed in real-mode, ever get to
above 1 megabyte where it can be decompressed?

I think LILO copies each buffer read from a below 1 Megabyte buffer
(which is the only place the floppy can put its data via the BIOS),
to above 1 megabyte using the BIOS block-move function.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: For comment: draft BIOS use document for the kernel

[Alan Cox]

> Didn't you disable DMI scan recently, in favor of userspace
> DMI tools?

No. We still scan it but we dont print the stuff out

> > should probably provide the $PIR table, even if it does not 
> > provide non ACPI versions of other services.
> 
> Sorry, legacy-free => ACPI, certainly not a $PIR table IMO.

Umm maybe that needs rewording. The point is that if you are building an
ACPI only setup then it will generally run Linux providing you also add in
the $PIR table, even though the ACPI OS's certainly won't use it

> Personally I'd like to explore adding support to Linux for
> the Simple Boot Flag spec.
> (http://www.microsoft.com/HWDEV/desinit/simp_bios.htm

See ac17. Actually its a bit buggy in ac17 but Dave Jones has been fixing it.
Feel free to assist (arch/i386/kernel/bootflag.c)

Re: For comment: draft BIOS use document for the kernel

[Alan Cox]

> I could not find any reference to BIOS int 0x15, function 0x87, block-
> move, used to copy the kernel to above the 1 megabyte real-mode
> boundary. I think this is still used.

I dont think the kernel has ever used it. The path has always been to enter
32bit mode then relocate/uncompress the kernel, then run it

Re: For comment: draft BIOS use document for the kernel

[Alan Cox]

> You've described a relatively complicated procedure well in this document.
> My only suggestion would be to reference the applicable source code files
> throughout the text, so that it's easy to find the associated code.

Thats a good idea . I'll fix that one up

Thanks to all the folks who sent me bug fixes

RE: For comment: draft BIOS use document for the kernel

[Dunlap, Randy]

Looks somewhat familiar.  8;)
(compare http://rddunlap.home.att.net/linit/lin240_init_x86.html) (blatant
plug)

Some comments below.


> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]

> Linux 2.4 BIOS usage reference
> 
> 
> Boot Sequence
> -------------
> 
...
> 
> int 0x10 service 3 is used during the boot loading sequence 
> to obtain the
> cursor position. int 0x10 service 13 is used to display 
s/13/0x13/                         0x13

> loading messages
> as the loading procedure continues. int 0x10 AH=0xE is used 
> to display a
> progress bar of '=' characters during the bootstrap
s/=/./            '.'


> Memory Sizing
> -------------
> 
> Firstly a call is made to BIOS INT 15  AX=0xE820 in order to read the
s/15/0x15/

> E820 map. A maximum of 32 blocks are supported by current kernels. The
> 'SMAP' signature is required and tested. In addition the SMAP 
> signature
> is restored each call, although not required by the 
> specification in order to handle some know BIOS bugs.
> 
> If the E820 call fails then the INT 15 AX=0xE801 service is 
s/15/0x15/

> called and the
> results are sanity checked. In particular the code zeroes the 
> CX/DX return 
> values in order to detect BIOS implementations that do not set them 
> usable memory data. It also handles older BIOSes that return 
> AX/BX but not AX/BX data.
???             CX/DX instead?


> Peripherals
> -----------
> 
...
> 
> Having completed video set up the hard disk data for hda and 
> hdb is copied
> from the low memory BIOS area into the kernel tables. INT 
> 0x13 AH-0x15 is
s/-/=/


> 32bit Bootstrap
> ---------------
> 
...
> 
> In the majority of systems the kernel will directly invoke 
> type 1 or type 2
> configuration. In this situation the kernel will search for a $PIR PCI
> IRQ routing table in the BIOS area (0xF0000->0xFFFFF) with a 
> revision of 0x100 (1.0). 

However, the $PIR table is a Windows 98 requirement.  Hence it
is not required for newer versions of Windows and also does not
apply to MP systems (unless the MP BIOS table is not being used).
(http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm)

$PIR *is* still used in Windows 2000 if available:
http://www.microsoft.com/HWDEV/cardbus/Spir.htm


> Power Management and BIOS Bugs
> ------------------------------
> 
...

> Finally the battery status querying can be disabled to work 
> around a small
> number of BIOSes which crash when this function is used from 
> 32bit space.
> These options can be keyed from the DMI table scanner, so 
> that, if we are
> made aware of BIOSes requiring options set specific ways we can
> automatically set the options correctly for that BIOS without user
> intervention.

Didn't you disable DMI scan recently, in favor of userspace
DMI tools?


> Future Paths
> ------------
> 
> Intel are currently working on ACPI support for Linux. While 
> much of this is
> functional it is not yet stable enough that vendors enable 
> it. Linux does
> not require APM services to do minimal power management, nor 
> does it require
> PnPBIOS services to function happily. It does however need to 
> know about 
> interrupt routing. For minimal Linux compatibility a 'legacy 
> free' BIOS
> should probably provide the $PIR table, even if it does not 
> provide non ACPI versions of other services.

Sorry, legacy-free => ACPI, certainly not a $PIR table IMO.

Personally I'd like to explore adding support to Linux for
the Simple Boot Flag spec.
(http://www.microsoft.com/HWDEV/desinit/simp_bios.htm

~Randy
(not speaking for Intel)

RE: For comment: draft BIOS use document for the kernel

[Richard B. Johnson]

On Fri, 22 Jun 2001, Schilling, Richard wrote:

> 
> You've described a relatively complicated procedure well in this document.
> My only suggestion would be to reference the applicable source code files
> throughout the text, so that it's easy to find the associated code.
> 

I could not find any reference to BIOS int 0x15, function 0x87, block-
move, used to copy the kernel to above the 1 megabyte real-mode
boundary. I think this is still used.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

RE: For comment: draft BIOS use document for the kernel

[Schilling, Richard]

You've described a relatively complicated procedure well in this document.
My only suggestion would be to reference the applicable source code files
throughout the text, so that it's easy to find the associated code.

Richard Schilling
Webmaster / Web Integration Programmer
Affiliated Health Services
Mount Vernon, WA USA
http://www.affiliatedhealth.org
phone: 360.856.7129


> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Friday, June 22, 2001 9:21 AM
> To: linux-kernel@vger.kernel.org
> Subject: For comment: draft BIOS use document for the kernel
> 
> 
> 
> Linux 2.4 BIOS usage reference
> 
> 
> Boot Sequence
> -------------
> 
> Linux is normally loaded either directly as a bootable floppy 
> image or from
> hard disk via a boot loader called lilo. The kernel image is 
> transferred 
> into low memory and a parameter block above it. 
> 
> When booting from floppy disk the BIOS disk parameter tables 
> are replaced
> by a new table set up to allow a maximum sector count of 36 
> (the track size
> for a 2.88Mb ED floppy)
> 
> int 0x13, AH=0x02 is issued to to probe and find the disk geometry.
> int 0x13, AH=0x00 is used to reset the floppy controller.
> int 0x13, AH=0x02 is then issued repeatedly to load tracks of 
> data. The
> 	boot loader ensures no issued requests cross the track 
> boundaries
> 
> 
> int 0x10 service 3 is used during the boot loading sequence 
> to obtain the
> cursor position. int 0x10 service 13 is used to display 
> loading messages
> as the loading procedure continues. int 0x10 AH=0xE is used 
> to display a
> progress bar of '=' characters during the bootstrap
> 
> 
> Control is then transferred to the loaded image whether by 
> the floppy boot
> loader or other services
> 
> 
> Kernel Setup
> ------------
> 
> The initial kernel setup executes in 16bit mode. While in 
> 16bit mode the
> kernel calls and caches data from several 16bit calls whose 
> data is not
> available in 32bit mode
> 
> It then uses int 0x10 AH=0x0E in order to print initial 
> progress banners so
> that immediate feedback on the boot status is available. The 
> 0x07 character
> is issued as well as printable characters and is expected to 
> generate a
> bell.
> 
> Memory detection is done as follows, attempting to handle the various
> methods that have been available over time
> 
> Memory Sizing
> -------------
> 
> Firstly a call is made to BIOS INT 15  AX=0xE820 in order to read the
> E820 map. A maximum of 32 blocks are supported by current kernels. The
> 'SMAP' signature is required and tested. In addition the SMAP 
> signature
> is restored each call, although not required by the 
> specification in order
> to handle some know BIOS bugs.
> 
> If the E820 call fails then the INT 15 AX=0xE801 service is 
> called and the
> results are sanity checked. In particular the code zeroes the 
> CX/DX return 
> values in order to detect BIOS implementations that do not set them 
> usable memory data. It also handles older BIOSes that return 
> AX/BX but not
> AX/BX data.
> 
> When service E801 is used the kernel assumes that usable 
> memory extends from
> 4K to the bottom of the EBDA, and from 1Mbyte to the top of 
> the E801 area.
> 
> If neither service is available then INT 0x15 AH=0x88 is 
> invoked in order to
> get the memory size, up to 64Mb by the original IBM PC BIOS service.
> 
> Peripherals
> -----------
> 
> Having sized memory the kernel moves on to set up 
> peripherals. The BIOS
> INT 0x16, AH=0x03 service is invoked in order to set the 
> keyboard repeat
> rate and the video BIOS is the called to set up video modes.
> 
> The kernel tries to identify the video in terms of its 
> generic features.
> Initially it invokes INT 0x10 AH=0x12 to test for the 
> presence of EGA/VGA
> as oppose to CGA/MGA/HGA hardware. 
> 
> INT 0x10 AH=0x03 is used to obtain the cursor position, and INT 0x10,
> AH=0x0F is used to obtain the video page and the mode. If EGA or VGA
> are present the normal BIOS locations of 0x485 and 0x484 are 
> used to obtain
> the font size and the screen height.
> 
> VESA BIOS video services are used to obtain the amount of 
> video memory 
> (INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0 
> protected mode interface
> data if available (INT 0x10, AX=0x4F0A). Users are able to 
> select graphical
> video modes (INT 0x10 AX=0x4F02), or if not available the pre 
> VESA mode
> setup. The presence of the VESA BIOS is checked by the VESA get mode
> information call (INT 0x10 AX=0x4F01)
> 
> Special modes will also invoke INT 0x10 AH=0x1200 (Alternate 
> print screen),
> INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10 AH=0x1201 (to 
> turn off cursor
> emulation) and INT 0x10 AH=0x01 (to set up the cursor).
> 
> Having completed video set up the hard disk data for hda and 
> hdb is copied
> from the low memory BIOS area into the kernel tables. INT 
> 0x13 AH-0x15 is
> used to check if a second disk is present. 
> 
> INT 0x15, AH=0xC0 is invoked in order to check for MCA bus 
> machines. If an
> MCA systab is available the first block of the table is also 
> saved into
> the kernel's own data areas.
> 
> INT 0x11 is used to check for a PS/2 mouse. If this function 
> reports that
> a PS/2 pointing device is present the kernel will also verify 
> directly with
> the PS/2 controller itself that the mouse is attached.
> 
> 
> Power Management
> ----------------
> 
> Linux supports APM power management. It will issue APM BIOS 
> service calls in 
> order to set up power management, and if present will then 
> issue calls to
> the 32bit APM services after boot up.
> 
> During boot the kernel issues INT 0x15 AX=0x0530 in order to 
> do an APM BIOS
> installation check. It requires that a 32bit capable APM BIOS 
> is present.
> Assuming a valid 32bit capable APM BIOS is reported the 
> kernel will then
> issue an APM disconnect (INT 0x15 AX=0x5304) followed by a 
> 32bit connect
> (INT 0x15 AX=0x5303). 
> 
> The kernel then issues an APM installation check again (INT 
> 0x15 AH=0x5300) 
> in order to check if the BIOS feature flags have changed now 
> 32bit mode
> has been selected. Finally it checks the signature and saves 
> the parameters.
> 
> At this point use of 16bit BIOS services cease and the kernel 
> begins talking
> directly to the hardware. It enters 32bit mode and transfers 
> execution to
> the 32bit kernel proper.
> 
> 
> 32bit Bootstrap
> ---------------
> 
> The 32bit bootstrap runs mostly independently of BIOS 
> services. It does
> however scan for and use certain tables if they are present.
> 
> PCI BIOS is used if the user requests it or PCI configuration 
> type 1 and
> type 2 are not available on the system. At that point the 
> kernel searches
> for the BIOS32 signature and then for the PCI signatures "PCI 
> " and "$PCI"
> 
> The kernel invokes the PCI_BIOS_PRESENT function initially, 
> in order to
> test the availability of PCI services in the firmware. 
> Assuming this is
> found them PCIBIOS_FIND_PCI_DEVICE, PCIBIOS_FIND_PCI_CLASS_CODE, 
> PCIBIOS_GENERATE_SPECIAL_CYCLE, 
> PCIBIOS_READ/WRITE_CONFIG_BYTE/WORD/DWORD
> calls are issued as the PCI service are configured, along with
> PCIBIOS_GET_ROUTING_OPTIONS and PCIBIOS_SET_HW_INT to handle 
> plug and play
> devices.
> 
> In the majority of systems the kernel will directly invoke 
> type 1 or type 2
> configuration. In this situation the kernel will search for a $PIR PCI
> IRQ routing table in the BIOS area (0xF0000->0xFFFFF) with a 
> revision of 
> 0x100 (1.0). 
> 
> Multiprocessor Machines
> -----------------------
> 
> The kernel will also search for an Intel MP 1.1 or MP 1.4 
> table. If this is
> found it is used to obtain the multiprocessor data required 
> to boot the
> other processors as well as the APIC information, including 
> IRQ routing
> tables. Some older Linux boot loaders would overwrite the 
> EBDA if it was
> more than 4K, so the SMP tables are best placed elsewhere for Linux
> compatibility. One extension the Linux kernel makes to the 
> official rules
> for parsing this table, is that in the presence of PCI/ISA 
> machines it will
> probe for and use the EISA ELCR configuration register if it 
> appears to be
> present.
> 
> If multiprocessor capability is detected then APM BIOS 
> service usage is
> disabled except for poweroff. The APM specification and the 
> behaviour of
> existing APM BIOS implementations under SMP conditions are at 
> best described
> as 'variable'.
> 
> VESA BIOS
> ---------
> 
> If the user selects a VESA BIOS console the VESA 32bit BIOS calls for 
> screen panning are used in order to scroll the VESA linear 
> frame buffer and
> to do colour manipulation. 
> 
> Providing the 32 bit VESA BIOS calls are available the kernel calls
> function 0x4F07 (pan display) in order to implement 
> scrolling. When using an
> 8bit console depth the palette reload (0x4F09) function is 
> used to reload
> colour tables. In the absence of the 32bit interface the kernel does
> software scrolling and assumes the colour registers are VGA 
> compatible 
> hardware.
> 
> The memory region segment option is not supported. If this is 
> found then
> the kernel acts as if 32bit VESA extensions are not available.
> 
> PnPBIOS
> -------
> 
> BIOS plug and play 32bit services are used if present. The 
> functions used
> are 0x00 (GET_NUM_SYS_DEV_NODES) , 0x01 (GET_SYS_DEV_NODE), 0x02
> (SET_SYS_DEV_NODE). Docking station and ESCD services are not 
> currently
> utilised at all. Linux currently makes fairly minimal use of 
> the PnPBIOS
> services, simply using them to find certain motherboard device
> configurations.
> 
> 32bit Power Management
> ----------------------
> 
> When 32bit APM services are available the kernel will use APM 
> facilities to
> do power management, instead of issuing 'hlt' instructions when idle.
> 
> After the initial boot up the APM kernel thread issues APM function
> VERSION (0x530E) specifying a maximum version of 1.2. If this fails it
> assumes APM 1.0 services. ENGAGE_PM (0x530F) is then issued 
> if the power 
> management is currently disengaged. 
> 
> The APM task then loops handling pending APM requests once a second.
> GET_EVENT (0x530B) is invoked to process pending events. When 
> the kernel
> wishes to change power state it will issue SET_STATE (0x5307) 
> in order to
> transfer state. 
> 
> The idle transition loops will invoke IDLE (0x5305) and BUSY 
> (0x5306) as
> appropriate to allow the BIOS to execute its power management policy.
> 
> GET_STATUS(0x530A) is issued when user processes request 
> battery status in
> order to implement battery monitoring applications. 
> 
> SET_STATE is also issued when the display timer expires in 
> the OS. In this
> situation the kernel tries to blank the primary display 
> device (0x100) or if
> this fails to blank all video devices (0x1ff)
> 
> Power Management and BIOS Bugs
> ------------------------------
> 
> The APM BIOS is a complex subsystem and has historically had 
> many bugs, 
> particularly in older laptop systems. To handle this the APM 
> BIOS supports a
> variety of options to work around problems
> 
> Linux will ignore small segment limits provided by the BIOS and always
> set the segment limit to 64K. This is necessary as some BIOSes get the
> limit values wrong.
> 
> Linux will call BIOS functions with a selector of 0x40 
> pointing to the real
> mode address base of 0x40:0. Many BIOS functions rely on this 
> selector being
> present even though the specification does not permit the assumption.
> 
> Options control whether BIOS functions are invoked with 
> interrupts enabled
> or disabled. A correctly functioning APM BIOS should not care 
> but some do.
> 
> Options also control whether the power off is issued 32bit or 
> 16bit, with
> the kernel transitioning to 16bit before issuing the power 
> off request.
> 
> Finally the battery status querying can be disabled to work 
> around a small
> number of BIOSes which crash when this function is used from 
> 32bit space.
> These options can be keyed from the DMI table scanner, so 
> that, if we are
> made aware of BIOSes requiring options set specific ways we can
> automatically set the options correctly for that BIOS without user
> intervention.
> 
> Power Management Assumptions
> ----------------------------
> 
> The Linux 2,4 kernel power management code will restore 
> certain devices
> itself but it does rely on the BIOS to correctly save and restore the
> following
> 	o	MTRR registers
> 	o	AGP configuration
> 	o	Hard disk parameters - including waking the 
> drive properly
> 		on a resume
> 
> The SMM BIOS code needs to be aware that Linux is not 
> windows. In particular
> we have seen problems where the save/restore code for the 
> video BIOS is not
> capable of handling any mode not used by windows. 
> 
> The Linux kernel makes use of certain advanced features, and 
> while these
> should not intrude into the SMM mode some of them are worth 
> mentioning 
> 
> 	Processor State
> 		Linux makes use of machine check exceptions, 36bit 
> 		extensions, MTRR registers, and 4Mbyte pages
> 
> 	Interrupt Controllers
> 		Linux will use the APIC when available, 
> including on newer
> 		single processor machines. SMM code must be 
> aware that the
> 		IRQ routing may have been configured for this
> 
> 	PCI
> 		In some circumstances Linux will assign PCI bus 
> resources
> 		and potentially renumber and relocate devices. It tries
> 		where possible to keep the existing BIOS setup
> 
> 
> Testing Strategy
> ----------------
> 
> Because Linux makes little use of the BIOS services it is 
> relatively easy to
> run a test sequence to get basic validation of APM functionality under
> Linux.
> 
> The recommended procedure is as follows
> 
> 1.	Boot Linux on the system
> 	Verify the system boots
> 	[Does basic verification of PCI services, boot up 16bit calls]
> 
> 	Login to the system
> 
> 1.1	Type 'free'
> 	Verify the amount of free memory appears correct
> 	[Verifies memory reporting is working correctly]
> 
> 1.2	Type 'cat /proc/apm'
> 	Verify that the machine does not crash
> 	[Verifies GET_STATUS 32bit call]
> 
> 1.3	Type 'apm -s'
> 	The machine should standby
> 
> 1.4	Wake it and type 'apm -S'
> 	The machine should suspend
> 
> 1.5	Verify the BIOS hot-keys for suspend etc work
> 
> 1.6	Verify the BIOS suspend to disk works if applicable
> 
> 1.7	Resume the machine and type 'poweroff'
> 
> The system should now shutdown
> 
> 2.	Boot Linux on the system
> 	Start the graphical user interface
> 
> 	Repeat steps 1.3 to 1.6 from a terminal window in the GUI
> 
> 	This verifies that the APM suspend/restore correctly handles 
> 	the GUI save/restore
> 
> 	Add the line "vga=0x0311" to the /etc/lilo.conf 
> 	Rerun lilo
> 
> 	Repeat step 1.7
> 
> 3.	Boot the system
> 	This time the VGA option will try to use VESA BIOS services
> 	to set a 640x480 16bit mode. 
> 
> 3.1	Login to the system
> 
> 3.2	Type 'ls -lR /'
> 
> 	This will cause the screen pan/scrolling BIOS calls to be tested
> 	After this has scrolled for a bit hit ^C
> 
> 3.3	Remove the "vga=0x0311" option from /etc/lilo.conf
> 	Rerun lilo
> 
> 	This ensures the setup is correct for any future test run
> 
> 
> 4. Additional Laptop Test
> 
> 4.1	Boot Linux on the system
> 
> 4.2	Insert a PCMCIA card, ensure the kernel detects it
> 
> 4.3	Remove the PCMCIA card, ensure the kernel detects the change
> 
> 4.4	Insert a cardbus card, ensure the kernel detects it
> 
> 4.5	Verify the cardbus device is usable
> 
> 4.6	Remove the cardbus device, ensure the kernel detects it
> 
> 
> 
> Compatibility With Older (2.2) Linux
> ------------------------------------
> 
> Linux 2.2 makes fairly similar BIOS calls to the 2.4 kernel. 
> It does not
> support PCI plug and play setup and should generally be 
> configured in the
> BIOS as a non plug and play operating system. On machines 
> with large amounts
> of memory the earlier 2.2 kernels frequently do not see all 
> of it as they
> lack the E820 memory sizing code. 2.2 users should probably 
> be advised to
> upgrade to Linux 2.2.19 or higher on such machines.
> 
> 
> Future Paths
> ------------
> 
> Intel are currently working on ACPI support for Linux. While 
> much of this is
> functional it is not yet stable enough that vendors enable 
> it. Linux does
> not require APM services to do minimal power management, nor 
> does it require
> PnPBIOS services to function happily. It does however need to 
> know about 
> interrupt routing. For minimal Linux compatibility a 'legacy 
> free' BIOS
> should probably provide the $PIR table, even if it does not 
> provide non ACPI
> versions of other services.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>