Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Work on PCI support :-)

10 views
Skip to first unread message

Radosław Kujawa

unread,
May 28, 2011, 9:40:09 PM5/28/11
to
Hi guys.

I'll just leave this dmesg here - I'm too sleepy after 2-day hacking marathon...

Connected.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011
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.45 (A3K_P5PB_DEV) #25: Sun May 29 03:18:40 CEST 2011
rku...@Radoslaw-Kujawas-MacBook-Pro.local:/Users/rkujawa/repos/NetBSD-current/src/sys/arch/amiga/compile/obj/A3K_P5PB_DEV
Amiga 3000 (68060 rev.1 CPU/MMU/FPU)
total memory = 127 MB
avail memory = 123 MB
memory segment 0 at 08000000 size 07f80000
memory segment 1 at 07c00000 size 00400000
memory segment 2 at 40000000 size 08000000
memory segment 3 at 00000000 size 00200000
sysctl_createv: sysctl_create(no_sa_support) returned 22
mainbus0 (root)
clock0 at mainbus0: CIA B system hz 100 hardware hz 709379
orig value: delaydivisor=100, amiga_clk_interval=7093
Calibrating delay loop...
diff 217 us, new divisor 22/1024 us
diff 958 us, new divisor 21/1024 us
diff 1005 us, new divisor 21/1024 us
a34kbbc0 at mainbus0
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 0x1e4bf0: dmabuf ka 0x45cbf0
fd0 at fdc0 unit 0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec
ahsc0 at mainbus0
scsibus0 at ahsc0: 8 targets, 8 luns per target
aucc0 at mainbus0
audio0 at aucc0: half duplex, playback, capture
zbus0 at mainbus0: i/o size 0x03052000
nextkva: 0x167c000, want pa 0x50000000, size 16777216
board at zbus0: pa 0x50000000 man/pro 3643/16 not configured
board at zbus0: pa 0xe90000 man/pro 3643/19 not configured
xsurf at zbus0: pa 0xea0000 man/pro 4626/23 not configured
nextkva: 0x267c000, want pa 0x51000000, size 16777216
board at zbus0: pa 0x51000000 man/pro 2206/62 not configured
cbiiisc0 at zbus0 pa 0xf01060 man/pro 8512/100
cbiiisc0: no SCSI termination, host adapter deactivated.
scsibus1 at cbiiisc0: 0 targets, 8 luns per target
nextkva: 0x267d000, want pa 0xfffe0000, size 4096
matched by Zorro ID 8512, 101
p5pb0 at zbus0 pa 0xfffe0000 man/pro 8512/101
nextkva: 0x26be000, want pa 0xfffa0000, size 266240
pci0 at p5pb0 bus 0
Texas Instruments TVP4020 Permedia 2 (miscellaneous display, revision 0x01) at pci0 dev 0 function 0: PCI configuration registers:
Common header:
0x00: 0x3d07104c 0x02800007 0x03800001 0x00000000

Vendor Name: Texas Instruments (0x104c)
Device Name: TVP4020 Permedia 2 (0x3d07)
Command register: 0x0007
I/O space accesses: on
Memory space accesses: on
Bus mastering: on
Special cycles: off
MWI transactions: off
Palette snooping: off
Parity error checking: off
Address/data stepping: off
System error (SERR): off
Fast back-to-back transactions: off
Interrupt disable: off
Status register: 0x0280
Interrupt status: inactive
Capability List support: off
66 MHz capable: off
User Definable Features (UDF) support: off
Fast back-to-back capable: on
Data parity error detected: off
DEVSEL timing: medium (0x1)
Slave signaled Target Abort: off
Master received Target Abort: off
Master received Master Abort: off
Asserted System Error (SERR): off
Parity error detected: off
Class Name: display (0x03)
Subclass Name: miscellaneous (0x80)
Interface: 0x00
Revision ID: 0x01
BIST: 0x00
Header Type: 0x00 (0x00)
Latency Timer: 0x00
Cache Line Size: 0x00

Type 0 ("normal" device) header:
0x10: 0xe1000000 0xe0000000 0xe0800000 0x00000000
0x20: 0x00000000 0x00000000 0x00000000 0xe4e4e4e4
0x30: 0xffff0001 0x00000000 0x00000000 0xc0c00100

