Tag Archive: beagleboard

I know, I have written about this before, but, here it is again. Installing ArchLinuxARM on the BeagleBoard, this time, taking a fresh SD card, and now it works like a sunshine. Yesterday, on the 8 GB card, I’d done exactly the same, without any result.

So, let’s see how to install the January 2013 ArchLinux OMAP3 rootfs to an SD card for use with a BeagleBoard.

Download the bootloader http://archlinuxarm.org/os/omap/BeagleBoard-bootloader.tar.gz
Download the rootfs http://archlinuxarm.org/os/ArchLinuxARM-omap-smp-latest.tar.gz

This says the latest rootfs, which would usually be the right thing to do. But to ensure you’re using the same rootfs as I do, you can use http://os.archlinuxarm.org/os/omap/ArchLinuxARM-2013.01-omap-smp-rootfs.tar.gz in stead.

extract the bootloader tarball. This tarball contains a mkcard.sh script which will partition the card for you. As I’ve had problems with the instructions on the ArchLinuxARM site last time, I will use this script instead, as it worked perfectly.

[root@hplaptop bootloader]# ./mkcard.sh /dev/mmcblk0
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 1.13529 s, 924 kB/s
DISK SIZE - 16130244608 bytes
Checking that no-one is using this disk right now ...

Disk /dev/mmcblk0: 1961 cylinders, 255 heads, 63 sectors/track
sfdisk: /dev/mmcblk0: unrecognized partition table type

Please note it also says

./mkcard.sh: line 37: kpartx: command not found

But this ain’t a fatal error. It seems this is a tool to re-read the partition table and create device maps. However, it seems it works without on my system. Anyhow, let’s continue. The said script only partitions the SD card and creates file systems, but nothing else. (unlike the script for the CubieBoard, which I will discuss later)

[root@hplaptop bootloader]# mount /dev/mmcblk0p1 /mnt/a
[root@hplaptop bootloader]# cp MLO /mnt/a
[root@hplaptop bootloader]# cp u-boot.bin /mnt/a
[root@hplaptop bootloader]# cp uEnv.txt /mnt/a
[root@hplaptop bootloader]# mount /dev/mmcblk0p2 /mnt/b
[root@hplaptop bootloader]# cd /mnt/b
[root@hplaptop b]# tar -xvf /run/media/andre/DataBlaat/arm/beagleboard/archlinux/ArchLinuxARM-omap-smp-20130118.tar.gz

It is important for the BeagleBoard that you copy the MLO file first to the FAT parition. This is a pre-boot-loader, “X-loader”, which will load the bootloader “U-Boot”. Then copy the other files to the FAT partition, “u-boot.bin”, the bootloader, and “uEnv.txt”, a configuration file.

Next extract the root file system to the ext3 parition. I usually include the v to the tar arguments to see what’s going on. When this is done, copy the kernel over to the FAT partition

[root@hplaptop b]# cp boot/uImage /mnt/a

This can take longer then expected. When this is done, create a boot script. This boot script will be like the one on the ArchLinuxARM site, but the mmc init line needs to be ommited. It was needed for ancient versions of U-Boot, but has been obsolete for quite a while. So, the boot script will look like

setenv bootargs 'console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait'
fatload mmc 0 0x80300000 uImage
bootm 0x80300000

write this bootscript to bootscr, and run mkimage to convert it to an U-boot script. Even though the current version supports the uEnv.txt file, I didn’t manage to get it to boot using the uEnv.txt only. I kept attemption to boot from NAND, but I want to boot from the SD card. I probably only have to set a certain variable to tell it to boot from SD in stead. However, with the boot.scr file present, it boots fine from the SD card.

[root@hplaptop b]# cd /mnt/a
[root@hplaptop a]# vim bootcmd
[root@hplaptop a]# mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Beagleboard boot script" -d bootcmd boot.scr
Image Name: Beagleboard boot script
Created: Fri Jan 25 11:05:47 2013
Image Type: ARM Linux Script (uncompressed)
Data Size: 151 Bytes = 0.15 kB = 0.00 MB
Load Address: 00000000
Entry Point: 00000000
Image 0: 143 Bytes = 0.14 kB = 0.00 MB
[root@hplaptop mnt]# cd ..
[root@hplaptop mnt]# umount a
[root@hplaptop mnt]# umount b
[root@hplaptop mnt]# sync

Please note: If you’re missing mkimage is available in the AUR repository as package “uboot-mkimage”. Last time when I made an BeagleBoard SD card, I compiled it from source. After this is all done, unmount the file systems, flush the caches, and just put the card into the BeagleBoard, connect to the serial console, and plug in the power. It boots up fine.

