via-rhine in Debian Wheezy

This blog post is only of interest to a small handful of people,  but since you found it, it might be you :). As always with system changes, there's a chance of damage or data loss. So check your backups first.

I have an old Averatec notebook that I use for travel and when I don't want to take risks with my main PC. I'm planning a trip so it's time to update to the latest debian distribution. After the update, everything seems to work, except the via-rhine wired ethernet.
The symptoms appear similar to Debian bug report 708757 . After a lot of hacking and experimenting, I finally upgraded to the latest kernel in wheezy-backports and the problem went away.

Details:

lspci shows the device as:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

It does work with Debian kernel packages:
 linux-image-2.6.32-5-686  # Old, from previous Debian distribution.
 linux-image-3.14-0.bpo.1-686-pae # Very latest, bleeding edge.

And does not work with
linux-image-3.2.0-4-686-pae # debian stable kernel for my system.

Fix:

To get the very latest kernel, you need the backports repository. Best instructions I found were:
scottlinux.com/2013/11/23/how-to-install-newer-kernel-from-debian-wheezy-backports
 Basically,
1) add wheezy-backports to /etc/apt/sources.list
2) apt-get update
3) apt-get -t wheezy-backports install linux-image-3.14-0.bpo.1-686-pae
4) done. reboot to use the new kernel.

Cleanup:

One side effect of the bug is that it returns a wrong and somewhat random MAC address for the ethernet controller. Recent versions of Debian try to ensure that each MAC address is always associated with a consistent eth* number. So each random mac address gets assigned to a new eth* number. If this is happening the output of dmesg will show messages like:

udev: renamed network interface eth0 to eth7

Every time udev sees a new MAC address it adds it to /etc/udev/rules.d/70-persistent-net.rules,
so the fix is to edit that file and remove all the junk MAC addresses.


STM32 on Linux, again.

Starting another project using the STM32 micro, so time to update and reinstall the toolchain. This is an update to my previous post on the topic at http://blog.sensicomm.com/2012/01/stm32-stm32f4discovery-arm-eval-board.html

Compiler

Previously I used the summon-arm gersion of GCC http://summon-arm-toolchain.org/
but the git repo says it's "not under active development" any more. They recommend https://launchpad.net/gcc-arm-embedded , which seems to be an offically ARM-supported
version.

It looks like Debian has packaged the launchpad version into the "unstable" branch: http://packages.debian.org/sid/gcc-arm-none-eabi but I'm running "stable" so I got it directly from launchpad instead. Install was simple:

• Download  gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
• unpack in /opt,
• add to PATH
• Create symlink:  cd /opt && ln -s gcc-arm-none-eabi-4_8-2013q4 gcc-arm-none-eabi

That's my setup, the chosen directory is just a matter of personal preference.

Programming tools:

I'm using the STM32F4DISCOVERY board for development, so there are two ways to get code
into the chip:

1. Use the st-link USB input to the built-in programming hardware.
2. Connect directly to the USB port of the STM32F4 chip and use dfu-util.

I used dfu-util before. That's now in Debian, and should still work but I haven't retested it.



Code for the st-link interface is available and built with no problem:

• git clone git://github.com/texane/stlink.git stlink
• cd stlink && ./autogen.sh && ./configure && make && make install

Programs are installed in /usr/local/bin: st-flash st-info st-term st-util

An example was successfully placed in flash using:
st-flash write *.bin 0x8000000

Libraries:

The open source libraries and examples at http://libopencm3.org/wiki/Downloads built without problem using the launchpad compiler. My build command was:
PATH=/usr/bin:/bin:/opt/gcc-arm-none-eabi/bin DESTDIR=/opt/libopencm3 make install

ST has standard peripheral library source code on their website, but it doesn't come with Makefiles. A USB serial example at http://vedder.se/2012/07/usb-serial-on-stm32f4/ includes some (all?) of the ST libraries and compiles fine with the launchpad compiler. I downloaded and unpacked STM32F4_USB_CDC.zip and "make" ran without problems. I only had to change the top-level Makefile so that BINPATH points to the directory that arm-none-eabi-gcc is in
(BINPATH=/opt/gcc-arm-none-eabi/bin for my install).

Linux system clock and hardware clock accuracy?

