Lattic iCEcube2 on Debian

I recently started looking at Lattice chips for a project that needs a fairly small FPGA. They have small devices that are significantly lower in cost than the larger Xilinx Spartan chips I've used in the past. To explore further, I ordered the ICE40HX1K eval board ($22) and downloaded the free iCEcube2 IDE for my Debian stable(Jessie) 64-bit PC.
The first try at installing the IDE hit issues:
 error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory
The library is installed, so obviously the IDE wants the 32-bit version. I haven't tried to work with 32-bit stuff since Debian went to the multiarch approach, so that led to a new learning experience. Previously one would install ia32 versions of the needed libraries. After a bit of googling, I found that the current approach is (as root, or using sudo):
dpkg --add-architecture i386 # Include 32-bit stuff
apt-get update  # Add in the lists of 32-bit packages.
apt-file search libXext.so.6 # Find out what package I need - libxext6 in this case.
apt-get install libxext6:i386 # Add the 32-bit version of thepackage.
Now, the install fails because it's missing libpng12.so.0, so repeat the apt-file search and apt-get install steps for that. In Total I ended up installing  libpng12-0:i386, libsm6:i386, libxi6:i386, libxrender1:i386, libxrandr2:i386, libxfixes3:i386, libxcursor1:i386, libxinerama1:i386, libfreetype6:i386, libfontconfig1:i386, libglib2.0-0:i386.
With that, iCEcube2 installs and runs.

Now I can start playing with the eval board when it shows up.

Notes:

hackaday.io/project/6592-dipsy/log/24272-installing-icecube-2-on-ubuntu-14042-lts  Pointed me in the right direction to complete the install. Their Dipsy project uses the Lattice chip, and looks interesting.

Debian on BeagleBoard classic.

I have one of the original beagleboards with the omap3 processor, which is ARM+DSP coprocessor. Originally it used the Angstrom Linux distribution, which uses bitbake to build the kernel and all related software tools. I saw recently that Debian is now supported on this device; I like to run Debian on everything including my PC's, BeagleBone Black, and Raspberry Pi (raspbian - almost Debian), so why not on the beagleboard as well?
My hardware setup is a USB-serial adapter from a Linux (Debian, of course) host to the serial port of the Beagleboard. I also have a Sabrent USB-Ethernet adapter on the Beagleboard.
The "official" instructions seem to be at elinux.org/BeagleBoardDebian, which I found from beagleboard.org/project/debian. Per those instructions, I downloaded the netinstall package from github.com/RobertCNelson/netinstall (using git of course), and put it on a 16GB SD card using the command:

sudo ./mk_mmc.sh --mmc $SDCARD --dtb omap3-beagle --distro wheezy-armhf --firmware --serial-mode

On my PC I have SDCARD=/dev/sdb, because that's where the memory card shows up when it's plugged in. MAKE SURE you get this right, because you could wipe out a disk on the PC if you get it wrong. I decided to uses the --serial-mode option to work from the serial port and avoid any HDMI display issues.
Moved the SD card from the PC to Beagleboard, powered up, and got a typical Debian install menu on the serial port! I used

minicom -D /dev/usb/prolific2303 -b 115200 -o

to connect to the USB-serial port. The Beagleboard serial port does not use the modem control lines, so had to turn off the "Hardware Flow Control" and "Modem has DCD" options in minicom.
The netinstall process was just like installing Debian on a PC: select some options and wait for it to download a bunch of packages. It found the Sabrent ethernet and used it with no problem; device usb0 shows up as a network device as well, so it should be possible to install by using a USB connection to the PC host, but I didn't try that.
Finished the install, rebooted the Beagleboard, aaaannnd - nothing happened!!! Load process just stopped in uboot. After a few hours of screaming, hair-pulling, and spelunking in uboot macros, I found the problem:
I had set up /boot as a separate partition.
The uboot macros look for  /boot/uEnv.txt on each partition and then boot Linux using that partition as the root partition. Made /boot a normal directory instead of a mount point, patched up /etc/fstab, and uboot brought up Debian with no problem.
Did my usual Debian tweaks (sensicomm.blogspot.com/2013/01/my-debian-tweaks.html) and everything seems to be working as expected.

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).

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.