[LinuxBIOS] A very good idea

MARTIN WOODHOUSE hokusai at btinternet.com
Fri May 4 11:01:49 CEST 2007


Yestereday Jordan wrotee
   
  > On Thu, May 03, 2007 at 05:55:39PM -0400, Jim Gettys wrote:
> > Mitch wrote a fast path resume from RAM for the OLPC Geode
> > hardware.
> 
> The fastest path is obviously attractive also in LinuxBIOS.
> 
> 
> > Once you've done that, you find that you've done just about
> > everything to initialize the hardware in the first place; so that
> > code is now used both at boot time and at suspend from RAM time.
> 
> This is an interesting observation.
> 
> 
> Perhaps all chip init would best be written in some macro language?
> (one specific for the task?)

> How much intelligence is actually needed to abstract the hardware
> enough for any system to be initialized? C is obviously not useful
> for an embedded system that could just write a table of registers
> into hardware.
> 
> I guess it's the old code reuse idea.
> 
> Perhaps I just reinvented OpenFirmware? And the v3 dts.
   
  ------------------
   
  From Martin
   
  Too right.  This is one of those ideas which is thrown off kind of light-heartedly but is actually crucual.
   
  (a)  Of all the posts here, I'd guess that more than half (to my inexpert and untutored eye) are about initiialising this processor/RAM chunk/other piece of hardware or that one.
   
  (b) My young (12-year-old) friend is leaning to program in that variety of C that's around now, what's its name can't remember? but anyway, he's written < Hello Word > of course, and it starts with more than a page of <inits> before we get down to the couple of lines of code which actually put "Hello World" in a nice little box on the screen :
   
  (c) Even when I was writing in Borland C all those years ago, the same was true (only not quite as badly as it is now, since we didn't have a huge variety of components to deal with.).
   
  ------
   
  So, yes, of course we should have a separate, small macro langage for initialising chunks of hardware, it would only take half an hour to learn it; and yes, every component manufacturer should agree on this same maro language and simply make available the necessary sequence of macros for every piece of hardware they make, so the prgram writers can just slam it into the front of any chunk of software they're constructing.
   
  I know that to somo extent this happens already, but I don't think it goes nearly far enough, to judge by the sequences of posts I see here discussing how to use one peice of hardware or another?
   
  ---- What should happen ---- it seems to my ancient mind --- is that the programmer should merely write a series of in a form such as :
   
  processor=xxxxx
  primaryRAM= yyyyy
  videochip=zzzzz
  etc
  etc
   
  --- and so forth, for whatever components are known to have the need to be handled,
   
  -- and the COMPILER then automatically inserts the necessary sequence(s) of macros known to be needed to "initialise"  xxxxx, yyyyy and zzzzz, whatever they are?
   
  Could this not work?   What are the possible snags?
   
  Of course everybody would have to agree upon, and learn, and then use, the same macro language, but I don't see that as insuperable? OK, it's another piece of stuff to learn, but we have to do that all the time, and this particular piece would save a whole lot of other learning.
   
  Maybe we should ask old Linus to put it together?
   
  Cheers,  Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070504/63f8593c/attachment.html>


More information about the coreboot mailing list