panic: bus_space_write_4 not implemented
Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x6: unlk a6
db>


Current source of the driver: http://nyopaste.ath.cx/n/KMt0o

--
Best regards,
Radoslaw Kujawa


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Christos Zoulas

unread,
May 28, 2011, 11:03:24 PM5/28/11
to
In article <B02A3FF1-226A-4E3C...@c0ff33.net>,

RadosĹ aw Kujawa <radosla...@c0ff33.net> wrote:
>Hi guys.
>
>I'll just leave this dmesg here - I'm too sleepy after 2-day hacking marathon...

Nice!

christos

Frank Wille

unread,
May 29, 2011, 4:53:39 AM5/29/11
to
Radoslaw Kujawa wrote:

> p5pb0 at zbus0 pa 0xfffe0000 man/pro 8512/101
> nextkva: 0x26be000, want pa 0xfffa0000, size 266240
> pci0 at p5pb0 bus 0
> Texas Instruments TVP4020 Permedia 2 (miscellaneous display, revision
> 0x01) at pci0 dev 0 function 0: PCI configuration registers: Common
> header: 0x00: 0x3d07104c 0x02800007 0x03800001 0x00000000

That's great! Congratulations!


> panic: bus_space_write_4 not implemented
> Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x6: unlk
> a6

Now we are only missing the 32-bit bus-space functions in simple_busfuncs.c.
This had already been a problem in the past, when using 32-bit
Cardbus/PCMCIA cards.

--
Frank Wille

Radosław Kujawa

unread,
May 29, 2011, 5:06:26 AM5/29/11
to
Hi again.

As you have already (probably) seen, I'm working on a driver for PCI bus present on CyberVisionPPC and BlizzardVisionPPC.

The basics are working - It is now possible to access the configuration registers through PCI MI code, but I'm still facing a few problems, which I am not sure how to solve:

- Implementation of bus_space_read_4 and write_4 is missing. It is used often in the PCI MI code, and most importantly in pm2fb.c. Ofcourse the only proper solution is to implement the missing functions functions, but I feel a bit lost with all these dbsdr/dbsdw/dbsm/dbss/bsr/bsw/bswm/bsrm/wtf...
- PCI MI code needs bus_space_mmap. For now I've just faked it, but it should be implemented to allow framebuffer mmaping. Not sure how to do it. I've looked atari's implementation and it seems not that complicated, but not don't know if it will work the same way on amiga port.
- PCI MI code needs bus_dma support, for now I've just included m68k/bus_dma.h in pci_machdep.h.
- CVPPC/BVPPC are very tricky to detect. Newer versions of the firmware autoconfigure the card like this:

Board (phase 5): Prod=8512/101($2140/$65) (@$FFFE0000 64K)
Board (phase 5): Prod=8512/101($2140/$65) (@$FFFA0000 64K)
Board (phase 5): Prod=8512/101($2140/$65) (@$FFFC0000 128K)
Board (phase 5): Prod=8512/101($2140/$65)
(@$E0000000, size RESERVED, subsize same)
Board (phase 5): Prod=8512/101($2140/$65)
(@$E0800000, size RESERVED, subsize same)
Board (phase 5): Prod=8512/101($2140/$65) (@$E1000000 128K)

The same vendor/product ID is used 6 times. Also, it is possible that the last entry is different on some configurations (EF000000 instead of E1000000). Unfortunately, some firmware versions do not create autoconfig entries at all.

- The above leads to another problem. PCI device resources are configured in the E0000000 - EFFFFFFF area. Doing VA=PA mapping of this space immediately leads to a panic, due to running out of Zorro I/O address space. I suspect that I should create an extent(9) for this space and not map it directly?

- VA=PA mapping of FFFA0000-FFFE1000 space is now done with zbusmap, which is kinda wrong, because I can't really use information from autoconfig. Temporarily I had to rip zbusmap out of zbus.c and make it available to both zbus.c and p5pb.c. I really dislike this solution.

- The pm2fb needs prop entries like "width", "height", "depth", "is_console". It is possible to fake these entries in p5pb driver, or modify the pm2fb to support operation when these entries are absent. I didn't look at pm2fb too closely yet.

