Temporary halt

I'm presently involved in creating Europen Games Academy, and thus I'm forced to stop the work on the Efika port. I plan to come back to the project later, yet in the middle I'm planning to use FreeBSD in the development of a new kind of computer games related device... I'll try to put some details as the project develop...

also

I'm preparing a diagram of our dev tree, showing the PIC location relative to PCI, root/nexus and others. Also, while filling out the final eval, an idea came to me to write a tutorial on using p4 in cumbersome situations, like having to fix broken local copy of branch etc... I had some problems with p4 and it's possible that future GSoCers will encounter them too, while the p4 part of the handbook is not helping much with those (of course one can always say RTFM..:)

Not much happened recently due to the exam I had to pass. What we did was thinking out the device structure using the ofwbus bus. The aim is to place the PIC driver in a suitable place so the rest of the dev tree can be constructed. Now is the time to read the PIC programming part of the MPC5200B UG... 

WANTED: PIC driver...

Finally, I've managed to fix all (at least up till now..) broken OF calls, and the kernel went further, to the place where devices are attached. Among them, there should be a PIC driver, which is missing... After adding the ofwbus driver which I got from Andrew, I've constructed a PIC driver skeleton from the sys/powerpc/powermac/hrowpic.c. The PIC was found to resist on the ofwbus3, and the attch method fails to allocate memory (nice screenshot on my wiki http://wiki.freebsd.org/Porting_FreeBSD_to_Efika_(PPC_bring_up)). Now I have to mutate the old mac driver to obey the mpc5k2 will... I've also created a new folder in the p4 branch, where all the stuff concerning MPC5200B will be stored. It's called ... mpc5k2 :)

Staying late pays...

Thanks to simple, yet great advice by Andrew Turner concerning calls to openfirmware and utilizing *OF_buf, it seems that eventually I came to the point where the kernel panics due to the lack of PIC!:

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

 atomic_subtract_16(0)... panic: no PIC detected

KDB: enter: panic
[thread pid 0 tid 100000 ]
Stopped at 0x29587c: addi r0, r0, 0x0

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

As you can see, the KDB by itself stops at this point, no crash at last:)

All thanks to the AT and the fact that I'm studying hard for the exam (Quantum Mechanics for PhD students....)

/*decr_init()*/

Some new things came up recentrly, I've added some code from NetBSD and commented out the decr_init() in cpu_startup(). Now, during the boot I've rached subsystem 3800000 , as last time w/o decr_init(), but this time it seems it entered the newbus!

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

[thread pid 0 tid 100000 ]
Breakpoint at 0x4930d8: stwu r1, r1, -0x20
db>
nexus0: registered as a time-of-day clock (resolution 1000us)
nexus0: , type (unknown) (no driver attached)
nexus0: , type (unknown) (no driver attached)
nexus0: , type (unknown) (no driver attached)
nexus0: , type (unknown) (no driver attached)
nexus0: , type (unknown) (no driver attached)
nexus0: , type memory (no driver attached)
nexus0: , type (unknown) (no driver attached)
nexus0: , type (unknown) (no driver attached)
nexus0: , type serial (no driver attached)
nexus0: , type builtin (no driver attached)
nexus0: , type pci (no driver attached)
sc0: no video adapter found.
nexus0: , type syscons (no driver attached)
done.
  ofw_bus_gen_get_name(0)... cpu_exception:
SRR0 0x01035CFC SRR1 0x00003030 MSR 0x00003030
LR 0x0103E1E4 CTR 0x0101A5F0 CR 0x44002042 XER 0x20000000
DAR 0xD0004DDE DSISR 0x42000000 Type 3
GPR[] 0x00000007 0x00559EB4 0x00000000 0x00000000 0x07C05323 0x00000005 0x0000000D 0x0058EBB8

...

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

And again, the old friend. I can't spot the cause of those crashes. They always look the same, with the same content of SRR0,1 and MSR. Adding some stuff from NetBSD helped, but it only took it just a few steps further. Thus it must be something wih the OF, but what? This time it's nothing about the stack, because the registers contains some crazy addresses, neither form kernel, nor from the OF stack... During some previous tests I've encountered some crashes on instructions reading/writing to SPRG0 and IBAT4, in  ofw_sprg_prepare(); and in

===========

from: src/sys/powerpc/aim/ofw_machdep.c

 __asm __volatile( "\t"
  "sync\n\t"
  "mfmsr %0\n\t"
  "mtmsr %1\n\t"
  "isync\n"
  : "=r" (oldmsr)
  : "r" (ofmsr[0])
  );
============

both in openfirmware()...

odd discovery

I was fighting with the OF_peer() to check if it passes the openfirmware() call, which is OF entry and after lots of tries it seems that it does. It's very different from what I thought before. After using ofw_stack() from NetBSD in OF_peer() as it was done in OF_read()/OF_write(), that function seems to be working but the crash remains. 

Here's the dump:

DEBUG 2
done.
subsystem 2100000
  freebsd4_sigreturn(0)...
cpu_startup() DEBUG 0
** DEBUGL OF_printf(): after OF_peer() in decr_init()
cpu_exception:
SRR0 0x004A0DF0 SRR1 0x00003030 MSR 0x00003030
LR 0x01003ED8 CTR 0x00000000 CR 0x24002044 XER 0x0
DAR 0xD0004D3C DSISR 0x42000000 Type 3
========================
What is very strange, during the trace I've encountered the call to OF_write() just after OF_peer(), like there were _two_ calls to openfirmware() insted of one. And it's the second one that crashes... Now, what I don't get is where from this second call come ? There's no printf() around OF_peer()...:

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

from: sys/dev/ofw/openfirm.c

phandle_t
OF_peer(phandle_t node)
{
      static struct {
      cell_t name;
      cell_t nargs;
      cell_t nreturns;
      cell_t node;
      cell_t next; }

               args = {
                           (cell_t)"peer",
                            1,
                            1,
                            };

  ofw_stack();
  args.node = node;
  if (openfirmware(&args) == -1)
  return (-1);
  return (args.next);
}
=========================