Category: Arch Linux

raspberry pi, weekend edition 16 february

whbeebe

I’ve been working to get my Raspberry Pi’s Arch Linux software fully configured for the last three weeks. This past week I worked to find either a better solution for twm, or a better configuration for twm. I also worked to add more software to manipulated and control the I2C and GPIO peripherals.

I upgraded Arch Linux for Raspberry Pi to the current repository release as of 16 February 2014.

I tried a number of light-weight window managers, two of which were fvwm and gnustep. In the end I went back to twm and started to find ways to configure that environment. Pi’s twm environment now has simple icons and background tiling, as well as colors other than dark red and black. The color styling is now around blues and greens, with very small primary colors to pick out important information (see vi above). I’ve spent enough time configuring twm and installing a few more X applications.

I have too many icons on the window bar. I need to dig a little deeper to trim off the ones I don’t want and keep the ones I like. That’s the last task before I declare victory and move on.

This week I installed node.js native bindings for I2C and GPIO. The packages were i2c and onoff. The largest window shows the installation of onoff (npm install onoff). I’m now to the point where I’m beginning to do simple wiring of devices (LEDs, switches, and FETs) to the various digital inputs and outputs. I’m looking for an inexpensive I2C device that I can use for later projects to test that.

I’m also looking at picking up a pair of BeagleBoard Black cards. Arch Linux supports those cards as well.

I’ve run into a problem with using SDHC cards. The file systems on two cards are beginning to behave oddly. What follows is the output captured via dmesg after the event was noticed by me.

[   30.078810] EXT4-fs error (device mmcblk0p5): ext4_mb_generate_buddy:755: group 19, 18079 clusters in bitmap, 18080 in gd[   30.106892] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p5, blocknr = 0). There's a risk of filesystem corruption in case of system crash.[  303.846051] EXT4-fs (mmcblk0p5): error count: 4[  303.846092] EXT4-fs (mmcblk0p5): initial error at 1392587916: ext4_mb_generate_buddy:755[  303.846114] EXT4-fs (mmcblk0p5): last error at 30: ext4_mb_generate_buddy:755

This concerns me because I don’t fully understand what is happening. This is the second time I’ve seen this. I saw it first while using a Samsung 16 GB microSDHC UHS-I Pro card. The second time was with an older Toshiba 8 GB SDHC UHS-I card. I have concerns using SDHC cards as file systems with a Linux system, especially ext4. This is the limitation of a $35 computer card. They’re great and they’re certainly inexpensive, but no matter how advance the technology, you get what you pay for.

I may be time for me to investigate the use of Android for Raspberry Pi.

Update 17 February

Checking online, it looks like this might be a kernel bug as much as a problem with SDHC cards. Kernel version currently being used for ARM Arch is 3.10.

See https://bugzilla.kernel.org/show_bug.cgi?id=42723

Look towards the bottom of the bug report. I didn’t start to see this until the latest Arch update, which included a new kernel and firmware. Maybe it’s time for me to start building kernels again, moving to the latest, which is 3.13. I know that 3.10 is labeled as long-term, but still.

In any event I won’t release a new image until I’m sure the problem is fixed one way or the other. At least, not a new image with kernel updates. I’m planning on reflashing today with the 9 February image and adding all my changes to that, in particular the node.js i2c and onoff extensions.

Update 2, 17 February

Looks like file system error was self inflicted. Plugged the card back into the Ubuntu notebook and ran fsck on /dev/mmcblk0p5 (/dev/sdb5 under Ubuntu). There was a reported bitmap difference of -127301, a free block wrong count for group #3 (651, counted=652) and a free block wrong count for group #19 (17504, counted=17503). Once those were fixed Arch booted just fine on the card. I am assuming this miscount occurred when I expanded the original 2 GB file system to 8 GB with gparted. I think in the future I need to run fsck on any file system I modify in that way. It means that every other image I’ve pushed up to Sourceforge also has this flaw. Once I finish testing node.js with i2c and onoff (GPIO) on this latest image I’ll push up the latest compressed image and replace the two currently there. It’s not a fatal problem, but it needs to be corrected none-the-less.

raspberry pi, weekend edition for 9 feb

whbeebe

My Arch Linux Raspberry Pi images were updated and uploaded to Sourceforge this weekend. The lead-in image is a screenshot of the TWM desktop running a colorized VM in an xterm and emacs. You’ll note that the colors and general look and feel are tweaked a bit.

This weekend I added additional functionality to my Raspberry Pi; the ability to manipulate the GPIO through RPi.GPIO. This meant updating the base image with more development tools as well as downloading and installing RPi.GPIO from its Sourceforge repository. I’ve had very little time to test it; the only test I’ve conducted so far is using test.py that’s part of the RPi.GPIO source bundle.

