Marcin Juszkiewicz

As already I wrote during summer I was working mostly on AArch64 (ARM 64-bit) — especially on OpenEmbedded support.

I spent time on reminding myself how OE works, learning new tricks and creating some limited images (we removed unneeded daemons etc) for our next step which would be booting ARM64 images in Fast Models. Yes, there is no existing hardware yet for this architecture :) But we want to have distributions ready for it when it became available.

Last Monday Linaro published glibc patches for AArch64 port so normal cross compiler works (people already built bare metal one) and work got speed up. During previous week I got opportunity to discuss with ARM Ltd. engineers about internal compiler errors in gcc and got some of them fixed next day. During hacking sessions in Linaro office (in Cambridge, UK) we managed to get most of our targets done:

• oe-core minimal image
• oe-core base image
• on device toolchain
• meta-toolchain based SDK
• openssl working
• libgcrypt ICE got work around
• meta-aarch64 layer for OE-Core got published

Plans for this week are LAMP image and start merging everything usable back into OpenEmbedded. I do have OpenEmbedded Core branch already and need to create such one for OpenEmbedded.

When I published my last post about ARM boards there were many questions and suggestions with interesting devices. Thank You all for it.

But there were also suggestions about ARM9 or ARM11 based devices. So I decided that it is good time to write what interest me now in ARM world.

But first some inventory. I had/used/have several devices with ARM cpu:

• StrongARM (armv4) one:

  • Sharp Zaurus SL-5500 (which took me to ARM world)

• ARM920 (armv4t) ones:

  • Openmoko GTA01 bv3, bv4 (s3c2410)
  • EDB9301 (EP9301 cpu)
  • Sim-One (EP9307)

• ARM926 (armv5te) ones:

  • Sharp Zaurus sl-5600 (pxa250)
  • Sharp Zaurus c760/sl-6000 (pxa255)
  • Sharp Zaurus sl-c3000 (pxa272)
  • Sheevaplug (kirkwood)
  • Atmel devboards (at91sam9263, at91sam9m10)
  • ST-Microelectronics/ST-Ericsson NDK-15, NHK-15 (st88n15)
  • Nokia 770 (omap1710)
  • Linksys NSLU2 (ixp425 iirc)

• ARM1136 (armv6) ones:

  • Nokia N810 (omap2430)
  • Bug r1.0, r1.2 (i.mx31)

• Cortex-A8 (armv7a) ones:

  • Beagleboard B7, B7, C3 (omap3430)
  • Nokia N900 (omap3430)
  • Nexus S (exynos3)
  • Genesi Efika MX Smartbook (i.mx51)
  • Freescale Quickstart (i.mx53)

• Cortex-A9 (armv7a) ones:

  • Pandaboard EA1, A1 (omap4430)
  • Archos G9 80 (omap4430)

All of that during last 8 years. Most of my ARM live so far was around ARM926 based devices (some of them still can not be listed here) and I do not want to go there again. Kirkwood core was fastest one with 1.2GHz clock and 512MB of RAM it was really fast machine. I only missed Serial ATA in my Sheevaplug (rev 1.0) but even with hard drive on USB it was nice improvement.

Then I played a bit with ARM11 processors. Ok, they were faster than most of ARM9 cpus but I already had experience with Sheevaplug. And after few months first Cortex-a8 board landed on my desk — I got Beagleboard B7 from Bug labs as test platform for their new device. This was improvement!

I still remember my reaction when connected it to normal LCD monitor and saw it used at 720p resolution (1680x1050 was a bit hard for omap3). Moved to Nokia N900 few months later and found that fast cpu means nothing when paired with slow storage and not enough memory for system.

So today I prefer to not look below Cortex-A9 (or comparable cores like ones from Qualcomm or Marvell). Hope to play one day with Cortex-A5 (which should replace ARM926 one day) just to see how low-end armv7a cpu behave.

And wait for ARMv8 to hit market.

Over year ago I wrote post in which I complained about cheap developer boards but concentrated on ones supported by Linaro. This time I want to write about boards which I did not even had occasion to play with.

Most popular one was Rasperry/Pi. But as I already wrote why I’m tired of it I prefer to not discuss it too much. In short: old cpu core (ARM11), not enough memory (256MB), requires closed binaries even to boot (the GPU binary also contains the first stage bootloader).

Then we have a lot of boards based on AllWinner A10/A13 cpus. Single core Cortex-A8, no Linux kernel support in mainline. Fun is that there is Serial ATA controller in SoC but most of the boards does not offer that so users have to use SD or USB storage which is slower. Example devices: Hackberry, Cubieboard, Mele A1000.

