Can't open /dev/ttyO2: No such file or directory (buildroot-2010.08)

Lately I have been using a beagle-xm and a lent pandaboard, with an old minimal file system (buildroot 2010.08) and newest kernels 2.6.39+, and encountered this message whenever I wanted to boot anything beyond 2.6.39.

Can't open /dev/ttyO2: No such file or directory

I realized the kernel version in the top Makefile was affecting after few git bisect runs, and then confirmed by playing with it for 3.0+ kernels.

Although I knew there was something wrong with udev and user space I didn't have the time to dig into it and just modified the version in the top Makefile while compiling the kernel (from 3.0+ to 2.6.X).

Later I discovered the issue was in my filesystem:

/etc/init.d/S10udev:19

# old kernels don't use udev
case $(uname -r) in
    2.6*|2.7*)  ;;
    *)          exit 0;;
esac

As it turns out newer kernels don't use udev either ;) according to the script.

Removing those lines from the udev start script gives your ttyO2 console back.

This was fixed in one of the latest buildroot releases, I didn't check which one, but the udev start script doesn't have the kernel version check in buildroot 2011.08.

However, the latest version doesn't quite work for me, so, until I find some time to check what I'm missing I'll stick to 2010.08.

On a side issue:

If you ever re-download buildroot-2010.08 and build from scratch, you're likely to face a build break during:

gzip: buildroot-2010.08/dl/fakeroot_1.9.5.tar.gz: not in gzip format
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

Which is caused by a broken fakeroot link.

The bad:

http://snapshot.debian.net/archive/2008/04/27/debian/pool/main/f/fakeroot//fakeroot_1.9.5.tar.gz

The good:

http://snapshot.debian.org/archive/debian/20080427T000000Z/pool/main/f/fakeroot/fakeroot_1.9.5.tar.gz

Just download from the good link and replace fakeroot tarball in:

    buildroot-2010.08/dl/fakeroot_1.9.5.tar.gz

And continue the build.

beagle-xm portable juice

After a long week waiting for the deliveries and few shipping issues[1], finally, I got my portable battery and usb-to-5.5mm cable to power my beagle-xm; the hunt started a few weeks back when I was looking for a battery to power the beagle-xm and maybe 1 or 2 peripherals, why? just because, and also I needed something that could be used for other devices as well and here I found the iSound —which by the way doesn't make any sound— and at a price of $40 from buy.com, it seemed like a fair buy.

According to the spec sheet, it holds 8000 mah, and the output is 5V and 2.1A for each USB port. So, it seems like a fit for beagle-xm which eats 5V and 750mA, and up to 3A with all the USB ports. It also last up to 500 charges which seems lousy by the way, but I'm just planning to use it on rare occasions and when I'm out of cellphone battery in the middle of desert.

Initial boot tests showed no problem, but I'm not plugging anything to the USB either; so I'll wait for a final verdict when using a USB based bluetooth, wifi or display.

Here are some pictures of how it looks:

---
[1] When ordering from buy.com and prompted to confirm billing address, I realized that I hadn't touched my account in 2 years since it had the address of the hotel I was at that time, I updated it and placed my order. Two days later, and like a desperate kid, reviewed the order progress and yes... the shipping address was the hotel; when contacting customer service, the guy said something like "Yep, I'll cancel the order and you can reorder again, just wait for one day for this to succeed", later on that day, I received an email: "Your order has been shipped" :/ .

Anyway, thankfully the hotel is in the same city I'm living now, so just registered my email for delivery tracking, went by and picked it up, no hassle, no sweat.

booting beagle-xm with tidspbridge

Thanks to Andresj, I got a good reason to dust off my beagle-xm and the dsp inside it.

So, this post is just a quickie about booting and poking the dsp, even though Andresj intends to bring up dsplink, me, being a complete noob on the subject, will just swap it for tidspbridge.

There are probably a lot of posts and wikis[1][2][3][4] detailing these steps, but what the hell, one (this one) polluting the web space doesn't hurt much, besides I'm not going to detail each point.

