lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OpenBIOS (was Re: UDI and Politics (was Re: Linux, UDI and SCO.) )

-----BEGIN PGP SIGNED MESSAGE-----


On Sun, Sep 20, 1998 at 11:02:09AM -0300, Brandon S. Allbery KF8NH wrote:
> In message <19980920140224.A329@hal.rnl.ist.utl.pt>, Carlos Morgado writes:
> +-----
> | > What is boils down to, is that I would like to see bios concentrate on
> | > the thing which it is desinted to: a) init device from which it is
> | > to load kernel b) load kernel c) _optionally_ provide some basic Input
> | > output.
> |
> | Unfortunatly BIOS stand very close to the hardware. PeCes are not the case
> | of Alphas were you have 1 architecture. BIOSs are made in some degree to fit
> | the hardware they are running on.
> +--->8
>
> True, but possibly not relevant: since Linux doesn't use the BIOS, it

nod :)

> already knows how to "fit the hardware" itself. That knowledge could e.g.

it knows better after you tell him :)

> be transported into an x86-pc Open Firmware implementation. (And OS
> writers, except possibly Microsoft, would thank you. Intel would hate your
> guts, though :-)
>

humm ... this brings to mind the distribution kernels with everything and
the kitchen sink. now ... having a firmware which i could compile on my pc
to fit my pc would be fun. this is not all too dificult i think, just "port"
the linux drivers to a more barebones architecture and write a little
bootstrap. the eth drivers would be a bit more hard cause the whole memory
allocation stuff.

[nod]
>
> | This would be fun except for the pain it would to be to make firmware for
> | all the motherboards out there. (or wouldn't this be needed ?)
> +--->8
>
> It probably would. But it would be nice if the x86-pc world started moving
> toward Open Firmware or eqyuivalent. We could support it the way 2.1
> supports fbcon (i.e. as an option on x86) with implementations on common
> motherboards, etc. to start the ball rolling.
>

Leave out the "old" mboards ? or write stuff for the good ones ? :)

> It also needs firmware on the devices, though; the "support for netbooting
> so I don't have to burn a PROM" comment missed the point there. You still
> need a PROM specific to each card, it just exports a standard interface.
>
You propose puting a BIOS prom on the eth card ? ehehhe :)

that could be done with the compile your own firmware scheme ... just throw
in suport for you card(s)

> A boot monitor which understood how to operate all possible boot devices
> itself would be equivalent to the Linux kernel itself, at least from the
> standpoint of device support. Somehow, I don't think booting a mini-Linux
> (where "mini" doesn't include removal of drivers) in order to boot Linux
> solves any problems --- you still need to boot that "mini"-Linux, and it's
> not clear that it would be "mini" enough to fit into a flash-ROM.
>

And average kernel is about 300k-400k (compressed). That could be romable
(plus a bootstrap).

I am using such a technique on an isa card i'm designing. An EPROM holds a
bootstrap and the program compressed. The bootstrap decompresses the program
into the board RAM and jumps there. A similar method could be used here .
flashRAM the whole kernel with a small alteration to the bootstrap
procedure.

Yes. I'm proposing not putting a mini-kernel in the flashRAM but the whole
kernel :)
The kernel already includes the booting-over-network thing.

yes. i am crazy :))


> --
> brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
> system administrator [WAY too many hats] allbery@ece.cmu.edu
> electrical and computer engineering KF8NH
> carnegie mellon university
>

- --

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNgWAjoewijNBLgpJAQF4lwQA0L87z8My4e9mSQdtlbizegcXjcHrLvjP
oPQV7ZkvPej7i9PJTOdq7Zexi+b8lQ9zmrrWkFS34tYHhZ+iLNf7L8d0E+9i9eaj
F+M65sCbi/Gfl5mSgaG5iS8AEZ0HbHCvfE21LK+/An+IvxhwslBeR6FS/GrN8el6
SsFCHzg756Y=
=ItEQ
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.070 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site