After focusing so much time on that old Toshiba card, I thought I'd see if I could get something more modern working as well. I've had one card in my bag knocking around in my bag based on the AX88790 chip. This is the corega FEther II-PXD. I saw it on sale in Akihabara when I was there a few weeks ago, and this card came from Akihabara a few years ago from a friend in Japan. So I thought I'd try it out.
Well, at first it didn't work too well. The MII code was finding gobs of PHYs that were phantoms. This in turned caused bad things to happen when dhclient(8) was run.
There turned out to be three root causes. First, the mii bit-bang code was wrong for reads, yielding bad register reads. Second, the AX88790 has an odd quirk for talking to its internal PHY, so more code was needed to cope with that. Third, the reset code for the NE2000 was also causing problems, so I rewrote it to be AX88x90 reset code. Finally, the internal phy for the AX88790 has a few quirks in silicon that need software workarounds.
Once I'd corrected these problems, the card started working again. Since most of this data is readily available on the net (the asix web site has datasheets for these parts), I'll skip over all the blow-by-blow details. I hopefully had enough comments in the code for people to follow along, as well as the datasheet should make what I've done easy to see.
Now, the arduous task of testing all the AX88x90 cards in my collections... The target card now works correctly, and I believe all of the ones in my collection will work too. Maybe I'll get to the point were all my ed-based PC Cards in my collection will work (except for the Mitsubushi B8895 which I've given up on, and the ones I don't have proper dongles for).
20090330
20090327
Toshiba LANCT00A PC Card
When I was in Akihabara last, I got a lot of PC Cards from the junk vendors for 100 Yen. One of these cards was the Toshiba LANCT00A. This card didn't probe when I first got it. FreeBSD didn't support it. This was a challenge.
As long-time reads of this blog may know, I sometimes go out of my way to hack on really oddball hardware that somehow I get it into my head needs to work. Never mind that I have a dozen other projects cooking that is more relevant to FreeBSD and its user base. Never mind that some of this hardware was obsolete when I started hacking on FreeBSD's PC Card layer. The cool thing is that I can find just enough documentation to be interesting on these cards.
This Toshiba card was like that. Google searches for information about it turned up a half dozen posts to different FreeBSD and Linux mailing lists asking about it, plus some speculation about what's in the card. One brave soul even took his card apart and reported it had a NS DP83902 under the hood. However, nobody that I can find ever got this card working under FreeBSD or Linux. Checks of the current Linux kernel was no help. Checks of OpenBSD and NetBSD also yielded no results. There was a windows driver available (actually an NDIS driver of unknown version).
So I was printing out random values for this card. At one time the FreeBSD PC Card probe routine for ed tried to probe WD80x3 cards as well as NE2000 cards. I removed this about 4 years ago after failing to find any cards that needed this, used it, etc. However, this card is almost a WD80x3 clone. I was printing the board type in the attach routine, trying to track down why attach was failing. I saw that it was 20 decimal or 0x14. A quick scan of the if_edreg.h file showed this was one of the Toshiba cards. The comments said it was a PCETC board. I immediately thought "Hmmm, isn't this a Toshiba card?" and then wondered if the 'C' in LANCT00A meant it was the same silicon revision as the 'C' in the PCETC. So I hacked up a quick little test into the if_ed_pccard probe routine.
It recognized it the card when I did that! Success. Well, almost. There was a snag. The memory allocated for this card was at 0x88000000. This didn't pass through the sanity test in the driver designed for ISA cards, so it didn't work. A little more hacking and I was getting a sane MAC address and the card was attaching. It dhcped its address w/o incident.
However, all is not right in mudville. As soon as I started using TCP, I started getting sbdrop panics. It looks like the packets that the WD80x3 code is pumping out aren't quite rightly aligned, or something (I have never had a sbdrop panic, so I'll have to investigate what that means when I have some time). This isn't too terribly surprising, since I haven't tested the ISA cards in years. Maybe something broke for the memory copyout path, but not for the PIO copyout path. I'll have to track that down another night.
[[ UPDATE: It looks like it was the copyin path. There was a bug in it that caused 2x too many bytes to be read into memory, causing the corruption. So now it works well enough for me to update this post and commit the change. ]]
Now, what does this gain FreeBSD? Not much, in the grander scheme of things. I'd be surprised if any of my readers actually had one of these cards and started using it as a result of my work. However, it was a relaxing hour or two of my life. Given my current job stress level, this has great value to me. Also, I think this is one of the first PC Cards to work with both I/O and Memory windows mapped at the same time from the CFE entry. While there are some other cards that manually allocate memory ranges, I don't think any of them have it in their CIS.
Postscript
Well, while I was doing research for this blog entry, I stumbled accross http://linux.toshiba-dme.co.jp/linux/eng/download.htm which has a tos_cs for download. There's a lot of voodoo magic in that driver that I'll have to investigate. This driver is 1000 lines long, and was for Linux 2.0.35. It was never integrated into Linux, so I'd stand by my statement that Linux doesn't support it. Just for kicks I tried building it under 2.6.29, and it didn't compile anymore.
My changes to the ed driver in FreeBSD are more like 20-25 lines of code. There's magic kick of a magic offset in shared memory that isn't present in FreeBSD's ed driver today. I'll keep that in mind in case I have the card wedge on me under load or something.
As long-time reads of this blog may know, I sometimes go out of my way to hack on really oddball hardware that somehow I get it into my head needs to work. Never mind that I have a dozen other projects cooking that is more relevant to FreeBSD and its user base. Never mind that some of this hardware was obsolete when I started hacking on FreeBSD's PC Card layer. The cool thing is that I can find just enough documentation to be interesting on these cards.
This Toshiba card was like that. Google searches for information about it turned up a half dozen posts to different FreeBSD and Linux mailing lists asking about it, plus some speculation about what's in the card. One brave soul even took his card apart and reported it had a NS DP83902 under the hood. However, nobody that I can find ever got this card working under FreeBSD or Linux. Checks of the current Linux kernel was no help. Checks of OpenBSD and NetBSD also yielded no results. There was a windows driver available (actually an NDIS driver of unknown version).
So I was printing out random values for this card. At one time the FreeBSD PC Card probe routine for ed tried to probe WD80x3 cards as well as NE2000 cards. I removed this about 4 years ago after failing to find any cards that needed this, used it, etc. However, this card is almost a WD80x3 clone. I was printing the board type in the attach routine, trying to track down why attach was failing. I saw that it was 20 decimal or 0x14. A quick scan of the if_edreg.h file showed this was one of the Toshiba cards. The comments said it was a PCETC board. I immediately thought "Hmmm, isn't this a Toshiba card?" and then wondered if the 'C' in LANCT00A meant it was the same silicon revision as the 'C' in the PCETC. So I hacked up a quick little test into the if_ed_pccard probe routine.
It recognized it the card when I did that! Success. Well, almost. There was a snag. The memory allocated for this card was at 0x88000000. This didn't pass through the sanity test in the driver designed for ISA cards, so it didn't work. A little more hacking and I was getting a sane MAC address and the card was attaching. It dhcped its address w/o incident.
However, all is not right in mudville. As soon as I started using TCP, I started getting sbdrop panics. It looks like the packets that the WD80x3 code is pumping out aren't quite rightly aligned, or something (I have never had a sbdrop panic, so I'll have to investigate what that means when I have some time). This isn't too terribly surprising, since I haven't tested the ISA cards in years. Maybe something broke for the memory copyout path, but not for the PIO copyout path. I'll have to track that down another night.
[[ UPDATE: It looks like it was the copyin path. There was a bug in it that caused 2x too many bytes to be read into memory, causing the corruption. So now it works well enough for me to update this post and commit the change. ]]
Now, what does this gain FreeBSD? Not much, in the grander scheme of things. I'd be surprised if any of my readers actually had one of these cards and started using it as a result of my work. However, it was a relaxing hour or two of my life. Given my current job stress level, this has great value to me. Also, I think this is one of the first PC Cards to work with both I/O and Memory windows mapped at the same time from the CFE entry. While there are some other cards that manually allocate memory ranges, I don't think any of them have it in their CIS.
Postscript
Well, while I was doing research for this blog entry, I stumbled accross http://linux.toshiba-dme.co.jp/linux/eng/download.htm which has a tos_cs for download. There's a lot of voodoo magic in that driver that I'll have to investigate. This driver is 1000 lines long, and was for Linux 2.0.35. It was never integrated into Linux, so I'd stand by my statement that Linux doesn't support it. Just for kicks I tried building it under 2.6.29, and it didn't compile anymore.
My changes to the ed driver in FreeBSD are more like 20-25 lines of code. There's magic kick of a magic offset in shared memory that isn't present in FreeBSD's ed driver today. I'll keep that in mind in case I have the card wedge on me under load or something.
20090325
Dumpster diving for PC Cards at Akihabara Junk Shops
When I was in Japan two weeks ago, I took a trip to Akihabara and found a few junk shops. Well, these places are just second hand stores for used computer hardware and software. There is quite the range of shops. Some are nice, neat, well lit and have plenty of room to move about. Others aren't quite so nice and are very cramped. The further you get away from the street level and from the main streets, the less polished these stores are. The harder it is for a non-Japanese speaker like myself finds it to do business. This was my first trip to Akihabara that I didn't have Japanese speakers to help me out, so I didn't get too far away from the beaten path. I managed to find about 20 PC Cards at these shops, and spent only 2500 yen for them.
First, the cards that worked. The CyQ've ELA-010 and NEC PC-9801N-J12 both worked with the ed driver without changes to the drivers. The TDK LAC-CD02x worked with the fe driver, again without changes. In a way, these were the disappointing cards in the lot. While I didn't have examples of them in my collection, I also didn't expand FreeBSD's support for PC Cards at all.
I was able to modify the fe driver to support two additional cards that I found. One was the Hitachi HT-4840-11. I had to update the fe driver to select an alternative CFE. What's a CFE? It is the Configuration Function Entry in the CIS. These nodes in the CIS describe the resources that the card will use, as well as control different ways the hardware interacts with the system. The PC Card infrastructure usually selects the proper CFE based on the available resources. However, there are cases like this where some CFEs don't work for whatever reason and alternatives need to be selected. That's what happened here. The HT-4840-11 CFE entries less than 10 appear to be designed to be used in a PC-9801 and PC-9821 laptop. They don't work in my modern HP laptop at all. Entries 10 and above all work fine.
The second fe card I was able to make work was the CONTEC CNETPC. Its first entry had a similar problem to the first few of the Hitachi HT-4840-11, but the rest were good. A quick modification to my earlier modification for the Hitachi and I was supporting both. Well, with one caveat. I can't get this card to get any link with any of the hubs that I have. I don't know if this is because the dongles got mixed up over time and I didn't have a good dongle, or if other parts of the card are 'blown out' or otherwise messed up. I had several cards like this.
Next up was a Toshiba JT Ethernet card. It worked out of the box with the ed driver. However, there was an issue. The MAC address showed up as 00:20:16:ff:ff:ff which seemed odd. Especially since 002016016b31 was labelled on the card. Digging into this deeper showed that the card has the bogus-looking address in the CIS. None of the other standard ways to get a MAC produced anything other than 0's. There's no aux entries in the CIS that could be mined for this data either. Since that's the case, I'm almost convinced that this is working the best it can given the circumstances. Also, there was no good dongle for this card...
There were a number of other boring cards. These were cards that I was able to add to the drivers more easily. The NextComK.K NC5310B Ver1.0 seems to work with the fe driver, but I don't know if the driver I have works or not. Also the MACNICA ME1-JEIDA worked with the ed driver, but the dongle didn't seem to be the right one.
Now, on to the odd-balls.
The NEC PC-9801N-J02R is a card made especially for PC-9801 and PC-9821 laptops. I've never been able to make this work with the smc driver that's in the tree. The card has a sonic chip in it, and it should just work. However, it is extremely limited to where it can be mapped in the I/O space (only at 0x880!), and none of the laptops I've ever had worked with this address.
The TDK LAC-CD011 I found turns out to be rare. At one time they were expensive, but no longer. Sadly, I didn't get dongles for this card. There's sources on the web that document it not working with the fe driver, but that it may have the MB86960A inside, which we might be able to make work. Plus, the NetBSD mbe driver supports the CD010, so I may fiddle with the fe driver to see if I can make this work...
The Toshiba LANCT00A doesn't work out of the box at all. The only information about this card on the net today is that once there was a web page that Toshiba said it was a custom-built card. Chances are good that there will never be a driver for this card.
I'll take a look at the other cards another time. They are even weirder, I fear...
First, the cards that worked. The CyQ've ELA-010 and NEC PC-9801N-J12 both worked with the ed driver without changes to the drivers. The TDK LAC-CD02x worked with the fe driver, again without changes. In a way, these were the disappointing cards in the lot. While I didn't have examples of them in my collection, I also didn't expand FreeBSD's support for PC Cards at all.
I was able to modify the fe driver to support two additional cards that I found. One was the Hitachi HT-4840-11. I had to update the fe driver to select an alternative CFE. What's a CFE? It is the Configuration Function Entry in the CIS. These nodes in the CIS describe the resources that the card will use, as well as control different ways the hardware interacts with the system. The PC Card infrastructure usually selects the proper CFE based on the available resources. However, there are cases like this where some CFEs don't work for whatever reason and alternatives need to be selected. That's what happened here. The HT-4840-11 CFE entries less than 10 appear to be designed to be used in a PC-9801 and PC-9821 laptop. They don't work in my modern HP laptop at all. Entries 10 and above all work fine.
The second fe card I was able to make work was the CONTEC CNETPC. Its first entry had a similar problem to the first few of the Hitachi HT-4840-11, but the rest were good. A quick modification to my earlier modification for the Hitachi and I was supporting both. Well, with one caveat. I can't get this card to get any link with any of the hubs that I have. I don't know if this is because the dongles got mixed up over time and I didn't have a good dongle, or if other parts of the card are 'blown out' or otherwise messed up. I had several cards like this.
Next up was a Toshiba JT Ethernet card. It worked out of the box with the ed driver. However, there was an issue. The MAC address showed up as 00:20:16:ff:ff:ff which seemed odd. Especially since 002016016b31 was labelled on the card. Digging into this deeper showed that the card has the bogus-looking address in the CIS. None of the other standard ways to get a MAC produced anything other than 0's. There's no aux entries in the CIS that could be mined for this data either. Since that's the case, I'm almost convinced that this is working the best it can given the circumstances. Also, there was no good dongle for this card...
There were a number of other boring cards. These were cards that I was able to add to the drivers more easily. The NextComK.K NC5310B Ver1.0 seems to work with the fe driver, but I don't know if the driver I have works or not. Also the MACNICA ME1-JEIDA worked with the ed driver, but the dongle didn't seem to be the right one.
Now, on to the odd-balls.
The NEC PC-9801N-J02R is a card made especially for PC-9801 and PC-9821 laptops. I've never been able to make this work with the smc driver that's in the tree. The card has a sonic chip in it, and it should just work. However, it is extremely limited to where it can be mapped in the I/O space (only at 0x880!), and none of the laptops I've ever had worked with this address.
The TDK LAC-CD011 I found turns out to be rare. At one time they were expensive, but no longer. Sadly, I didn't get dongles for this card. There's sources on the web that document it not working with the fe driver, but that it may have the MB86960A inside, which we might be able to make work. Plus, the NetBSD mbe driver supports the CD010, so I may fiddle with the fe driver to see if I can make this work...
The Toshiba LANCT00A doesn't work out of the box at all. The only information about this card on the net today is that once there was a web page that Toshiba said it was a custom-built card. Chances are good that there will never be a driver for this card.
I'll take a look at the other cards another time. They are even weirder, I fear...
20090319
AsiaBSDCon 2009
I just presented a paper at AsiaBSDCon 2009 on the FreeBSD/mips status. There's a lot going on with the FreeBSD/mips project these days. You can find out most of the details from my paper, which is available in letter or a4 format.
In summary, there's a number of new ports underway. There's Cavium Octeon, Atheros 7xxx/9xxxx, RMI Au1xxxx and a couple others.
AsiaBSDCon is always fun. There's many Japanese developers that don't get a chance to go to other conferences who I only get to see in Japan. This conference allows me to see them, as well as talk to them to see what they are using BSD in general, and FreeBSD specifically. The Japanese have often lead the way in many areas, and seeing their current projects is very interesting.
Also, I could cut and paste large parts of my paper here, but I'm not sure of the value of doing that. Can people that have strong opinions leave feedback on this issue.
In summary, there's a number of new ports underway. There's Cavium Octeon, Atheros 7xxx/9xxxx, RMI Au1xxxx and a couple others.
AsiaBSDCon is always fun. There's many Japanese developers that don't get a chance to go to other conferences who I only get to see in Japan. This conference allows me to see them, as well as talk to them to see what they are using BSD in general, and FreeBSD specifically. The Japanese have often lead the way in many areas, and seeing their current projects is very interesting.
Also, I could cut and paste large parts of my paper here, but I'm not sure of the value of doing that. Can people that have strong opinions leave feedback on this issue.