Marcin Juszkiewicz

Again early wake up… This time 4:44 but I think that today will be better then yesterday because 6h of sleep is often my default amount. Few minutes ago room mate woke up and said: you will never convert to this timezone if you will not sleep longer. But why do I have to? In few days I will be back home.

After “let’s do nothing” Sunday it is time to start doing UDS things. I have quite long list of sessions to attend and for few I will need to select which one to go:

Monday:

• 11:00 Linaro@UDS roundtable
• 12:00 Xdeb cross-compilation environment
• 15:00 Current state of Linaro toolchain
• 16:15 Package development tools
• 17:10 Future Linaro toolchain areas

Tuesday:

• 09:00 Toolchain consumption models
• 11:00 Design a safe and stable build cluster for public ARM PPAs based on the OMAP4 Pandaboard
• 11:00 Using QEMU for demonstrations
• 12:00 Integrate gdbserver support in Linaro
• 15:00 Kexec
• 16:15 Improve detection of device class at install time
• 16:15 Current and future GDB for ARM plans

Wednesday:

• 09:00 Create minimal preinstalled developer images
• 11:00 The Multi-Monitor User Experience multimedia
• 12:00 State of ARM developer tools
• 12:00 Kubuntu Natty and X.org
• 15:00 Provide ARM cross-compiler packages for Ubuntu Natty
• 16:15 Linaro toolchain integration in Ubuntu Natty
• 17:00 Cross-Compilation Environment

Thursday:

• 10:00 Git for Bzr users
• 11:00 Kernel version and flavours
• 11:00 Performance inside of GCC
• 12:00 ARM specific library tuning
• 15:00 Produce an image suitable for set-top boxes for armel

Friday:

• 09:00 Provide a Linaro image with a set of developer-oriented tools installed by default
• 10:00 More stable VM solution for running armel VMs
• 11:00 Multiarch Support for gcc, binutils, dpkg, and apt
• 12:00 Discuss the way forward with the 2D ARM netbook UI
• 15:00 Provide solutions for netbooting and minimally installed Thin Clients on ARM boards

For now this is a list of sessions which I will attend or consider to. Some of them are required for me, some I will lead, some are for curiosity and few I will attend to check what is going on and maybe provide some hints. Compared to UDS-M this one will be rather busy for me. And I have to catch Jamie to grab my PandaBoard from him :)

BTW — if you are interested in checking something on PandaBoard then catch me. Maybe it will be possible to organize some kind of hacking session (but note that I do not have any of required things for board — no psu, no cables/keyboard/mouse/etc).

At 4:30 had to get up and ~hour later I was in a bus to Berlin Tegel (TXL) airport. Arrived, met few people from Canonical, got first coffee. Lufthansa did not has so much luck with 10s as Ubuntu did so our flight moved from 10:10 by about hour. Reason was bad weather and traffic jam over Frankfurt airport.

But finally plane landed there and trip though terminal began. After few minutes I heard that passengers to Orlando should hurry so I did. Just to wait insane amount of time in shuttle bus and then in a plane… Good part of flight was that there were many free seats so we (zyga and me) were able to seat next to each other.

But long flights are boring… Lufthansa on board entertainment system uses wrong calibrated touch screens with very long reaction time. There were few good movies to choose but seating after the jet engine does not make it comfortable due to amount of background noise. On return trip I will test headphones from Nokia N900 as they should isolate more then Lufthansa ones (or ones which I use with laptop).

Arrived in Orlando with about 40 minutes delay. Acceptable I think. Customs queue was huge and I did not track how much time we wasted there but everything went fine. We met few other people and took a taxi to hotel. American seat belts are strange - I prefer European way of mounting them instead of “let it hang from ceiling” which is used here.