The base image started with the Groundhog Day base image had the following actions performed:

  • removal of regular vi and its replacement with vim via softlink;
  • update of system to Arch Linux for Raspberry Pi as of 8 Feb 2014;
  • addition of git;
  • addition of more development tools, especially for Python 3;
  • addition of RPi.GPIO 0.5.4.

That running image was copied back and compressed (zipped) into ArchLinuxARM-2014.02.08-rpi-base08G.zip where it was uploaded to the Rubus Project on Sourceforge.

I then took the base image and duplicated it on another card where I installed Xorg and TWM. This installation was meant to be cleaner than the Groundhog Day image release, having learned a bit over the past week. In particular I did not install lxde.

The graphical system consisted of the base image plus:

  • xorg
  • xorg-xinit
  • xorg-twm
  • xterm
  • xorg-oclock
  • xorg-xlogo
  • xorg-xeyes
  • xorg-xload
  • xv
  • medit

The pi account also has proper local .twmrc, .xinitrc, and .Xresources files. The system X files under /etx/X11 are no longer being hacked. I finally remembered the proper syntax for just about everything that matters. The .vimrc has been edited to enable line numbering and syntax highlighting for vi/vim. There is a .emacs file to configure Emacs to my tastes. You should check this and modify to suit your tastes.

After testing the image was compressed (zipped) as rchLinuxARM-2014.02.09-rpi-twm08G.zip and moved up to Sourceforge.

The usual root and pi accounts are on both images. As always, change the root and pi passwords if you plan on using these images on networks you do not have absolute control of.

I’m now moving on to tying hardware into the RPi. I have a Parallax Propeller Professional Development Board that’s been sitting around in its anti-static bag for years now, purchased when Parallax had a sale on them for less than $100, waiting for me to pull that board out and put it to work. I’ll be using the Parallax board with the RPi to begin my hardware integration. It has a large breadboard, lots of switches, lots of single blue LEDs, and size blue 16 segment displays on the board. It’s for developing the 8 core Propeller Chip, and I have every intention of buying one and integrating that with the RPi. I got lots of crazy ideas…

Oh, two other little things.

  1. I’ve joined the wayland-devel mailing list and I’m lurking at the moment. I want to get Wayland/Weston up and running on my RPi, either through packages, building from sources, or some combination of the two. I’m well aware of the fork of Wayland/Weston to Northfield/Norwood that occured last year, but when I went looking at the Northfield and Norwood git repositories I discovered that nothing has been done on either for nearly a year. I may just give up on Wayland and follow Canonical’s lead with Ubuntu and adopt Mir. Or maybe not. But somehow, some way, I want optimized native support of the RPi’s built-in on-chip graphics hardware.
  2. I’ve switched to using Samsung 16GB micro SDHC I 1, class 10 cards. Why 16GB? Because that’s the smallest I can find locally that doesn’t cost an outrageous amount ($17 + tax). I’ve been using SanDisk and Toshiba 8GB regular cards. Of all the cards I have, I prefer the Samsung for their performance. I’m debating whether the next release will be a 16GB image compressed. I’m already pushing the 1GB upload limit as it is with my current compressed images.

How to Use Either Image

  1. Download either image from Sourceforge (see links in this post or at the top of my blog)
  2. Unzip on your OS of choice. They’re zipped up on Ubuntu.
  3. Plug in an SDHC card of 8GB or larger capacity into your primary computer or notebook.
  4. Copy the unzipped image directly to the flash card. For Linux, use dd.
  5. When finished copying plug the SDHC into a Raspberry Pi. With the RPi connected to a monitor/TV, keyboard and mouse, turn it on. The RPi should boot. Note that a wireless mouse, such as the Logitech M305 or later, will work with the RPi.
  6. At the console login, either login as pi (password pi) or root (password root). You should login as pi and use sudo to work rootly commands.
  7. If you’ve flashed with the TWM image, start TWM by typing ‘startx’ at the command prompt.
  8. Once in the desktop environment, a right mouse button on the desktop will bring up the long command menu (see screenshot above). A left mouse button will bring up a short menu of applications.
  9. The xterms have menus bound to the <Ctrl>Left Mouse and <Ctrl>Right Mouse.
  10. Remember that TWM was chosen for its relatively small footprint. There are absolutely no games or productivity applications. There is no browser. It’s purely a developer’s environment (i.e. editors + development tools and languages).
  11. For further details read the README and wiki on the Rubus Project at Sourceforge.