I entered bios and disabled FDC and expected to linux
work still well with floppy, that is fd0.
I thought that linux is not dependent on bios for using
fdc, hdc, and other things. I want to know how linux uses bios.
does linux still depends on bios thing?
Hi Halil,
On Tue, 6 May 2003, Halil Demirezen wrote:
> I entered bios and disabled FDC and expected to linux
> work still well with floppy, that is fd0.
>
> I thought that linux is not dependent on bios for using
> fdc, hdc, and other things. I want to know how linux uses bios.
>
> does linux still depends on bios thing?
No, it does not, but the floppy driver (drivers/block/floppy.c) looks at
certain hardcoded IO addresses to see if there is a floppy controller or
not.
What you do in the BIOS does not only disable the BIOS calls for the
floppy controller, it turns it completely off in the chipset (software
disconnect) so it is never accessed with the IO access, and therefore is
not detected.
It would probably be possible to turn it on again in floppy.c, but it
would be chipset dependent how to do it.
Cheers,
Thomas
>
> What you do in the BIOS does not only disable the BIOS calls for the
> floppy controller, it turns it completely off in the chipset (software
> disconnect) so it is never accessed with the IO access, and therefore is
> not detected.
>
> It would probably be possible to turn it on again in floppy.c, but it
> would be chipset dependent how to do it.
>
> Cheers,
> Thomas
>
So can we say that, during initialization, setup.s pushes some bios info
to the memory, and then after entering protected mode in i386, it pops
these information and sets kernel depending on it. Because of absence of
FDC controller info at this data area linux does not recognize FDC. However,
I can turn it on still usin IO ports and using in, out assembly instructions.
what i mention above for sure is not correct, however, is the procedure something like that?
thank you..
On Tue, 6 May 2003, Halil Demirezen wrote:
> So can we say that, during initialization, setup.s pushes some bios info
> to the memory, and then after entering protected mode in i386, it pops
> these information and sets kernel depending on it. Because of absence of
> FDC controller info at this data area linux does not recognize FDC. However,
No it doesn't push or pop any info from the BIOS. The FDC is simply turned
off in the chipset initialisation code (in BIOS), in a proprietary way
that Linux doesn't know about.
> I can turn it on still usin IO ports and using in, out assembly
> instructions.
No. You need to change a chipset register to power it back on. And how to
do this depends on the chipset. On an old ISA floppy controller, this
would not be possible in software but would have to be done by a jumper,
but modern chipsets are configurable through registers. Unfortunately all
the different chipsets have different initialisation code for this, and
some are even not documented at all.
This is why, even though Linux does not use the BIOS at any point after
booting, some chipset setup code is still required and therefore you can't
just burn a Linux kernel into flash and start it directly (there is a
project called LinuxBIOS that was working on a replacement BIOS for some
common chipsets, intended for embedded systems).
Regards,
Thomas
> This is why, even though Linux does not use the BIOS at any point after
> booting, some chipset setup code is still required and therefore you
> can't just burn a Linux kernel into flash and start it directly (there
> is a project called LinuxBIOS that was working on a replacement BIOS for
> some common chipsets, intended for embedded systems).
'was working'? The project is alive and well.
It is much more than just embedded systems. In fact with recent addition
of legacy bios support we are able to boot other operating systems (BSD,
Win, etc). Being able to boot Windows provides easy migration patch to
Linux :-)
By the way. Yes you can burn the linux kernel into flash (together with
linuxBIOS) and boot it this way. But given that many motherboards limit
your flash size to 256KiB you probably want to put the kernel on the
CompactFlash over ide nevertheless. Interestingly enough if not this size
limit we might have ended up using Linux Kernel as hardware initalizator
to some degree.
<shameless plug>
In fact we are presenting a paper on LinuxBIOS booting other operating
systems this summer during Usenix 03.
</shameless plug>
Adam
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Mon, 5 May 2003, Adam Sulmicki wrote:
> 'was working'? The project is alive and well.
Sorry, didn't mean it as "the project is now dead", just "been a while
since I checked its status" :-)
>[..]
> By the way. Yes you can burn the linux kernel into flash (together with
> linuxBIOS) and boot it this way. But given that many motherboards limit
> your flash size to 256KiB you probably want to put the kernel on the
> CompactFlash over ide nevertheless. Interestingly enough if not this size
> limit we might have ended up using Linux Kernel as hardware initalizator
> to some degree.
A couple of years ago I was doing a Linux port to a MIPS based embedded
system, and while we did set up the SDRAM controller, chip select timings
etc. in the flash bootloader, most of these were settings overwritten
again by the kernel (that way, a kernel would work with any version of the
bootloader, and the bootloader would not have to be updated if something
had to be changed or a timing improved for performance).
This approach seems to me to make sense, and it would be interesting if
the kernel would include direct support for various chipsets and
(optional?) code to set them up from scratch (or almost, e.g. SDRAM
working but not much else), that way a truly minimal BIOS stub could be
used and the kernel could provide interfaces to tune the chipsets in
various ways.
That would probably mean the limit on kernel command line length would
have to be dropped (if it hasn't already) to allow for things like
"sis_enable_fdc=1" (to get back to the original question), but it would
certainly be flexible on the chipsets that were supported.
// Thomas
Thomas Horsten <[email protected]> writes:
> On Mon, 5 May 2003, Adam Sulmicki wrote:
>
> > 'was working'? The project is alive and well.
>
> Sorry, didn't mean it as "the project is now dead", just "been a while
> since I checked its status" :-)
>
> >[..]
> > By the way. Yes you can burn the linux kernel into flash (together with
> > linuxBIOS) and boot it this way. But given that many motherboards limit
> > your flash size to 256KiB you probably want to put the kernel on the
> > CompactFlash over ide nevertheless. Interestingly enough if not this size
> > limit we might have ended up using Linux Kernel as hardware initalizator
> > to some degree.
>
> A couple of years ago I was doing a Linux port to a MIPS based embedded
> system, and while we did set up the SDRAM controller, chip select timings
> etc. in the flash bootloader, most of these were settings overwritten
> again by the kernel (that way, a kernel would work with any version of the
> bootloader, and the bootloader would not have to be updated if something
> had to be changed or a timing improved for performance).
In LinuxBIOS this is true for things like IDE timings. We just allocate
the resources and enable the IDE device. Our bootloader uses pio mode
and the kernel can setup what is reasonable for an optimized IDE timing.
3MB/s is generally fast enough to load a kernel without a noticeable delay.
> This approach seems to me to make sense, and it would be interesting if
> the kernel would include direct support for various chipsets and
> (optional?) code to set them up from scratch (or almost, e.g. SDRAM
> working but not much else), that way a truly minimal BIOS stub could be
> used and the kernel could provide interfaces to tune the chipsets in
> various ways.
In essence that is what LinuxBIOS is. Though we are slowly developing
several interesting bootloaders that can do interesting things. ADLO
uses a derivative of the bochs BIOS to look like a normal BIOS. etherboot
provides super small drivers for lots of hardware.
In addition things like DRAM timing cannot be changed as that is generally
an operation you can only perform once after reset on most chipsets.
> That would probably mean the limit on kernel command line length would
> have to be dropped (if it hasn't already) to allow for things like
> "sis_enable_fdc=1" (to get back to the original question), but it would
> certainly be flexible on the chipsets that were supported.
There is a major difference between Linux on embedded systems and linux
on general purpose commodity hardware.
On general purpose commodity hardware the kernel makes the assumption
that if it does not know what is going the BIOS set things up properly. So
for handling resource conflicts and such the pci bridges the assumptions
are dramatically different.
But beyond that the big service LinuxBIOS provides is that it has hard coded
information on what all of the non enumerable devices on the motherboard are.
Things like a winbond superio chips, and i2c clock controllers.
I am in the middle of a major revision and I hope to yield a code base that
is clean enough that I can reliably generate a table of the onboard devices.
Until that or something equivalent is done the kernel simply does not have
enough information to work with. Probing devices that don't have
a standardized enumeration method is simply too unreliable.
Eric
Hello Adam ,
On Mon, 5 May 2003, Adam Sulmicki wrote:
> 'was working'? The project is alive and well.
> It is much more than just embedded systems. In fact with recent addition
> of legacy bios support we are able to boot other operating systems (BSD,
> Win, etc). Being able to boot Windows provides easy migration patch to
> Linux :-)
> By the way. Yes you can burn the linux kernel into flash (together with
> linuxBIOS) and boot it this way. But given that many motherboards limit
> your flash size to 256KiB you probably want to put the kernel on the
> CompactFlash over ide nevertheless. Interestingly enough if not this size
> limit we might have ended up using Linux Kernel as hardware initalizator
> to some degree.
Thank you for the update . I had been to the site every so often
looking for updates to the chipsets known to be usable . Just do
not have a system I can spare if I foobar the flash .
> <shameless plug>
> In fact we are presenting a paper on LinuxBIOS booting other operating
> systems this summer during Usenix 03.
> </shameless plug>
I am hoping that after the usenix conferences there will be
a URL for the rest of us to view this paper ? Tnx , JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
On Tue, 6 May 2003, Mr. James W. Laferriere wrote:
> > <shameless plug>
> > In fact we are presenting a paper on LinuxBIOS booting other operating
> > systems this summer during Usenix 03.
> > </shameless plug>
> I am hoping that after the usenix conferences there will be
> a URL for the rest of us to view this paper ? Tnx , JimL
Indeed it is. You can get it at http://www.eax.com/ Enjoy.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
Hello Adam , Thank you ! Also Congradulations to the team for
the honours presented . Twyl , JimL
On Wed, 18 Jun 2003, Adam Sulmicki wrote:
> On Tue, 6 May 2003, Mr. James W. Laferriere wrote:
> > > <shameless plug>
> > > In fact we are presenting a paper on LinuxBIOS booting other operating
> > > systems this summer during Usenix 03.
> > > </shameless plug>
> > I am hoping that after the usenix conferences there will be
> > a URL for the rest of us to view this paper ? Tnx , JimL
> Indeed it is. You can get it at http://www.eax.com/ Enjoy.
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+