Messages in this thread | | | Date | Sun, 20 Sep 1998 23:02:17 +0100 | From | Carlos Morgado <> | Subject | Re: 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/
| |