Monday, March 30, 2009

More HVR-950q i2c debugging

Since I've basically conceded that I am going to have to run at a 30 KHz i2c bus for the 950q, I started looking at where the rest of the time was being spent.

I started a new tree where I am putting in some incremental improvements, such as removing the unneeded udelay() calls, changing the xc5000 reset strobe to 10ms, etc. And I started profiling how the i2c bus is actually loaded with data.

Part of the problem is I have to program the au0828 registers for each byte to be sent. As a result, for a four byte sequence, I do one USB control command for each byte, one control command to strobe the bus, and then a series of read commands to poll for status. This results in huge gaps in the loading sequence, since the code does not continue to load new bytes in while it is strobing the bytes currently into the buffer onto the i2c bus.

(notice the 661us gap between sequences of four bytes)

I started to code up a prototype where as the polling for status was in progress, I would see how many bytes had been clocked out (stored in the top three bits of the status register), and writing additional bytes as the FIFO emptied. It appears to work, and I can see larger concurrent sequences appearing in the analyzer output (with the correct data). However, the intergroup gap appears to increase almost proportionately, thereby eliminating the benefit. There also appears to be a bug somewhere in my code that causes the loading sequence to abort about half way through.

I will probably give it one more night of experimentation before I give up. I've gone *way* off the supported path since this method isn't in the current driver or the Windows driver from what I can see in the USB trace.

Sunday, March 29, 2009


Victoria came out to New York this weekend. We did a walking tour of Union Square, and then had a nice dinner at Hangawi. Today we took it easy and spent a couple of hours at the coffee house.

This evening continued to work on the HVR-950q i2c implementation. It seems that at higher clock rates the au0828's hardware implementation drops the stop bit after certain write sequences. I can see it on the logic analyzer's dump (the master never pulls the signal high and it stays in that state until the next i2c sequence), but I cannot nail down the underlying problem yet. Seems like the au0828 might improperly handling the SCL clock stretching the xc5000 does after some operations (which is why it only starts to occur *after* the firmware load completes).

Update: I think I know what is going on now: The xc5000 *is* stretching the clock for 15 us. Now, when you're running at 100KHz, that means the clock basically gets held low for three cycles, which screws up the au0828 and causes it to not write the stop bit. However, if you turn the clock down to 30 KHz, the normal clock cycle is 17 us. As a result, the au0828 never notices that the clock is being held low by the xc5000, since it's inside the interval it would be holding it low anyway.

In other words, the au0828 has a crappy i2c implementation in its hardware. Basically, my options are to keep the clock at 30KHz, and suffer from the 10 second loading time, or get the au8522's i2c master working and refactor the xc5000 driver, which would allow me to use the au0828's faster bus mode for firmware loading, and a slower clock rate for sending the commands for tuning via the au8522.

Wednesday, March 25, 2009

HVR-950q i2c progress

Using the logic analyzer, I did some more debugging of the au0828 i2c implementation. I've got the xc5000 firmware load time down to about 3.2 seconds (down from 12 seconds).

There is still a bug that occurs whenever the dvb_attach queries the product ID. I suspect it is some garbage being dumped on the i2c line I am seeing about 1.3ms before the register query. I don't know yet where the garbage is coming from, but the i2c clock was at 250 KHz, which is pretty suspicious since it should only be in that mode when talking to the au8522 demod. Perhaps some sort of concurrency issue where both the dvb subsystem and the analog subsystem are trying to use the i2c bus at the same time? Or perhaps something screwed up with the i2c gate?

Will keep working on it tomorrow....

Tuesday, March 24, 2009

Saleae Logic Analyzer

My Saleae logic analyzer arrived from Sparkfun today. For those of you who might be doing some reverse engineering for linux-dvb, figured I would share my initial experiences.

First off, the actual analyzer is actually alot smaller than I thought it would be. Here is the full kit unpacked (it comes with the carrying pouch, a USB cable, and the probes):

Since I bought this to debug the i2c implementation for the HVR-950q, I broke out an iron and soldered a couple of coupling wires onto the board, and then hooked everything up:

I downloaded and installed the software, which went smoothly. I needed to download Windows Installer 3.1 via Windows Update, and the Saleae installer automatically downloaded .NET 3.5 (which took far longer than the installer for the analyzer itself). Also worth mentioning that this is a PC that I use solely for reverse engineering so a typical PC would probably have both of these prerequisites already installed. But once those two things were done, I plugged in the device and started up a capture:

Here is a screenshot of the first capture:

The verdict? To my shock, it worked perfectly the first time. I started the capture, plugged in the device, waited for the firmware to finish uploading, and then stopped the capture. The user interface made it very simple to tell it to decode i2c (asking for which signals were for the clock and data pins), and I was able to drill down and see the actual traffic.

If you click on the above screenshot, you can see that the i2c clock is running at 29.4 KHz (which is pretty slow). When I did the analog support I had played around with the clock divider register until I had found a value that worked. Now that I can see how the clock divider register effects the actual clock, I can tune it to the proper value (around 100 KHz). Also, you see that huge gap between the bytes? That's the effect of of a pair of 500ns sleeps that occur in the current code. With the analyzer you can see that it has a huge effect on the overall firmware download time.

Long story short, the analyzer was worth every penny. I can see the effects of the code changes, and I should be able to get the 12 second firmware loading process down to around 1 second.