- I was not able to figure out how interrupt stuff works. Fortunately, it seems that pm2fb does not need it. Same with DMA support, hardware is probably capable of doing DMA.

Any suggestions on how to deal with these problems would be appreciated. All information related to programming the Phase5 PCI bridge was obtained thorugh reverse engineering, so I may be wrong here and there.

--
Best regards,
Radosław Kujawa

Radosław Kujawa

unread,
May 30, 2011, 6:40:18 AM5/30/11
to

On May 29, 2011, at 10:53 AM, Frank Wille wrote:

> Now we are only missing the 32-bit bus-space functions in simple_busfuncs.c.
> This had already been a problem in the past, when using 32-bit
> Cardbus/PCMCIA cards.

I've added the missing bus_space functions. Does this diff make sense? Simple read and write functions are probably OK, at least PCI code does work with these. The rest is untested yet...

bus_space_4.diff

Frank Wille

unread,
May 30, 2011, 7:45:35 AM5/30/11
to
On Mon, 30 May 2011 12:40:18 +0200
Rados?aw Kujawa <radosla...@c0ff33.net> wrote:

> On May 29, 2011, at 10:53 AM, Frank Wille wrote:
>

> > Now we are only missing the 32-bit bus-space functions in
> > simple_busfuncs.c. This had already been a problem in the past,
> > when using 32-bit Cardbus/PCMCIA cards.
>

> I've added the missing bus_space functions. Does this diff make
> sense?

Looks good to me. As long as Ignatios or Michael don't object. ;)

I would have tried that myself long ago, but I have no hardware which
needs these 32-bit functions.


> Simple read and write functions are probably OK, at least PCI
> code does work with these. The rest is untested yet...

When it works for you and doesn't break anything then it is fine.
Future problems can be fixed when they occur.

Unfortunately I cannot help you much with your catalog of questions in
your previous posting. The properties for the pm2fb driver are not a big
problem. Just create them with the typical default settings (640x480).

bus_space_mmap and bus_dma is something I didn't completely understand
either, to be able to implement it.

I would favour common bus_space functions in the m68k directory, which can
be used by all 68k ports, similar to those in powerpc. I'm not sure why
each port needs to do their own set of functions.

--
Frank Wille

Radosław Kujawa

unread,
May 30, 2011, 5:13:40 PM5/30/11
to
Hi!

On May 30, 2011, at 1:45 PM, Frank Wille wrote:
> Unfortunately I cannot help you much with your catalog of questions in
> your previous posting.

You're already helping a lot! :-)

I've moved a bit forward, to the point where pm2fb is even trying to attach. Unfortunately, I've encountered a non-trivial problem with bus_space_map, or rather, the way it is used on amiga.

In p5pb driver I created a bus_space_tag for a PCI memory area like this:

sc->pci_mem_area.base = (bus_addr_t) zbusmap(
(void *) 0xe0000000, 0x02000000);
sc->pci_mem_area.absm = &amiga_bus_stride_1;

This is area is mapped into KVA at 0x268a000, all seems to be cool at this point. The tag is passed on to MI code.

During pm2fb attachment, PCI MI code tries to map memory regions using information acquired from BARs. Permedia 2 registers are located at PA 0xe1000000, 128kB wide. PCI MI code (pci_mapreg_submap in pci_map.c) calls bus_space_map like this:

bus_space_map(pci_mem_area, 0xe1000000, 20000 0);

Where pci_mem_area is the exact same tag I created earlier in p5pb. That's no good, because pci_mem_area is already pointing to 0x268a000, which is mapped PA 0xe0000000. So, if I understand correctly, any read or write using handle created by this bus_space_map is hitting 0x268a000 + 0xe1000000, which leads to a MMU fault.

In all amiga drivers I've seen, the second argument to bus_space_map was always an offset (from base specified in MD bus_space_tag).

p5pb0 at zbus0 pa 0xfffe0000 man/pro 8512/101

nextkva: 0x268a000, want pa 0xfffa0000, size 266240, avail 84221952
nextkva: 0x468a000, want pa 0xe0000000, size 33554432, avail 84221952
mapped fffa0000 -> 2649000, e0000000 -> 268a000


pci0 at p5pb0 bus 0

pm2fb0 at pci0 dev 0 function 0: PCI configuration registers:

