Thursday, September 6, 2012

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.

Tuesday, December 6, 2011

tidspbridge for 3.2

Early in the 3.2 development (3.2-rc1) I faced some tidspbridge issues with recent changes on dm_timer framework and module.h.

After looking at the issues, few patches were created:

1. [PATCH] staging: tidspbridge: include module.h by default
  • Made to fix a compilation break if you compile tidspbridge as part of the kernel. 

2. [PATCH v2] staging: tidspbridge: request dmtimer clocks on init
  • Recent changes to dm_timer framework, specifically the one that get the parent clock handles to set new source to a specific clock, make lockdep to complain when requesting dm timer clocks within a hardirq or softirq. In tidspbridge, this was changed to request the clocks on module load.
  • The dm timer framework also changed the behavior of ..._request* calls, given that the clocks are no longer returned in enable state, explicit calls were added in tidspbridge to enable/disable the clocks.
  • BUG:
  • An infinite loop with the following message:
    ------------[ cut here ]------------
    WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161 omap3_l3_app_irq+0xd0/0x12c()
    In-band Error seen by IVA_SS  at address 0
    Modules linked in: mailbox_mach bridgedriver(C) mailbox
    [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x4c/0x64)
    [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40)
    [] (warn_slowpath_fmt+0x30/0x40) from [] (omap3_l3_app_irq+0xd0/0x12c)
    [] (omap3_l3_app_irq+0xd0/0x12c) from [] (handle_irq_event_percpu+0x5c/0x22c)
    [] (handle_irq_event_percpu+0x5c/0x22c) from [] (handle_irq_event+0x3c/0x5c)
    [] (handle_irq_event+0x3c/0x5c) from [] (handle_level_irq+0xac/0x130)
    [] (handle_level_irq+0xac/0x130) from [] (generic_handle_irq+0x30/0x48)
    [] (generic_handle_irq+0x30/0x48) from [] (handle_IRQ+0x4c/0xac)
    [] (handle_IRQ+0x4c/0xac) from [] (__irq_svc+0x3c/0xe0)
    [] (__irq_svc+0x3c/0xe0) from [] (__do_softirq+0x78/0x200)
    [] (__do_softirq+0x78/0x200) from [] (irq_exit+0x98/0xb4)
    [] (irq_exit+0x98/0xb4) from [] (handle_IRQ+0x50/0xac)
    [] (handle_IRQ+0x50/0xac) from [] (__irq_svc+0x3c/0xe0)
    [] (__irq_svc+0x3c/0xe0) from [] (__delay+0x0/0xc)
    ---[ end trace e028a0afcbe16fc7 ]---
    
    Which is caused because the dsp wants to access to gp timer registers, but tidspbridge failed to power on the clocks for those registers.

    Also here, you can find a sample module to prove the scenario that triggers lockdep error. 

3. [PATCH] ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support
  • Somehow this code didn't make it to mainline when pushing the other patch series. Without this patch, dm timers start/stop sequence doesn't work.
  • BUG:
  • modprobe bridgedriver
    cexec.out <your baseimage>
    modprobe -r bridgedriver
    modprobe bridgedriver
    Will throw:
    omap_timer omap_timer.5: omap2_dm_timer_set_src: clk_set_parent() to 32k_ck FAILED
    omap_timer omap_timer.6: omap2_dm_timer_set_src: clk_set_parent() to 32k_ck FAILED
    

Now you know, in case you happen to try something while these patches are accepted. Hopefully they will before final 3.2, 1 & 2 were pushed to staging-next and not staging-linus :/ (working on it) and haven't seen 3 reposted (tracking it too).

Wednesday, November 30, 2011

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.

Friday, March 4, 2011

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.

Thursday, February 17, 2011

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:


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.

Wednesday, February 16, 2011

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.

Saturday, December 18, 2010

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: