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

Igor Kovalenko igor.v.kovalenko at gmail.com
Tue Dec 23 00:07:24 CET 2008


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.

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

-- 
Kind regards,
Igor V. Kovalenko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbios-sparc64-cpufreq.patch
Type: application/octet-stream
Size: 1124 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20081223/4ed624cd/attachment.dmg>


More information about the OpenBIOS mailing list