Clockport devices programming
Radek Kujawa
Today I wondered, how one should program devices connected to Amiga 1200 clockport. There are many popular expansion cards available, but I found no drivers for such devices in NetBSD source tree. Is there any example source code I can read? I'm interested in experimenting with some of my clockport cards.
In case of Zorro cards, matching and attaching drivers is quite easy, because we have zbus abstraction. This exposes Zorro autoconfig mechanism - driver can match the card according to vendor and product ID. However, we have no similar mechanism for clockport expansions.
As I understand, clockport devices are connected directly to 68k bus. So matching and attachment must work by "probing" for a card. For example by writing some values into bus space where it expects the device, and reading values back. Am I right? If that is true, how would example probe procedure look? Most NetBSD/Amiga drivers either use zbus, or matchname(). Both of these methods seems wrong for clockport. I'm really not sure how should I probe for clockport stuff.
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
Frank Wille
Radek Kujawa <radosla...@c0ff33.net> wrote:
> Today I wondered, how one should program devices connected to
> Amiga 1200 clockport. There are many popular expansion cards available,
> but I found no drivers for such devices in NetBSD source tree. Is there
> any example source code I can read?
AFAIK no clockport devices are supported yet.
> As I understand, clockport devices are connected
> directly to 68k bus. So matching and attachment must work by "probing"
> for a card. For example by writing some values into bus space where it
> expects the device, and reading values back. Am I right?
Yes, that's the way to do it.
But poking in the bus space may be dangerous and anything can happen.
So when you finish your driver, I wouldn't enable it by default in a
GENERIC config file, but let the user enable the driver when she or he
really needs it.
> If that is true,
> how would example probe procedure look? Most NetBSD/Amiga drivers either
> use zbus, or matchname(). Both of these methods seems wrong for
> clockport. I'm really not sure how should I probe for clockport stuff.
AFAIK the NetBSD/amiga kernel doesn't use a VA=PA mapping, so you cannot
access the hardware address directly in your probe functions.
It depends which address you have to probe for the clockport device.
For example the following three regions are mapped:
CHIPMEMBASE (0x000000) to CHIPMEMTOP (0x200000) at CHIPMEMADDR.
CIABASE (0xbfc000) to CIATOP (0xc00000) at CIAADDR.
ZTWOROMBASE (0xd80000) to ZTWOROMTOP (0xf80000) at ZTWOROMADR.
When it is the last region you can also use the ztwomap() macro, e.g.
va = ztwomap(pa)
--
_ Frank Wille (fr...@phoenix.owl.de)
_ // http://sun.hasenbraten.de/~frank/
\X/ Phx @ #AmigaGer
Ignatios Souvatzis
> On Tue, 28 Sep 2010 17:07:27 +0200
> Radek Kujawa <radosla...@c0ff33.net> wrote:
>
> > Today I wondered, how one should program devices connected to
> > Amiga 1200 clockport. There are many popular expansion cards available,
> > but I found no drivers for such devices in NetBSD source tree. Is there
> > any example source code I can read?
>
> AFAIK no clockport devices are supported yet.
Some are - clocks that are at locations where the A2000 clock is -
see dev/a2kbbc.c
As for the probing/matching:
- there are direct and indirect busses.
zbus and pci are direct, that is, the *bus* has knowledge of the
devices that are connected to it, and your driver's *match* function
checks whether the attributes of some device match your driver.
- clockport, ISA, the VAX are indirect, that is, you have a *probe*
function, and it checks whether your hardware is at the addresses you're
configured with. As Frank wrote - this is dangerous - e.g. in the old
days, some ISA probe function for device A used to leave device B in a
state where B's driver wouldn't recognize it, etc.
I have some clockport devices' documentation somewhere, I think. I'll
see what I can find.
Regards,
-is
Radek Kujawa
> On Sun, Oct 03, 2010 at 07:18:40PM +0200, Frank Wille wrote:
> > Radek Kujawa <radosla...@c0ff33.net> wrote:
> >
> > > Today I wondered, how one should program devices connected to
> > > Amiga 1200 clockport. There are many popular expansion cards available,
> > > but I found no drivers for such devices in NetBSD source tree. Is there
> > > any example source code I can read?
> >
> > AFAIK no clockport devices are supported yet.
> Some are - clocks that are at locations where the A2000 clock is -
> see dev/a2kbbc.c
This source is of some use to me, but clock drivers are relatively simple and don't have proper probe procedure. Driver just assumes that clock is there and tries to attach. And I guess there's nothing wrong with it, as it's just a clock.
> > So when you finish your driver (...)
I wouldn't go as far as stating that I'll finish a driver ;). Though, if anything even remotely complete comes out of my tinkering, I will gladly donate it to NetBSD. Recently some cool clockport cards reached my hands and it's a pity I can't use these with NetBSD.
> I have some clockport devices' documentation somewhere, I think. I'll
> see what I can find.
That would be great, as freely available clockport devices documentation is mostly nonexistant.
> > For example the following three regions are mapped: (...)
> > ZTWOROMBASE (0xd80000) to ZTWOROMTOP (0xf80000) at ZTWOROMADR.
I belive that most clockport expansions live in this region. For example Subway USB controller is located on 0xd80000-0xd8ffff (if installed in A1200).
> > When it is the last region you can also use the ztwomap() macro, e.g.
> > va = ztwomap(pa)
Ok, but this marco returns base address only. Length of used bus space doesn't need to be specified? How does kernel know which addresses I am going to use? What happens when two drivers want to use adress spaces that overlap? Such circumstances may actually arise with clockport devices... As I see, ztwomap just returns physical address that was already translated into VA (contrary to its name, this marco does not do any mapping?).
There is also zbusmap(pa, size) function defined, but it is not used anywhere outside of zbus.c. I guess this is used only for VA=PA mapping for real Zorro cards.
Best regards,
Radoslaw Kujawa
Frank Wille
>> see dev/a2kbbc.c
>
> This source is of some use to me, but clock drivers are relatively
> simple and don't have proper probe procedure. Driver just assumes that
> clock is there and tries to attach. And I guess there's nothing wrong
> with it, as it's just a clock.
But it checks whether the values read are within expected limits. When they
are not, the clock won't be attached.
You would have to do the same for your device. Maybe you also have to write
to some registers and check if that produces the expected result in another
register.
>> > e.g. va = ztwomap(pa)
>
> Ok, but this marco returns base address only. Length of used bus space
> doesn't need to be specified?
No. The bus_space(9) functions are not used in Amiga drivers.
I guess it made not much sense, as most drivers for Amiga are not portable?
The length is not needed. You can always access any location from va to
va+(0xf80000-pa).
> How does kernel know which addresses I am going to use?
Not needed. All drivers run on the same mapping, which is already
established in amiga_init.c.
> What happens when two drivers want to use adress spaces
> that overlap?
Nothing. It just works.
> Such circumstances may actually arise with clockport
> devices... As I see, ztwomap just returns physical address that was
> already translated into VA (contrary to its name, this marco does not
> do any mapping?).
Exactly. :)
> There is also zbusmap(pa, size) function defined, but it is not used
> anywhere outside of zbus.c. I guess this is used only for VA=PA mapping
> for real Zorro cards.
It creates a new MMU mapping for Zorro address space which is not within
the above mentioned 0xd80000-0xf80000 area (which means Z3 memory?).
You don't have to care about that.
--
_ Frank Wille (fr...@phoenix.owl.de)
_ // http://sun.hasenbraten.de/~frank/
\X/ Phx @ #AmigaGer
Ignatios Souvatzis
> No. The bus_space(9) functions are not used in Amiga drivers.
> I guess it made not much sense, as most drivers for Amiga are not portable?
Uh, they are in a lot of them, mostly for zbus and DraCo mainboard
devices. Look closer.
We could use more generic drivers if we'd implement a minimal bus_dma(9),
(think DMA capable SCSI interfaces).
>
> The length is not needed. You can always access any location from va to
> va+(0xf80000-pa).
>
>
> > How does kernel know which addresses I am going to use?
>
> Not needed. All drivers run on the same mapping, which is already
> established in amiga_init.c.
Only for Zorro 2 and for low address mainboard devices.
Zorro 3 is mapped by zbus initialization.
Regards,
-is
--
seal your e-mail: http://www.gnupg.org/
Frank Wille
Ignatios Souvatzis <i...@netbsd.org> wrote:
> > No. The bus_space(9) functions are not used in Amiga drivers.
> > I guess it made not much sense, as most drivers for Amiga are not
> > portable?
>
> Uh, they are in a lot of them, mostly for zbus and DraCo mainboard
> devices. Look closer.
You're right, bus_space(9) is used for drivers which depend on MI code,
but what I wanted to say was that it didn't made much sense for the
other, MD, drivers.
> We could use more generic drivers if we'd implement a minimal bus_dma
> (9), (think DMA capable SCSI interfaces).
So m68k/bus_dma.c wouldn't help?
I always asked myself why there is no bus_space.c in sys/arch/m68k for
all the m68k ports (as in sys/arch/powerpc, for example) ?
--
Frank Wille
Radek Kujawa
> On Wed, 6 Oct 2010 10:16:49 +0200
>
> > > No. The bus_space(9) functions are not used in Amiga drivers.
> > > I guess it made not much sense, as most drivers for Amiga are not
> > > portable?
> >
> > Uh, they are in a lot of them, mostly for zbus and DraCo mainboard
> > devices. Look closer.
>
> but what I wanted to say was that it didn't made much sense for the
> other, MD, drivers.
E3B Fa. created very nice USB controller for A1200 compatible clockports - Subway. Michael Böhmer of E3B agreed to share documentation with me, so I (hopefully) can create driver for NetBSD.
This controller is based on UHC124 chip. There's nothing Amiga-specific in this IC, so it should have MI driver with Amiga frontend. This implies use of bus_space(9). But I'm unsure if it is possible to mix bus_space functions and VA which is returned from ztwomap(). Frontend driver should somehow "connect" MI driver to virtual adress space returned from ztwomap.
Situation with Subway is a bit similar to SL811HS driver for X68 series, but they use bus_space for intio attachment too, which is far more understandable for me ;).
Btw. here's skeleton of my driver:
http://c0ff33.net/svn/netbsd-subway/src/sys/
Does not do anything at all yet.
Best regards,
Radoslaw Kujawa
Frank Wille
Radek Kujawa <radosla...@c0ff33.net> wrote:
> E3B Fa. created very nice USB controller for A1200 compatible
> clockports - Subway. Michael Böhmer of E3B agreed to share
> documentation with me, so I (hopefully) can create driver for NetBSD.
Very nice project (although I don't own an A1200). I have a Deneb USB
card from E3B and I wanted to ask for documentation, but didn't yet,
because I was never sure to have enough time to finish it.
> This controller is based on UHC124 chip. There's nothing
> Amiga-specific in this IC, so it should have MI driver with Amiga
> frontend. This implies use of bus_space(9).
Yes.
> But I'm unsure if it is
> possible to mix bus_space functions and VA which is returned from
> ztwomap().
There are several examples doing that (e.g. wdc_amiga.c). You have to
build the bus space tag yourself, by assigning the base from ztwomap(),
e.g.: sc->cmd_iot.base = (u_long)ztwomap(0xdd2020 + 2);
Then you can call bus_space_map() using the constructed tag.
--
Frank Wille
Radek Kujawa
> On Wed, 6 Oct 2010 11:53:23 +0200
> Radek Kujawa <radosla...@c0ff33.net> wrote:
>
> > E3B Fa. created very nice USB controller for A1200 compatible
> > clockports - Subway. Michael Böhmer of E3B agreed to share
> > documentation with me, so I (hopefully) can create driver for NetBSD.
>
> card from E3B and I wanted to ask for documentation, but didn't yet,
> because I was never sure to have enough time to finish it.
Cool, I have Deneb in my A3000 too, but can't use it now due to PSU failure. It is even more interesting because Deneb controller is not based around existing chip, but designed from scratch in FPGA.
> > But I'm unsure if it is
> > possible to mix bus_space functions and VA which is returned from
> > ztwomap().
>
> There are several examples doing that (e.g. wdc_amiga.c). You have to
> build the bus space tag yourself, by assigning the base from ztwomap(),
> e.g.: sc->cmd_iot.base = (u_long)ztwomap(0xdd2020 + 2);
>
> Then you can call bus_space_map() using the constructed tag.
Ok, I'll investigate it closely. Expect more noob questions ;).
Best regards,
Radoslaw Kujawa