amigappc test kernel for CSPPC and BPPC
Frank Wille
anybody who owns a CSPPC or BPPC can test the generic kernel under
ftp://ftp.netbsd.org/pub/NetBSD/misc/phx/amigappc/netbsd.gz
For the beginning you should just check whether the kernel reaches the
"askroot" prompt on you machine. To boot the kernel you need "gobsdppc"
from
ftp://ftp.netbsd.org/pub/NetBSD/misc/phx/amigappc/gobsdppc.gz
gobsdppc loads and relocates the kernel for your memory configuration and
starts the PowerPC. I tried to fix it for BPPC users by copying the boot
code below 0xfff03000. For a test (with debugging symbols) you should do:
gobsdppc askroot symbols
When it works fine for most people I can also upload the amigappc userland
archives (you will need a NetBSD/amiga installation to install amigappc).
The IDE drivers are completely untested, so I'm expecting system hangs while
scanning for drives, etc..
Please report your test results, so I know what to fix next.
--
Frank Wille
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Jukka Andberg
Long Time Ago, Frank Wille wrote:
> Please report your test results, so I know what to fix next.
I spent some more time playing with BPPC and this...
One problem which I probably mentioned previously was that the machine
usually gets stuck when using dcbz instructions to clear memory
(cacheable fast memory pages.)
I found out that this seems to only happen when the accessed memory has
the memory coherence bit enabled. As far as I can tell, no exception is
generated. Often the machine gets so badly stuck that it needs to be
powered off for a moment before it will reboot.
Normal dcbz errors such as trying to zero uncacheable memory do
generate exceptions as expected, so this seems to be something
different.
Any ideas about this? Maybe my hardware is just broken.
Br,
--jukka
Frank Wille
> One problem which I probably mentioned previously was that the machine
> usually gets stuck when using dcbz instructions to clear memory
> (cacheable fast memory pages.)
Yes, I do remember.
> I found out that this seems to only happen when the accessed memory has
> the memory coherence bit enabled.
Why is coherency enabled? I'm sure all Fast RAM is bat-mapped without BAT_M.
So it must be page-table mapped? I saw the pmap-code using PTE_M quite
often.
One difference for your pmap-system is that it is using Chip RAM (for the
tables?). Maybe the cache-attributes for Chip RAM (cache-inhibited and
guarded) do have a bad influence on the whole pmap module...?
Just guessing - I know next to nothing about pmap. :|
> As far as I can tell, no exception is generated.
But you saw any other exceptions correctly handled on the BPPC? Or is there
a problem with this type of exception.
> Normal dcbz errors such as trying to zero uncacheable memory do
> generate exceptions as expected, so this seems to be something
> different.
I remember I had a similar problem with dcbz many years ago when I started
working on amigappc. Never found out what happened and I gave up. After
some months with updated sources the problem was gone...
> Any ideas about this? Maybe my hardware is just broken.
When any Amiga PPC software is working on it I would doubt that.
--
Frank Wille
Jukka Andberg
> Why is coherency enabled? I'm sure all Fast RAM is bat-mapped without BAT_M.
> So it must be page-table mapped? I saw the pmap-code using PTE_M quite
> often.
Yes, it happens with page table mappings (right away when init is being
started), and also when running with address translation off in kernel (in
pmap_zero_page). In the latter case the M bit is on by default.
> One difference for your pmap-system is that it is using Chip RAM (for the
> tables?). Maybe the cache-attributes for Chip RAM (cache-inhibited and
> guarded) do have a bad influence on the whole pmap module...?
> Just guessing - I know next to nothing about pmap. :|
Right, I found out that having page tables in non-cacheable memory does
not really work too well.
I didn't spend too much time with the chipmem solution.
I'm trying now to get the pmap to accept fast RAM. But this is a
different problem.
> But you saw any other exceptions correctly handled on the BPPC? Or is there
> a problem with this type of exception.
At least page faults and alignment exceptions are caught normally.
> I remember I had a similar problem with dcbz many years ago when I started
> working on amigappc. Never found out what happened and I gave up. After
> some months with updated sources the problem was gone...
Until now!
Well, at least disabling the coherency bit is some kind of a workaround.
--jukka
Frank Wille
> Right, I found out that having page tables in non-cacheable memory does
> not really work too well.
Ok.
> I didn't spend too much time with the chipmem solution.
> I'm trying now to get the pmap to accept fast RAM. But this is a
> different problem.
Yes. I fear this will be the only clean solution to make NetBSD/amigappc run
on BPPC boards.
Another big problem left, which I also have to fix for CSPPC, is that DMA
doesn't work well. For example the ahsc(4) A3000 scsi driver will only work
reliably without DMA. Otherwise it slowly corrupts the file system.
--
Frank Wille
Frank Wille
> sorry, it took me some time to test this because I have limited access
> to my A4000T with CSPPC.
> Now I finally managed to try the files and it boots ok. The kernel
> reaches the askroot prompt. Attached is also a poor picture.
> Not sure if this is of any help. But I just wanted to let you know that
> it works so far. Thank you!
Thanks! It's always nice to hear something works. :)
On the screenshot I found two new pieces of hardware which I didn't test
yet: The grfcv3d(4) seems to work fine (assuming a dark background is
correct? grfcv uses a light background). The A4000 SCSI aftsc(4) is
recognized, but we cannot say it it works as long as you have no devices
connected to it.
I detected some minor problems in the "Model:" line. The CPU version and
clock is printed wrong. I fixed that.
Thanks for your test. You may want to try with an amigappc userland now, but
this is not recommended without manually changing the source, as all
amigappc SCSI drivers still have problems with DMA.
Jukka Andberg
Frank Wille wrote:
> > I didn't spend too much time with the chipmem solution.
> > I'm trying now to get the pmap to accept fast RAM. But this is a
> > different problem.
>
> Yes. I fear this will be the only clean solution to make NetBSD/amigappc run
> on BPPC boards.
I got it to boot now. Luckily there were no other problems than pmap
not taking fast memory and that dcbz+memory coherence issue discussed
earlier.
ftp.netbsd.org:/pub/NetBSD/misc/jandberg/amigappc/20101205/bppc-pmap.diff
There is a new option to set maximum address used for pmap allocations.
Another option disables use of dcbz in kernel. And third disables the
use of memory coherence bit bit in page tables.
I think this is going to need some more work. Hopefully a better
solution to the dcbz problem could be found.
ftp.netbsd.org:/pub/NetBSD/misc/jandberg/amigappc/20101205/bppc-identify.diff
Some small changes to have the machine identification printed
correctly. My bppc board has type 'H' and version 7 processor is called
603ev instead of 603e+ by the common powerpc code so we might as well.
I think that this is the only part that I feel confident about
committing at this point. ;)
Also it looks like cpuclock/busclock calculation is a bit off.
This one should have 200Mhz processor instead of 233Mhz.
-- jukka
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.99.41 (GENERIC) #0: Mon Dec 6 16:52:24 EET 2010
jandberg@moth:/tmp/build/amigappc/GENERIC
Model: Amiga 1200 [BlizzardPPC] (603ev v2.1 233 MHz, busclk 66 MHz)
total memory = 32256 KB
avail memory = 26676 KB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0: 603ev (Revision 2.1), ID 0 (primary)
cpu0: HID0 0x90c000<DOZE,DPM,ICE,DCE>, powersave: 1
ser0 at mainbus0: input fifo 512 output fifo 32
par0 at mainbus0
kbd0 at mainbus0: CIA A type Amiga
ms0 at mainbus0
grfcc0 at mainbus0
grf0 at grfcc0: width 640 height 400 colors 4
ite0 at grf0: rows 50 cols 80 repeat at (30/100)s next at (10/100)s has keyboard
fdc0 at mainbus0: dmabuf pa 0x1e1c5c: dmabuf ka 0x1e1c5c
fd0 at fdc0 unit 0: 3.5dd 80 cyl,
atabus0 at wdc0 channel 0
pccard0 at mainbus0
pcmcia0 at pccard0
ne0 at pcmcia0 function 0: <D-Link, DE-660+, A, 0004743118001>
ne0: Ethernet address 00:50:ba:34:63:17
aucc0 at mainbus0
audio0 at aucc0: half duplex, playback, capture
zbus0 at mainbus0
board at zbus0: pa 0xf00c04 man/pro 8512/110 not configured
biomask 800001e netmask 800001e ttymask 800001e
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "mftb" frequency 16666666 Hz quality 100
wd0 at atabus0 drive 0: <OCZ AGILITY>
wd0: drive supports 1-sector PIO transfers, LBA48 addressing
wd0: 30533 MB, 62037 cyl, 16 head, 63 sec, 512 bytes/sect x 62533296 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd1 at atabus0 drive 1: <IBM-DTLA-305020>
wd1: drive supports 16-sector PIO transfers, LBA addressing
wd1: 19623 MB, 39870 cyl, 16 head, 63 sec, 512 bytes/sect x 40188960 sectors
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
4 views configured
Kernelized RAIDframe activated
wd0: wd_flushcache: status=0xa8<ERROR>
root device (default wd1a): wd0f
dump device (default wd0b): wd1b
file system (default generic):
root on wd0f dumps on wd1b
root file system type: ffs
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
init path (default /sbin/init):
init: trying /sbin/init
Radosław Kujawa
> Hi,
>
> Frank Wille wrote:
>>> I didn't spend too much time with the chipmem solution.
>>> I'm trying now to get the pmap to accept fast RAM. But this is a
>>> different problem.
>>
>> Yes. I fear this will be the only clean solution to make NetBSD/amigappc run
>> on BPPC boards.
>
> I got it to boot now. Luckily there were no other problems than pmap
> not taking fast memory and that dcbz+memory coherence issue discussed
> earlier.
Is it possible to build this kernel from CVS HEAD (with attached patches)? I own Blizzard PPC and I am willing to give it a try.
Also, after some hardware related break, I'm back on track with development of SUBWAY driver. It would be great to test it with both m68k and ppc.
Btw. what's the state of Blizzard PPC onboard SCSI driver? It does not exist, right? The chip is already supported by NetBSD, so perhaps it's a matter of writing some glue code...
--
Best regards,
Radosław Kujawa
Jukka Andberg
Great. Yes, you can build the kernel in the usual manner.
Then follow Frank Wille's booting instructions (earlier in this thread).
> Btw. what's the state of Blizzard PPC onboard SCSI driver? It does not exist, right? The chip is already supported by NetBSD, so perhaps it's a matter of writing some glue code...
No idea about that. My BPPC doesn't have the SCSI option.
-- jukka
Frank Wille
> I got it to boot now. Luckily there were no other problems than pmap
> not taking fast memory and that dcbz+memory coherence issue discussed
> earlier.
>
> ftp.netbsd.org:/pub/NetBSD/misc/jandberg/amigappc/20101205/bppc-pmap.diff
> There is a new option to set maximum address used for pmap allocations.
Would be interesting to know why there is a maximum address at all? Maybe
the intention was not to set a maximum address, but to restrict page tables
and pmap allocations to a single 256MB region, because you don't want to
use more than one BAT for it?
> Another option disables use of dcbz in kernel. And third disables the
> use of memory coherence bit bit in page tables.
Perhaps I have to read the whole thread again, but at the moment I don't
understand why this is still needed, since pmap is allowed to use the
on-board Fast RAM now, same as a CSPPC.
And shouldn't dcbz at least work when you disable memory coherency?
It could be interesting if Radek finds some time to test your modifications
and disables the last two options just to see what happens. I see no reason
why it should work differently on a CSPPC than on a BPPC once you have your
pmap allocations in Fast RAM.
I just tested your patches with my CSPPC and can confirm that it does no
harm to it. ;)
> I think this is going to need some more work. Hopefully a better
> solution to the dcbz problem could be found.
Yes. The first option is ok and can be argumented. But the other two are
strange.
>
ftp.netbsd.org:/pub/NetBSD/misc/jandberg/amigappc/20101205/bppc-identify.diff
> Some small changes to have the machine identification printed
> correctly. My bppc board has type 'H' and version 7 processor is called
> 603ev instead of 603e+ by the common powerpc code so we might as well.
> I think that this is the only part that I feel confident about
> committing at this point. ;)
Your confidence is justified. Commit it! :)
> Also it looks like cpuclock/busclock calculation is a bit off.
> This one should have 200Mhz processor instead of 233Mhz.
Have a look at the pll603[] array in amigappc_identify(). There is probably
a wrong entry for your CPU.
Radosław Kujawa
> It could be interesting if Radek finds some time to test your modifications
> and disables the last two options just to see what happens. I see no reason
> why it should work differently on a CSPPC than on a BPPC once you have your
> pmap allocations in Fast RAM.
I'll look into it tomorrow! I successfully booted GENERIC with Jukka's patches.
>
>> Also it looks like cpuclock/busclock calculation is a bit off.
>> This one should have 200Mhz processor instead of 233Mhz.
>
> Have a look at the pll603[] array in amigappc_identify(). There is probably
> a wrong entry for your CPU.
Something's certainly wrong there, I've got a 0 MHz CPU ;).
I had to use a serial console, as gobsdppc starts 15kHz video mode which my monitor does not like (even if I use aga option), but I could only receive data, I couldn't type anything. Serial port tested was with AmigaOS, works just fine.
$ sudo cu --line /dev/tty.usbserial -s 9600 --parity=none --nostop
Connected.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.99.41 (GENERIC) #1: Sun Dec 12 22:50:18 CET 2010
rku...@Radoslaw-Kujawas-MacBook-Pro.local:/Users/rkujawa/repos/NetBSD-current/src/sys/arch/amigappc/compile/obj/GENERIC
Model: Amiga 1200 [BlizzardPPC] (603ev v2.1 0 MHz, busclk 60 MHz)
total memory = 127 MB
avail memory = 119 MB
mainbus0 (root)
cpu0 at mainbus0: 603ev (Revision 2.1), ID 0 (primary)
cpu0: HID0 0x90c000<DOZE,DPM,ICE,DCE>, powersave: 1
ser0 at mainbus0: input fifo 512 output fifo 32
par0 at mainbus0
kbd0 at mainbus0: CIA A type Amiga
ms0 at mainbus0
grfcc0 at mainbus0
grf0 at grfcc0: width 640 height 400 colors 4
ite0 at grf0: rows 50 cols 80 repeat at (30/100)s next at (10/100)s has keyboard
fdc0 at mainbus0: dmabuf pa 0x1e1c84: dmabuf ka 0x1e1c84
fd0 at fdc0 unit 0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec
wdc0 at mainbus0
atabus0 at wdc0 channel 0
pccard0 at mainbus0
pcmcia0 at pccard0
ne0 at pcmcia0 function 0: <TAMARACK, Ethernet, A, 004743118001>
ne0: Ethernet address 00:00:21:2f:6c:ee
aucc0 at mainbus0
audio0 at aucc0: half duplex, playback, capture
zbus0 at mainbus0
board at zbus0: pa 0xf00c38 man/pro 8512/110 not configured
biomask 800001e netmask 800001e ttymask 800001e
wd0 at atabus0 drive 0: <SanDisk SDCFH2-004G>
wd0: 3919 MB, 7964 cyl, 16 head, 63 sec, 512 bytes/sect x 8027712 sectors
4 views configured
root device (default wd0a):
--
Best regards,
Radosław Kujawa
Frank Wille
Rados?aw Kujawa <radosla...@c0ff33.net> wrote:
> > Something's certainly wrong there, I've got a 0 MHz CPU ;).
>
> The 604e User's Manual states that "604e?s PLL_CFG settings are
> compatible with the 603e and the 604, although the supported frequency
> ranges may differ". Values found in 603e User's Manual (rev. 5/98,
> table C-4) and 604e User's Manual (rev. 3/98, table 7-6) are
> different in some cases:
>
> PLL_CFG 603e 604e
> 0000 0 1x 1x
> 0001 1 1x 1x
> 0010 2 1x 7x
> 0011 3 PLL Bypass PLL Bypass
> 0100 4 2x 2x
> 0101 5 2x 6.5x
> 0110 6 no info 2.5x
> 0111 7 no info 4.5x
> 1000 8 3x 3x
> 1001 9 3x 5.5x
> 1010 10 no info 4x
> 1011 11 no info 5x
> 1100 12 4x 1.5x
> 1101 13 no info 6x
> 1110 14 no info 3.5x
> 1111 15 off off
I just checked the latest 603eUM from 2002 (Q2/02 REV 3). Some changes to
your table:
0110 6 2.5x
1001 9 no info
1010 10 4x
1100 12 1.5x
1110 14 3.5x
Those new values all match with the 604e PLLs, but some, like 0010 and 0101,
are still wrong. So you are probably right that we could use the 604e PLL
table for the 603e as well.
> I have a BlizzardPPC upgraded with 603e 300MHz (60MHz bus) and PLL_CFG
> returns 1011, which is absent in 603e datasheet...
Still absent. But it would match the 604e PLL.
Andreas Barth
sorry, but I only have irregular access to my PPC machine.
Recently I could try again with the original kernel. Sorry, I did not check for updates so far.
Here are some more screenshots. I hope they can be seen.
http://u1.ipernity.com/17/85/73/9628573.96ae6ab0.jpg
kernel boots, there is a IDE harddisk type of device on internal IDE and a CD-ROM unit at the A4000T SCSI controller with no medium inserted, looks ok so far
http://u1.ipernity.com/17/85/74/9628574.a30d4a3f.jpg
kernel boots, drives configuration is the same, but now with a medium in the CD-ROM drive, looks not ok, ends up in debug console. On Amiga side, the CD-ROM works ok.
http://u1.ipernity.com/17/85/75/9628575.27a2bbaa.jpg
tried to use the debug console, most things don't seem to work. Should it?
The CV643D shows garbage, when I try to boot netbsd from an fully booted Amiga system, means also the graphics card is already in use.
It only works so far, when I run netbsd before graphics card was initialized by Amiga drivers. Yes, the background is black.
Hope this helps.
Bye,
Andreas
-------- Original-Nachricht --------
> Datum: Mon, 01 Nov 2010 16:04:56 +0100
> Von: Frank Wille <fr...@phoenix.owl.de>
> An: supernobby <super...@gmx.net>
> CC: port-a...@netbsd.org, port-...@netbsd.org
> Betreff: Re: amigappc test kernel for CSPPC and BPPC
> supernobby wrote:
>
> > sorry, it took me some time to test this because I have limited access
> > to my A4000T with CSPPC.
> > Now I finally managed to try the files and it boots ok. The kernel
> > reaches the askroot prompt. Attached is also a poor picture.
> > Not sure if this is of any help. But I just wanted to let you know that
> > it works so far. Thank you!
>
> Thanks! It's always nice to hear something works. :)
>
> On the screenshot I found two new pieces of hardware which I didn't test
> yet: The grfcv3d(4) seems to work fine (assuming a dark background is
> correct? grfcv uses a light background). The A4000 SCSI aftsc(4) is
> recognized, but we cannot say it it works as long as you have no devices
> connected to it.
>
> I detected some minor problems in the "Model:" line. The CPU version and
> clock is printed wrong. I fixed that.
>
> Thanks for your test. You may want to try with an amigappc userland now,
> but
> this is not recommended without manually changing the source, as all
> amigappc SCSI drivers still have problems with DMA.
>
> --
> Frank Wille
>
--
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Radosław Kujawa
> Those new values all match with the 604e PLLs, but some, like 0010 and 0101,
> are still wrong. So you are probably right that we could use the 604e PLL
> table for the 603e as well.
>
Attached patch simplifies amigappc_identify() by merging PLL tables into one. I think that we can safely use values from 604e PLLs, as 603e's 0010 and 0101 corresponds to high multipliers of 604e. Probability that 603e with these PLL_CFGs exist is quite low (and I've never seen 603e faster than 300MHz). Anyway, It works for me, 300MHz CPU is detected OK.
However, my serial console still does not work, and I don't know why. I see no messages related to configuration of timecounters. Maybe that's the problem?
NetBSD 5.99.41 (GENERIC) #2: Mon Dec 13 18:41:38 CET 2010
rku...@Radoslaw-Kujawas-MacBook-Pro.local:/Users/rkujawa/repos/NetBSD-current/src/sys/arch/amigappc/compile/obj/GENERIC
Model: Amiga 1200 [BlizzardPPC] (603ev v2.1 300 MHz, busclk 60 MHz)
Radosław Kujawa
> and disables the last two options just to see what happens. I see no reason
> why it should work differently on a CSPPC than on a BPPC once you have your
> pmap allocations in Fast RAM.
I disabled PMAP_NODCBZ and PMAP_INTERNALMEMLIMIT=0x80000000. Kernel started but I saw literally nothing on a serial console. Maybe something is displayed on a local console, but I can't see it due to 15kHz video mode... Can we fix the aga switch (if it ever worked)? Where can I find gobsdppc source?
--
Best regards,
Radosław Kujawa
Radosław Kujawa
On Dec 13, 2010, at 7:46 PM, Alan Hourihane wrote:
> On Mon, 2010-12-13 at 19:12 +0100, Radosław Kujawa wrote:
>> On Dec 13, 2010, at 1:58 PM, Frank Wille wrote:
>>
>>> Those new values all match with the 604e PLLs, but some, like 0010 and 0101,
>>> are still wrong. So you are probably right that we could use the 604e PLL
>>> table for the 603e as well.
>>>
>>
>> Attached patch simplifies amigappc_identify() by merging PLL tables into one. I think that we can safely use values from 604e PLLs, as 603e's 0010 and 0101 corresponds to high multipliers of 604e. Probability that 603e with these PLL_CFGs exist is quite low (and I've never seen 603e faster than 300MHz). Anyway, It works for me, 300MHz CPU is detected OK.
>
> There are 603e's faster than 300MHz. People have been upgrading the
> BlizzardPPC to 330MHz, and CSPPC to 363MHz.
All these BlizzardPPCs I've seen were 300MHz clocked at 330MHz. In fact, my patch fixed detection for 330MHz boards too. I highly doubt that faster 603e chips were ever manufactured (and that's not the problem here). CSPPC is a completely different story, as there's 604e. PLL table for 604e was always fine. It should even work for a guy who upgraded his CSPPC with 466MHz 604e.
--
Best regards,
Radosław Kujawa
Alan Hourihane
> On Dec 13, 2010, at 7:46 PM, Alan Hourihane wrote:
>
> > On Mon, 2010-12-13 at 19:12 +0100, Radosław Kujawa wrote:
> >>
> >>> are still wrong. So you are probably right that we could use the 604e PLL
> >>> table for the 603e as well.
> >>>
> >>
> >
> > BlizzardPPC to 330MHz, and CSPPC to 363MHz.
>
> All these BlizzardPPCs I've seen were 300MHz clocked at 330MHz. In fact, my patch fixed detection for 330MHz boards too. I highly doubt that faster 603e chips were ever manufactured (and that's not the problem here). CSPPC is a completely different story, as there's 604e. PLL table for 604e was always fine. It should even work for a guy who upgraded his CSPPC with 466MHz 604e.
Cool. Thanks.
Alan.
Jukka Andberg
> Would be interesting to know why there is a maximum address at all? Maybe
> the intention was not to set a maximum address, but to restrict page tables
> and pmap allocations to a single 256MB region, because you don't want to
> use more than one BAT for it?
Could be something like that. I hope to find out the answer before this
is over.
> Perhaps I have to read the whole thread again, but at the moment I don't
> understand why this is still needed, since pmap is allowed to use the
> on-board Fast RAM now, same as a CSPPC.
The combination of dcbz and memory coherence just doesn't seem to work
(causes freeze), even when fast memory is used. No idea why.
> And shouldn't dcbz at least work when you disable memory coherency?
If you mean the pmap_zero_page case, the function turns data address
translation off, which enables memory coherence for everything (page
tables and bats are ignored).
> It could be interesting if Radek finds some time to test your modifications
> and disables the last two options just to see what happens. I see no reason
> why it should work differently on a CSPPC than on a BPPC once you have your
> pmap allocations in Fast RAM.
I guess the hardware is somewhat different.
> I just tested your patches with my CSPPC and can confirm that it does no
> harm to it. ;)
Guess that is something. :)
> > I think this is going to need some more work. Hopefully a better
> > solution to the dcbz problem could be found.
>
> Yes. The first option is ok and can be argumented. But the other two are
> strange.
I'm not too excited about them either.
> > Also it looks like cpuclock/busclock calculation is a bit off.
> > This one should have 200Mhz processor instead of 233Mhz.
> Have a look at the pll603[] array in amigappc_identify(). There is probably
> a wrong entry for your CPU.
PLL_CFG has value 1110, which would indicate multiplier 3.5.
I might have been mistaken about 200MHz. I tried some powerup and
warpos tools and they say that cpuclock is 210 and busclock is 60.
So it would seem that the multiplier is correct but busclock is
guessed wrong. Maybe we need a separate switch for BPPC for busclock
handling. Or maybe we need to implement measuring it like the
comment suggests.
-- jukka
Ignatios Souvatzis
> The combination of dcbz and memory coherence just doesn't seem to work
> (causes freeze), even when fast memory is used. No idea why.
Maybe you should read the PowerPC architecture documents again? In short,
only from memory:
I think dcbz and friends work by operating on cache lines. Not the
memory behind cache lines, but cache lines themselves (so dcbz gets
a cache line for address foo, and zeros it, without first reading it
in - but it is marked dirty and will be written back using normal cache
operation). So they only work, IIRC, with normal cached operation.
I don't know what happens when you try them in coherent mode, and
even if it is defined at all, I don't know if csppc or bzppc hardware
have the necessary sort of access cycles implemented.
(others are, I think: dcbt - tell the memory interface that you'll
operate on address foo soon, and some more? Don't remember right now.)
Vaguely related issue that has to be kept in mind: 68k CAS and on
68020-40 CAS2 don't work in chip memory, because chip memory doesn't
implement read-modify-write cycles.
-is
Radosław Kujawa
On Mon, 13 Dec 2010 23:49:10 +0200, Jukka Andberg <jand...@welho.com>
wrote:
>> > Also it looks like cpuclock/busclock calculation is a bit off.
>> > This one should have 200Mhz processor instead of 233Mhz.
>> Have a look at the pll603[] array in amigappc_identify(). There is probably
>> a wrong entry for your CPU.
>
> warpos tools and they say that cpuclock is 210 and busclock is 60.
>
> So it would seem that the multiplier is correct but busclock is
> guessed wrong. Maybe we need a separate switch for BPPC for busclock
> handling.
It would be just another hack. Method used now in amigappc_identify()
works by reading values stored in P5 ROM. It will not work properly for
cards which were repaired or upgraded with other CPU model than
originally shipped (CSPPC or BPPC makes no difference here). Maybe
that's the case with your card?
> Or maybe we need to implement measuring it like the
> comment suggests.
Yes, that's the way to go. I have a vague idea how should it be
implemented using CIA timer, but it needs working time measurement
functions. The problem is that we set up timebase using bus clock. How
can I measure time flow _before_ timebase is set up? Will functions like
getmicrotime() work in amigappc_identify() ?
--
Best regards,
Radosław Kujawa
--
Frank Wille
>> Or maybe we need to implement measuring it like the
>> comment suggests.
>
> Yes, that's the way to go. I have a vague idea how should it be
> implemented using CIA timer, but it needs working time measurement
> functions. The problem is that we set up timebase using bus clock. How
> can I measure time flow _before_ timebase is set up? Will functions
> like getmicrotime() work in amigappc_identify() ?
No, as the timecounters are not yet set up.
You will use the on-chip timebase or decrementer register to measure the
amount of buscycles passed during a defined amount of time. Example:
- reset CIA timer
- reset timebase
- start CIA timer, running for 1 second
after 1 second (or a shorter value, to reduce the delay during configure()):
- read timebase
The timebase * 4 now represents the number of bus clock cycles during this
time. To load the right value into the CIA timer you can use eclockfreq,
which is passed by the bootloader (or just assume as 709kHz when not set).
Frank Wille
> Attached patch simplifies amigappc_identify() by merging PLL tables
> into one. I think that we can safely use values from 604e PLLs, as
> 603e's 0010 and 0101 corresponds to high multipliers of 604e.
For me the patch is ok. But I have no BPPC, so Jukka has the last word! :)
Frank Wille
> http://u1.ipernity.com/17/85/74/9628574.a30d4a3f.jpg
>
> kernel boots, drives configuration is the same, but now with a medium
> in the CD-ROM drive, looks not ok, ends up in debug console. On Amiga
> side, the CD-ROM works ok.
There are known problems with DMA on amigappc. Here the hardware was found
to be in an unknown state after an interrupt. When you recompile a kernel
without DEBUG and without DDB in the config file it will continue running,
but probably without success. Maybe afsc.c also needs some membarriers,
which I already inserted into ahsc.c.
Better would be to edit sys/arch/amiga/dev/siop.c and change line 131 to
int siop_no_dma = 1;
On my A3000 the same driver works ok without DMA.
> http://u1.ipernity.com/17/85/75/9628575.27a2bbaa.jpg
>
> tried to use the debug console, most things don't seem to work. Should
> it?
Yes. Functions like ps and show map do work here. Maybe something was
trashed?
Does ddb work when you don't insert a CD and boot with "askroot", then enter
ddb manually by typing "ddb" for the root device?
> The CV643D shows garbage, when I try to boot netbsd from an fully
> booted Amiga system, means also the graphics card is already in use. It
> only works so far, when I run netbsd before graphics card was
> initialized by Amiga drivers. Yes, the background is black.
I have never seen a CV643D. How does it behave under NetBSD/amiga (68k)?
Should be the same.
The current gobsdppc-solution is just temporary. When amigappc ever becomes
a usable port we would install a boot-block for booting, as with amiga68k.
Then this problem doesn't matter.
Radosław Kujawa
On Dec 18, 2010, at 5:16 PM, Frank Wille wrote:
> Radoslaw Kujawa wrote:
>> Yes, that's the way to go. I have a vague idea how should it be
>> implemented using CIA timer, but it needs working time measurement
>> functions. The problem is that we set up timebase using bus clock. How
>> can I measure time flow _before_ timebase is set up? Will functions
>> like getmicrotime() work in amigappc_identify() ?
>
> No, as the timecounters are not yet set up.
So I thought.
> You will use the on-chip timebase or decrementer register to measure the
> amount of buscycles passed during a defined amount of time.
Looks like I have to do the mftb asm magic. I checked arch/powerpc/ and it seems we don't have any generic functions to access timebase register.
> Example:
>
> - reset CIA timer
> - reset timebase
> - start CIA timer, running for 1 second
> after 1 second (or a shorter value, to reduce the delay during configure()):
> - read timebase
Sounds good, but... how does one reset the timebase? I thought that it's only possible to read from it.
> The timebase * 4 now represents the number of bus clock cycles during this
> time.
Does always timebase frequency = busclock/4 ? Is it PowerUP specific? I heard that on (at least some) Macs timebase is set from external clock.
> To load the right value into the CIA timer you can use eclockfreq,
> which is passed by the bootloader (or just assume as 709kHz when not set).
eclockfreq is 709kHz only on PAL models. Should not be problematic, as bootloader always passes the correct value.
Out of curiosity: Is it possible to use PMC instead of timebase register to achieve the same thing? Anyway, PMC is available only on 604 and newer CPUs.
Btw. today I cvs up'ed the source and GENERIC kernel does not boot anymore (even without my pll.patch, so I suppose that's not the problem). Can anyone confirm this? :(
--
Best regards,
Radosław Kujawa
Frank Wille
>> You will use the on-chip timebase or decrementer register to measure
>> the amount of buscycles passed during a defined amount of time.
>
> Looks like I have to do the mftb asm magic. I checked arch/powerpc/ and
> it seems we don't have any generic functions to access timebase
> register.
Yes. Usually you will access the timebase only in few situations, until
timecounter(9) is set up.
>> - reset CIA timer
>> - reset timebase
>> - start CIA timer, running for 1 second
>> after 1 second (or a shorter value, to reduce the delay during
>> configure()): - read timebase
>
> Sounds good, but... how does one reset the timebase? I thought that
> it's only possible to read from it.
In user mode. But in OEA mode you can also write to it.
>> The timebase * 4 now represents the number of bus clock cycles during
>> this time.
>
> Does always timebase frequency = busclock/4 ?
Probably. I have seen more ports than amigappc using this equation.
> Is it PowerUP specific?
Using a CIA-timer definitely is. So it doesn't matter. :)
> eclockfreq is 709kHz only on PAL models. Should not be problematic, as
> bootloader always passes the correct value.
True.
> Out of curiosity: Is it possible to use PMC instead of timebase
> register to achieve the same thing?
Sure. It is used in powerpc/oea/cpu_subr.c to determine the clock frequency
for some CPUs.
> Anyway, PMC is available only on 604 and newer CPUs.
Which disqualifies this method here.
> Btw. today I cvs up'ed the source and GENERIC kernel does not boot
> anymore (even without my pll.patch, so I suppose that's not the
> problem). Can anyone confirm this? :(
Fortunately (or unfortunately?) not. I have just updated an hour ago and a
generic kernel still boots on my CSPPC.
Do not update while in the middle of some development! ;)
Jukka Andberg
> Radoslaw Kujawa wrote:
> > Attached patch simplifies amigappc_identify() by merging PLL tables
> > into one. I think that we can safely use values from 604e PLLs, as
> > 603e's 0010 and 0101 corresponds to high multipliers of 604e.
>
> For me the patch is ok. But I have no BPPC, so Jukka has the last word! :)
I think it's still your show. My knowledge about powerpc arch is quite
limited.
I tested the patch and it didn't hurt in my case. But I don't know if
it's correct or not to merge those two cases that differ between 603e
and 604e.
--jukka
Jukka Andberg
> Does always timebase frequency = busclock/4 ? Is it PowerUP specific? I heard that on (at least some) Macs timebase is set from external clock.
603e user's manual (section 1.1.7.2) has some info on this.
> Btw. today I cvs up'ed the source and GENERIC kernel does not boot anymore (even without my pll.patch, so I suppose that's not the problem). Can anyone confirm this? :(
It works for me with this morning's sources. Even with your patch.
I can however confirm your earlier reports that serial port is not
fully working.
--jukka
Frank Wille
>> For me the patch is ok. But I have no BPPC, so Jukka has the last
>> word! :)
>
> I think it's still your show. My knowledge about powerpc arch is quite
> limited.
>
> I tested the patch and it didn't hurt in my case. But I don't know if
> it's correct or not to merge those two cases that differ between 603e
> and 604e.
The 604e manual states the PLL_CFGs are the same and this indeed seems to be
the case.
Ok, I committed the patch. Thanks.
Frank Wille
> I can however confirm your earlier reports that serial port is not
> fully working.
Yes, confirmed. Receiving does not work and freezes the machine.
I was calling the wrong interrupt handler for an RBF interrupt. It should
have been ser_fastint() instead of ser_intr().
Fixed and committed (sys/arch/amigappc/amigappc/machdep.c). Works.
--
Frank Wille
Radosław Kujawa
On Sat, 18 Dec 2010 22:58:31 +0100, Frank Wille <fr...@phoenix.owl.de>
wrote:
> Radoslaw Kujawa wrote:
>>
>> Looks like I have to do the mftb asm magic. I checked arch/powerpc/ and
>> it seems we don't have any generic functions to access timebase
>> register.
>
> Yes. Usually you will access the timebase only in few situations, until
> timecounter(9) is set up.
At first I read the datasheets, and tried to implement it myself. I
came up with following code:
static uint64_t
amigappc_gettimebase(void)
{
uint64_t tbr;
register uint32_t tbu, tbl;
tbu = 0; tbl = 0;
/* TBR register contains 64-bit value, which must
be read as two 32-bit values on non 64-bit PowerPC */
__asm ("mftbl %0; mftbu %1" : "=r"(tbl), "=r"(tbu));
return (uint64_t)tbu << 32 | tbl;
}
Suspicious about my fast success, I looked again at the arch/powerpc
source, and after all, I've found mftb() in arch/powerpc/include/cpu.h.
If you read it, you'll see it's more complicated than my example. What I
didn't understand is why upper part of timebase is read twice, then
compared, then everything is looped if it's different. I googled for
some other implementations, and everybody is doing it that way. Of
course, nothing in "PowerPC Virtual Environment Architecture" or
"PowerPC Operationg Environment Architecture" document justifies the
need to execute mftbu twice.
I dug out really outdated (dated 1997) "PowerPC Microprocessor Family:
The Programming Environments For 32-Bit Microprocessors". Section "2.2.1
Reading the Time Base" states that: "Because of the possibility of a
carry from TBL to TBU occurring between reads of the TBL and TBU (...)
comparison and loop are necessary to ensure that a consistent pair of
values has been obtained".
Why is this information absent from newer documents (rhetorical
question)? Maybe it was needed only on older CPUs, maybe IBM already
forgot about 32-bit CPUs. Nevermind, I'll just use mftb() as implemented
in cpu.h. Just a "fun" fact.
>> Sounds good, but... how does one reset the timebase? I thought that
>> it's only possible to read from it.
>
> In user mode. But in OEA mode you can also write to it.
Great, looks like it's possible with mtspr instruction.
> Fortunately (or unfortunately?) not. I have just updated an hour ago and a
> generic kernel still boots on my CSPPC.
>
> Do not update while in the middle of some development! ;)
Yes, after all, problem was with my tree. Checking out everything again
and then merging by hand fixed it, now kernel boots fine.
--
Best regards,
Radosław Kujawa
--
Frank Wille
> [..mftb..]
> I didn't understand is why upper part of timebase is read twice, then
> compared, then everything is looped if it's different. I googled for
> some other implementations, and everybody is doing it that way. [...]
>
> I dug out really outdated (dated 1997) "PowerPC Microprocessor Family:
> The Programming Environments For 32-Bit Microprocessors". Section
> "2.2.1 Reading the Time Base" states that: "Because of the possibility
> of a carry from TBL to TBU occurring between reads of the TBL and TBU
> (...) comparison and loop are necessary to ensure that a consistent
> pair of values has been obtained".
Exactly. :)
> Why is this information absent from newer documents (rhetorical
> question)? Maybe it was needed only on older CPUs, maybe IBM already
> forgot about 32-bit CPUs.
Maybe because it should be clear that you cannot safely read hardware time
counter registers with multiple read operations?
It would be the same with the Amiga CIA timers, which have a low and a
high-byte.
> Yes, after all, problem was with my tree. Checking out everything again
> and then merging by hand fixed it, now kernel boots fine.
Ok.
--
Frank Wille
Ignatios Souvatzis
> (...)
> The 604e User's Manual states that "604e?s PLL_CFG settings are (...)
I approved this (as the mailing list software thought some characters
in it were suspicious) a few minutes ago for completeness, as I
wasn't sure I approved it back then. People with threading mailreaders
like mutt will have it sorted into the right place; you others,
please accept my apologies for the inconvenience caused.
Regards,
-is