This is a followup to the "my Debian Tweaks" post on on Jan 21. Briefly, my PC tends to spend a lot of time disconnected from the Internet, and the default clock management as implemented in /etc/init.d/hwclock.sh doesn't work very well in that case.

Debian timekeeping background

Linux on Intel-based PC's has two timekeepers, often referred to as the system clock and the hardware clock. The system clock is based on a high frequency crystal oscillator and is mainly intended for timing and scheduling programs and such. It doesn't run when the system is turned off, so it needs to be initialized with the current time when the PC is powered on. The hardware clock is a battery-backed circuit that keeps time even when the PC is off; it provides a value to initialize the system clock at power up and is rarely used for anything else. Debian systems assume the system clock is more accurate than the hardware clock, and they update the hardware clock every time the system is powered down (see /etc/init.d/hwclock.sh).

So how accurate are the crystal oscillators for system and hardware clocks?

Relative accuracies of these clocks depend on the specific PC. The only spec I found in a quick search is 500 parts per million (PPM) in the Intel HPET timer spec software-developers-hpet-spec-1-0a.pdf. The system clock may or may not be related to the HPET timer. Timing crystals are usually spec'ed at 100 PPM or better even for cheap crystals, so 500PPM sounds like a really loose spec.
The PC hardware clock typically uses a 32.768 kHz watch crystal and a battery-backed timing circuit (you can see the coin cell battery in the photos in my Dec 24 2012 posting). Watch crystals are readily available with 20 PPM accuracy specs, and the frequency is generally stable with time and temperature. For example, the CFS206 available from Digikey and other distributors is 20PPM accuracy, 3PPM per year max drift and .034 PPM per degree C temperature sensitivity. So timekeeping accuracies of a few PPM should be feasible with some calibration.
The US National Institute of Standards and Technology did an interesting study of wristwatches, tf.nist.gov/general/pdf/2276.pdf, and found that even a cheap[2] ($30) modern watch can achieve better than 1 PPM timekeeping accuracy. Older quartz watches were orders of magnitude worse, which implies that manufacturers have started calibrating the crystals in the last few years. So a PC's hardware clock should be capable of similar performance.

How good are the clocks in my PC?

Here's a quickie experiment with my main PC, an Acer Aspire 5253 notebook  with hardware clock updating disabled in hwclock.sh.  I set the hardware clock on Feb 13, 2013, and it hasn't been touched since. The hardware clock lost 6.227 seconds in 4609045 seconds (about 53 days), which is an average frequency offset of 1.35 parts per million (PPM).[1] In contrast the Linux system clock lost 0.44 seconds in 9103 seconds (about 2.5 hours), which is 48 PPM.
I checked a couple of older systems and their hardware clocks are in the 6 to 10 PPM range. So newer PC's are probably being calibrated like newer watches are. I suspect that the hardware clock is still more accurate than the system clock on the older PC's, but the difference should be less pronounced.

My Setup

The hardware clock in the Acer Aspire is more accurate than the system clock by a factor of 35, so that's why I don't let hwclock.sh update the hardware clock on shutdown; instead I manually set the time using ntpdate-debian every month or so, and manually update the hardware clock at that time. That keeps me within 3 seconds or so of true time, which is more than adequate for my purposes.
There are routines (adjtimex and such) that attempt to improve the calibration of the hardware clock and/or the system clock. They generally assume the oscillators are off by a fixed percentage from the true rate and that frequency changes due to temperature and drift are insignificant. In the 1 PPM range I doubt that that's true, so I don't bother with adjtimex and friends.

Side Notes

[1] I checked my Timex DataLink USB watch at the same time, and it lost about 2 seconds over the same interval. So it's averaging around 0.5 PPM.
[2] And if you want to spend a few thousand dollars, you can get a Grand Seiko SBGX059 which is spec'ed at less than 10 seconds per year, or about 0.3 PPM. Nice, but I think I'll stick with my sub-$100 Timex.

My Debian tweaks

When doing a new Debian Linux installation, there are a set of basic configuration changes that I nearly always make. While the issues do not apply to everyone, I think they are common enough that many others may find them useful. As always, your mileage may vary, use at your own risk, etc.
My system is Debian Testing installed on a laptop that is typically shut down at night and that often runs disconnected from the Internet. So here are the problems I often see and my solutions:

