[OpenBIOS] [PATCH v3 3/5] Pretty-print reg property
Artyom Tarasenko
atar4qemu at gmail.com
Mon Dec 6 10:59:28 CET 2010
On Sun, Dec 5, 2010 at 12:21 PM, Andreas Färber <andreas.faerber at web.de> wrote:
> Am 05.12.2010 um 03:08 schrieb Tarl Neustaedter:
>
>> On 2010-12-4 8:54 AM, Andreas Färber wrote:
>>>
>>> [...]
>>> Just wondering, what does /virtual-memory at 0,0 contain?
> Actually the context here was sparc32/sun4m. Artyom reported no /chosen node
> on an SS-5 but apparently some /virtual-memory at 0,0 node.
I thought he also reported the contents of the node here:
http://lists.openbios.org/pipermail/openbios/2010-October/005611.html
For SS-5:
ok .attributes
available 00000000 fff00000 00100000
00000000 fef00000 00e00000
00000000 00000000 fe400000
00000000 ffe15000 000cd000
00000000 ffd00000 00008000
00000000 fe400000 00b00000
reg 00000000 00000000 80000000
00000000 80000000 80000000
name virtual-memory
Btw, the contents of this node is the same regardless whether the ram
size is 256M or 32M.
> OpenBIOS/sparc32 on the other hand does have a /chosen node and an "mmu"
> property, but its value is 0 so that pretty-printing of /virtual-memory's
> "available" isn't triggered. So I'm thinking, if the virtual memory
> "available" property is there and we do have a /chosen node then "mmu"
> should point to /virtual-memory, even if there's no "translations" property.
> The alternative would be to [IFDEF] CONFIG_SPARC32 a special handling of
> "available" in the /virtual-memory node.
The question is how does the OS get this information. Can it be that
the name of the node doesn't matter?
It Solaris wouldn't get the available memory from the firmware I'd
expect some error message like
"Can't deduct msgbuf from physical memory list". (had it when qemu had
math and mmu problems).
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
More information about the OpenBIOS
mailing list