Unbricked my old SheevaPlug

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.

ODROID-X developer board

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

Open Exynos4 Quad Mobile Development Platform

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.

OpenEmbedded again

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.