Recently, I started hacking a TiVo HR10-250 that I've had for a million years unhacked.
Back when I first got it, there were dozens of threads of hundreds of messages in about 10 different forums you needed to read in order to hack the goofy thing. Everybody did their own thing, it was manual and a big pain.
Then came zipper (you can find all the details out at this link). It makes it very easy to hack the TiVos in general. However, there was just one problem. The ISO authoring tools it used were windows-based. Since I don't generally run on a Windows machine, this was a problem for me. So I tried to do the steps from the batch file by hand, and it didn't work out so well.
So I rewrote the batch file in a unix script running on FreeBSD. FreeBSD's iso extraction feature of tar made this process hassle free. I can build a new ISO image from an old one using only one port (mkisofs) and no privs are needed at any step. I thought about trying to teach tar how to create an iso image, but since mkisofs does such a good job, and there are *SO* many knobs and dials that need to be implemented to do that right, I just let mkisofs do its thing. I just can't get over how easy FreeBSD's tar made it to break apart the old bootable cd that does the hacking to add the zipper files. Kudos!
I've uploaded the script to the TiVo Community Forum thread about zipper if you are interested in looking into it.
20091105
20091104
T-Mobile and iPhone 3.1.2 firmware update issue
Recently, I used PwnageTool on my mac to update my 2G iPhone from 2.2.1 to 3.1.2. I've been using T-Mobile since day one with my iPhone without hassle. Well, except for the upgrade hassles that I have from time to time. Once I unlocked the SIM, I was able to use the SIM from my T-Mobile DASH in the phone.
When I upgraded this time, however, there was a problem. My data connections stopped working. Since 3.1.2 was otherwise a nice upgrade for me, I went looking for the problem. It turns out that the bundled carrier files that describe what you can and can't do with the iPhone basically said no data.
Carrier files that are correct for T-Mobile, and the data plan I have, can be found iPhone-Dev.ca under the IPCC section of the web page. Instructions for loading the IPCC file were there as well. For T-Mobile, you'll need to call T-Mobile to find the right APN to use. For my plan it turned out to be wap-apn. Your milage may vary, but worst case would involve trying all 4 of the files.
While not a programming hack, this should come in handy for anybody that's in a similar situation. Alas, I have no experience with the 3G or 3GS phones, and problems with the upgrades for those phones seem to be more widely covered (and blogged about).
When I upgraded this time, however, there was a problem. My data connections stopped working. Since 3.1.2 was otherwise a nice upgrade for me, I went looking for the problem. It turns out that the bundled carrier files that describe what you can and can't do with the iPhone basically said no data.
Carrier files that are correct for T-Mobile, and the data plan I have, can be found iPhone-Dev.ca under the IPCC section of the web page. Instructions for loading the IPCC file were there as well. For T-Mobile, you'll need to call T-Mobile to find the right APN to use. For my plan it turned out to be wap-apn. Your milage may vary, but worst case would involve trying all 4 of the files.
While not a programming hack, this should come in handy for anybody that's in a similar situation. Alas, I have no experience with the 3G or 3GS phones, and problems with the upgrades for those phones seem to be more widely covered (and blogged about).
20090514
Broadcom BCM43xx support (bwi) committed
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.
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.
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...
Subscribe to:
Posts (Atom)
