A bit about OpenEmbedded

My project's primary goal is making life easier for developers who want to develop for the DSP, and thus I need to familiarize myself as much as possible with how development cycle for OMAP3 systems (specifically for the BeagleBoard) is like in order to be able to understand the pain and suffering the developers undergo. And this, in turn, involves setting up OpenEmbedded, the toolchain/build framework which is the way to build the Ångström distribution from its source.

One might ask, why is a seperate build framework necessary in the first place? Isn't makefiles sufficient to carry out pretty much any build task? While I'm not exactly in the position to make expert comments on the subject, I can point out several things that would render such a seperate framework necessary:

• it makes cross-compilation (=compiling something on your machine that's going to run on some other processor/type of machine) easier since you don't have to manually obtain and set-up a compiler suite for the target machine
• building a whole Linux distribution from scratch can involve a lot of complicated internal dependencies between the things you're going to build, and this probably will mean things like a lot of downloading, untar'ing, strict order of building packages, making a lot of "make config"s and running recursive makefiles, and so on
• as a mixture of the two above, when you want to build a specific new package for your embedded device, the build framework also helps since it keeps track of changes and dependencies for these. 

So here's what OpenEmbedded (and bitbake, which is quite central to OE's workings) does for you: once you set it up properly, you just tell it "all right, I want the latest Ångström console image built for the BeagleBoard" and it downloads, configures and builds everything for you by itself! Isn't that great?

Well, of course, it's far from perfect - there might be some difficulties involved with setting it up properly, dealing with the errors that may occur during the build process, and running things for the first time tends to take very long, so be prepared to face a lot of frustration and have a lot of time in your hands (possibly even a second computer to do other things in parallel :)).

In my next post, I'll be describing my experiences about setting up OpenEmbedded in Ubuntu 10.04, solving the errors that may come up and similar. As of the time of writing, I was still trying to build the Ångström console image successfully and failing miserably, but I can at least see some light at the end of the tunnel :)

Ångström running on the Beagle

Once I got my Beagle communicating, it was time to get the penguins in (although later I found out that carrying out the actual verification process might have been a good idea - check here for the latest version of the official verification process).

Following the instructions on the beginners page on eLinux wiki, I decided to use XorA's script to make formatting the SD card easier. On my Ubuntu 10.04 machine, the 2GB Kingston card I used showed up as /dev/mmcblk0 and it was a simple matter of sudo-calling the script on it afterwards. I plugged out the card and put it back again, verifying that both partitions (boot and rootfs) were in place when Ubuntu displayed them on the desktop.

Next, I downloaded the latest Beagle demo image files from here, which were as follows:

• the latest rootfs archive, Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.rootfs.tar.bz2 
• the MLO file, MLO
• the modules archive, modules.tgz
• the u-boot image, u-boot.bin
• the kernel image, uImage

