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

2001-07-08 Thread 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. 0xe is limit for floppy boot. Kernel errorneously thinks it
is 0xf, 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-07-08 Thread 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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-07-08 Thread 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-07-08 Thread 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: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-07-08 Thread 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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-07-08 Thread 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. 0xe is limit for floppy boot. Kernel errorneously thinks it
is 0xf, and loops if it is 0xf. We use int15 to copy it. Take a
look, there are ugly hacks around that.

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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-25 Thread Timur Tabi

** Reply to message from Eric W. Biederman <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-25 Thread Timur Tabi

** Reply to message from Eric W. Biederman [EMAIL PROTECTED] 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 - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-23 Thread 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, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-23 Thread 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 

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

2001-06-23 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-23 Thread Eric W. Biederman

Alan Cox <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-23 Thread 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, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-23 Thread Eric W. Biederman

Alan Cox [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-23 Thread 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
  

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

2001-06-23 Thread 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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. 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread H. Peter Anvin

Followup to:  <[EMAIL PROTECTED]>
By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
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
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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/ 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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:[EMAIL PROTECTED]]

> 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 (0xF->0xF) 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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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:[EMAIL PROTECTED]]
> Sent: Friday, June 22, 2001 9:21 AM
> To: [EMAIL PROTECTED]
> 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 

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

2001-06-22 Thread 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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread Timur Tabi

** Reply to message from Alan Cox <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread Timur Tabi

** Reply to message from Alan Cox [EMAIL PROTECTED] 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 - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread H. Peter Anvin

Followup to:  [EMAIL PROTECTED]
By author:Richard B. Johnson [EMAIL PROTECTED]
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
-- 
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
Unix gives you enough rope to shoot yourself in the foot.
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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:[EMAIL PROTECTED]]

 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 (0xF-0xF) 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)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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:[EMAIL PROTECTED]]
 Sent: Friday, June 22, 2001 9:21 AM
 To: [EMAIL PROTECTED]
 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 

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

2001-06-22 Thread 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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/ 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

2001-06-22 Thread 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. 



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/