Fun stuff starts to appear from Freescale area. i.MX6 cpu has potential and many options available. There are Wandboard, Sabrelite with second one providing interesting addons like mini PCI-Express slot (with PCIe signals) or small board with buttons (Android oriented).

Quad A9 boards are also available with Samsung s3c4412 cpu — like ODroid-X which I described when it was released. But no Serial-ATA in this processor.

So which one to choose? All depends what you want to do with it. Few days ago on debian-arm mailing list someone asked “Workstation based on ARM motherboard, good idea ?” which got me to conclusion that it possible to setup low specification desktop today with ARM cpu.

I wonder how much would I have to pay for mini-ITX compatible board (can be smaller but has to be mountable to normal PC case) with 2-4GB of memory (SO-DIMM preferred) with quad core cpu and Serial ATA. So I could connect usb mouse/keyboard, monitor though HDMI, speakers with 3.5mm jack, Ethernet (1GbE preferred) and boot Debian/Ubuntu straight from SATA hard drive or ssd. 2D/3D acceleration working and recent (max 2 versions old) Linux kernel working with not insane amount of patches. But such day probably will not happen.

UPDATE: Looks like VIA had such idea with their APC board. Neo-ITX format but components few years old ;(

Long, long time passed since last time I changed theme on my blog. What you see this time is Twenty Twelve from Wordpress team. Maybe it is not yet finished but it works better than Carrington which I had before. Not to mention that previous theme was not updated for long time (I did few updates by hand with code from their Subversion repository but it was not comfortable).

This theme looks good on desktop, phone, tablet and I will use it for probably quite long time. Will update it to released version once there will be such one ;D

In 2002—2003 I was thinking about becoming Debian Developer as I had some experience with packaging, solving problems with it etc. But then 2004 came, I bought Sharp Zaurus SL-5500 PDA and started using OpenEmbedded…

Time passed, I got even more experience about packaging, different build systems used in FOSS projects and made good use of that in OE, Poky work. And as a result I went to Linaro (though Canonical) and started working on Ubuntu packages…

So now, when I have my own packages: android-tools and powerdebug the time came to finally start work on becoming Debian Developer to give back to community which gave me so much during last 13 years of my use of Debian.

My application on debian-newmaint ML.

Few months ago one of my friends borrowed SheevaPlug from me. About two weeks later he gave it back — bricked… I did not had time to play with it so it landed on shelf.

Yesterday I took it and decided to get it back to live. Requirements:

• bricked SheevaPlug (v1.0 without SATA)
• power cable
• mini usb cable
• usb thumb drive
• OpenOCD (“apt-get install openocd”)
• cross compiler (“apt-get install gcc-arm-linux-gnueabi” under Ubuntu)
• U-Boot sources (HEAD of mainline)
• Linux sources (also HEAD of mainline)
• serial terminal (picocom, minicom, screen etc)
• few terminals or terminal multiplexer (I used tmux)

Then:

• Connected power and mini usb cables to SheevaPlug. Desktop recognized usb-serial device as /dev/ttyUSB1.
• Connected to it with serial terminal. Nothing appeared there of course ;)
• Run OpenOCD: “cd /tmp/;sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts”. SheevaPlug was detected.
• Connected to OpenOCD: “telnet localhost 4444”.
• Built U-boot:

export CROSS_COMPILE=arm-linux-gnueabi-
make mrproper
make sheevaplug_config
make u-boot.kwb

• Copied “u-boot” to “/tmp/uboot.elf” and used “reset;sheevaplug_init;load_image u-boot.elf;resume 0x00600000” — landed in U-Boot ;)
• There is “sheevaplug_reflash_uboot” macro but it was not working for me. So I used U-Boot to flash itself:

Marvell>> usb start
Marvell>> fatload usb 0:1 0x0800000 u-boot.kwb
Marvell>> nand erase 0x0 0xa0000
Marvell>> nand write 0x0800000 0x0 0xa0000
Marvell>> reset

• Went to Ångström online image builder and built small busybox based image.
• Unpacked tarball into /tmp/initfs, added /dev/ttyS0 node.
• Built Linux kernel:

export CROSS_COMPILE=arm-linux-gnueabi-
make mrproper
make kirkwood_config
make menuconfig (set INITRAMFS_SOURCE to /dev/initfs)
make uImage

• Copied “arch/arm/boot/uImage” to USB thumb drive and inserted it into SheevaPlug.
• Booted image:

Marvell>> set ethaddr 'c0:ff:ee:c0:ff:ee'
Marvell>> set bootargs 'console /dev/ttyS0,115200 rw'
Marvell>> usb start;fatload usb 0:1 0x800000 /uImage;bootm 0x800000

• Landed in nice and small Ångström distribution image ;)
• Went to Ångström online image builder and built console image (task-base based).
• Built Linux kernel (this time without initramfs):