Base address register at 0x10
type: 32-bit nonprefetchable memory
base: 0xe1000000, size: 0x00020000
Base address register at 0x14
type: 32-bit nonprefetchable memory
base: 0xe0000000, size: 0x00800000
Base address register at 0x18
type: 32-bit nonprefetchable memory
base: 0xe0800000, size: 0x00800000
Base address register at 0x1c
not implemented(?)
Base address register at 0x20
not implemented(?)
Base address register at 0x24
not implemented(?)
Cardbus CIS Pointer: 0x00000000
Subsystem vendor ID: 0xe4e4
Subsystem ID: 0xe4e4
Expansion ROM Base Address: 0xffff0001
Reserved @ 0x34: 0x00000000
Reserved @ 0x38: 0x00000000
Maximum Latency: 0xc0
Minimum Grant: 0xc0
Interrupt pin: 0x01 (pin A)
Interrupt line: 0x00

Device-dependent header:
0x40: 0x00000000 0x00000000 0x00000000 0x00000000
0x50: 0x00000000 0x00000000 0x00000000 0x00000000
0x60: 0x00000000 0x00000000 0x00000000 0x00000000
0x70: 0x00000000 0x00000000 0x00000000 0x00000000
0x80: 0x00000000 0x00000000 0x00000000 0x00000000
0x90: 0x00000000 0x00000000 0x00000000 0x00000000
0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
0xb0: 0x00000000 0x00000000 0x00000000 0x00000000
0xc0: 0x00000000 0x00000000 0x00000000 0x00000000
0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
0xf0: 0x00000000 0x00000000 0x00000000 0x00000000

Don't know how to pretty-print device-dependent header.

Texas Instruments TVP4020 Permedia 2 (miscellaneous display, revision 0x01) at ? dev 0 function 0 (intrswiz 0, intrpin 0x1, i/o off, mem on, no quirks): Texas Instruments TVP4020 Permedia 2
doing bus_space_map in PCI MI: tag 0xfbdda0c (tag->base: 268a000) base e1000000 maxsize 20000 busflags 0
pm2fb0: 8 MB aperture at 0xe0000000
uvm_fault(0x1abc40, 0xe368a000, 0x1) -> 0xe
type 8, code [mmu,,ssw]: 1051000
trap type 8, code = 1051000, v = e368a018
pid = 0, lid = 1, pc = 0000FC62, ps = 2708, sfc = 1, dfc = 1
Registers:
0 1 2 3 4 5 6 7
dreg: 00000000 0EAC2700 00000008 E0000000 0FBEB230 0FBEADA0 0FBEADCC 00000000
areg: E368A000 00000018 0FBEAC30 0FBEAC30 0FBEAC50 000D44D0 002217DC 1DFFFFFC

Kernel stack (0022165C):
22165C: 000FD47C 00221788 00000080 0018BA30 00000008 01051000 E368A018 0000000E
22167C: 002216F8 000FD8FE 00000008 01051000 E368A018 00221788 00000008 E368A018
22169C: 01051000 00000000 00000000 00000000 0019E310 0019DB80 00221788 0021E000
2216BC: 00000000 00000000 001AF4D0 00000001 00000000 00000000 00000000 00000001
2216DC: 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00221770
2216FC: 000FDC78 00000008 01051000 E368A018 00221788 0019DB80 00000000 00000000
22171C: 00000008 E0000000 0FBEB230 0FBEADA0 0FBEADCC 0FBEAC30 0FBEAC30 0FBEAC50
22173C: 000D44D0 00000001 00000000 00000000 00000000 00000000 00000000 00000000
22175C: 00000008 00000000 00000000 00000000 00000000 002217DC 00002060 00221788
22177C: 00000008 01051000 E368A018 00000000 0EAC2700 00000008 E0000000 0FBEB230
22179C: 0FBEADA0 0FBEADCC 00000000 E368A000 00000018 0FBEAC30 0FBEAC30 0FBEAC50
2217BC: 000D44D0 002217DC 1DFFFFFC 00000000 27080000 FC624008 E368A018 01051000
2217DC: 002217F0 000AE0FA E368A000 00000018 000AE0DA 0022193C 000AEEB0 0FBEAC30
2217FC: 0FBDDE1C 0FBDDE00 002219E4 FFFFFFE3 02800007 00199BC4 0015FB74 00000000
22181C: 0FBEB230 54657861 7320496E 73747275 6D656E74 73205456 50343032 30205065
22183C: 726D6564 69612032 000A9D82 54657861 7320496E 73747275 6D656E74 73205456
panic: MMU fault


Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x6: unlk a6

