Linux kernel start up and debugging

Slightly off-topic, but linux is stil a unixoid operating system. And every hint on system startup and debugging is valuable.

Click to access lf_abs12_anderson.pdf

Seems like running OpenOCD and Turtelizer2 JTAG dongle with NanosG20 will be necesssary. AT91SAM9G20 support should be available, I hope.

Other points are:

  • Use QEMU/VirtualBox + GDB to observe startup behaviour of FreeBSD
  • Remember, nobody forbids looking at certain portions of Linux/NetBSD/OpenBSD kernel sources
  • OpenBSD and NetBSD are also a source of knowledge
  • Take a look at Atmel startup code
  • Make a table of prio 1 peripherials used by the kernel
  • Prioritize other peripherials

So, in summary I will use NanosG20 hardware, U-boot for PortuxG20 and FreeBSD kernel (no idea what is implemented at the moment)

NanosG20 FreeBSD

I would be glad to see FreeBSD running on NanosG20. Since I have no idea how to do that, I need  to investigate. One way would be finding a posibility to run u-boot for AT91SAM9G20 out of the NanosG20 2nd Stage Bootloader (stripped linux kernel). But another solution does exist:

It is a transplantation of PortuxG20 u-boot into NanosG20.

If this will work, next step would be flashing AT91SAM9G20 u-boot with FreeBSD booting support. And last but not least a working AT91SAM9G20 kernel must be available.

Another help:

Similar processor:

Comparison of linux and bsd kernel startup sequence:

Click to access 05paper_linux.pdf

BSD kernel structure:

Click to access openkyiv2009_proger_sys.pdf


I am stuck with modifying kernel and building console-image. It does work only once after removing  all tmp’s and deploy”s  since afterwards console-image recipe uses wrong outdated shared cache files. Manually configuring kernel via menuconfig and subsequent deploy via bitbake -c deploy virtual/kernel is always succesful.


The undocumented tasks of OE-core bitbake :

  • cleanall
  • cleansstate

They appear to solve my problems. Clean is not sufficient.


Migrating Ångström framework (Bitbake/Poky/OpenEmbedded issues)

Last week I had to use my wife’s powerful laptop. Since downloaded sources take approx. 13 GB, starting from scratch would be not especially efficient. So I had to copy the stuff and met some problems. Of course, it was up to absolute paths contained in configuration files and created temporary data. Following points are important:

  • delete old .oe directory from your home directory if there was one before
  • change saved_tempdir file in ../angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc as there is a absolute path to the original temporary directory in it (do simple `pwd` > saved_tempdir)
  • delete content of ../angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc, leave only saved_tempdir file in it
  • delete site.conf and sanity-info files contained in ../angstrom/setup-scripts/conf, they are being created while running MACHINE=beagleboard ./ config beagleboard
  • sometimes, but do not ask why, sanity.conf contained in ../angstrom/setup-scripts/sources/openembedded-core/meta/conf must be touched. Rules for this behavior remain unknown.

This instruction sounds to be simple and short, but discovering it took quite a while. I hope it will help you !


Another bad thing found is u-boot recipe error, deployment is done only once, after building for first time. The only method to do it again is running following commands with –force option:

bitbake -f -c clean u-boot

and consecutive

bitbake -f -c deploy u-boot

Only this combo works! bitbake u-boot doesn’t – copying from staging area fails, although logfile comment remarks an attempt to do that!


Ångström never ending battle

Found out where the f*** meta-toolchain recipes are stored. Hoorrah!!  /Projects/angstrom/setup-scripts/sources/openembedded-core/meta/recipes-core

Ångström  distribution build environment set following infos at :

I must say, the fragmentation of the embedded linux software development tools is horrific. I’ll try to make my notices publique to contribute a small piece to open source community.

There is a difference between “setup-script method” and Narcissus building – the latter one uses ancient stable 2.6.32 kernel, the first one the 3.0.14 branch.


General remark: never ever use Ralink WLAN adapters (rt73usb) on Linux! After years spent on chasing sloooow SSH logins and dripping SSH-Session bytes I discovered ath9k_htc driven TP-LINK device (TL-WN722NC) – it works like a charm. 


Why am I using Ångström? It is coherent (sic!! in comparison to Ubuntu rootfs/kernel splitted maintanance). My goal is to create a BeagleBoard based low-latency gateway system for connecting CAN bus with WLAN device on the other side. It needs PEAKCAN driver, stable WLAN driver, and hostapd based Access Point. That’s all. It took a lot of time to build separate working software chunks. Ubuntu Natty rootfs with Robert C Nelson kernel 3.1 + hostapd + PeakCan driver works allright (but slow!). One has to remember aligning gdb and gdbserver when working remotely from Ubuntu Oneiric + linaro toolchain (GDB version mismatch).


Angstrom “setup-script” compilation this morning:

  • meta-toolchain -> OK
  • meta-toolchain-sdk -> NOK, fails while trying to change something in my host /etc and so on. Why? Where is the description of this bb file? What does it do? Questions over questions…
  • console-image -> OK


Next problem will be compiling PeakCAN driver with Angstrom kernel, since the driver needs kernel headers. Compilation of Ubuntu RCN kernel aganist them was a piece of cake.


Next, I’ll try Yocto/Poky. How do they differ form OpenEmbedded? How often do they cross-contribute if ever? I think without analyzing Angstrom setup-scripts which are somehow easier to understand I’ll stay stupid…


This link let me understanding what to do to be able to cross-compile stuff using local built native ipk packages:

Hopefully, this will work fo bare-bone Angstrom/OE, not Poky only.


Bought a new Linux SBC today.

The NanosG20 SBC comes from and seems to be better than Olimex SBC’s, being built with a newer AT91SAM9G20 microcontroller and offering a already patched kernel ver. 2.6.35 together with Debian distro for a price of of merely 99 EUR (+VAT)!

There is an alternative SBC coming from taskit – PortuxG20, but it is more expensive (179 EUR).

SAM9-L9260 or SAM9-L9261 from Olimex are quite expensive (resp. 139.95 and 299.95). The latter offers an TFT display interface, and both do not reach the performance of taskit or ledato SBC’s.

All considered SBC’s have robust 2.54 mm pinheaders and DB9 connectors for heavy-duty HW interfaces (the rest are standard mini-USB and RJ45).