From: Thomas Horsten <thomas@horsten.com>
To: Adam Sulmicki <adam@cfar.umd.edu>
Cc: Halil Demirezen <nitrium@bilmuh.ege.edu.tr>,
<linux-kernel@vger.kernel.org>
Subject: Re: about bios
Date: Tue, 6 May 2003 10:03:37 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.40.0305060946450.8287-100000@jehova.dsm.dk> (raw)
In-Reply-To: <20030505193733.T76699-100000@www.missl.cs.umd.edu>
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
next prev parent reply other threads:[~2003-05-06 7:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-05 22:50 about bios Halil Demirezen
2003-05-05 22:45 ` Thomas Horsten
2003-05-05 23:04 ` Halil Demirezen
2003-05-05 23:08 ` Thomas Horsten
2003-05-05 23:52 ` Adam Sulmicki
2003-05-06 8:03 ` Thomas Horsten [this message]
2003-05-06 10:06 ` Eric W. Biederman
2003-05-06 12:28 ` Mr. James W. Laferriere
2003-06-18 14:43 ` Adam Sulmicki
2003-06-18 15:18 ` Mr. James W. Laferriere
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.40.0305060946450.8287-100000@jehova.dsm.dk \
--to=thomas@horsten.com \
--cc=adam@cfar.umd.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=nitrium@bilmuh.ege.edu.tr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).