(just a quick addendum - after publishing this I noticed the screenshot looks like crap. The actual GUI looks much better and the dithering was just from the conversion to gif and livejournal's rescaling). Also, you have to click on the image twice to get it to show in full scale.

Sunday, March 22, 2009

HVR-950q frame droppage and other stuff going on...

Spent the weekend in Philadelphia with Victoria.

Robert Krakora was nice enough to show me a test case where mplayer had issues with the analog video constantly slowing down and speeding up. Turns up there is a pretty serious bug in the isoc handling code which is causing entire fields to get dropped. Ugh. That's going to be a pain to nail down (I already spent two hours on it Saturday).

Trying to get some consensus on how SNR should be represented in the kernel interface, so that applications can reliably show the information without the format varying from device-to-device. Hearing lots of different views, and I'm hopeful that this issue can finally be put to rest this week.

Issued a pull for a few miscellaneous fixes tonight that have been queuing up:

The xc5000 stuff is continuing to move along in the background. I will hopefully have more to say about it later this week.

Thursday, March 19, 2009

Paying homage to good science fiction...

I was reading a discussion on computer viruses tonight, where someone suggested the following:

If you have malicious code running in ring 0, you're already so boned, you really need to dust off and nuke it from orbit.

I like how that nice little line of Ripley's from Aliens has made it into common dialog.

Tuesday, March 17, 2009

xc5000 tuner improvements

A few months ago, I put together a series of patches for cleanups and improvements to the xc5000 driver:

These changes never went into the codebase, since there were issues with the XREG_BUSY polling. Thanks to Pinnacle, I gained access to the Xceive reference driver code and newer 1.3 firmware, which properly supported the XREG_BUSY register. This means that tuning time goes from 3200ms down to about 300ms (a 10x improvement).

There was one problem: the power management register stopped working in the newer firmware. This means I had to choose between the 1.1 firmware which was much older but had proper power management, or the 1.3 firmware that had fast tuning but no power management.

With the HVR-950q analog work pretty much wrapped up, I finally sat down and dug deeper into the problem, confirmed it definitively, and emailed Xceive support a full explanation including how I reproduced the issue.

They actually got back to me within a couple of hours! It turns up they got rid of the register and the supported way to put the device to sleep is just to strobe the reset pin. I implemented it in about five minutes, and now with the 1.3 firmware I have both fast tuning *and* power management. Yay.

All I need now is to straighten out the redistribution rights on the 1.3 firmware and this stuff will go into the mainline.

Most people don't worry about a three second tuning time when doing digital, however being unable to "channel-surf" with analog is something that gets annoying really fast.

Sunday, March 15, 2009


Haven't posted in a while. Things have been pretty busy lately. Continuing to deal with feedback from Mauro and Hans on what is required to get the 950q analog support into the mainline. I think I've resolved all their outstanding issues:

I also put together a patch for the ARM based LinuxStamp so that V4L devices work with both the em28xx and usbvision drivers. I've collected three or four miscellaneous patches and will include it in the PULL request. Unfortunately, once the panic was fixed I realized that the ARM chip in question only has a full-speed USB bus (as opposed to high speed), so getting captures with modern raw video devices will be problematic. They are generally not designed to work with 12Mb/s USB. So, if they want it to work, we will have to find an older device that is designed to work with the full speed bus, or extend the usbvision driver to support the NT1004 640x480 capture mode (currently the driver only supports 320x240).

Finished watching the West Wing series on DVD. At 46 disks it's a safe bet that is pretty much the only thing I've watched on TV for the last few weeks. Tonight got caught up on "Terminator: The Sarah Connor Chronicles", which I didn't realize had started back up again about six weeks ago. Yay for networks making available back episodes available online!

Sunday, March 8, 2009

Stone passed. Yay!

I just passed my stone, and I feel like a huge weight has been lifted. Still a little tired, but looking forward to getting back to being productive.

When they said 3-4 weeks, I freaked out. But four days I could handle.


Thursday, March 5, 2009

Devin on Morphine!

So I woke up yesterday morning at 6:30am and had to go to the ER, which turned up to be the result of kidney stone. Ouch.

This is me on morphine. That stuff works good.

Now I'm home and just waiting for the thing to pass. Victoria has been kind enough to take care of me (which is good because keeping track of the five different prescriptions I'm on needs help). Hoping that the situation resolves itself either today or tomorrow.

Tuesday, March 3, 2009

950q subdev conversion

Spent most of last night working on the only real remaining issue before the 950q support can be merged - conversion to the v4l2_device/subdev framework. While the au8522 demod driver is already converted, I still had to do the au0828 bridge, which is proving to be quite a challenge. Because I don't have any other devices configured that use the framework, it's a bit troublesome to compare the behavior of the subdev registration process. Perhaps I will get my HVR-1600 installed, so I can see how the cx88 driver behaves.

I'm going to have to litter the i2c core with some debugging so I can figure out why the device registration is failing.

If any of the 950q analog testers are reading this, feel free to update to the latest tree and let me know if you see any issues:

(this includes the i2c enumeration fix from a couple of nights ago)

Monday, March 2, 2009

950q i2c fixes

This weekend continued to work on various outstanding 950q analog bugs. Isolated one of the more annoying problems related to i2c enumeration returning false positives, and checked in a fix (removing the really nasty hack).

The list of things outstanding for the merge is getting shorter:
  • More testing
  • Robert's case of "choppy video"
  • Conversion to new video subdev framework
  • Possible issue with colorspace one user reported with mplayer (so far unreproducible)

In addition, I'm still looking to do the following at some point after the merge
  • VBI support
  • Better power management when idle