--
Best regards,
Radosław Kujawa

Radosław Kujawa

unread,
May 31, 2011, 7:03:12 AM5/31/11
to

On May 30, 2011, at 11:13 PM, Radosław Kujawa wrote:

> Where pci_mem_area is the exact same tag I created earlier in p5pb. That's no good, because pci_mem_area is already pointing to 0x268a000, which is mapped PA 0xe0000000. So, if I understand correctly, any read or write using handle created by this bus_space_map is hitting 0x268a000 + 0xe1000000, which leads to a MMU fault.

Ok, I've created workaround, by implementing another absm with special bus_space_map, that operates on absolute PA address. Also I've had to implement swab32'ing absm methods (to access the device little-endian registers).

The p5pb driver sort-of-works now and Permedia framebuffer driver is able to attach properly.

Still, it does not work as a console, the kernel just dies without a word, somewhere in wsdisplay_cnattach. Probably during/just after setting wsdisplay's cn_tab. Otherwise it works fine:

Connected.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011
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.45 (A3K_P5PB_DEV) #70: Tue May 31 12:45:19 CEST 2011


rku...@Radoslaw-Kujawas-MacBook-Pro.local:/Users/rkujawa/repos/NetBSD-current/src/sys/arch/amiga/compile/obj/A3K_P5PB_DEV
Amiga 3000 (68060 rev.1 CPU/MMU/FPU)
total memory = 127 MB
avail memory = 123 MB
memory segment 0 at 08000000 size 07f80000
memory segment 1 at 07c00000 size 00400000
memory segment 2 at 40000000 size 08000000
memory segment 3 at 00000000 size 00200000
sysctl_createv: sysctl_create(no_sa_support) returned 22
mainbus0 (root)
clock0 at mainbus0: CIA B system hz 100 hardware hz 709379

orig value: delaydivisor=12, amiga_clk_interval=7093
Calibrating delay loop...
diff 1755 us, new divisor 21/1024 us


diff 1005 us, new divisor 21/1024 us
diff 1005 us, new divisor 21/1024 us
a34kbbc0 at mainbus0
ser0 at mainbus0: input fifo 512 output fifo 32
par0 at mainbus0
kbd0 at mainbus0: CIA A type Amiga

wskbd0 at kbd0 mux 1
ms0 at mainbus0
wsmouse0 at ms0 mux 0
wsmouse1 at ms0 mux 0
fdc0 at mainbus0trying to get pa for va: 0x46c000: dmabuf pa 0x1f8000: dmabuf ka 0x46c000


fd0 at fdc0 unit 0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec
ahsc0 at mainbus0
scsibus0 at ahsc0: 8 targets, 8 luns per target
aucc0 at mainbus0
audio0 at aucc0: half duplex, playback, capture

zbus0 at mainbus0: i/o size 0x06552000
nextkva: 0x1678000, want pa 0x50000000, size 16777216, avail 106242048


board at zbus0: pa 0x50000000 man/pro 3643/16 not configured
board at zbus0: pa 0xe90000 man/pro 3643/19 not configured
xsurf at zbus0: pa 0xea0000 man/pro 4626/23 not configured

nextkva: 0x2678000, want pa 0x51000000, size 16777216, avail 106242048


board at zbus0: pa 0x51000000 man/pro 2206/62 not configured
cbiiisc0 at zbus0 pa 0xf01060 man/pro 8512/100

trying to get pa for va: 0x1acf58cbiiisc0: no SCSI termination, host adapter deactivated.


scsibus1 at cbiiisc0: 0 targets, 8 luns per target

nextkva: 0x2679000, want pa 0xfffe0000, size 4096, avail 106242048


matched by Zorro ID 8512, 101
p5pb0 at zbus0 pa 0xfffe0000 man/pro 8512/101

