:I've recently been trying to get the EDGE/GPRS portion of the GC89
:working under 1.8.x, but have been having some troubles ..
:
:The card attaches fine as a regular 'com' port under OpenBSD 4
:and can handle a 15minute PPP session, but unfortunately the com/sio
:and cardbus differences between DF/Free and Net/Open are quite
:different so I'm having trouble nailing down the problem.. thinking this
:should be a 'sio' though, as it appears to be a Broadcom 4344 '16550'
:kind of thing.
:
:Initially, the card was 'unable to drain sio0', but after hacking
:around that test on the odd chance that it probed with no spare data,
:it doesn't seem to work in any case.
:
:diff against sio.c attached, only other changes were to add the card
:to pcidevs (not included here), add tons of printk's in various
:places and set:
Well, usually an 'unable to drain sio' error means that it either
couldn't map the IO ports or they aren't where it thinks they are.
I'm not an expert on the cardbus stuff, but I know we've always
had interrupt issues with it, too. If the interrupt isn't working
you may have to turn on emergency interrupt polling
(kern.emergey_intr_enable=1). But the problem at the moment
sounds more like a mapping issue then an interrupt issue.
One thing you can do is print out the mappings and then access the
IO space with a userland program using /dev/io. See i386_get_ioperm()
and i386_set_ioperm(). Then write a userland program to try to access
the hardware directly so you can see if the ports are even present
and debug it.
The SIO driver is the correct driver, and it should be able to handle
a 16550 no problem once everything is mapped properly.
One thing I did notice was on (I think) your NetBSD output:
:pccom3 at cardbus0 dev 0 function 1: irq 9: ns16550a, 16 byte fifo
It says it is using 'function 1'. I'm not sure what that means,
but if it is the RID then it doesn't match the 0x10 used for the rid
in your sio patch.
-Matt
