EBDA - Extended Bios Data Area
Does Linux and various boot loaders(lilo/grub/etc)
having any restrictions on where and how big
memory allocated in EBDA is? Is this
handled for 2.4/2.6 Kernels?
Reason I ask is we are considering having
BIOS(for a SCSI HBA Controller) allocating
memory in EBDA for Firmware use.
We are concerned whether Linux would be writing
over this region of memory during the handoff
of BIOS to scsi lower layer driver loading.
Eric Moore
LSI Logic
EBDA is safe to use during lilo and grub as part of a BIOS. As long as
the EBDA is properly formed.
However, it is considered 'bad behavior' to allocate much more than 4k
of EBDA as we find others (not Linux) that depend on the 640K region of
memory run out of this precious resource. Beware of several add-in
BIOSii that each allocate EBDA; nest/size/relocate/offset properly.
Sincerely -- Mark Salyzyn
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Moore, Eric Dean
Sent: Monday, February 07, 2005 2:45 PM
To: [email protected]; [email protected]
Subject: EBDA Question
EBDA - Extended Bios Data Area
Does Linux and various boot loaders(lilo/grub/etc)
having any restrictions on where and how big
memory allocated in EBDA is? Is this
handled for 2.4/2.6 Kernels?
Reason I ask is we are considering having
BIOS(for a SCSI HBA Controller) allocating
memory in EBDA for Firmware use.
We are concerned whether Linux would be writing
over this region of memory during the handoff
of BIOS to scsi lower layer driver loading.
Eric Moore
LSI Logic
Followup to: <[email protected]>
By author: "Moore, Eric Dean" <[email protected]>
In newsgroup: linux.dev.kernel
>
> EBDA - Extended Bios Data Area
>
> Does Linux and various boot loaders(lilo/grub/etc)
> having any restrictions on where and how big
> memory allocated in EBDA is? Is this
> handled for 2.4/2.6 Kernels?
>
> Reason I ask is we are considering having
> BIOS(for a SCSI HBA Controller) allocating
> memory in EBDA for Firmware use.
> We are concerned whether Linux would be writing
> over this region of memory during the handoff
> of BIOS to scsi lower layer driver loading.
>
In general, dropping the EBDA below 0x9a000 is probably a
bad idea. Recent Linux kernels and boot loaders should handle it,
though. Keep in mind that you might find yourself in serious trouble
if you then have, for example, a PXE stack layered on top of your SCSI
BIOS.
-hpa
"H. Peter Anvin" wrote:
> Followup to: <[email protected]>
> By author: "Moore, Eric Dean" <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > EBDA - Extended Bios Data Area
> >
> > Does Linux and various boot loaders(lilo/grub/etc)
> > having any restrictions on where and how big
> > memory allocated in EBDA is? Is this
> > handled for 2.4/2.6 Kernels?
> >
> > Reason I ask is we are considering having
> > BIOS(for a SCSI HBA Controller) allocating
> > memory in EBDA for Firmware use.
> > We are concerned whether Linux would be writing
> > over this region of memory during the handoff
> > of BIOS to scsi lower layer driver loading.
> >
>
> In general, dropping the EBDA below 0x9a000 is probably a
> bad idea. Recent Linux kernels and boot loaders should handle it,
> though. Keep in mind that you might find yourself in serious trouble
> if you then have, for example, a PXE stack layered on top of your SCSI
> BIOS.
There are test software used in manufacturing line that needs this DOS memory.
>
>
> -hpa
>
> -
> 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/
Bukie Mabayoje wrote:
>>
>>In general, dropping the EBDA below 0x9a000 is probably a
>>bad idea. Recent Linux kernels and boot loaders should handle it,
>>though. Keep in mind that you might find yourself in serious trouble
>>if you then have, for example, a PXE stack layered on top of your SCSI
>>BIOS.
>
> There are test software used in manufacturing line that needs this DOS memory.
>
For that purpose, you can probably get away with a lot more than that.
-hpa