5MP3ugmvtzvndr3Q";   
   r.org";	posting-account="U2FsdGVkX1/HMPwQS+g/BtL6gp6V4Vbj"   
   Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7   
   .os2.ecomstation:872 comp.os.os2.beta:28   
   From: Marty    
      
   On 03/03/2011 08:04 PM, Jonathan de Boyne Pollard wrote:   
   >>>> Might be able to leverage this for eCS boot code (or future   
   >>>> OS/2-based projects)?   
   >>>>   
   >>> No you wouldn't. It's replacement firmware, not operating system   
   >>> software.   
   >>>   
   >> Can't we learn something from it though? There will be examples of   
   >> tapping into interfaces that our loader currently has no clue about.   
   >   
   > Once again: It's not an operating system or an operating system loader.   
   > It's replacement firmware. There won't be any "tapping into interfaces"   
   > because it isn't a loader. It's what loaders (the so-called "payload")   
   > run on top of and use.   
      
   http://www.coreboot.org/Developer_Manual   
      
   "The final mainboardinit fragment is mainboard-specific, in C, called    
   romstage.c. For non-cache-as-RAM targets, it is compiled with romcc. It    
   includes and uses other C-code fragments for:   
      
       1. Initializing MSRs, MTTRs, APIC.   
       2. Setting up the southbridge minimally ("early setup").   
       3. Setting up Super I/O serial.   
       4. Initializing the console.   
       5. Initializing RAM controller and RAM itself.   
      
   ..."   
      
   Really?  None of that is useful?  Clearly we don't need to initialize    
   the RAM controller and things like that, but what about APIC support?    
   MTRR init examples could have been useful some years back for video    
   drivers.  I'm sure there's some other useful tidbits in there.  High IRQ    
   handling, special memory ranges and meanings, enabling SSE, ...   
      
   Just because this stuff is designed to execute from ROM doesn't mean we    
   can't make use of it.   
      
   > And what's this "our loader" business? I for one don't have any stake in   
   > the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I looked.   
      
   The loader that we, who use OS/2, use.  If you prefer not to be included    
   in that group, then I won't complain if you don't read yourself into my    
   statement.   
      
   > I know of only three groups outwith IBM that have stakes in OS/2-clone   
   > kernel loaders. The OSFree people have their own loader, which is (we're   
   > told) based upon the old FreeLDR loader from David C. Zimmerli (not to   
   > be confused with the ReactOS FreeLDR). They're the only people with an   
   > interest in "our loader", and they'll tell you as I do that firmware   
   > source code doesn't show how to *use* firmware APIs.   
      
   I'd be mining for data from under every rock if I were them, and    
   hopefully they are not as close-minded as you seem to assume.   
      
   --    
   Reverse the parts of the e-mail address to reply by mail.   
      
   --- Internet Rex 2.31   
    * Origin: A noiseless patient Spider (1:261/20.999)