1. PC locked by fsck. The fsck partition check program typically runs every 30 reboots or so on EXT2/EXT3 filesystems (and maybe others). This automatically happens during the boot process and, per Murphy's law, it usually happens while setting up a critical demo or presentation. The problem is that it can't be interrupted, so the group gets to spend several minutes watching the progress bar slowly move. The fix is to add the lines:
   [options]
   allow_cancellation = true
   to the file /etc/e2fsck.conf. One site that discusses this fix and potential issues is wiki.archlinux.org/index.php/Fsck
2. Boot pauses due to exim. When booting while not connected to the Internet, the exim mail handling program may hang for 60 seconds. I found that adding
   MAIN_HARDCODE_PRIMARY_HOSTNAME = mypc.example.com
   to /etc/exim4/exim4.conf.localmacros gets rid of the hang, where mypc.example.com should be changed to whatever is appropriate for that PC. Depending on other configuration options, this line might belong somewhere in  /etc/exim4/conf.d instead.
3. Annoying computer beep.For some reason, many programs seem to think a loud "beep" on errors is a helpful feature. I'm one of the legions that disagree, so I disable the pcspkr device by adding
blacklist pcspkr
blacklist snd_pcsp
to a file in the /etc/modprobe.d/blacklist directory. See www.thinkwiki.org/wiki/How_to_disable_the_pc_speaker_%28beep!%29 for example.
4. Hardware Clock. Normal PC's have a hardware clock that keeps track of the date and time of day even when the PC is powered off, and Linux also has a system clock that keeps time when running. This system clock is initialized from the hardware clock while booting. In normal Debian setups the /etc/init.d/hwclock.sh script also copies the system clock back to the hardware clock during system shutdown. That's a problem in my system because it's using the less accurate clock to reset the more accurate clock. One fix is to install the ntpdate package; then the system time gets set whenever an Internet connection comes up. Another option I use sometimes is to edit hwclock.sh to disable the hardware clock update, and just set it manually. I'm planning a more detailed post on this issue.

STM32 STM32F4DISCOVERY arm eval board and Linux

Picked up this eval board at the last Embedded Systems Conference, and finally starting to work with it. The chip is a 168MHz ARM Cortex M4 with 12-bit A/D and D/A's . The eval board includes an accelerometer, microphone, and separate audio D/A chip, among other things. Pricing is really interesting. Here are Digikey quantity-1 prices:
STM32F4DISCOVERY $19.50
STM32F407VGT6     $16.00
STM32F103C8T6    $ 5.71
(The F407 is the main ARM chip, and the F103 is a smaller ARM chip used as a programming interface). So the eval board is actually cheaper than the chips on it.

The F407 chip has a built-in program loader using either the serial port or the USB port. Both are supported by Linux tools, so I'm ignoring the F103-based programming port and using the F407's USB port.

Connections: I have USB cables from my Linux box to both the F103's mini-USB connector at the top and the F407's micro-USB connector at the bottom. The mini-usb is just used to supply power to the board, and isn't necessary if an external supply is used.