nextkva: 0x26ba000, want pa 0xfffa0000, size 266240, avail 106242048
nextkva: 0x46ba000, want pa 0xe0000000, size 33554432, avail 106242048
mapped fffa0000 -> 2679000, e0000000 -> 26ba000


pci0 at p5pb0 bus 0

pm2fb0 at pci0 dev 0 function 0: PCI configuration registers:

Base address register at 0x10

Texas Instruments TVP4020 Permedia 2 (miscellaneous display, revision 0x01) at ? dev 0 function 0 (intrswiz 0, intrpin 0x1, i/o off, mem on, no quirks): Texas Instruments TVP4020 Permedia 2
bsr4: e0000000 from 0x2699014
bsr4: ff800000 from 0x2699014
bsr4: e1000000 from 0x2699010
bsr4: fffe0000 from 0x2699010
doing bus space map: tag 0x2391130c base e1000000 maxsize 20000 busflags 0bus space tag->base: 26ba000
trying to get pa for va: 0x26ba000
welcome to bsm_absolute, tag->base=26ba000, pa=e0000000, wanted address=e1000000
returning 0x24f788, PA 36ba000
trying to get pa for va: 0x36ba000
sanity check with kvtop: e1000000


pm2fb0: 8 MB aperture at 0xe0000000

bsr4_swap: 2010000 from 0x36ba018
bsr4_swap: 0 from 0x36ba020
bsr4_swap: 1000000 from 0x36ba020
bsr4_swap: 88010000 from 0x36bc000
bsr4_swap: 2010000 from 0x36ba018
bsr4_swap: 2010000 from 0x36ba018
bsr4_swap: 2010000 from 0x36ba018
bsr4_swap: e4000000 from 0x36c2a80
bsr4_swap: 2010000 from 0x36ba018
bsr4_swap: 2010000 from 0x36ba018
bsr4_swap: 0 from 0x36ba020
bsr4_swap: 1000000 from 0x36ba020
bsr4_swap: 88010000 from 0x36bc000
wsdisplay at pm2fb0 not configured
board at zbus0: pa 0xfffa0000 man/pro 8512/101 not configured
board at zbus0: pa 0xfffc0000 man/pro 8512/101 not configured
board at zbus0: pa 0xe0000000 man/pro 8512/101 not configured
board at zbus0: pa 0xe0800000 man/pro 8512/101 not configured
board at zbus0: pa 0xe1000000 man/pro 8512/101 not configured
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
4 views configured
root device:

Best regards,
Radosław Kujawa

Frank Wille

unread,
May 31, 2011, 7:48:43 AM5/31/11
to
On Mon, 30 May 2011 23:13:40 +0200
Rados?aw Kujawa <radosla...@c0ff33.net> wrote:

> In p5pb driver I created a bus_space_tag for a PCI memory area like
> this:
>
> sc->pci_mem_area.base = (bus_addr_t) zbusmap(
> (void *) 0xe0000000, 0x02000000);
> sc->pci_mem_area.absm = &amiga_bus_stride_1;
>
> This is area is mapped into KVA at 0x268a000, all seems to be cool at
> this point. The tag is passed on to MI code.

Was this memory range considered in amiga_init.c, and added to ZBUSAVAIL?
Otherwise you can get a problem running out of KVA space.


> During pm2fb attachment, PCI MI code tries to map memory regions
> using information acquired from BARs. Permedia 2 registers are
> located at PA 0xe1000000, 128kB wide. PCI MI code (pci_mapreg_submap
> in pci_map.c) calls bus_space_map like this:
>
> bus_space_map(pci_mem_area, 0xe1000000, 20000 0);
>
> Where pci_mem_area is the exact same tag I created earlier in p5pb.

That's normal.


> That's no good, because pci_mem_area is already pointing to
> 0x268a000, which is mapped PA 0xe0000000. So, if I understand
> correctly, any read or write using handle created by this
> bus_space_map is hitting 0x268a000 + 0xe1000000, which leads to a MMU
> fault.

True. Your PCI bus space doesn't work that way.


> In all amiga drivers I've seen, the second argument to bus_space_map
> was always an offset (from base specified in MD bus_space_tag).

AFAIK this is absolutely normal. When calling bus_space_map() you will
always pass an offset, relative to the start address of your bus.