export CROSS_COMPILE=arm-linux-gnueabi-
make menuconfig (unset INITRAMFS_SOURCE)
make uImage

• Copied “arch/arm/boot/uImage” to USB thumb drive and inserted it into SheevaPlug.
• Prepare NAND for UBI:

# mount none /dev -t devtmpfs
# udhcpc eth0
# opkg-cl update
# opkg-cl install mtd-utils
# ubiformat /dev/mtd2
# ubiattach -p /dev/mtd2
# ubimkvol /dev/ubi0 -N rootfs -s 490MiB
# ubiupdatevol /dev/ubi0_0 /media/sda1/angstrom-task-base.ubifs
# mount -t ubifs ubi0:rootfs /media/rootfs
# chown -R root:root /media/rootfs
# cp /media/sda1/uImage /media/rootfs/boot
# sync
# reboot

• Another reconfiguration in U-Boot:

Marvell>> bootargs 'console=ttyS0,115200 rw ubi.mtd=2 rootfstype=ubifs root=ubi:rootfs'
Marvell>> bootcmd 'ubi part nand0,2; ubifsmount rootfs; ubifsload 0x800000 /boot/uImage;bootm 0x800000'
Marvell>> mtdids 'nand0=orion_nand'
Marvell>> set mtdparts 'mtdparts=orion_nand:512k(uboot),4m@1m(kernel),507m@5m(rootfs)'
Marvell>> save
Marvell>> reset

And now my SheevaPlug is operational again. Boots from NAND with latest U-Boot and Linux. There is around 440MB free still on NAND (not counting 4MB partition where kernel was expected to be). I can put it back on shelf now.

The only parts which I needed to compile were U-Boot and Linux kernel. I could skip bootloader and use binary image from Internet but prefer to know what my machines run (and building U-Boot is really easy). Initramfs support in Linux is real live saver as I did not had to play with initrd etc — just build image and boot it. The only problem was that devtmpfs was not auto mounted (even if option in kernel was selected).

I could also use one of those “easy installers” made by PlugComputer community but I found such solutions more complicated (fetching binaries, finding requirements etc) than the one I used.

Day has started as usual. Looked at my Google+, Facebook and Twitter streams and noticed new toy: ODROID-X developer board from HardKernel.

Is it interesting board? Yes, it is:

• Quad core Exynos4412 CPU (ARM Cortex-A9)
• 1GB ram
• 6 x High speed USB2.0 Host port
• 10/100Mbps Ethernet with RJ-45 LAN Jack
• Audio codec with headphone jack and microphone jack
• (micro)HDMI output with audio

As usual some things to complain about:

• 1.8V serial console with own connector (15USD for cable)
• microHDMI connector when normal HDMI would fit
• no Serial ATA (Exynos 4210 has controller, no docs for 4412)
• 2GB ram would be lovely (Samsung Galaxy S3 has it in Korean version)

Anyway looks like during month I will check does someone from friends wants to buy it and get one for myself. May be good replacement for Pandaboard and/or MX53 Quickstart.

When I moved to Canonical and Linaro I stopped using OpenEmbedded. But recently I got some tasks which involved it. In short: there is a plan to use OE to bootstrap ARMv8 support in some Linux distributions.

2 years ago OE guys started creation of OpenEmbedded Core set of metadata. I have to admit that I never used it at that time but supported idea (first mentions of splitting recipes was at OEDEM 2006).

This time using layers is the only way. So I fetched OE Core, OpenEmbedded and Linaro layers and did some builds to find out how it looks today. Some time later Ken Werner left Linaro team so I took over maintenance of meta-linaro layer. Improved documentation a bit and started creating small LAMP like image.

There were issues with toolchain. I use Linaro branded GCC and found out issue with binutils and then with C++ headers — sent some patches and problems were solved by Khem Raj in a bit other way.

After some tests and patches I got LAMP image working out of box. So moved to some more advanced things…

First was update of qemuarmv7a machine to use Versatile Express emulation instead of hacked Versatile PB one. Ken did work for 3.2 kernel but in meantime Yocto moved to 3.4 one. I looked at issues and tried to get it working.

OMG… Now I know why people say that OpenEmbedded have exponentially steep learning curve… Getting kernel into usable state is nightmare. Years ago defconfig was nearly sacred — there were few small changes done to it in kernel.bbclass/linux.inc but it was easy to understand. Now there are KERNEL_FEATURES which may be ignored, big set of scripts, config parts which may be applied (or removed or something else)… I really tried to understand it but my brain decided to go away.

Maybe other day I will manage to understand this magic stuff or will just go for linux-yocto-custom.bb or will write old style linux_3.4.bb recipe without all that magic.