The programming tool is dfu-util, from dfu-util.gnumonks.org . I downloaded and built the latest version from the git repository. To test it, I used the miniblink example program from the libopencm3 package at www.libopencm3.org/wiki/Downloads . libopencm3 uses the summon-arm toolchain, so I downloaded and built that as well so the example would compile easily. (This also means I now have 5 different versions of GNU GCC for ARM on my system: summon-arm (linaro-based), 2 from CodeSourcery, one from openembedded, and a built-from-scratch GCC. One of these days I'll simplify that).

To program, I connect a jumper between the 3V and boot0 pins on connector P2. After hitting the black reset button, lsusb shows USB devices connected as:
Bus 001 Device 011: ID 0483:df11 SGS Thomson Microelectronics STM Device in DFU Mode
Bus 001 Device 012: ID 0483:3748 SGS Thomson Microelectronics ST-LINK/V2
To use it without being root, I also added the line:
SYSFS{idVendor}=="0483", SYSFS{idProduct}=="df11", MODE="666" GROUP="plugdev" SYMLINK+="usb/stm32_dfu"
to plugdev (in Debian, I just created a new file in the /etc/udev/rules.d directory with this single line in it. Locations may be slightly different in other Linux distributions).
With that done, the command:
dfu-util  --device 0483:df11 --alt 0 \
        --dfuse-address 0x08000000 \
        --download /miniblink.bin
works. I removed the jumper and hit reset again, and a single LED blinks, as expected.

So that's "Hello, World" for the STM32F4DISCOVERY. Now I can start doing real work with it.

Atlys and HDMI on Linux

Xilinx App Note 495 describes sample implementations of DVI/HDMI receiver and transmitter on the Digilent Atlys board. I built the code using WebPACK 12.4, and it works as advertised: The colorbar test pattern displays nicely on my HDMI monitor.

Also installed Digilent's Linux version of their Adept tools for FPGA programming. They don't seem to have the full GUI version available, but the command-line tool was able to load my test code (as a WebPACK-generated .bit file) into the Atlys FPGA with no problem. Don't see any way to load code into the SPI flash: it appears that Windows-based tools are still needed for that.

Only one minor glitch: I use Debian, which isn't one of Digilent's supported distributions. In recent versions of Debian, the udev package doesn't allow plugin devices to have protection mode 0666, which means that the Digilent tools will only work if run as root.
The fix is to edit "/etc/udev/rules.d/52-digilent-usb.rules" and add a group:
SYSFS{idVendor}=="1443", MODE="666" GROUP="plugdev"
then any user in the "plugdev" group can run the Digilent tools. The /etc/group file should have a line like
plugdev:x:46:jr
where "jr" is my username.

Digilent Atlys

For Christmas, Santa Claus brought a Digilent Atlys development board for the Xilinx Spartan-6 FPGA's. Nice board, with a bunch of peripherals (Ethernet, USB, audio, HDMI!, etc).
The HDMI interface and protocol is implemented as firmware in the FPGA. My only test so far was to connect an HDMI output to a monitor and power up the board. It generates a test pattern of colored squares right out of the box. Nice. 2011 is going to be interesting.
While setting it up, I also noticed that Digilent now provides tools for Linux programming and communication with their FPGA boards. Need to check those out as well.

Grub-ing

Just got a nice Gateway quad-core PC to speed up FPGA designs, so time to install Debian Linux on it. Install went smoothly, until I tried to boot into Linux for the first time. Then I get error messages:
ata1: softreset failed (device not ready)
ata2: softreset failed (device not ready)
and Linux hangs.
After a lot of Google-ing and hacking (and hair-pulling), I finally found the problem: The Debian installer set the boot partition on the SATA drive to /dev/sdb3, and it really should have been /dev/sda3. Still get the "softreset failed" errors, but Linux boots and seems to operate normally.
Thinking about the problem: I used a USB DVD drive for the install, and then disconnected it before booting. I suspect the DVD was sda and the sata disk was sdb during the install, and the sata became sda when booting without the DVD drive.

Dying Disk.

My old Winbook laptop (100 MHz 486!) finally died. I was using it as a private webserver, mail collector, Christmas light controller, remote access when I'm away, etc. So it's been running 24/7 for about 5 years now. The battery died several years ago, and the hinge cracked, but the guts still worked fine and it doesn't suck too much power. So, if it ain't broke too bad, don't fix it.
Finally, the disk started sticking: I have to pick up the PC and shake it to get the drive to start spinning so it can boot. Now the fun part: I decided to move the drive to a new PC and copy all the settings off before it died completely. Unfortunately the disk was too big for the BIOS in the 486, so it's formatted with an OnTrack DiskManager partition hack, and the new PC (running a Debian Linux 2.6 kernel) doesn't see the real partitions. Google found 2 couple of suggestions: Add the hda=remap or hda=remap63 kernel option in grub (didn't help), or use device-mapper (didn't find any instructions on how to actually do it). Apparently, DM support was deleted in 2.6. So, I rebooted with a 2.4 kernel, whacked the drive with my hand, and all my partitions were readable without changing any settings.
The disk did die for good shortly after that. I suppose I could dig up an old 2.5 drive and get a few more years out of the 486, but I think I've gotten my money's worth.
I think I'll get the backups on my main PC up to date, then go back to useful work.

Starting FPGA project

I've just started working with the Xilinx Spartan-3AN development board. First step was getting the USB interface to work with my Debian 32-bit Linux system. Fortunately, the latest (10.1) version of the Xilinx ISE WebPACK software supports a nice interface using the libusb package. Notes on the system are now on my website, at www.sensicomm.com/main/projects/fpga/ieee_fpga.shtml