P.S. In the rootfs there are some boot.scr files, but they won’t work. First of all, they appear to be for the TrimSlice. But that’s not the problem. They appear to be configured to load the kernel from the rootfs. In the directory /boot there is uImage, so, perfectly fine. However, U-Boot only supports ext2 and not ext3, therefore these files won’t work.

We might need to adjust the kernel parameters later if we want to set something like hdmi or svideo to work. As stated before, when specifying 1280×1024@60Hz, the BeagleBoard is only capable to deliver 57Hz, which my Compaq 1720 monitor refuses to accept. As I have found out with some CubieBoard tests, which I will write about later, the monitor might be a little more tolerant when the input is analogue. Therefore I tried the mentioned HDMI->VGA adaptor also on the BeagleBoard.

When I had my old BeagleBoard installation running, I experienced lots of USB problems, mostly related to the USB Ethernet adaptor. Lots of errors in the pegasus driver. So, I wonder, are the problems really hardware or are they caused by a crappy driver. Anyhow, I’ve bought an SPI Ethernet adaptor for testing purposes.

The BeagleBoard, the Raspberry Pi. They both use an SD card. The CubieBoard uses a µSD card. Basically the same card in a different form factor. Flash memory to store your operating system. As these ARM Boards commonly run a regular Linux distro compiled for ARM, usually logs are written to the file system, updates are installed frequently, and often you see an ext3 file system, which is a journalling file system. This all means there will be frequently written to an SD card in an ARM board, and knowing the write cycles of such a card are limited, makes you wonder, how long will it last. I believe I have hit the end of such an SD card yesterday night.

Kingston SD4/8GB

I bought this card, back in 2009 when I bought my BeagleBoard. When I first tried to use my BeagleBoard, I was stopped by the unstable USB bus, therefore it hasn’t been used much. The SD card has probably been used in cameras in the mean time. When I read the USB problems where probably hardware related and a capacitor might fix them, I’ve started using the BeagleBoard again, yet, experiencing various instability issues.

BeagleBoard Rev. C3

Regular crashes and rebooting, not good for the condition of a file system, and such fsck running on the file system, what are the results for write cycles? Anyhow, when I got my Raspberry Pi, I bought some 16 GB SD cards it. However, wanting to test RISCOS, I didn’t want to use such a 16 GB card for it. So I took this 8 GB card and wrote that image to it. RISCOS booted fine on the Raspberry Pi. However, now I think about it. I once had some boot problems, which disappeared as spontaneous as they came.

Now, I wanted to play around with my BeagleBoard again. I took the 8 GB SD card, I made an image of its contents (the RISCOS image), ran the BeagleBoard SD card script, to correctly partition it for use with a BeagleBoard, which also makes a FAT and ext3 file system. I wanted to try geexbox, an XBMC distro, which also has a version for OMAP3, which includes the BeagleBoard, IGEPv2, and others.

So, I copied the bootloader files to the FAT partition, the rootfs to the ext3 parition, put the card in the BeagleBoard and booted it up. This distro uses systemd, which is also in use by ArchLinux. Anyhow, I was conducting some experiments with the hdmi and svideo outputs of the BeagleBoard.

The HDMI to VGA converter worked fine with my Raspberry Pi and CubieBoard, so I was like, let’s give it a try on the BeagleBoard. Even though it would probably not work without modification to the BeagleBoard, as it shows here, it has overcurrent protection on the HDMI output. Such an HDMI to VGA adaptor without own power supply violates the HDMI/DVI specs and draws much more current from the HDMI port that officially allowed. Actually, the BeagleBoard is the only board (known to me) that restricts HDMI devices to the standards.

In general, specifications about maximal current drawn are violated everywhere, especially on USB busses. And then those cables with an extra USB plug to allow more current in case one port is restricted. Or USB fans, lights and even warming plates for a cup of coffee….. all just drawing current without any USB logic, no identification to the host. Well… enough ranting about that. What was I talking about?

Anyhow, after a few seconds the screen would go off, due the HDMI to VGA adaptor drawing too much current. I went to try the svideo output. Where the video output goes is a kernel parameter, so chaging the files in the boot partition and rebooting. Also note, the manual of the BeagleBoard states I should only (un)plug the cable from the HDMI port when the device is unpowered. Anyhow. When I plugged in the power supply again, nothing happened. Of course I was like, “WTF?!?!?!”. After measuring the power adaptor, it turned out this one just decided to die.

Dead power adaptor

