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.