0xe1000000 is also an offset, because the PCI bus usually starts at 0x00000000
and is 4GB large. So correct would have been to define your PCI bus space tag
with a base of 0. But the problem is that you cannot map 4GB of memory.


There may be several solutions to this problem. You could add a new flag
or offset field to our bus space tag to handle this special situation.
Or you could delay the zbusmap() until bus_space_map() is called.

Or maybe you should run a new PCI bus enumeration and reassign the BARs
to reflect the real offset.

But I'm also no expert in this topic.

--
Frank Wille

Frank Wille

unread,
May 31, 2011, 1:50:05 PM5/31/11
to
Radoslaw Kujawa wrote:

> Ok, I've created workaround, by implementing another absm with special
> bus_space_map, that operates on absolute PA address.

Sounds like a good idea. Can you give more details?

You are mapping the absolute address to a KVA, when bus_space_map() is
called?


> Still, it does not work as a console, the kernel just dies without a
> word, somewhere in wsdisplay_cnattach. Probably during/just after
> setting wsdisplay's cn_tab.

Nothing in the message buffer, after a reboot?


--
Frank Wille

Radosław Kujawa

unread,
May 31, 2011, 4:01:54 PM5/31/11
to

On May 31, 2011, at 7:50 PM, Frank Wille wrote:

> Radoslaw Kujawa wrote:
>
>> Ok, I've created workaround, by implementing another absm with special
>> bus_space_map, that operates on absolute PA address.
>
> Sounds like a good idea. Can you give more details?
>
> You are mapping the absolute address to a KVA, when bus_space_map() is
> called?

It's not (that) clean solution. I'm actually using the mapping done earlier with zbusmap. For example:

sc->pci_mem_area.base = (bus_addr_t) zbusmap(
(void *) 0xe0000000, 0x02000000);

sc->pci_mem_area.absm = &amiga_bus_stride_1abs_swap;

This is mapped somewhere into KVA, let's say 0x26ba000. Just as earlier PCI MI code calls bus_space_map:

bus_space_map(pci_mem_area, 0xe1000000, 20000 0);

However, this time bus_space_map is redirected to my new implementation, defined in amiga_bus_stride_1abs_swap:

int
oabs(bsm_absolute_)(tag, address, size, flags, handlep)
bus_space_tag_t tag;
bus_addr_t address;
bus_size_t size;
int flags;
bus_space_handle_t *handlep;
{
uint32_t pa = kvtop((void*) tag->base);
*handlep = tag->base + (address - pa) * AMIGA_SIMPLE_BUS_STRIDE;
return 0;
}

Which works, because *handlep = 0x26ba000 + (0xe1000000 - 0xe0000000). So the accesses hit VA 0x36ba000 - exaclty where I want :-P. Personally, I think that is a workaround, not a real solution. See the attached bus.diff for the details.

>
>> Still, it does not work as a console, the kernel just dies without a
>> word, somewhere in wsdisplay_cnattach. Probably during/just after
>> setting wsdisplay's cn_tab.
>
> Nothing in the message buffer, after a reboot?

The case is a bit complicated:
- I don't have any free SCSI disk I could use now with the A3000. FastATA 4000 driver still isn't completed. I've asked Elbox about some details needed to finish the driver, but they never answered my emails. Now I'm coding this PCI stuff without ever booting into the userland.
- I own the A1200 + BPPC, which I could use here, but my BVPPC has stopped working few weeks ago. No idea what's wrong with it, the machine won't even boot with BVPPC attached. It's probably dead :(. Or maybe my A1200 acting up again.
- I could access the chipmem from AmigaOS after a reboot and read the message buffer this way... But I've never done it before, don't know where to start. I guess I must look into it, as it seems the least complicated way now...

I've attached the two diffs, one contains changes to the amiga bus code, the other adds PCI support. These are not final, this code needs some serious polishing, sanitizing, error checking, etc (which will take a few weeks...).

bus.diff
pci.diff

Frank Wille

unread,
Jun 1, 2011, 5:28:34 AM6/1/11
to
On Tue, 31 May 2011 22:01:54 +0200
Rados?aw Kujawa <radosla...@c0ff33.net> wrote:

> > Nothing in the message buffer, after a reboot?
>

