Re: A3000 problems

[Frank Wille <frank%phoenix.owl.de@localhost>]

Radoslaw Kujawa wrote:

>> I can also upload the full gobsdppc source somewhere, when anybody is
>> interested. But it may only be compilable with vbcc at the moment.
>
> I am interested, as I stated some days ago when I asked for gobsdppc
> source ;).

The current source archive can be downloaded from:
  http://sun.hasenbraten.de/~frank/NetBSD/gobsdppc.lha


> Why not commit it to sys/arch/amigappc/stand/ ?

Because it cannot be compiled under NetBSD. And it is just a temporary
solution. When amigappc ever reaches a usable state we should use/enhance
the port-amiga bootblock code.


> PowerUP seems to handle this situation well, I ran some PPC programs
> this way. I was unable to fill CSPPC RAM completely, so ppc.library
> managed to fit into CSPPC RAM. Started PPC tasks were loaded and
> executed in Z3 RAM (I checked this with SysInfo, tasks were indeed
> running somewhere within 0x5000 0000).  

Ok, so it would theoretically work. But I think that it is practically
useless to run PPC code in memory which is so slow as Z3 RAM.


> So number of BATs is limited only by battable size (512) ?

Data-BATs, yes. ISI traps are not handled by replacing BATs. So the kernel
and maybe other firmware code it needs, should be covered by IBAT0 and
IBAT1.


> amigappc_batinit(0x00000000, BAT_BL_16M, BAT_I|BAT_G,
>                     (startkernel & 0xf8000000), BAT_BL_128M, 0,
>                     0xfff00000, BAT_BL_512K, 0,
>                     0x40000000, BAT_BL_256M, BAT_I|BAT_G, 0,
>                     0x50000000, BAT_BL_256M, BAT_I|BAT_G, 0,
>                     0x60000000, BAT_BL_256M, BAT_I|BAT_G, 0,
>                     0x70000000, BAT_BL_256M, BAT_I|BAT_G,
>                     ~0);
>
> Still, kernel did not boot with CV64/3D inserted, but works if I remove
> it. Should I modify anything else?

This should have worked. I have no more spontaneous ideas. You have to debug
it.

Did you try to swap position with the Deneb, so the CV64/3D appears at
0x40000000?


> Any idea how to debug this before console is initialized?

Yes, write data into Chip-RAM (e.g. 0x1f0000), which you can inspect after a
reboot.


-- 
Frank Wille