[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Robert Millan
Subject: Re: GRUB on OLPC / XO
Date: Sat, 12 Jan 2008 19:58:43 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Sat, Jan 12, 2008 at 08:02:03AM -1000, Mitch Bradley wrote:
> Robert Millan wrote:
> >Some comments on things that need polishing.  Some are more addressed at 
> >one
> >of the two lists than the others, but feel free to join in either case.
> >
> >(also, if you feel this is off-topic in olpc-devel, feel free to ki^W let
> >me know)
> >
> >btw, Mitch mentioned to me on IRC that the ELF loader on XO has some 
> >"weird"
> >modifications to support Minix.  Is this documented somewhere?
> >  
> I was mistaken about Minix - there are no Minix-specific hacks in the 
> ELF loader.  The only Minix support is a handler for the Minix 
> filesystem layout, which doesn't affect the ELF loader.
> The ELF loader has two special cases, which are not documented anywhere 
> except the source code (cpu/x86/pc/olpc/linux.fth : ?memtest-elf-map-in )  :
> a) It recognizes the memtest86 binary that is embedded in OFW, setting 
> up some special mappings that memtest requires (or at least used to require)
> b) It recognizes the ELF form of the Linux binary and sets up a mapping 
> from virtual c0xx.xxxx to physical 00xx.xxxx .  Normally this isn't 
> used, because we load the bzImage version of Linux.  But OFW can load 
> the ELF portion of the Linux kernel, without the bzImage wrapper.  If 
> you do it that way, OFW has access to the ELF symbol table and can thus 
> resolve symbolic names for addresses inside Linux.

Ok, thanks for the explanation.  It doesn't seem like GRUB would be affected

> >On Sat, Jan 12, 2008 at 02:42:30PM +0100, Robert Millan wrote:
> >  
> >>+void
> >>+grub_exit (void)
> >>+{
> >>+  /* Trap to Open Firmware.  */
> >>+  /* FIXME.  */
> >>+
> >>+  for (;;);
> >>+}
> >>    
> >
> >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.

> 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?

> 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?

> >>   /* 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?

Thank you!

Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]