[OpenBIOS] [PATCH] sparc64 add cpuid to cpu node

Blue Swirl blauwirbel at gmail.com
Tue Dec 23 09:16:19 CET 2008


On 12/23/08, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
> On Sat, Dec 13, 2008 at 6:10 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
>  > On 12/12/08, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
>  >> On Thu, Dec 11, 2008 at 8:11 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
>  >>  > On 12/7/08, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
>  >>  >> On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
>  >>  >>  > On 9/27/08, Igor Kovalenko <igor.v.kovalenko at gmail.com> 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 (root at arthur.devel.redhat.com) (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)
>  > (waldi at debian.org) (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.



More information about the OpenBIOS mailing list