[OpenBIOS] [PATCH] RFC: Change ofmem_common.c to set memory translation properties by reference
blauwirbel at gmail.com
Fri Oct 15 19:57:34 CEST 2010
On Fri, Oct 15, 2010 at 1:43 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Artyom Tarasenko wrote:
>>> I think so. Actually m48t59 is emulated in sparc32, but not connected
>>> in case of sparc64.
>> The referencing comment in the opensolaris source:
>> * Appropriate tod module will be dynamically selected while booting
>> * based on finding a device tree node with a "device_type" property value
>> * of "tod". If such a node describing tod is not found, for backward
>> * compatibility, a node with a "name" property value of "eeprom" and
>> * "model" property value of "mk48t59" will be used. Failing to find a
>> * node matching either of the above criteria will result in no tod module
>> * being selected; this will cause the boot process to halt
>> On the real U30 machine:
>> ok cd /pci at 1f,4000/ebus at 1/eeprom at 14,0
>> ok .properties
>> address fffa4000
>> reg 00000014 00000000 00002000
>> model mk48t59
>> name eeprom
> Oh, that's interesting. If I look in drivers/obio.c then I can see an eeprom
> device named "mk48t08" rather than "mk48t59". Is this a typo, or does it
> need a new explicit device defined in pci.c's ebus_config_cb() somewhere?
mk48t59 is a newer version of mk48t08, there is alarm etc.
> If this is the case, it appears that qemu-system-sparc64 is set to use
> mc146818rtc rather m48t59 and so there is going to have to be a qemu build
> patch required here too.
Actually, while mc146818rtc is linked in, it's not used (there are
some machines that have similar device, so that's why it still hangs
around). m48t59 is on ebus.
Maybe it's time to pick a specific real machine type instead of 'Sun4u
platform'. Something that is not too far from what we have now, with
PC-like hardware. Is Netra-T1 OK?
More information about the OpenBIOS