[PATCH] sparc64 add cpuid to cpu node

[Igor Kovalenko]

Hi!

Linux kernel expects at least "cpuid" property in cpu device node, or
it halts execution. This patch adds one with dummy "1" value. This
allows to make some progress into booting the kernel.

Please apply.

[Blue Swirl]

On 9/27/08, Igor Kovalenko  wrote:
> Hi!
>
> Linux kernel expects at least "cpuid" property in cpu device node, or
>  it halts execution. This patch adds one with dummy "1" value. This
>  allows to make some progress into booting the kernel.
>
> Please apply.

Thanks, applied. The real implementation would be to probe the real ID
from various registers but as we don't have SMP yet this is sufficient
for now.

[Igor Kovalenko]

On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl  wrote:
> On 9/27/08, Igor Kovalenko  wrote:
> > Hi!
> >
> > Linux kernel expects at least "cpuid" property in cpu device node, or
> >  it halts execution. This patch adds one with dummy "1" value. This
> >  allows to make some progress into booting the kernel.
> >
> > Please apply.
>
> Thanks, applied. The real implementation would be to probe the real ID
> from various registers but as we don't have SMP yet this is sufficient
> for now.

Small correction: cpuid property of qemu cpu should be "0" for the
linux kernel to boot on qemu. This is because kernel is reading cpu
registers to find out current smp processor ID and it happens to find
out "0" cpuid because corresponding register is zeroed by qemu.
Currently kernel fails since there is no "0" cpu node in tree.

Please apply the following patch: openbios-sparc64-cpuid.patch

[Blue Swirl]

On 12/7/08, Igor Kovalenko  wrote:
> On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl  wrote:
> > On 9/27/08, Igor Kovalenko  wrote:
> > > Hi!
> > >
> > > Linux kernel expects at least "cpuid" property in cpu device node, or
> > >  it halts execution. This patch adds one with dummy "1" value. This
> > >  allows to make some progress into booting the kernel.
> > >
> > > Please apply.
> >
> > Thanks, applied. The real implementation would be to probe the real ID
> > from various registers but as we don't have SMP yet this is sufficient
> > for now.
>
> Small correction: cpuid property of qemu cpu should be "0" for the
>  linux kernel to boot on qemu. This is because kernel is reading cpu
>  registers to find out current smp processor ID and it happens to find
>  out "0" cpuid because corresponding register is zeroed by qemu.
>  Currently kernel fails since there is no "0" cpu node in tree.
>
> Please apply the following patch: openbios-sparc64-cpuid.patch

Thanks. I did not see any difference, but applied anyway.

[Igor Kovalenko]

On Thu, Dec 11, 2008 at 8:11 PM, Blue Swirl  wrote:
> On 12/7/08, Igor Kovalenko  wrote:
> > On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl  wrote:
> > > On 9/27/08, Igor Kovalenko  wrote:
> > > > Hi!
> > > >
> > > > Linux kernel expects at least "cpuid" property in cpu device node, or
> > > >  it halts execution. This patch adds one with dummy "1" value. This
> > > >  allows to make some progress into booting the kernel.
> > > >
> > > > Please apply.
> > >
> > > Thanks, applied. The real implementation would be to probe the real ID
> > > from various registers but as we don't have SMP yet this is sufficient
> > > for now.
> >
> > Small correction: cpuid property of qemu cpu should be "0" for the
> >  linux kernel to boot on qemu. This is because kernel is reading cpu
> >  registers to find out current smp processor ID and it happens to find
> >  out "0" cpuid because corresponding register is zeroed by qemu.
> >  Currently kernel fails since there is no "0" cpu node in tree.
> >
> > Please apply the following patch: openbios-sparc64-cpuid.patch
>
> Thanks. I did not see any difference, but applied anyway.

What are you using to test it?

Here with gentoo-sparc64 minimal install iso it still traps before
something useful is printed - my local experiment with debugging
kernel output hangs while processing first or second periodic timer
tick. It successfully reports clocksource and clockevent multiplier
and shift.

[Blue Swirl]

