On Sat, Dec 13, 2008 at 6:10 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 12/12/08, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Thu, Dec 11, 2008 at 8:11 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 12/7/08, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Sat, Sep 27, 2008 at 10:51 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 9/27/08, Igor Kovalenko igor.v.kovalenko@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@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@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.