On Fri, Oct 29, 2010 at 8:42 PM, Artyom Tarasenko atar4qemu@gmail.com wrote:
On Fri, Oct 29, 2010 at 10:28 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
So it would be useful to have someone who understands both SPARC32 and qemu 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.
Which 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.