On 12/12/08, Igor Kovalenko  wrote:
> On Thu, Dec 11, 2008 at 8:11 PM, Blue Swirl  wrote:
> > On 12/7/08, Igor Kovalenko  wrote:
> > > On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl  wrote:
> > > > On 9/27/08, Igor Kovalenko  wrote:
> > > > > Hi!
> > > > >
> > > > > Linux kernel expects at least "cpuid" property in cpu device node, or
> > > > >  it halts execution. This patch adds one with dummy "1" value. This
> > > > >  allows to make some progress into booting the kernel.
> > > > >
> > > > > Please apply.
> > > >
> > > > Thanks, applied. The real implementation would be to probe the real ID
> > > > from various registers but as we don't have SMP yet this is sufficient
> > > > for now.
> > >
> > > Small correction: cpuid property of qemu cpu should be "0" for the
> > >  linux kernel to boot on qemu. This is because kernel is reading cpu
> > >  registers to find out current smp processor ID and it happens to find
> > >  out "0" cpuid because corresponding register is zeroed by qemu.
> > >  Currently kernel fails since there is no "0" cpu node in tree.
> > >
> > > Please apply the following patch: openbios-sparc64-cpuid.patch
> >
> > Thanks. I did not see any difference, but applied anyway.
>
> What are you using to test it?
>
> Here with gentoo-sparc64 minimal install iso it still traps before
>  something useful is printed - my local experiment with debugging
>  kernel output hangs while processing first or second periodic timer
>  tick. It successfully reports clocksource and clockevent multiplier
>  and shift.

I'll have to try that. I'm using some ISO images I grabbed for
Sparc32, some of them support Sparc64 as well. Then I have some
Sparc64 only images, for example OpenBSD, milaX, marTux and HelenOS.

For Linux, you get more messages by adding '-p' flag, that specifies
that early prom console will be used for debug. For example, Aurora
2.0 prints to serial console:
 [1-Main] [2-General] [3-Expert] [4-Rescue] [5-Kickstart] [6-Kernel]
boot: linux -p
Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.13
Loading initial ramdisk (2522576 bytes at 0xC00000 phys, 0x40C00000 virt)...
service close: argument count error (0 0)

PROMLIB: Sun IEEE Boot Prom 3.10.24 1999/01/01 01:01
Linux version 2.6.13-1.1603sp13 ([e-mail]) (gcc
version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Mon Apr 10 12:18:58
EDT 2006
ARCH: SUN4U
Ethernet address: 52:54:00:12:34:56
Remapping the kernel... done.
Registering callbacks... va>tte-data:interpret: exception -13 caught
.soft1:interpret: exception -13 caught
.soft2:interpret: exception -13 caught
done.

Debian 4.0r0:
[ ENTER - Boot install ]   [ Type "expert" - Boot into expert mode ]
                           [ Type "rescue" - Boot into rescue mode ]
boot:
install                  expert                   rescue
auto
boot: install -p
Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.18
Loading initial ramdisk (3879265 bytes at 0xC00000 phys, 0x40C00000 virt)...
service close: argument count error (0 0)

PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
PROMLIB: Root node compatible: sun4u
Linux version 2.6.18-4-sparc64 (Debian 2.6.18.dfsg.1-11)
([e-mail]) (gcc version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)) #1 Wed Feb 21 16:19:25 UTC 2007
ARCH: SUN4U
Ethernet address: 52:54:00:12:34:56
Remapping the kernel... done.
service nextprop: argument count error (0 1)
service nextprop: argument count error (0 1)
[cut]
service nextprop: argument count error (0 1)
PROM: Built device tree with 15983 bytes of memory.
Booting Linux...
CPU[0]: Caches D[sz(16384):line_sz(32)] I[sz(16384):line_sz(32)]
E[sz(4194304):line_sz(64)]
Built 1 zonelists.  Total pages: 15318
Kernel command line: cdrom -p
PID hash table entries: 512 (order: 9, 4096 bytes)
spitfire_data_access_exception: SFSR[0000000000000000]
SFAR[0000000000000010], going.
              |/ ____ |/
              "@'/ .. `@"
              /_| __/ |_\
                 __U_/
