I've tried to find the differences between the contexts of calling openfirmware()
from OF_write()/OF_read() and OF_peer(), but I found none. It's not possible
to break into the fwentry() call from openfirmware(), since it always results in
spinlock corrupt crash.  I've tried to insert the call to decr_init() into several
boot subsystems, it always ended with the same crash, even before the VM init.
I've also called the OF_peer() at the very beginning of OF_write() to see if it's
possible to execute it at the very early stage of the boot, before the KDB entry.
It crashed. I've also tried to switch off the decr_init() call in the cpu_starup() and the system passed several following subsystems to subsystem 3000000 (or so) and crashed in the same way it does with decr_init().
I've inspected what does the ofw_stack() function do, but it only copies the current call stack to the firmware stack located in locore.S. This call was added in OF_read()/write() to make them work on Efika. Now, I can guess it's something with what could have change in p4 FBSD vs FBSD 6.x, since the patch was for that version. I'll try to apply the patch to version 6.x. Also, I'll have a look at the NetBSD source. I really don't understand, why it does work work the OF_read()/OF_write() and does not for OF_peer(), since those calls are so similar.

still no luck, and a new problem

I've performed lots of experiments with the ofwreal.S and locore.S
sources in aim to try to remove the problem with the stack.
It does't work for now, but I've managed to overcome that by utilizing
some free registers. Now I've encountered yet another problem - the
kernel now crashes on the openfirmware entry in the fwentry(). It's probably
coused by a wrong address of the entry point, coming from the virtual
instead of the real addressing. Here's the crash site:
=============
cpu_exception:
SRR0 0x00000000 SRR1 0x00083030 MSR 0x00003030
LR 0x004A0E70 CTR 0x00000000 CR 0x44002082 XER 0x20000000
=============
I've made a small test by changing the address the firmware entry is supposed to
be at and I get slightly similar crash:
=============
cpu_exception:
SRR0 0x01003ED8 SRR1 0x00003030 MSR 0x00003030
LR 0x004A0E70 CTR 0x00000000 CR 0x44002044 XER 0x0
=============
The LR's point to the same location, the very next instrucion after branch to OF.
So I suppose it's the OF address, not just the argument addresing
that is responsible at the moment. I'm trying to find out how to translate an
address to the real mode. All help would be greatly appreciated...:)

hard progress

Eventually, with the aid of my mentor, we found the exact position of the faulting instruction. I've managet to turn on the KDB facility and thus we were able to make some breakpoints. In aim to spot the bug we used the DAR register content and toolchan version of the objdump tool.  Fortunately, it appeared that addresses obtained from the objdump and those from the running kernel match. Here's the dump:

====================================================================

...

SRR0 0x004A0D10 SRR1 0x00003030 MSR 0x00003030
LR 0x01003ED8 CTR 0x00000000 CR 0x24002044 XER 0x0
DAR 0xD0004D3C DSISR 0x42000000 Type 3
GPR[] 0x004A0BC4 0xD0004D30 0x00000000 0x01003ED8 0x00003030 0x00000000 0x00000020 0x00000000
...

====================================================================

The evil instrucion is in the openfirmware entry point wrapper,

====================================================================

ofwreal.S

...

/*
 * Emulated firmware entry.
 */
fwentry:

...

 lis %r3,clsave@ha   /* save mmu values of client */
  addi %r3,%r3,clsave@l
  lis %r3,fwsave@ha /* restore mmu values of firmware */
  addi %r3,%r3,fwsave@l
  bl restoremmu

  lis %r3,ofentry@ha
  lwz %r3,ofentry@l(%r3) /* get actual firmware entry */
  mtlr %r3

  mfmsr %r4
  stw %r4,12(%r1) /* save MSR */
  ori %r4,%r4,PSL_IR|PSL_DR /* turn on MMU */
  andi. %r4,%r4,~PSL_EE@l /* turn off interrupts */
  mtmsr %r4
  isync

====================================================================

The problem is with the stack,

stw %r4,12(%r1) /* save MSR */

That line causes probably a DSI exception. The problem is that it crashes just after the restoremmu function branch. If one stores something on the stuck before that branch, ther's no crash. So the problem lies in the restoremmu function, but it's not clear to me where exactly it is, because the restoremmu does not operate the %r1 register explicitly.

