[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments
blauwirbel at gmail.com
Fri Oct 29 22:58:02 CEST 2010
On Fri, Oct 29, 2010 at 8:42 PM, Artyom Tarasenko <atar4qemu at gmail.com> wrote:
> On Fri, Oct 29, 2010 at 10:28 PM, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk> wrote:
>> Blue Swirl wrote:
>>>> So it would be useful to have someone who understands both SPARC32 and
>>>> to take a look (hint, hint!) ;)
>>> Trap 0x29 is TT_DATA_ACCESS, invoked on access to unassigned memory by
>>> QEMU. Perhaps enabling DEBUG_UNASSIGNED in target-sparc/op_helper.c
>>> may reveal something.
>>> It has been suspected that QEMU may be a bit too trigger happy with
>>> unassigned memory accesses. There may also be an undocumented device,
>>> or Solaris just tries to access a device which does not exist on SS-5.
>> Okay. With that DEBUG_UNASSIGNED enabled I get the following message as the
>> trap is invoked:
>> Unassigned mem write access of 4 bytes to ffffffffffff0ecc from f004127c
> No, it's not the same as with OBP. Btw I have a fix for the OBP fault,
> but it waits till someone commits the
> promised refactoring.
>> Is there some kind of device map for SPARC32 somewhere so we can lookup what
>> kind of device this is?
> None. It probably tries to access something which is not mapped.
This could be verified by changing a line in helper.c:
*physical = 0xffffffffffff0000ULL;
to for example
*physical = 0xfef1f0fef1ff0000ULL;
and see if the address changes.
More information about the OpenBIOS