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
20090423
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.
Subscribe to:
Posts (Atom)