suspect spotted

I've managed to find the faulty function. It's openfirmware() from ofw_machdep.c. Back to __asm__ and OF vs SF...

Bad surprise

I've been playing around with the kernel to turn on some debugging
in the driver source code, and it appeared that it doesn't even come to
SI_SUB_CONFIGURE. I've turned on VERBOSE_SYSINIT, here's the snipped:

=======================================================================
0x253718(0x57d068)... done.
0x253718(0x57d120)... done.
0x253718(0x578dcc)... done.
0x26d900(0x56f194)... done.
0x253718(0x56f19c)... done.
0x253718(0x57d5a0)... done.
0x2a46e8(0)... done.
0x308d88(0)... done.
0x295c50(0)... done.
subsystem 1c00000
0x293e94(0)... done.
subsystem 1c00001
0x27a9d8(0)... done.
subsystem 2000000
0x2520e0(0)... done.
0x245f24(0)... done.
0x284630(0)... done.
linker_file_unload(0)... done.
ktrsyscall(0)... done.
linker_file_lookup_set(0)... done.
subsystem 2100000
freebsd4_sigreturn(0)... cpu_exception:
SRR0 0x004A0D10 SRR1 0x00003030 MSR 0x00003030
LR 0x01003ED8 CTR 0x00000000 CR 0x24002044 XER 0x0
DAR 0xD0004D3C DSISR 0x42000000 Type 3
GPR[] 0x004A0BC4 0xD0004D30 0x00000000 0x01003ED8 0x00003030 0x00000000 0x00000020 0x00000000
GPR[] 0x00000000 0x00000000 0x00000000 0x004A0D00 0x00003030 0x00000000 0xEFF7737F 0x00575BC8
GPR[] 0x00590000 0x00554D0C 0x00522C6C 0x00522C4C 0x00522C5C 0x00522C90 0xD0004E18 0xD0004E1C
GPR[] 0x00590000 0x00800001 0x00590000 0x00000001 0x00590000 0x02100000 0x00003032 0xD0004D40
ibat0U 0x00001FFF ibat0L 0x00000012
ibat1U 0xF0001FFF ibat1L 0xF0000012
ibat2U 0x00000000 ibat2L 0x00000000
ibat3U 0x00000000 ibat3L 0x00000000
dbat0U 0xF0001FFF dbat0L 0xF000002A
dbat1U 0x80001FFF dbat1L 0x8000002A
dbat2U 0x00001FFF dbat2L 0x00000012
dbat3U 0xC0001FFF dbat3L 0xC000002A
HID0 0x0000C000
deadend:
=======================================================================

The crashing subsystem is subsystem 2100000, and is responsible for the
CPU resources:

=======================================================================
from sys/sys/kernel.h

...
enum sysinit_sub_id {
...
SI_SUB_KLD = 0x2000000, /* KLD and module setup */
SI_SUB_CPU = 0x2100000, /* CPU resource(s)*/
...
};
...
=======================================================================

It crashes somwhere near sigreturn(). The PIC has to wait for a second...

Recent activity report 01

This week I had a liitle progress in making p4 obeying my will:) I've managed to cleanup some mess I done there some time ago when I created my first branch. Now, after fixing that I've made a submit of the FreeBSD code merged with Andrew Turner's code. The code boots well and stops in the middle of nowhere...
Now it's the time to check if the device enumeration goes well. I'll be trying to turn on the debugging in the devices source code to see if dev's ID's are OK with the OpenFirmware... After that I plan to get aquired with the newbus framework and I'll be heading towards the allmighty PIC... nexux.c awaits...

So here we go...

Welcome everybody!
It's my blog on my 2008's GSoC project, which is porting FreeBSD to Efika, a PPC based evaluation board. I've decided to create this blog in aim to show you how a geek spends his summer :) - I'll be describing ups and downs of being a GSoCer as the time passes, but also I'll be reporting the progress of the project. More techincal info can be foud on my FreeBSD wiki:
http://wiki.freebsd.org/PrzemekWitaszczyk#preview