Re: First steps towards PCMCIA support on the PB190
Just as a note, I never saw the original message come across the mailing
list. Also, you might want to include linux-m68k@lists.linux-m68k.org
on this sort of topic.
On Tue, Nov 24, 2009 at 07:01:30PM -0200, diego wrote:
> in case anyone is interested, I decided to pick up Brad's idea and did
> some work towards turning it into reality.
> I just took the driver from the nubus-pmac project, adapted it to
> kernel 2.6 and did some hacking to get at least
> a few card drivers to work with it.
> Below patchset contains enough to add basic socket services support on
> the PB190 and to drive a Orinoco Gold Wireless
> card with kernel 2.6.31-2.
> Note that this code is far from complete (or mergeable) at the moment,
> I just posted this in the hope
> that it will inspire others interested in pcmcia support on the PB190
> to read it and maybe fill in some of the gaps.
I do have a PB190 laying around, so hopefully I'll find some time to
try out this code. I should have some time over the holiday season. It's
good to see some code that at least works to some degree. This was one
thing keeping me from bothering, since I wanted ethernet support. I'm
not sure if there is already a Linux driver for the ethernet card I have,
but that's something I'll have to check.
> Unfortunately I don't have all too much time to work on this, that's
> why I decided to just post my current effort
> (in it's half finished state) and provide a quick line-out of the
> major issues involved in getting pcmcia support to work
> on this platform.
> The main question being, whether there are enough people using linux
> on a PB190 to justify the effort.
> I also apologize beforehand for the unclean code / patch.
I think it's better to share what you have. I've been guilty of keeping
code to myself when I'm not happy with it. To be honest, there probably
aren't enough people using Linux on m68k to justify the work in pure
practical terms anyway. I drag it out once in a while because it is
interesting and a chance to try out things I wouldn't otherwise try.
> There are mainly three problems l'm facing here....
> The first two should be fairly easy to work out, whereas the 3rd
> represents a major roadblock at the moment:
>
> 1. Proper mac specific definitions that wrap around ISA bus access.
>
> 2. If you look at the patches to the orinoco driver, you will see that
> there's another enemy hiding, his name is ioport_map.
These should be relatively simple. We need to clean up some of that
stuff anyway. It's just a matter of taking the time to do it right.
This is the sort of thing that ought to be handled better in the
common code anyway.
> 3. This has already been haunting the driver in the nubus-ppc
> project, and I couldn't come up with anything better either:
> I can't figure out how to make the TREX chip use IO memory and
> attribute memory simultaneously. From the little docs
> provided by apple it appears that it would be possible, then again
> they don't provide any documentation on how this
> chip works at the register level.
> The original author of the driver did find out how to switch between
> the two modes, but this requires the ugly patches to
> pcmcia_resource.c to, which in turn makes it impossible to merge this
> into an all-arch kernel tree.
> This wasn't a problem for the nubus-ppc port since they maintained
> their own development tree, but obviously in the
> case of m68k this would represent a major problem.
> Another thing is that it breaks some drivers that implement more
> exotic features like requesting card configuration
> changes etc..
> If anyone happens to know how to program the TREX chip to use both
> attribute and IO mem simultaneously then this
> wouldn['t be an issue anymore.
> The alternative would be to convince the pcmcia core maintainers to
> have mercy with cards that need switching between
> these modes, but I doubt that this is a realistic alternative.
This is pretty much the sort of thing we've constantly encountered
trying to get old Macs to work. Unless someone can get official docs
on the chip, we may need to try to reverse engineer the Apple drivers
for all of this stuff.
Brad Boyer
flar@allandria.com
Reply to: