So… I have been playing around with my BeagleBoard again. Yes…. I got an exam tomorrow, but I got so bored while studying I had to do something else.

Well… I undusted the thing yesterday, and continued today. And of course, this didn’t go completely without trouble. A few issues I ran into yesterday, well… this little puppy is rather picky about the partitioning of it’s SDCARD.

So… my BeagleBoard…. last time, I ran the ARM port of Debian, which is compiled for armv4t, meaning… it’s not very fast. One time I started installing Ubuntu but never finished it. To be honest, Ubuntu isn’t my favourite distro.

Since ArchLinux has an ARM port nowadays too, and the BeagleBoard belongs to the supported models, I decided to give it a try. Take a look at http://archlinuxarm.org/platforms/armv7/beagleboard

Like I mentioned, the puppy is picky about the contents of the SDCARD. I was aware of the MLO to be the first file copied to the FAT paritition, but it appears even pickier then that. The instructions on the ArchLinuxARM site didn’t get it working. Other sites mention it should be a FAT32 in stead of a FAT16 partition… well… just that isn’t enough either…

I’ve downloaded the files mentioned on the ArchLinuxARM site, and in the BeagleBoard bootloader tarball I found a script for preparing the SDCARD. But even this script was giving me trouble. I am not really sure what went wrong, but the script made the parititons correctly but failed at formatting them. Even manually trying to format them failed. I had to eject the SDCARD from my laptop, and insert it again, before I was able to make the file systems. However, after copying the files from the bootloader tarball, I got some more response from the BeagleBoard.

However, there was still some content in the NAND from my previous unfinished attempt to run Ubuntu, which tried to boot, but failed. The BeagleBoard didn’t respond to the serial console, just output, not accepting input. But appearently this is related to my desktop machine, as it works fine with a USB serial port on my laptop.

So after instructing u-boot to erase the NAND, the boot loader ran the boot script stored on the SDCARD.

So, now I mention the boot script. Well… it had to be compiled with mkimage, which I had to compile from the u-boot sources.

So…. there we go….. booting ArchLinux on my BeagleBoard. As I mentioned last year, I was experiencing USB issues… which I initially blaimed as a kernel issue, as this was suggested by various sites in the days. That’s why I also wanted to try Ubuntu…. but later turned out this was caused by a noisy 1.7 Volt line, confusing the USB controller. As suggested by a site, I have mentioned earlier in this blog, I mounted an extra capacitor….

Time to see the results, right? Well…. connecting a bus powered USB hub to OTG port… REBOOT!!! the duck!!! well… the OTG port isn’t able to deliver enough power, so that could be the issue. Connecting Self powered hub to the normal USB port… well… it worked for a bit and went down. And I really mean a bit. Like… it got initialised during boot, all devices found, but even before the boot process was finished it died again. Seems like the problems gotten worse in stead of better… Well… I am not sure if the suggested capacity is correct… I mean… 10 µF… I think it should rather have been something like 10 nF. Oh well…. when connecting the self-powered hub to the OTG port, results seem much better… USB has been functioning properly for a while now.

But another thing that is still giving me issues, I don’t get it to play back sound. Some sites mention ALSA is broken and I should use OSS, but there is OSS but there appears to be ALSA. Even though it appears to be playing back, I hear no sound. Besides… I had to add myself to the audio group else I had to access to the device.

Well… the system is running… that’s what I can tell you…. Perhaps I will be able to use it as mp3 player later on, we’ll see about that.

Video… well… this port is an optimised build, which includes hard floating point, and that binary blob of a driver us compiled using soft floating point, which makes it incompatible. Hooray for binary blobs…. so that means no hardware acceleration for video.

I never made that VGA adaptor for the BeagleBoard, so I have no clue if it will work. In theory it should work… I mean… a simple D-A converter, how hard can it be? As the digital signals are, well, just the same as VGA signals, just not converted. Well… this is not completely true, as I might have to adjust the timing a little bit, but that shouldn’t be too hard either…. but yeah…. installing ArchLinux on a BeagleBoard shouldn’t be that hard either, and look at all the little issues that appeared.

The DVI issue remains the same, the native resolution of my only monitor with DVI in is not supported at a refresh rate high enough for my monitor to accept. The BeagleBoard can only output it at 57 Hz, and my monitor is rather strict about this, and it won’t accept anything below 60. But I’ve discussed that issue before.

Well… and all my other monitors are CRT, so using them would require the VGA adapter as I suggested above, and discussed before in this blog.

On the other news… last tuesday during the SHoBo, I was asked if I were interessed in a Raspberri Pi. This is an ARM machine for only £22. I mean…. a machine capable of runnng GNU Linux for only £22. Sounds like a good deal to me. It’s video accelerator is capable of decoding H.264 in Full HD 1080p. I mean… the BeagleBoard can only output 720p. Allthough I am afraid the drivers will be again a binary blob. I mean… it is a Broadcom SoC after all… Compared to the BeagleBoard…. This Broadcom is only an ARMv6, while the TI on the Beagle is an ARMv7. But… what will this mean in practice…. well… it’s not even sure when the RP will start shipping, but the plans were to order some at Stack.

« »