On Fri, Oct 29, 2010 at 7:51 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
- Are the memory properties physical or virtual? (totphys and totavail
appear to be physical, where as totmap appears to be virtual?)
I think that's right. We don't update totavail, which is a linked list of all virtual memory zones available. So map_pages should add an entry to the list.
Yeah. The SPARC32 memory routines are quite simple in that they only have one item in each linked list; so while the memory regions represented in the device tree may not be exactly accurate, all memory within each region still meets the required criteria.
- Should the relevant properties in the /memory and /virtual-memory
nodes in the device tree be updated at the same time? (I think yes, as removing the properties causes boot to fail even on SPARC32).
Probably and /virtual-memory nodes should have the same information as totavail list.
Yes, that sounds about right.
Great job, anyway!
Thanks :) Do you have access to any 32-bit Solaris images at the moment for testing purposes? Following up on the trap 0x29 error, it seems that Artyom sees this on the more modern versions of Solaris which suggests it may possibly be a qemu emulation bug (see the comments especially):
http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html
There's a lot of comments. One of them says that the trap also happens on real SS-5.
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.