Then I followed the copy order present in the wiki (MLO, u-boot and uImage to the boot partition, copy and untar the rootfs into the rootfs partition, followed by copying and untar'ing the modules archive in the same place). My hands were getting sweaty as the big moment approached. Would I see the ASCII Ångström logo? Would I get kernel panics, or everything just freezing at some point while booting?

There was only one way to find out. I sudo'd up minicom, put in the SD card into the Beagle card reader, held down the USER button on my Beagle, and connected the Y USB cable...

And there it was! All to swiftly, the kernel uncompressed itself, set up, and a couple of ten seconds later I was greeted by the ASCII Ångström logo, prompting me for the username. I typed in "root" and got to the shell. After playing around for a little while with some commands and verifying that everything was working, I decided to try out setting up USB networking and then VNC'ing into the Beagle to see some GUI action. I set up an IP address on the Beagle side for the usb0 using ifconfig as described, then enabled the interface.

But something was wrong: my Ubuntu host didn't detect the Beagle at all! I looked at the dmesg kernel logs, the lsusb device listing, the network manager interfaces list...it simply wasn't there. I tried loading the usbnet and cdc_ether kernel modules manually on the host side, re-loading them on the Beagle side and many combinations of these actions in different orderings - none of which helped.

I was feeling quite depressed when Koen mentioned in #beagle that the problem might be a bad USB cable :)

Rummaging around the house, I found another USB A to mini B cable, and tried with that instead. Instantly, before the kernel had even booted up, it showed up as an USB gadget in the Ubuntu networking manager! I had just sighed with relief, but was just about to find out it's too soon...

It was time for...Kernel Panic!

[   17.127868] Unable to handle kernel NULL pointer dereference at virtual address 00000014
[   17.135986] pgd = c0004000
[   17.138732] [00000014] *pgd=00000000
[   17.142333] Internal error: Oops: 5 [#1] PREEMPT
[   17.146972] last sysfs file:
[   17.149963] Modules linked in:
[   17.153045] CPU: 0    Tainted: G        W   (2.6.32 #1)
[   17.158325] PC is at musb_interrupt+0x9f8/0xbb8
[   17.162902] LR is at musb_interrupt+0x9e4/0xbb8
[   17.167449] pc : []    lr : []    psr: 60000193
[   17.167449] sp : c0625ee0  ip : c0625f18  fp : 000000f0
[   17.178985] r10: 00000000  r9 : 00000099  r8 : 00000009
[   17.184234] r7 : 00000000  r6 : cf82f108  r5 : 00000001  r4 : 00000000
[   17.190795] r3 : 00000000  r2 : 00000000  r1 : fa0ab000  r0 : cf82f108
[   17.197357] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   17.204803] Control: 10c5387d  Table: 80004019  DAC: 00000017
[   17.210571] Process swapper (pid: 0, stack limit = 0xc06242f0)
[   17.216430] Stack: (0xc0625ee0 to 0xc0626000)
[   17.220825] 5ee0: 00000000 ffff6b60 00000000 c0684a28 c0624000 cf82f108 60000113 cf8a0a00
[   17.229064] 5f00: c0624000 0000005c 00000000 00000000 c066cfc0 c034101c 060db884 cf8a0a00
[   17.237274] 5f20: c063a5d8 c00a4e90 00000000 cf8a0a00 c063a5d8 0000005c 00000002 00000001
[   17.245513] 5f40: c0624000 0000001f 00000000 c00a7058 0000005c 00000000 c0627e84 c003c074
[   17.253723] 5f60: 00000001 ffffffff fa200000 c003cb44 00000000 80000013 80000013 00000000
[   17.261962] 5f80: c0624000 c0627fe0 c0627e84 c0670fcc 8002f790 411fc083 0000001f 00000000
[   17.270172] 5fa0: c06385c8 c0625fbc c004ca8c c004d2e4 60000013 ffffffff 00000000 c003dfc4
[   17.278411] 5fc0: 00000000 c06b80a0 c0670f90 c0032010 c0627e78 c0008984 c0008498 00000000
[   17.286621] 5fe0: 00000000 c0032010 10c53c7d c0671020 c0032414 80008034 00000000 00000000
[   17.294891] [] (musb_interrupt+0x9f8/0xbb8) from [] (generic_interrupt+0x64/0xa8)
[   17.304168] [] (generic_interrupt+0x64/0xa8) from [] (handle_IRQ_event+0xac/0x1ec)
[   17.313537] [] (handle_IRQ_event+0xac/0x1ec) from [] (handle_level_irq+0xbc/0x148)
[   17.322906] [] (handle_level_irq+0xbc/0x148) from [] (asm_do_IRQ+0x74/0x98)
[   17.331665] [] (asm_do_IRQ+0x74/0x98) from [] (__irq_svc+0x44/0xa8)
[   17.339721] Exception stack(0xc0625f70 to 0xc0625fb8)
[   17.344787] 5f60:                                     00000000 80000013 80000013 00000000
[   17.353027] 5f80: c0624000 c0627fe0 c0627e84 c0670fcc 8002f790 411fc083 0000001f 00000000
[   17.361236] 5fa0: c06385c8 c0625fbc c004ca8c c004d2e4 60000013 ffffffff
[   17.367919] [] (__irq_svc+0x44/0xa8) from [] (omap3_pm_idle+0x4c/0x50)
[   17.376220] [] (omap3_pm_idle+0x4c/0x50) from [<00000000>] (0x0)
[   17.383148] Code: e3530003 13a02000 05963078 05933018 (05d33014)
[   17.389343] ---[ end trace 650abcc06c2958fc ]---
[   17.394012] Kernel panic - not syncing: Fatal exception in interrupt

I'll admit that it wasn't very pleasant, and the fact that I could boot the kernel just fine with the "bad" USB cable was also a bit curious. I still don't know for sure why this particular kernel panic occurs, but it seems to be related with the USB gadget drivers (I don't think it's host-computer related, since I got exactly the same results using a Windows XP host as well. How I hate HyperTerminal).

Guessing that it's probably a kernel issue, I decided to go for the other closest kernel image I could get my hands on, which was really close indeed. In the rootfs, under the /boot directory was another uImage-2.6.32 so I just copied it to my computer, did a comparison with cmp against the uImage I had downloaded to make sure it wasn't the same (it wasn't), and finally replaced the uImage with the one from /boot. This did solve the kernel panic issue, and I was once again able to get to the shell. And this time, the USB networking was all functional! I first ssh'd into the Beagle to make sure everything was working, then I used Ubuntu's VNC viewer (called "Remote Desktop Viewer") to take a small tour of the Ångström Enlightenment GUI. All was fine and mellow :)

Coming Up Next: Setting up OpenEmbedded in Ubuntu 10.04

Setting up the BeagleBoard and the dev-env

My Beagle arrived some three days ago after waiting in the local DHL distribution hub for several days (something went wrong with the address). As can be imagined, I was quite happy about finally receiving it and immediately made some nerd porn (=unboxing photos) out of it. A handsome little board it is to be sure.

Next was a little cable nightmare to go through. The Beagle has various channels of communications available, but unfortunately the RS232 (serial) interface is somewhat compulsory to get the board going for the first time. Thus I went out hunting in Uppsala to find the AT/Everex (IDC-10 to DBM9) cable.

Doesn't look all that fancy, does it? The problem is that it's a bit old and it's not the kind of thing that one would come across in modern electronics stores. I tried several bigger boutiques like MediaMarkt, ELGiganten, ONOFF, then a number of smaller shops in town. Not a chance. I finally found it in a modding/hardware service kind of shop (the variant I bought, as seen above, allows the serial port to be "brought out" from the older motherboards) and bought a female-to-female null modem cable there as well. Voila!

Back home, I noticed that the input pin 10 in my cable was plugged - appearantly pin 10 is used neither on the Beagle nor the cable itself, so it's suggested to either remove the plug or cut away the pin 10 on the Beagle. I tried removing the plug on the cable with a hot needle but it put up quite a fight. And I didn't have needle-nose pliers, so I just bent pin 10 on the Beagle sideways instead. It looks a bit crocodile-ish but does the job (plus it gives reference together with the plugged corner of the cable so I can't plug in the cable backwards :)).

I set up minicom on my Ubuntu 10.04 system, connected the USB-to-serial adapter (which uses the profilic PL2303 kernel module and works without problems, by the way) to the null modem cable, connnected the Beagle to the null modem with the AT/Everex cable, plugged in the USB A to miniB cable, and got a warm welcome from the U-Boot already present on the NAND.

Coming up next: Ångström running on the Beagle and the importance of working and non-working USB cables.

So what's this all about?

My dear readers(-to-be), welcome once again to maltanar's scribbles. Aside from attempting a reclaim on the blogging world, this blog will also serve a more important purpose. Here will be my scribbles on my Google Summer of Code project, for the BeagleBoard, which was initially entitled, rather horrifically, RPC-Like POSIX Wrappers for DSPEasy. A better name is in the works, but in the meanwhile I'd like to tell you all what it's all about.

BeagleBoard is (and the Pandora will be) a powerhouse, thanks to its 3-core (a GPP - generic processing, a GPU - for graphics processing, and a DSP - for, let's say, heavy number crunching! the acronym itself means Digital Signal Processor) OMAP3530 system. Therefore laptop-like performance at handheld power levels is most certainly not a myth. But to be able to achieve true laptop-like performance, the power inside needs to be harnessed to the max.

Of course, thanks to the heterogenous multi-core architecture, there are quite a few different ways in which this power can be harnessed. What I'll be doing will be targeting the DSP. Or more accurately, I'll be doing something that targets (in a friendly way!) programmers that wish to develop for the DSP by doing their work easier.

Right now, making actual use of the DSP is rather cumbersome and even after once you've gotten started, the development cycle isn't exactly bliss: you can't just "printf" the results of your experimental FFT code to the screen, for example, since there is really none - you have to deal with the details of interprocessor communications to see what's going on inside the DSP, as well as put data inside.

My aim with this project will be to create a RPC (remote procedure call)-like framework, which can be used to call any GPP-side function from the DSP-side, and create a set of POSIX wrappers using this framework to make life easier for developers.

Actual status updates coming soon! :)

New blog is here

Having let maltanar.net down for quite some time, I started feeling guilty and eventually decided that blogging was worth another try. Plus, I have a feeling that it might just become necessary in the near future. So...