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 /.) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel