[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