Last year I did some experiments with the Theora video decoder on a Texas Instruments DM642 DSP. A royalty free video decoder is very attractive for embedded devices, but after some major restructuring for performance, some problems remained.

The main problem is that, unlike MPEG video, Theora video is not packed in the bitstream in the raster order that it is displayed on screen, but instead in Hilbert curve order. This is not a problem in itself, but Theora’s DC prediction and post-processing loop filter are both defined in raster order. The need to go over the data once in Hilbert curve order and once in raster order leaves Theora decode requiring higher memory bandwidth than MPEG decode.

The encoder faces a similar problem. Andrey N. Filippov describes an FPGA implementation of the Theora Encoder, and comments on the high memory bandwidth required. The solution in the article is to implement a custom SDRAM controller with knowledge of the Theora data structures, an option not available on a DSP.

There are other minor problems remaining. The DM642 has instructions to assist video encoding and decoding, but these are optimised for MPEG and may not easily apply to Theora. For example, the avg2 instruction averages two pairs of 16-bit values, but it uses the formula (x + y + 1) >> 1, whereas Theora’s half-pixel predictor uses the formula (x + y) >> 1.

Where does this leave Theora decode on DSP? The DM642 is just capable of decoding NTSC quality video (640×480, 30fps) provided that the bitrate is controlled. The good news is that the newer DaVinci architecture provides extra memory bandwidth through a DDR2 memory controller, plus the possibility of splitting the workload to place bitstream decode on the ARM processor and frame reconstruction on the DSP.

After several years of use, the server for my development machines developed a problem. If I rebooted the machine without an internet connection, it would pause for several minutes while starting the NFS service.

The Linux NFS server keeps track of status in several files. Whenever a client mounts a filesystem, the server records this in /var/lib/nfs/rmtab. If the server reboots, exportfs passes this list to the kernel to ensure that the reboot is invisible to the clients. So far, this is harmless.

If the server is used with clients that do not send clean unmount requests, such as diskless machines in a development lab, then rmtab fills up with entries for machines that aren’t around anymore. This is mostly harmless.

The final part of the problem is that on reboot exportfs performs a reverse DNS lookup for each entry in rmtab. If the DNS server is unavailable, the request waits for a timeout. This can take a very long time.

And the moral of the story? If NFS clients come and go on your network, check rmtab for clutter.

As of Linux 2.6.9.1, the driver is in the kernel as i2c-mpc.c. This version of the driver has been tested on Tsi107 (formerly MPC107), and on MPC8240, MPC8540, and MPC5200 PowerPCs. Thanks to all the testers.

The Tsi106 (formerly MPC106) and Tsi107 (formerly MPC107) PowerPC host bridges both contain a data cache. This note describes why it may be necessary to mark memory as SMP coherent even in a single processor system using these bridges.

The driver has so far been tested on a small number of systems and with a small number of I2C parts. Thanks to Gleb Natapov, Matthew S. McClintock, and others for testing. Further test results are welcome.Read more

These are experimental Linux 2.2 and 2.4 framebuffer drivers for the Asiliant 69030 graphics chip. This chip was previously available from Intel, and is descended from a Chips and Technologies part. The 2.2 driver is thus based on the Linux chipsfb.c driver, which supports the 65555 part in certain Apple Powerbooks. The 2.4 driver is also based on work by Jordan Crouse.

The driver currently leaves the flat panel as it was set up by the BIOS. In most cases this displays the same image on flat panel and VGA outputs. The goal for the driver is to support multi-head operation, and multiple 69030 chips. The driver supports operation without a VGA BIOS for embedded applications, but currently contains no flat panel setup code.

These are experimental Linux 2.2 and 2.4 framebuffer drivers for the Asiliant 69030 graphics chip. This chip was previously available from Intel, and is descended from a Chips and Technologies part. The 2.2 driver is thus based on the Linux chipsfb.c driver, which supports the 65555 part in certain Apple Powerbooks. The 2.4 driver is also based on work by Jordan Crouse.

This driver is experimental, but is intended as a basis to merge into the mainstream kernel. Though the driver should work on the 69000, I currently have no 69000 hardware to test it on. Reports of using a panel and CRT simultaneously on 69000 are very interesting.

Current PowerPC kernels have a number of flaws in their machine check handling. The first fault is that they raise a SIGSEGV exception if the machine check occurs during user mode code. Many causes of machine check are not directly related to the current process. For example, on some platforms a PCI parity error detected while a PCI bus master writes into memory will cause a machine check. On some platforms a parity error reading data from the L2 cache in order to write it out to memory will cause a machine check.