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