Met more people in hotel, got “all american burger” for dinner (was quite good) and went to sleep. Timezones difference kills — I woke up at 3:30 and could not get to sleep again ;(

So you got ARM device and want to build kernel for it? There are few ways how you can do it under Ubuntu 10.10 (or higher).

First you need proper cross compiler. After “apt-get install gcc-arm-linux-gnueabi” you will get proper one.

Next step is compilation of kernel. I will cover 2 things: Ubuntu kernel packages and own kernel.

So… to cross compile Ubuntu kernel we need to have some libraries installed in ARM versions. Simplest way is to use “xdeb” for it:

# apt-get install xdeb
# xdeb -aarmel --only-explicit --apt-source linux-linaro

This will fetch some libraries and install it in host system. But it will not build kernel for us :( Filled bug to not lose track of it.

NOTE: check “dpkg -l *elf*-armel-cross” after xdeb run. If it does not return anything then you need to edit “/etc/apt/source.list” and add line with “deb-src” so APT will know where to go for sources. Do not forget to run “apt-get update” after edit.

Next step is quite simple — all is needed is:

$ cd linux-linaro-2.6.35
$ CROSS_COMPILE=arm-linux-gnueabi- dpkg-buildpackage -b -aarmel

After some time kernel will be cross compiled and packaged.

If you want official Ubuntu kernel instead of Linaro one then use:

$ apt-get source linux-source-2.6.35
$ cd linux-2.6.35
$ CROSS_COMPILE=arm-linux-gnueabi- dpkg-buildpackage -b -aarmel

Other way (not supported by Ubuntu developers) is to build kernel from source outside of Ubuntu. Once you got sources unpacked and configured you need just one command: “ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage modules” to build kernel (replace uImage with zImage if your device does not use U-Boot).

Yes, they (usually) do — but which one? And this is what I want to write about.

Ubuntu 10.10 ‘maverick’ got released week ago. I was using it since UDS-M — especially on my laptop as 2.6.34 kernel worked better on it. Some developers told me that they do not touch it before first Alpha release, others wait for Beta releases even. Fun was with one friend who installed Maverick on his laptop and found that touchpad is not working any more (worked in Lucid)… But it was at RC phase so nearly nothing could be done…

Now Natty development started. Both my x86-64 machines runs kernels from it, laptop is fully upgraded, desktop uses newer toolchain packages (will upgrade soon). But those are mine computers and I used Debian “sid” since it was created…

It was known since previous UDS that there will be OMAP4 based PandaBoard available for developers. And some time ago pandaboard.org was started (for now with temporary website). Boards are still not available at distributors but there are some of them in different projects (like Ubuntu/ARM), some are on a way to new users (mine for example).

When final price was announced many people said that PandaBoard is BeagleBoard XM killer due to same (179USD) price. But is it? Let have a look.

First group of users for such boards are software developers. If they do not work for hardware companies then usually want to get more power for same price. So they will choose PandaBoard.

Second group would be companies which want to produce own hardware based on OMAP3/4. Here it depends on how soon OMAP4 chips will be available in small orders. As OMAP3 can be bought now and BBXM is available to buy many will choose it as this allow to get own hardware ready to market in less then year with having working platform for own developers so final device will start with ready software. One of such is BUG 2.0 which I used at prototype phase. It was designed after using BeagleBoards with BUGBoard extension as base for hardware development.

And Beagleboard XM is available to buy today — with fast CPU, 512MB ram, Ethernet, few USB ports it is big update to previous versions. I never used it — BB C3 is still my primary ARM development system. But in 2-3 weeks situation will change and BB will meet another C3 and one B7 versions in a box due to arrival of PandaBoard.

Each time when I have to use Bazaar I feel sick. It takes hours to do things which should not take more then few minutes. Let’s start with today problem and compare it to git.

I finally got armel-cross-toolchain-base to build with non-sysrooted binutils. It required adding one patch and building binutils twice (once with sysroot for use during build, second without to put it in Ubuntu archive). After whole work I had 2 files to add, 3 hunks of changes in debian/rules and that’s all.

So I used “bzr add” on new files and “bzr commit -i” to select which hunks goes into which commit and repeated it until all changes landed in local branch. But then I discovered that I forgot to add 1.51 version into debian/changelog file before whole that work. So I did it now and next commit added 1.52 version.

And this is when whole “fun” started… I wanted to move r131 (the one with 1.51 changelog entry) to be before r128 one. With git it is just a matter or “git rebase -i” and whole work is done. But this was bzr…

“bzr rebase” command (part of “bzr-rewrite” package) supports only rebasing on top of other branch. But it was also useful as my branch was a bit out of sync with upstream one. So I started to ask questions on #linaro channel as Zygmunt was there and his knowledge of Bazaar was a big help in past. There were few ideas and I did some reading in meanwhile.

One solution was “use pipelines” and you know? They even works but then I needed to cherry pick one commit (r131 one). The only way which I found was “bzr merge -r130..131 :first” and I got all changes but not changeset. Right, git users, you have to commit after merge (and use “bzr log” to find commit message). And when you try “bzr merge” for few revisions they will be squashed… So finally what I did was merging changeset by changeset and commiting with original commit messages. Good that it was just few of them.

So after more then 10 minutes (“git rebase -i”) I finally got branch ready to be pushed. Next time I will spend that time on checking what is wrong with git-bzr-ng plugin as this will give me working two-way handling of Bazaar repositories without touching “bzr” command.

Two weeks ago I was updating Award BIOS on Alix.1c board and failed — computer bricked :(

But there was a way to get it to working state again — PC Engines (vendor or Alix boards) has LPC1a adapter with extra BIOS chip. I contacted them and few days later it arrived here (I will send it back as it is loaned).

Use is simple: plug into LPC connector, boot machine, reprogram on-board flash chip, power off, unplug lpc1a, power on. But I decided to make a use of it and decided to migrate from Award BIOS to coreboot with some extra payload.

As I use only Linux on Alix I tried FILO first. It booted to prompt but refused to see files on CompactFlash card. GRUB v2 supports coreboot but did not run so I tried SeaBIOS instead. And that was it — clean, fast boot to GRUB from CF card.

There is one problem which I did not solved yet: VGA BIOS rom does not work for me. But I will rather do not spend time on it as framebuffer under Linux works without it and I do not plan to run FreeDOS or other systems which would do VGA BIOS calls. Other option is to use SGABIOS which redirects input/output from video card to serial port — works fine.

But the nicest moment was still before me. When I disabled all debug output in coreboot and SeaBIOS I got HUGE improvement in boot time. Linux was loading in a time which previously was needed for Award BIOS to make a beep sound…

Dear fsck

I am not a filesystem expert so when you said to me “filesystem has errors, please run me without -a -p options” I did that. But then you gave me some numbers asked question which I did not had a chance to understand (even Google query did not helped) so I dig for my dusted normal user hat and pressed “Enter” key. Then again and again and again and then I just looked for something heavy and put it on keyboard so you will stop interrupting and just do your work.

So can you just do what you can next time instead of asking me to keep “Enter” key like any other monkey? That heavy object was hedgehog made by my lovely daughter and I prefer to not use for things like that.

Sincerely yours, Marcin