aarch64 toolchain

In the last months there has been movement towards merging a new architecture in the mainline kernel, called aarch64. Along with it, they came the binutils and gcc ports.

kernel:   http://lwn.net/Articles/505682/ 
binutils: http://sourceware.org/ml/binutils/2012-07/msg00269.html 
gcc:      http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html

Given that I have never touched a bare metal toolchain, I thought this was a good thing to pass the time, so I started playing with these pieces and got to compile binutils, gcc and the kernel, from the patches submitted. Now it is easier given that binutils support was merged.

I don't really use cvs, just downloaded the latest snapshot of binutils (2.22.90 doesn't have aarch64):

wget ftp://sourceware.org/pub/binutils/snapshots/binutils.tar.bz2

Extract.

Assuming you are at /my_tc, you create build/binutils and compile from there, your source is at /my_tc/binutils-latest/.

$ cd /my_tc/build/binutils/ 
$ /my_tc/binutils-latest/configure --prefix=/my_tc/out --target=aarch64-none-linux-gnu --disable-werror
$ make -j4 && make install

And for gcc:

svn checkout http://gcc.gnu.org/svn/gcc/branches/ARM/aarch64-branch

Assuming you are at /my_tc, you create build/gcc and compile from there, your source is at /my_tc/aarch64-branch/.

$ cd /my_tc/build/gcc/ 
$ /my_tc/aarch64-branch/configure --prefix=/my_tc/out --target=aarch64-none-linux-gnu --disable-nls --enable-languages=c --disable-threads --without-headers --with-newlib --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp  --disable-libquadmath
$ make -j4 && make install

$ export PATH=/my_tc/out/bin:$PATH
$ export CROSS_COMPILE=aarch64-none-linux-gnu-
$ export ARCH=arm64

Get the kernel:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
$ cd linux-aarch64
$ make allnoconfig && make -j4

And now you have a compiled kernel with a bare metal toolchain. You can play with the menuconfig or just go randconfig and fix some of the bugs too.

---

Back then when aarch64 binutils wasn't merged, I had to download and patch binutils code and regenerate the makefile and include files. Something like:

1. Download binutils-2.22.90, patch it with aarch64 changes.
2. automake on bfd/, binutils/, gas/, ld/ and opcodes/; automake must be 1.11.1.
3. autoconf on top configure file, bfd/ and opcodes/; autoconf must be 2.64.
4. configure and make, and wait for it to break or just run configure inside bfd in order to get a Makefile there.
5. cd bfd/; make headers and cd -, this will generate some missing symbols.
6. Now you can either clean your previous failed build or continue it.

And then follow the steps to compile binutils, gcc and kernel.

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.

beagle xm unbox

It arrived 2-3 weeks ago, sadly I haven't had the time to try anything on it, other than the angstrom SD card environment included...

I thought I could rely on USB to feed the board and boot, but when I tried the kernel that came with the board, I saw there was a nasty bug panicking every time I try to boot (I guess it is USB related), so, I had to search in my "cables" (spanish) junkyard box and found a perfect 5V match for it.

Then, I wanted to test the display output, but since my TV doesn't have a DVI port :(, I got an ugly S-Video signal which I yet have to tweak and play with to see if it can get better.

And... uboot doesn't have tftp support. I know these are the preloaded binaries, so I have to try the latest stuff to see if it gets better :).

So, I leave a few pictures of the unboxing:

gst dsp/omapfb on zoom2

While waiting for the new board to arrive, I started to setup the gst-dsp + omapfb environment for what I currently have available: a zoom2.

After few tips from Axel Castaneda (for fb and v4l2 options) and much of googling, I got the board to show the video on the display using gst dsp/omapfb plugins.

As of today, you can easily use any kernel above 2.6.37-rc2, since it has a usable tidspbridge driver.

Here it's what I did (BTW, you can find a tidspbridge kernel in gitorious and ignore fetch & merge steps):

Clone/fetch latest linux-2.6 from git.kernel.org, took linux-2.6 2.6.37-rc3:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git checkout -b tidspbridge-2.6.37-rc3 v2.6.37-rc3

Then merge the patches providing display support for zoom2/3 boards from Tomi's DSS2 repo, the easiest thing to do is pulling his entire devel branch.

git pull git://gitorious.org/linux-omap-dss2/linux.git devel

And last, pick a patch to solve a gpio reset problem on zoom2 (zoom3 works fine without this last step).

wget http://patchwork.kernel.org/patch/351421/mbox/ -O display.patch
git am display.patch

Config for omap2+, and in menuconfig select:

CONFIG_TIDSPBRIDGE=m
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_VRAM_SIZE=4
CONFIG_FB_OMAP2=y
CONFIG_PANEL_NEC_NL8048HL11_01B=y

Build the uImage and copy to the filesystem:

arch/arm/plat-omap/mailbox.ko
arch/arm/mach-omap2/mailbox_mach.ko
drivers/staging/tidspbridge/bridgedriver.ko

Alternatively, you can use modules_install after compiling kernel and modules.

Now, assuming you have a filesystem + gstreamer environment (or you can take my rootfs, which has a uImage + dsp needed modules/binaries, be sure to read and agree to the license under /lib/dsp, just in case).

Boot the uImage and insmod/modprobe the modules.

insmod /dspbridge/mailbox.ko
insmod /dspbridge/mailbox_mach.ko
insmod /dspbridge/bridgedriver.ko base_img=/lib/dsp/baseimage.dof

Generate a test video to play with:

gst-launch videotestsrc num-buffers=200 ! video/x-raw-yuv, framerate=30/1, width=320, height=240 ! dspmp4venc ! avimux ! filesink location=my_avi.avi 

If you noticed, the video generated is encoded using the dsp.

Then send the video to the framebuffer, with:

gst-launch filesrc location=my_avi.avi ! avidemux ! dspvdec ! omapfbsink 

And that's it.