> The case is a bit complicated:
> - I don't have any free SCSI disk I could use now with the A3000.
> FastATA 4000 driver still isn't completed. I've asked Elbox about
> some details needed to finish the driver, but they never answered my
> emails.

I would just reassemble the AmigaOS device file. I can recommend IRA,
which I improved over the last years... ;)

But somehow I fear that the FastATA 4000 doesn't use interrupts at all,
which makes it useless for NetBSD.


> - I own the A1200 + BPPC, which I could use here, but my BVPPC has
> stopped working few weeks ago. No idea what's wrong with it, the
> machine won't even boot with BVPPC attached. It's probably dead :(.

Sorry to hear that. Probably a short circuit somewhere?


> - I could access the chipmem from AmigaOS after a reboot and read the
> message buffer this way... But I've never done it before, don't know
> where to start. I guess I must look into it, as it seems the least
> complicated way now...

Just use a command line based memory monitor after the reboot.
Maybe you can also move the message buffer to a fixed address which is
not overwritten when booting AmigaOS. I did the same when testing amigappc.

Radosław Kujawa

unread,
Jul 13, 2011, 5:22:52 PM7/13/11
to
Hi.

(many, many kernel compiles later...)

http://ichigo.c0ff33.net/genfbamiga.jpg

Currently it is possible to use CyberVisionPPC/BlizzardVisionPPC with the p5pb + genfb drivers.

Unfortunately, there are still problems:
- You will notice that the are some pixels missing, on the left side of the screen. I discussed this with macallan. We've reached the conclusion that the firmware sets up such weird mode. In a few days I'll install CGX on AmigaOS and do additional testing on other screen modes.
- The pm2fb driver isn't working yet. Not much progress here.
- The keyboard isn't working with genfb yet. Probably I need to touch the console-related code, because now it does not know anything about my changes.

--
Best regards,
Radosław Kujawa

Frank Wille

unread,
Jul 16, 2011, 3:53:29 PM7/16/11
to
Radoslaw Kujawa wrote:

> http://ichigo.c0ff33.net/genfbamiga.jpg
>
> Currently it is possible to use CyberVisionPPC/BlizzardVisionPPC with
> the p5pb + genfb drivers.

Wow, congratulations! I didn't expect that to work. :)


> - You will notice that the are some pixels missing, on the left side of
> the screen.

Hm. Seems that the pixels are not shifted, so that they reappear on the
other edge or leave some space there. It is probably a bad setting of the
left display window border (or whatever it is called for Permedia2) ?


> I discussed this with macallan. We've reached the
> conclusion that the firmware sets up such weird mode.

At which point does the firmware initialize the screen mode? Can the early
startup menu be displayed via the Permedia?

Radosław Kujawa

unread,
Jul 16, 2011, 4:29:07 PM7/16/11
to
Hi.

On Jul 16, 2011, at 9:53 PM, Frank Wille wrote:
>> - You will notice that the are some pixels missing, on the left side of
>> the screen.
>
> Hm. Seems that the pixels are not shifted, so that they reappear on the
> other edge or leave some space there. It is probably a bad setting of the
> left display window border (or whatever it is called for Permedia2) ?

It's possible, and the same problem is visible in AmigaOS, if the card drivers (CGX) are not installed. Firmware boots the card in 640x480x8 mode, but it configures the Permedia to emulate PAL modes, so you can install AmigaOS without PAL monitor or scandoubler. I had no time to do the additional testing with CGX yet, but I assume that it might "just work" once some sane mode is configured on AmigaOS. Provided that CGX will not change the framebuffer location on the bus :-P.

Currently both pm2fb and genfb can't change the running graphics mode or "cold boot" the Permedia chip, so we have to rely on whatever firmware or AmigaOS configures for us. I could probably take a look at Adam's old cvppc driver, which implemented mode setting, but first we'd need to get the pm2fb running...

>
>> I discussed this with macallan. We've reached the
>> conclusion that the firmware sets up such weird mode.
>
> At which point does the firmware initialize the screen mode?

During CSPPC/BPPC ROM execution.

> Can the early
> startup menu be displayed via the Permedia?

Yes. CVPPC/BVPPC are probably the only RTG cards capable of this. Excluding cards with integrated scandoublers, ofcourse.

--
Best regards,
Radoslaw Kujawa

0 new messages