GRUB on OLPC / XO

[Mitch Bradley]

Robert Millan wrote:
>    
>   
>>> We used to run "trap" insttruction on powerpc.  I assume for exitting via 
>>> trap
>>> on i386 we need to generate an interrupt;  I'm just not sure which is the 
>>> right
>>> number for it.
>>>  
>>>       
>> To exit to OFW, call the "exit()" client service.
>>     
>
> I see.  Is this one expected to work everywhere including Apple etc?  We'd
> probably be better off ditching the __asm__("trap") altogether.
>   

In principle, that should work on Apple, but that would only be true if 
the client program has left the world set up so that OFW can still 
work.  I no longer keep up with what is happening in the PowerPC world.

x86 has no "trap" instruction.  The closest equivalent is "int N", but 
that isn't close enough to be useful, because there is no guarantee that 
any specific INT handlers are available.  I'm not even sure why an 
unspecific "trap" works on PowerPC.

>   
>> To reboot, call "boot()" with an empty string as the single IN argument.
>>     
>
> For this we used "reset-all".  The standard seems to indicate both are
> equally fine;  is that it?
>   

reset-all is probably better.  "boot()" calls reset-all after setting 
things up to force a re-execution of "boot" after OFW comes back up, 
whereas "reset-all" just makes the firmware restart with whatever 
default startup action has been configured.  (XO has virtually no 
firmware configurability - it is intended to "just work", nothing to 
screw up - so the distinction is moot for XO).

>   
>> To power off, call "interpret()" with a cmd string of "power-off".
>>     
>
> We used "shut-down" for this one.  Unfortunately not mentioned in the
> standard (not sure where it came from).  Is there a portable way to do this?
>   

I think shut-down is something that the PowerPC OFW community (or 
perhaps an individual vendor) came up with after the committee went 
dormant.  The XO OFW has "power-off" but not "shut-down".  I don't know 
of a portable way, other than to try both.

>   
>>>>   /* Load pre-loaded modules and free the space.  */
>>>>   grub_register_exported_symbols ();
>>>> -  grub_load_modules ();
>>>> +//  grub_load_modules ();
>>>>    
>>>>         
>>> This generates an out of bounds exception.  GRUB puts modules above _end
>>> (0x1000-aligned).  Is access to that address allowed by OFW ?
>>>  
>>>       
>> The ELF loader will map in anything listed in a program header of type 
>> PT_LOAD , according to the vaddr, memsize, and filesize fields.  If the 
>> module area is covered by such a program header, they should be accessible.
>>     
>
> Ah, that hints at a known bug in our ELF generator (affecting LinuxBI^W
> Coreboot).  I'll check if the patches for that one help.
>
>   
>>>>   grub_ieee1275_finddevice ("/options", &options);
>>>>   rc = grub_ieee1275_get_property (options, "real-mode?", &realmode,
>>>> 				   sizeof realmode, 0);
>>>> -  if ((rc >= 0) && realmode)
>>>> +//  if ((rc >= 0) && realmode)
>>>>     grub_ieee1275_set_flag (GRUB_IEEE1275_FLAG_REAL_MODE);
>>>>    
>>>>         
>>> This OFW operates in what GRUB calls "real mode" (not to be confused with
>>> x86 realmode!), but /options/real-mode? doesn't exist.  Should we probe
>>> for the actual feature (/chosen/mmu IIRC), probe for firmware version, or
>>> #ifdef it for x86 CPUs?
>>>  
>>>       
>> This OFW operates in virtual mode, but happens to have an identity 
>> mapping of low memory for convenience.
>>     
>
> /chosen/mmu is set to 0, at least on my (qemu) environment.  Should clients
> interpret this as identity mapping, or is this unintended?
>   
That is probably a bug in the OFW build.

> Thank you!
>
>