swapper(0): Dax [#1]
TSTATE: 0000000080f01601 TPC: 0000000000701680 TNPC: 0000000000406684
Y: 00000000    Not tainted
TPC: <time_init+0xd4/0x130>
g0: 00000000006859ec g1: 000000000000006c g2: 0000000000000004 g3:
0000000070000000
g4: 0000000000685e40 g5: 0000000000000000 g6: 0000000000681e40 g7:
00000000006ec000
o0: 0000000000000000 o1: 000000000063ef04 o2: 0000000000000c40 o3:
0000000000000000
o4: 0000000000000077 o5: 0000000000737800 sp: 0000000000685121 ret_pc:
0000000000426c8c
RPC: <of_find_node_by_type+0x2c/0x48>
l0: 0000000000009000 l1: 000000000073757b l2: 0000000000406680 l3:
0000000000000001
l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000681e40 l7:
0000000080009001
i0: 0000000000000004 i1: 000000000063ef40 i2: 0000000000000000 i3:
0000000000000040
i4: 0000000000000400 i5: 0000000000001400 i6: 0000000000685281 i7:
000000000042696c
I7: <of_find_property+0x14/0x44>
Caller[000000000042696c]: of_find_property+0x14/0x44
Caller[0000000000701678]: time_init+0xcc/0x130
Caller[00000000006fa57c]: start_kernel+0x148/0x294
Caller[00000000004045c0]: setup_trap_table+0x0/0xe8
Caller[00000000ffd10870]: 0xffd10878
Instruction DUMP: c270a140  7ff494ba  25001bb0 <c25a2010> 05001a20
9010a398  e0004000  826c20fa  e070a3c8
Kernel panic - not syncing: Attempted to kill the idle task!
 <0>Press Stop-A (L1-A) to return to the boot prom

[Igor Kovalenko]

On Sat, Dec 13, 2008 at 6:10 PM, Blue Swirl  wrote:
> On 12/12/08, Igor Kovalenko  wrote:
> > On Thu, Dec 11, 2008 at 8:11 PM, Blue Swirl  wrote:
> > > On 12/7/08, Igor Kovalenko  wrote:
> > > > On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl  wrote:
> > > > > On 9/27/08, Igor Kovalenko  wrote:
> > > > > > Hi!
> > > > > >
> > > > > > Linux kernel expects at least "cpuid" property in cpu device node, or
> > > > > >  it halts execution. This patch adds one with dummy "1" value. This
> > > > > >  allows to make some progress into booting the kernel.
> > > > > >
> > > > > > Please apply.
> > > > >
> > > > > Thanks, applied. The real implementation would be to probe the real ID
> > > > > from various registers but as we don't have SMP yet this is sufficient
> > > > > for now.
> > > >
> > > > Small correction: cpuid property of qemu cpu should be "0" for the
> > > >  linux kernel to boot on qemu. This is because kernel is reading cpu
> > > >  registers to find out current smp processor ID and it happens to find
> > > >  out "0" cpuid because corresponding register is zeroed by qemu.
> > > >  Currently kernel fails since there is no "0" cpu node in tree.
> > > >
> > > > Please apply the following patch: openbios-sparc64-cpuid.patch
> > >
> > > Thanks. I did not see any difference, but applied anyway.
> >
> > What are you using to test it?
> >
> > Here with gentoo-sparc64 minimal install iso it still traps before
> >  something useful is printed - my local experiment with debugging
> >  kernel output hangs while processing first or second periodic timer
> >  tick. It successfully reports clocksource and clockevent multiplier
> >  and shift.
>
> I'll have to try that. I'm using some ISO images I grabbed for
> Sparc32, some of them support Sparc64 as well. Then I have some
> Sparc64 only images, for example OpenBSD, milaX, marTux and HelenOS.
>
> For Linux, you get more messages by adding '-p' flag, that specifies
> that early prom console will be used for debug. For example, Aurora
> 2.0 prints to serial console:
>  [1-Main] [2-General] [3-Expert] [4-Rescue] [5-Kickstart] [6-Kernel]
> boot: linux -p
> Allocated 8 Megs of memory at 0x40000000 for kernel
> Loaded kernel version 2.6.13
> Loading initial ramdisk (2522576 bytes at 0xC00000 phys, 0x40C00000 virt)...
> service close: argument count error (0 0)
>
> PROMLIB: Sun IEEE Boot Prom 3.10.24 1999/01/01 01:01
> Linux version 2.6.13-1.1603sp13 ([e-mail]) (gcc
> version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Mon Apr 10 12:18:58
> EDT 2006
> ARCH: SUN4U
> Ethernet address: 52:54:00:12:34:56
> Remapping the kernel... done.
> Registering callbacks... va>tte-data:interpret: exception -13 caught
> .soft1:interpret: exception -13 caught
> .soft2:interpret: exception -13 caught
> done.
>
> Debian 4.0r0:
> [ ENTER - Boot install ]   [ Type "expert" - Boot into expert mode ]
>                           [ Type "rescue" - Boot into rescue mode ]
> boot:
> install                  expert                   rescue
> auto
> boot: install -p
> Allocated 8 Megs of memory at 0x40000000 for kernel
> Loaded kernel version 2.6.18
> Loading initial ramdisk (3879265 bytes at 0xC00000 phys, 0x40C00000 virt)...
> service close: argument count error (0 0)
>
> PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
> PROMLIB: Root node compatible: sun4u
> Linux version 2.6.18-4-sparc64 (Debian 2.6.18.dfsg.1-11)
> ([e-mail]) (gcc version 4.1.2 20061115 (prerelease) (Debian
> 4.1.1-21)) #1 Wed Feb 21 16:19:25 UTC 2007
> ARCH: SUN4U
> Ethernet address: 52:54:00:12:34:56
> Remapping the kernel... done.
> service nextprop: argument count error (0 1)
> service nextprop: argument count error (0 1)
> [cut]
> service nextprop: argument count error (0 1)
> PROM: Built device tree with 15983 bytes of memory.
> Booting Linux...
> CPU[0]: Caches D[sz(16384):line_sz(32)] I[sz(16384):line_sz(32)]
> E[sz(4194304):line_sz(64)]
> Built 1 zonelists.  Total pages: 15318
> Kernel command line: cdrom -p
> PID hash table entries: 512 (order: 9, 4096 bytes)
> spitfire_data_access_exception: SFSR[0000000000000000]
> SFAR[0000000000000010], going.
>              |/ ____ |/
>              "@'/ .. `@"
>              /_| __/ |_\
>                 __U_/
> swapper(0): Dax [#1]
> TSTATE: 0000000080f01601 TPC: 0000000000701680 TNPC: 0000000000406684
> Y: 00000000    Not tainted
> TPC: <time_init+0xd4/0x130>
> g0: 00000000006859ec g1: 000000000000006c g2: 0000000000000004 g3:
> 0000000070000000
> g4: 0000000000685e40 g5: 0000000000000000 g6: 0000000000681e40 g7:
> 00000000006ec000
> o0: 0000000000000000 o1: 000000000063ef04 o2: 0000000000000c40 o3:
> 0000000000000000
> o4: 0000000000000077 o5: 0000000000737800 sp: 0000000000685121 ret_pc:
> 0000000000426c8c
> RPC: <of_find_node_by_type+0x2c/0x48>
> l0: 0000000000009000 l1: 000000000073757b l2: 0000000000406680 l3:
> 0000000000000001
> l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000681e40 l7:
> 0000000080009001
> i0: 0000000000000004 i1: 000000000063ef40 i2: 0000000000000000 i3:
> 0000000000000040
> i4: 0000000000000400 i5: 0000000000001400 i6: 0000000000685281 i7:
> 000000000042696c
> I7: <of_find_property+0x14/0x44>
> Caller[000000000042696c]: of_find_property+0x14/0x44
> Caller[0000000000701678]: time_init+0xcc/0x130
> Caller[00000000006fa57c]: start_kernel+0x148/0x294
> Caller[00000000004045c0]: setup_trap_table+0x0/0xe8
> Caller[00000000ffd10870]: 0xffd10878
> Instruction DUMP: c270a140  7ff494ba  25001bb0 <c25a2010> 05001a20
> 9010a398  e0004000  826c20fa  e070a3c8
> Kernel panic - not syncing: Attempted to kill the idle task!
>  <0>Press Stop-A (L1-A) to return to the boot prom

Problem with debian boot is with firmware device tree: it is missing
"clock-frequency" property on the cpu node. This leads to trap in
timers subsystem initialization. Attached is
openbios-sparc64-cpufreq.patch which adds fake 10MHz clock. Frequency
may be passed through configuration device, as it should match
emulated one because linux sparc64 periodic timers code depends on it.

Another problem is with qemu sun4u timers code. These timers must
implement "disable" bit which seems not to be the case.

[Blue Swirl]

On 12/23/08, Igor Kovalenko  wrote:
> On Sat, Dec 13, 2008 at 6:10 PM, Blue Swirl  wrote:
> > On 12/12/08, Igor Kovalenko  wrote:
> > > On Thu, Dec 11, 2008 at 8:11 PM, Blue Swirl  wrote:
> > > > On 12/7/08, Igor Kovalenko  wrote:
> > > > > On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl  wrote:
> > > > > > On 9/27/08, Igor Kovalenko  wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > >  Linux kernel expects at least "cpuid" property in cpu device node, or
> > > > > > >  it halts execution. This patch adds one with dummy "1" value. This
> > > > > > >  allows to make some progress into booting the kernel.
> > > > > > >
> > > > > > >  Please apply.
> > > > > >
> > > > > > Thanks, applied. The real implementation would be to probe the real ID
> > > > > > from various registers but as we don't have SMP yet this is sufficient
> > > > > > for now.
> > > > >
> > > > > Small correction: cpuid property of qemu cpu should be "0" for the
> > > > >  linux kernel to boot on qemu. This is because kernel is reading cpu
> > > > >  registers to find out current smp processor ID and it happens to find
> > > > >  out "0" cpuid because corresponding register is zeroed by qemu.
> > > > >  Currently kernel fails since there is no "0" cpu node in tree.
> > > > >
> > > > > Please apply the following patch: openbios-sparc64-cpuid.patch
> > > >
> > > > Thanks. I did not see any difference, but applied anyway.
> > >
> > > What are you using to test it?
> > >
> > > Here with gentoo-sparc64 minimal install iso it still traps before
> > >  something useful is printed - my local experiment with debugging
> > >  kernel output hangs while processing first or second periodic timer
> > >  tick. It successfully reports clocksource and clockevent multiplier
> > >  and shift.
> >
> > I'll have to try that. I'm using some ISO images I grabbed for
> > Sparc32, some of them support Sparc64 as well. Then I have some
> > Sparc64 only images, for example OpenBSD, milaX, marTux and HelenOS.
> >
> > For Linux, you get more messages by adding '-p' flag, that specifies
> > that early prom console will be used for debug. For example, Aurora
> > 2.0 prints to serial console:
> >  [1-Main] [2-General] [3-Expert] [4-Rescue] [5-Kickstart] [6-Kernel]
> > boot: linux -p
> > Allocated 8 Megs of memory at 0x40000000 for kernel
> > Loaded kernel version 2.6.13
> > Loading initial ramdisk (2522576 bytes at 0xC00000 phys, 0x40C00000 virt)...
> > service close: argument count error (0 0)
> >
> > PROMLIB: Sun IEEE Boot Prom 3.10.24 1999/01/01 01:01
> > Linux version 2.6.13-1.1603sp13 ([e-mail]) (gcc
> > version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Mon Apr 10 12:18:58
> > EDT 2006
> > ARCH: SUN4U
> > Ethernet address: 52:54:00:12:34:56
> > Remapping the kernel... done.
> > Registering callbacks... va>tte-data:interpret: exception -13 caught
> > .soft1:interpret: exception -13 caught
> > .soft2:interpret: exception -13 caught
> > done.
> >
> > Debian 4.0r0:
> > [ ENTER - Boot install ]   [ Type "expert" - Boot into expert mode ]
> >                           [ Type "rescue" - Boot into rescue mode ]
> > boot:
> > install                  expert                   rescue
> > auto
> > boot: install -p
> > Allocated 8 Megs of memory at 0x40000000 for kernel
> > Loaded kernel version 2.6.18
> > Loading initial ramdisk (3879265 bytes at 0xC00000 phys, 0x40C00000 virt)...
> > service close: argument count error (0 0)
> >
> > PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
> > PROMLIB: Root node compatible: sun4u
> > Linux version 2.6.18-4-sparc64 (Debian 2.6.18.dfsg.1-11)
> > ([e-mail]) (gcc version 4.1.2 20061115 (prerelease) (Debian
> > 4.1.1-21)) #1 Wed Feb 21 16:19:25 UTC 2007
> > ARCH: SUN4U
> > Ethernet address: 52:54:00:12:34:56
> > Remapping the kernel... done.
> > service nextprop: argument count error (0 1)
> > service nextprop: argument count error (0 1)
> > [cut]
> > service nextprop: argument count error (0 1)
> > PROM: Built device tree with 15983 bytes of memory.
> > Booting Linux...
> > CPU[0]: Caches D[sz(16384):line_sz(32)] I[sz(16384):line_sz(32)]
> > E[sz(4194304):line_sz(64)]
> > Built 1 zonelists.  Total pages: 15318
> > Kernel command line: cdrom -p
> > PID hash table entries: 512 (order: 9, 4096 bytes)
> > spitfire_data_access_exception: SFSR[0000000000000000]
> > SFAR[0000000000000010], going.
> >              |/ ____ |/
> >              "@'/ .. `@"
> >              /_| __/ |_\
> >                 __U_/
> > swapper(0): Dax [#1]
> > TSTATE: 0000000080f01601 TPC: 0000000000701680 TNPC: 0000000000406684
> > Y: 00000000    Not tainted
> > TPC: <time_init+0xd4/0x130>
> > g0: 00000000006859ec g1: 000000000000006c g2: 0000000000000004 g3:
> > 0000000070000000
> > g4: 0000000000685e40 g5: 0000000000000000 g6: 0000000000681e40 g7:
> > 00000000006ec000
> > o0: 0000000000000000 o1: 000000000063ef04 o2: 0000000000000c40 o3:
> > 0000000000000000
> > o4: 0000000000000077 o5: 0000000000737800 sp: 0000000000685121 ret_pc:
> > 0000000000426c8c
> > RPC: <of_find_node_by_type+0x2c/0x48>
> > l0: 0000000000009000 l1: 000000000073757b l2: 0000000000406680 l3:
> > 0000000000000001
> > l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000681e40 l7:
> > 0000000080009001
> > i0: 0000000000000004 i1: 000000000063ef40 i2: 0000000000000000 i3:
> > 0000000000000040
> > i4: 0000000000000400 i5: 0000000000001400 i6: 0000000000685281 i7:
> > 000000000042696c
> > I7: <of_find_property+0x14/0x44>
> > Caller[000000000042696c]: of_find_property+0x14/0x44
> > Caller[0000000000701678]: time_init+0xcc/0x130
> > Caller[00000000006fa57c]: start_kernel+0x148/0x294
> > Caller[00000000004045c0]: setup_trap_table+0x0/0xe8
> > Caller[00000000ffd10870]: 0xffd10878
> > Instruction DUMP: c270a140  7ff494ba  25001bb0 <c25a2010> 05001a20
> > 9010a398  e0004000  826c20fa  e070a3c8
> > Kernel panic - not syncing: Attempted to kill the idle task!
> >  <0>Press Stop-A (L1-A) to return to the boot prom
>
> Problem with debian boot is with firmware device tree: it is missing
>  "clock-frequency" property on the cpu node. This leads to trap in
>  timers subsystem initialization. Attached is
>  openbios-sparc64-cpufreq.patch which adds fake 10MHz clock. Frequency
>  may be passed through configuration device, as it should match
>  emulated one because linux sparc64 periodic timers code depends on it.

Thanks. I changed the parameter to clock_frequency, because on some
models there is additionally a 'stick-frequency' property. Also the
real clock frequencies are much higher than 10MHz, so I changed that
to 100MHz. I applied the patch after these changes (r308).
> Another problem is with qemu sun4u timers code. These timers must
>  implement "disable" bit which seems not to be the case.

True. I'll implement it next.