The BCM43xx driver from DragonFlyBSD has been ported to FreeBSD. Andrew Thomas and others have done the port. I've pushed it into the tree, and plan on fixing the one or two quirks with my card.
The driver is far from perfect. 802.11a isn't support. Some older BCM4306 cards don't support channels 1, 2 or 3. It is rumored not to work at all for some people.
The driver was written by Sepherosa Ziehau for DragonFlyBSD. He used the specs available at http://bcm-specs.sipsolutions.net/Specification to write the driver. The driver is written against the v3 firmware. The v4 firmware is needed for support of newer cards, and many people have made noise about porting to that, but nobody has emerged yet to do that work.
The driver will be in FreeBSD 8.0. A back port of the driver to 7.x is difficult because it relies on all the new VAP work that Sam Leffler has done that is not in 7.x (although backports exist for 7.x, they won't be committed to the FreeBSD tree because it breaks binary compatibility).
You need the net/bwi-firmware-kmod port installed for the firmware. Although the binary .o file that the firmware is extracted from is apparently easy to distribute, distributing derived works of that .o file is not. So, there's a port to download, extract the firmware and make a kld for the driver to access.
A man page will be committed soon.
20090514
20090505
Belkin F6D4230 "Enhanced Wireless Router"
Just got the Belkin Enhance Wireless Router F6D4230-4. Looks like it has a ralink RT3052 or RT3050 under the hood. This is a MIPS24KEc based SoC, with a full Linux GPL tarball available from Belkin's web site.
I haven't had a chance to open the box yet to see what else is inside, and this is inferred entirely from the Linux config file that was in the GPL compliance package.
Not sure what I'm going to do with this box...
I haven't had a chance to open the box yet to see what else is inside, and this is inferred entirely from the Linux config file that was in the GPL compliance package.
Not sure what I'm going to do with this box...
20090423
ExpressCard
Now that I've managed to knock down the number of bugs in NEWCARD to a more reasonable level, I've started looking at ExpressCard again.
As you may know, FreeBSD supports ExpressCard right now for usb devices. They all work, and there's no additional work needed here, except maybe to make more drivers. In fact, I recently purchased an ExpressCard to CardBus adapter (one that lets me plug in an expressCard into a CardBus slot) and it worked with all the usb-based ExpressCards that I have laying around with no changes.
The problem with ExpressCard for PCIe-based devices is one of resource allocation. If the BIOS allocates the resource, then the ExpressCard works without hot-plug. If the BIOS doesn't, then we can see the device with pciconf -l, as well as probe the device. However, since there's no resources setup for the PCI bridge, attempts for the driver to allocate them fail. There's also some bus numbering issues as well.
I've started to attack the resource problem. I'll keep people posted
As you may know, FreeBSD supports ExpressCard right now for usb devices. They all work, and there's no additional work needed here, except maybe to make more drivers. In fact, I recently purchased an ExpressCard to CardBus adapter (one that lets me plug in an expressCard into a CardBus slot) and it worked with all the usb-based ExpressCards that I have laying around with no changes.
The problem with ExpressCard for PCIe-based devices is one of resource allocation. If the BIOS allocates the resource, then the ExpressCard works without hot-plug. If the BIOS doesn't, then we can see the device with pciconf -l, as well as probe the device. However, since there's no resources setup for the PCI bridge, attempts for the driver to allocate them fail. There's also some bus numbering issues as well.
I've started to attack the resource problem. I'll keep people posted
20090421
Update my old CardStatus page...
If anybody still cares about 16-bit PC Cards and 32-bit CardBus cards still, I've updated the latest testing I've done.
You can find it here. I think it does more to show what a big pack-rat I am, but maybe someone will find it useful. It shows I'm down to one or two ed cards that aren't working for me yet...
You can find it here. I think it does more to show what a big pack-rat I am, but maybe someone will find it useful. It shows I'm down to one or two ed cards that aren't working for me yet...
20090413
3Com 3C1 works
Years ago, I bought a 3Com 3C1 CF card. This card was an early attempt by 3Com to minimize the power usage of the traditional 3C589 line of cards. These cards were important for the early palm-sized PDAs that were on the market. Through a number of different connections, I was able to get documentation on the 3c1. At the time I got it, I barely understood network drivers or even how the hardware worked. The documentation I got from 3com had pages for the flow charts for transmit and ISR, but the flowcharts weren't actually included on those pages. My connections couldn't get a better copy of the documentation, always saying it was coming soon.... The descriptions of the commands had some vague hints, but I never could make them connect. This was around 1999 or so.
Over the years, I kept trying to make this card work on FreeBSD. I considered it unfinished business from my past and I kept trying to find time to work on it. I never could find the time, or if I had the time my brain was burned out from the deliverables I had to produce for work. Over the years I've acquired all the cards that I could find in the 3c5xx line and made them work, but never got the 3c1 working.
Recently I stumbled across the 3c1 documentation and had a few minutes to read it. It was a nice change of pace from all the other stuff I'd been working on lately. After reading through it, I realized that there were a few key items that I'd not properly implemented before. There was a cryptic new command to turn on and off the TX PLL. So I had 30 minutes the other night and started reading the document again.
In the interim between when I started looking at the 3c1 documentation and now I did a lot of work in the high precision time and frequency world. This world is all about PLLs and controlling the oscillators/clocks to an insanely high degree of precision. So this clicked in my brain "Hmm, TX PLL sounds like it controls the clock used to do the transmission." So everywhere we enabled TX in the driver, I added a call to turn on TX PLL. This got me started: dhclient worked! I was able to transmit packets. This was the first. However, it stopped working after a while. So I searched through the 3c1 docs. There was nothing about PLL enable and disable, except for the documentation of the command. It appears there's an automatic timeout in the hardware which was turning off the PLL. So, an additional enabling of the PLL in start did the trick. I only enabled the PLL when we're not actively transmitting (which means we were idle for some unknown period of time). I could refine it further if I knew what the timeout of the PLL (which isn't documented), but there appears to be no ill effects doing it all the time the TX unit has been idle.
Ah, one more piece of unfinished business from the past is now complete. I can move on to other more interesting things...
Over the years, I kept trying to make this card work on FreeBSD. I considered it unfinished business from my past and I kept trying to find time to work on it. I never could find the time, or if I had the time my brain was burned out from the deliverables I had to produce for work. Over the years I've acquired all the cards that I could find in the 3c5xx line and made them work, but never got the 3c1 working.
Recently I stumbled across the 3c1 documentation and had a few minutes to read it. It was a nice change of pace from all the other stuff I'd been working on lately. After reading through it, I realized that there were a few key items that I'd not properly implemented before. There was a cryptic new command to turn on and off the TX PLL. So I had 30 minutes the other night and started reading the document again.
In the interim between when I started looking at the 3c1 documentation and now I did a lot of work in the high precision time and frequency world. This world is all about PLLs and controlling the oscillators/clocks to an insanely high degree of precision. So this clicked in my brain "Hmm, TX PLL sounds like it controls the clock used to do the transmission." So everywhere we enabled TX in the driver, I added a call to turn on TX PLL. This got me started: dhclient worked! I was able to transmit packets. This was the first. However, it stopped working after a while. So I searched through the 3c1 docs. There was nothing about PLL enable and disable, except for the documentation of the command. It appears there's an automatic timeout in the hardware which was turning off the PLL. So, an additional enabling of the PLL in start did the trick. I only enabled the PLL when we're not actively transmitting (which means we were idle for some unknown period of time). I could refine it further if I knew what the timeout of the PLL (which isn't documented), but there appears to be no ill effects doing it all the time the TX unit has been idle.
Ah, one more piece of unfinished business from the past is now complete. I can move on to other more interesting things...
20090402
More PC Card enhancements
Every few months/years I take all the cards that I have in my collection and start to run through them testing to see what's working in FreeBSD and what's broken. Over the past year or two I've neglected this task as I've been involved in other things. After my last trip to Akihabara, I've been playing with this stuff, so I thought I'd pull out the cards again. However, for the moment, I'm restricting things to the cards supported by the ed driver.
I've already blogged about the AX88x90 enhancements. The only additional enhancement is that I've eliminated some code that duplicates reading the NIC from what is just memory. I'll be committing that soon.
I've finally implemented the workaround for fullduplex disabling SQE in the DL10019 parts. This gives slightly better performance on the parts that are affected, but I'm having trouble measuring it. I'm not sure that it is worth the hassle.
I've also made a number of cards work by tweaking the MII initialization. I think I have a good way to kick the PHYs that are on these cards to get them working (this has helped to get three cards going).
I'm approaching 100% of the ne-2000ish cards working. I'll do a final cleanup of my patches and try to get them into the tree. It is time to move on to the CardBus cards. Most of them appear to work, once certain resource allocation issues are addressed. At the very least I need to test them all to see how they work. I may skip this and move directly and address the resource issues there.
I've already blogged about the AX88x90 enhancements. The only additional enhancement is that I've eliminated some code that duplicates reading the NIC from what is just memory. I'll be committing that soon.
I've finally implemented the workaround for fullduplex disabling SQE in the DL10019 parts. This gives slightly better performance on the parts that are affected, but I'm having trouble measuring it. I'm not sure that it is worth the hassle.
I've also made a number of cards work by tweaking the MII initialization. I think I have a good way to kick the PHYs that are on these cards to get them working (this has helped to get three cards going).
I'm approaching 100% of the ne-2000ish cards working. I'll do a final cleanup of my patches and try to get them into the tree. It is time to move on to the CardBus cards. Most of them appear to work, once certain resource allocation issues are addressed. At the very least I need to test them all to see how they work. I may skip this and move directly and address the resource issues there.
20090330
AX88x90 updates
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).
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).
Subscribe to:
Posts (Atom)
