All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: Mitch Bradley <wmb@laptop.org>
Cc: grub-devel@gnu.org, devel@lists.laptop.org
Subject: Re: GRUB on OLPC / XO
Date: Sat, 12 Jan 2008 19:58:43 +0100	[thread overview]
Message-ID: <20080112185843.GA12074@thorin> (raw)
In-Reply-To: <4789009B.8030403@laptop.org>

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
then.

> >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 /.)



  parent reply	other threads:[~2008-01-12 19:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-12 13:42 GRUB on OLPC / XO Robert Millan
2008-01-12 14:00 ` Robert Millan
     [not found]   ` <4789009B.8030403@laptop.org>
2008-01-12 18:58     ` Robert Millan [this message]
     [not found]       ` <47891639.7070500@laptop.org>
     [not found]         ` <47891889.5020402@laptop.org>
2008-01-12 20:30           ` Robert Millan
  -- strict thread matches above, loose matches on Subject: below --
2008-01-12  3:14 Robert Millan
2008-01-15 11:31 ` Marco Gerards
2008-01-15 12:06   ` Robert Millan
2008-01-15 12:23     ` Marco Gerards
2008-01-15 12:32       ` Robert Millan
2008-01-15 12:48         ` Marco Gerards
2008-01-15 16:36     ` Robert Millan
2008-01-21 10:24       ` Marco Gerards
2008-01-21 11:33         ` Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080112185843.GA12074@thorin \
    --to=rmh@aybabtu.com \
    --cc=devel@lists.laptop.org \
    --cc=grub-devel@gnu.org \
    --cc=wmb@laptop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.