In the "nearly-done-from-scratch" world, you should have:

• ARM GCC to compile your x-load (MLO), u-boot, uImage (vanilla kernel or linux-omap kernel) and fileystem + utilities (I use buildroot), besides of your user space apps.
• TI's CGT and BIOS to compile dsp binaries.
• Filesystem storage: NFS, MMC or NAND.

If not, you could try my rootfs and mount it on MMC.

UPDATE: Remember to change the rootfs files owner (chown) and group (chgrp) to "root" after decompressing into MMC or for NFS boot.

In rootfs/etc/inittab, change ttyS0 for ttyO2 (on latest kernels, previously ttyS2)
In rootfs/etc/securetty, add ttyO2 (on latest kernels, previously ttyS2)

Compile your kernel with tidspbridge and copy to the uImage to mmc, the modules should go to the filesystem.

I was using 2.6.38-rc3 with omap2plus_defconfig. I noticed a strange issue though: if you let the kernel booting messages through the console, you get a panic because mmc couldn't be mounted.

UPDATE: Thanks to Vaibhav for pointing out, you can set rootwait on your bootargs, solving above mmc detection problem.

And in u-boot.

set bootargs 'mem=512M console=ttyO2,115200n8 noinitrd root=/dev/mmcblk0p2 rw rootwait'

Be sure your boot.scr or the default environment variables doesn't override your bootargs, I had to modify mine, so the mmcboot didn't overwrite the bootargs.

set mmcboot 'bootm ${loadaddr}'

Then.

bootd

If everything went well, you can login as root and try the gst commands from one of my previous posts. Enjoi :P

Usual solutions to random problems

Compiling

• Export your compiler path before cross-compiling, and also your CROSS_COMPILE variable, in some cases even the ARCH variable might be needed too.
• Configure your target defconfig.
• Remember to take mkimage from u-boot project to compile the uImage, you should put it under a folder in your PATH.

Booting

• No messages: recheck serial, USB-serial connections; check settings with the emulation terminal (usual ones are the port and speed configs, 115200n8); check MLO and SDcard, recompile & reflash if needed.
• X-loader hangs: check u-boot, recompile & reflash if needed.
• Kernel hangs in "Starting kernel": Something went horribly wrong enable earlyprintk to debug (with the right tty).
• Kernel hangs in "Uncompressing Linux...": Recheck your bootargs (most common errors are that kernel throws messages through ttyS0, but bootargs listen ttyS2).
  
• Kernel hangs around "Freeing init...": Recheck the same tty stuff in your file system /etc/inittab.
• Filesystem doesn't allow login: check your configured users; add the tty to the list in /etc/securetty.
• Kernel panic while mounting FS:
• NFS: check NFS server settings and exports; check bootargs; check file system path in server and bootargs; check ip, serverip, nfs server ip.
• MMC: check bootargs; check filesystem partition in bootargs; check the SD card, if possible try another one.

Beagle Board Challenge: SuperBeagle

A few weeks back I ran over this project, its purpose is to give dspbridge (or tidspbridge) users, a fair example of how to interact between a userspace application and a dsp dll, it is heavily based on dsp-dummy made available by FelipeC.

To be honest, I have never looked at dsp-dummy before this, but now I want to try writing a codec following this simple approach, although the result will be pure crap—coding and performance wise ;)—it seems like a good exercise.

In the mean time, other nice projects from the same Beagle Challenge can be found here.

---

BTW, if you ever run "SuperBeagle" project with TIDSPBRIDGE_WDT3 enabled, it may cause an overflow because of the way this dll was changed from the original dsp-dummy. Once it executes, the dsp side (dummy-dsp.c) falls into a while loop checking for messages all the time (NODE_getMsg with timeout=0) never refreshing the WDT timer... the common practice (on dsp side code) is to set the timeout value to infinite so the dsp can block that task and wake it up once a message arrives.