On 13/02/11 14:31, Mark Cave-Ayland wrote:
My current feeling is that maybe OpenBIOS isn't doing something right with PIL state somewhere, or we're reading back a zero value from either the clock (or a missing OpenBIOS property) which is causing us to die in the division in cbe_enable(). And another thing, what does cbe actually stand for?
Finally I finally have made some progress! :) Firstly here is the gdb session with OpenBIOS from SVN trunk at the point where we hit the division by zero:
build@zeno:~/src/openbios/openbios-git/openbios-devel$ sparc64-linux-gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=sparc64-linux". (gdb) target remote :1234 Remote debugging using :1234 [New Thread 1] 0x00000000 in ?? () (gdb) file ../../ss5 A program is being debugged already. Are you sure you want to change the file? (y or n) y Reading symbols from /home/build/src/openbios/ss5...(no debugging symbols found)...done. (gdb) break *0xf00a3f2c Breakpoint 1 at 0xf00a3f2c (gdb) cont Continuing.
Breakpoint 1, 0xf00a3f2c in ?? () (gdb) stepi 0xf00a3f30 in ?? () (gdb) 0xf0062cf0 in __div64 () (gdb) 0xf0062cf4 in __div64 () (gdb) 0xf0062cf8 in __div64 () (gdb) info regi i0 i0 0x0 0 (gdb) info regi i1 i1 0x3e60c 255500 (gdb) info regi i2 i2 0x0 0 (gdb) info regi i3 i3 0x0 0 (gdb)
Browsing around the Linux source code, I saw some comments mentioning that the level 14 timer was handled by OBP, so I made the following experimental change in drivers/obio.c:
counter_regs->cpu_timers[0].l14_timer_limit = 0x55555555;
And now I don't get the divide by zero error any more:
build@zeno:~/src/openbios/openbios-git/openbios-devel$ sparc64-linux-gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=sparc64-linux". (gdb) target remote :1234 Remote debugging using :1234 [New Thread 1] 0x00000000 in ?? () (gdb) file ../../ss5 A program is being debugged already. Are you sure you want to change the file? (y or n) y Reading symbols from /home/build/src/openbios/ss5...(no debugging symbols found)...done. (gdb) break *0xf00a3f2c Breakpoint 1 at 0xf00a3f2c (gdb) cont Continuing.
Breakpoint 1, 0xf00a3f2c in ?? () (gdb) stepi 0xf00a3f30 in ?? () (gdb) 0xf0062cf0 in __div64 () (gdb) 0xf0062cf4 in __div64 () (gdb) 0xf0062cf8 in __div64 () (gdb) info regi i0 i0 0x0 0 (gdb) info regi i1 i1 0x7a6fc 501500 (gdb) info regi i2 i2 0x0 0 (gdb) info regi i3 i3 0x53555408 1398101000 (gdb)
However I still don't get much further with the boot because I now get stuck in another loop which keeps outputting the following onto the QEMU console:
spurious interrupt at processor level 10 spurious interrupt at processor level 10 spurious interrupt at processor level 10 ...etc...
So my next question is that if OpenBIOS is supposed to handle the level 14 timer, what should it doing with it? And is there a relationship between the level 14 timer and level 10 timer which causes one to trigger the other?
ATB,
Mark.