This power adaptor belonged to an USB HUB I’ve decided to retire, as it was causing trouble on the USB bus. Please note this was a 4 port USB hub, and the adaptor is rated 2.5 Amps, as it should. Nowadays you see only 1 Amp for a 4 port USB hub. So, in these days, USB devices draw more power then they should, and USB hubs provide less power then they should. Can someone please explain how on earth this is supposed to work???

Anyhow, the fact the power adaptor just died may make me re-evaluate that USB hub, as its misbehaviour might be related to unstable power. Nevertheless, it’s an old hub, perhaps it even belongs to the first generation of USB 2.0 hubs?


Anyhow, recently I had some more USB hub issues. I have announced a couple of time again I should write about them. And I should just do it otherwise it will never happen, as I have said I am supposed to write about a certain subject before, but never done in the end. But there are more things to write about so.

I almost forgot, I should still get to the point of this story. So, I had a booting geexbox distro, but I wasn’t able to get anything xbmc on the tv out for some reason. I decided to install ArchLinuxARM in stead. So, I formatted the ext3 partition again and copied the ArchLinuxARM OMAP3 root fs over, I copies the uImage over to the FAT partition, and….. it doesn’t boot. Kernel Panic! Cannot find init! and such. I’ve been testing all night, re-creating the file system, boot loader and everything. I couldn’t find anything wrong. But missing init? it’s right there! I’ve copied a statically linked “hello world” binary (compiled on the Raspberry Pi. ARMv6 Hard Float binaries run fine on ARMv7 Hard Float) over there to test, which ran perfectly fine.

In the end, I noticed the umount command was hanging, when unmounting the card on my laptop. Now, I believe this is related to the SD card malfunctioning. I’ve noticed this before, but I assumed this was some kind of bug instead.

While the umount command was hanging, in another terminal, we see data is being written to the card at a very slow rate:

[andre@hplaptop ~]$ iostat
Linux 3.6.11-1-ARCH (hplaptop) 25-01-13 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
9,95 0,00 4,02 21,73 0,00 64,30

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 4,41 51,38 57,41 547377 611549
mmcblk0 0,61 0,35 28,54 3745 30402

When we look at dmesg, it doesn’t complain about anything to do with the sd card, but it noticed the umount being blocked for over two minutes.

[10680.535700] INFO: task umount:3089 blocked for more than 120 seconds.
[10680.535709] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[10680.535714] umount D ffff880127dd58b0 0 3089 2881 0x00000000
[10680.535724] ffff88011e23dc08 0000000000000086 ffff880127dd58b0 ffff88011e23dfd8
[10680.535733] ffff88011e23dfd8 ffff88011e23dfd8 ffffffff81814420 ffff880127dd58b0
[10680.535741] ffff880127f330a8 ffff88013fc13e70 ffff88011e23db98 ffffffff810145b3
[10680.535749] Call Trace:
[10680.535765] [] ? __switch_to+0x163/0x410
[10680.535776] [] ? finish_task_switch+0x49/0xe0
[10680.535787] [] schedule+0x29/0x70
[10680.535794] [] schedule_timeout+0x204/0x260
[10680.535802] [] ? check_preempt_curr+0x75/0xa0
[10680.535809] [] ? ttwu_stat+0xaa/0x120
[10680.535816] [] wait_for_common+0xcd/0x160
[10680.535824] [] ? try_to_wake_up+0x2f0/0x2f0
[10680.535831] [] wait_for_completion+0x1d/0x20
[10680.535841] [] writeback_inodes_sb_nr+0x85/0xb0
[10680.535849] [] ? sys_mknod+0x1/0x20
[10680.535886] [] writeback_inodes_sb+0x2e/0x40
[10680.535893] [] sync_filesystem+0x3d/0xb0
[10680.535902] [] generic_shutdown_super+0x3b/0xf0
[10680.535910] [] kill_block_super+0x30/0x80
[10680.535920] [] deactivate_locked_super+0x3c/0xa0
[10680.535927] [] deactivate_super+0x4e/0x70
[10680.535936] [] mntput_no_expire+0x101/0x160
[10680.535944] [] sys_umount+0x76/0x3a0
[10680.535953] [] system_call_fastpath+0x1a/0x1f

Anyhow, I declare this 8GB SD card deceased. Just another thought. As this “dying sd card” causes weird symptoms.

Edit: I believe the cause of the problems were rather different. During an update, the governor was set to ondemand again, in stead of powersave which I had configured. The issues were probably caused by overheating. I have experienced SD problems before related due overheating. I wonder why my laptop has to run at 800 MHz nowadays, while when it was new it ran at 2800 MHz without problems, but suddenly, overheating issues arrised.