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