Buildroot Linux on the Pandaboard Rev. 3

March 13, 2014 Leave a comment

At my work I have to develop software for the Pandaboard. Unfortunately there are a lot of false or incomplete information on how to build/run U-Boot and/or the Linux kernel on the Pandaboard. Most of the false information is due to the fact, that a lot of people own a Pandaboard ES and just write something like: “How to build Linux for the Pandaboard”, when it should state “…for the Pandaboard ES.
This tutorial is all about booting Linux on the Pandaboard Rev. 3 with the TI Omap 4430. You can easily check which version of the Pandaboard you have, by flipping it over to the backside. In the picture below you see a photo of my Pandaboard Rev. 3.

Pandaboard Rev. 3

Pandaboard Rev. 3

Builroot GIT
Unfortunately the GIT repository of Buildroot is incredibly slow, but once you have cloned the repository with

git clone git://git.buildroot.net/buildroot

you are ready to go.

Linux .config
Before we start configuring our target system, we have to fetch a working configuration for the Linux kernel. I have prepared a .config for the Linux kernel 3.9.11 which boots on my Pandaboard Rev.3.

cd buildroot
wget http://pastebin.com/raw.php?i=pEY0SwCq -O panda_config

Now we have a working config and can start setting up the rest of our target system.

Buildroot configuration for the Pandaboard
First we have to configure Buildroot to build an uImage (Linux Kernel), a MLO binary (second stage bootloader) and an u-boot.bin (third stage bootloader). To start the configuration we have to change into the newly created directory and call the following

make menuconfig

Once we are in the settings we can start configuring our system.

Target options
The Target options menu defines the overall target architecture (and some additional settings). The entries should look like

    Target Architecture (ARM (little endian)) —>
    Target Architecture Variant (cortex-A9) —>
    Target ABI (EABI) —>
[ ] Enable NEON SIMD extension support
    Floating point strategy (Soft float) —>
    ARM instruction set (ARM) —>

Kernel
The Kernel menu allows us to customize our Linux kernel. In the entry Configuration file path we specify our previously downloaded Linux Kernel configuration. The target binary should be an uImage, because that’s the image type U-Boot can easly recognize and load. The load address is somewhere in the RAM of the Pandaboard (start of RAM is 0x80000000). Everything else can be taken from below

[*] Linux Kernel
      Kernel version (Custom version) —>
(3.9.11) Kernel version
()   Custom kernel patches
      Kernel configuration (Using a custom config file) —>
(panda_config) Configuration file path
      Kernel binary format (uImage) —>
(0x80008000) load address (for 3.7+ multi-platform image)
[ ]  Device tree support
      Linux Kernel Extensions —>

Filesystem images
To make the boot process easier we link a RAM disk into the Linux kernel. This increases the size of the uImage but adds the convenience that we only have to load one image.

[ ] cloop root filesystem for the target device
-*- cpio the root filesystem (for use as an initial RAM filesystem)
      Compression method (no compression) —>
[ ]   Create U-Boot image of the root filesystem
[ ] cramfs root filesystem
[ ] ext2/3/4 root filesystem
[*] initial RAM filesystem linked into linux kernel
[ ] jffs2 root filesystem
[ ] romfs root filesystem
[ ] squashfs root filesystem
[ ] tar the root filesystem
[ ] ubifs root filesystem

U-Boot
Newer U-Boot versions can create the second stage bootloader for the Pandaboard, in addition to the actual third stage bootloader (U-Boot). So we don’t have to enable X-loader in the Buildroot configuration. As a source for U-Boot we use Linaro’s customized U-Boot repository. We check out the required branch and load the correct Board definition (omap4_panda).

[ ] Barebox
*** gummiboot needs a toolchain w/ largefile, wchar ***
[ ] mxs-bootlets
[*] U-Boot
(omap4_panda) U-Boot board name
      U-Boot Version (Custom Git repository) —>
(git://git.linaro.org/boot/u-boot-linaro-stable.git) URL of custom reposito
(2011.11.2) Custom repository version
()    custom patch dir
U-Boot binary format (u-boot.bin) —>
[ ]   produce a .ift signed image (OMAP)
[ ]   Custom Network Settings —-
[ ]   U-Boot SPL support
[ ]   Environment image —-
[ ] X-loader

Build
Once we are done with the configuration we save the settings…

Saving the menuconfig

…and then we can build everything, by calling

make

When everything is done, we can find the binaries in the following folders

  1. uImage - output/images
  2. u-boot.bin - build/uboot-2011.11.2
  3. MLO - build/uboot-2011.11.2

U-Boot boot script
Before we copy everything to an SD card we create a small U-Boot script to automate the boot process. Just copy the below text into a file called boot_mmc.txt.

setenv bootargs ‘root=/dev/mmcblk0p2 rw rootwait rootfstype=ext3 console=ttyO2,115200n8 vram=16M’
fatload mmc 0 82000000 uImage
bootm start 82000000
bootm loados
bootm go 82000000

Afterwards execute the following command to create the boot.scr script

mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n “Panda SD Boot” -d boot_mmc.txt boot.scr

Now we put an SD card into our PC, format it to FAT32 and enable the boot flag. For this job I usually use gparted. But feel free to use the tool of your choice.

Afterwards we copy all files to the SD card

mount /dev/sdc1 /media/sd_card
cp /output/build/uboot-2011.11.2/MLO /media/sd_card
cp /output/build/uboot-2011.11.2/u-boot /media/sd_card
cp /output/images/uImage /media/sd_card
cp /boot.scr /media/sd_card

Finally put in the SD card and see the system boot.

My Pandaboard in action

My Pandaboard in action

That’s it now you should have a running Linux setup for the Pandaboard.

Have fun & Happy hacking!

Advertisements

Root Access on Ouya

May 31, 2013 7 comments

Today I received my Ouya. For the ones who don’t know what an Ouya is, check out this link. The Ouya device has already the ‘su’ binary installed, so there is no actual ‘rooting’ necessary. But in order to get root access you still have to take some things into account.

ADB (Android Debug Bridge)
First we need a copy of ADB (Android Debug Bridge). ADB ist part of the Android SDK, which can be downloaded from here. Download the package according to your OS. On Linux just do the following steps

$ wget http://dl.google.com/android/adt/adt-bundle-linux-x86-20130522.zip
$ unzip adt-bundle-linux-x86-20130522.zip
$ cd adt-bundle-linux-x86-20130522/sdk/platform-tools
$ sudo cp adb /usr/local/bin

The ADB binary is self contained, so it can just be copied to somewhere else (e.g. /usr/local/bin).

adb_usb.ini
The second thing we need is an entry for the Ouya in our usb devices list. First we need to connect the Ouya to our PC with a micro-usb/usb-cable. Then call

$ dmesg

The output should look something like the following

[289053.442387] usb 1-1.5.6: new high-speed USB device number 25 using ehci_hcd
[289053.564585] usb 1-1.5.6: New USB device found, idVendor=2836, idProduct=0010
[289053.564595] usb 1-1.5.6: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[289053.564601] usb 1-1.5.6: Product: OUYA
[289053.564606] usb 1-1.5.6: Manufacturer: OUYA
[289053.564610] usb 1-1.5.6: SerialNumber: 00000000000000

If you haven’t upgraded the Ouya’s firmware yet the vendor ID (idVendor) might be different. If you have installed the latest firmware the ID should be ‘2836’, like the one from above. Now we have to add the vendor ID to our ‘adb_usb.ini’. Just do the following steps to add the device

cd ~
mkdir .android
echo “0x2836” >> ~/.android/adb_usb.ini

It is important to add a ‘0x’ in front of the actual number (its hexadecimal).

Connecting to the Ouya
Now we should be able to connect to our Ouya using ADB

$ sudo killall adb
$ sudo adb devices

The ‘devices’ command should list the Ouya

List of devices attached
00000000000000        device

If it does not list your device make sure to kill all ADB instances on your machine, and the start ADB (with ‘sudo’) again.

sudo killall adb
ps -e | grep adb

The second command shouldn’t output anything. If it lists

 6680 pts/1 00:00:00 adb
15926 ?      00:01:31 adb

then there are still instances of ADB running.

When everything is cleaned up, and the ‘adb devices’ lists our Ouya we can connect to it using

$ sudo adb shell

This gives us a shell on the Ouya (we can even be super user).

Categories: tech foo Tags: , ,

Linux not From Scratch – But Debian

February 8, 2013 1 comment

I’m a huge fan of the APT package management system, but I don’t like the trend where Canonical is going with Ubuntu and I’m not really a fan of Gnome3. Therefore, I was looking for something based on the APT package management system which is neither Ubuntu/Unity nor Gnome3.

My idea was to take a minimal Debian testing installation and customize it to my needs. No sooner said than done!

Preparation

I already had a running Linux system on my Laptop, so I was able to prepare the boot medium directly from this machine. But the following steps can also be performed from a Windows or Mac machine, because UNetbootin is available for all these three operating systems (my boot medium had to be a USB stick because my X220 doesn’t have a CD/DVD drive).

I started my plan by installing two necessary packets

sudo apt-get install gparted unetbootin

Then I started gparted and created a fat32 partition on my USB stick. Afterwards I started UNetbootin and selected Debian testing x86_64 hd_media as my target system. Once finished I downloaded the first DVD of the Debian testing release

wget http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso

and stored it on the USB sticks root directory along with the stuff that UNetbootin put on it. Now, some of you might ask why I didn’t use the much smaller network installer and instead downloaded the whole DVD image when I only wanted to use a minimal set of applications. In my defense, I tried the network installer first, but I had some problems with it. The running Kernel lacked support for LVM, disk encryption and my SSD wasn’t recognized.
Once done preparing my USB stick I plugged it into the X220 and rebooted the system. During boot I held down the blue ThinkVantage-button, then hit F12 to select a temporary Boot device. From the menu I selected my USB stick and started the Debian installer.

Installation

I went through the default Debian installation (I used my entire disk with LVM and full disk encryption) up to the software selection dialog. There I only selected the following:

[ ] Desktop environment
[ ] Web server
[ ] Print server
[ ] DNS server
[ ] File server
[ ] Mail server
[ ] SQL server
[*] SSH server
[*] Laptop
[*] Standard system utilities

I didn’t want a graphical system just yet, because I didn’t want one of the bloated environments like Gnome or KDE. I just selected some essential components (Even the SSH server is optional. I use it quite often therefore I enabled it, but it isn’t a must-have).

Configuration

After installing a basic system it was time for me to boot my newly created system. After logging in I installed a set of tools

sudo apt-get install i3 vim-gtk zsh rxvt-unicode build-essential xinit

The package build-essential is also optional. I’m a developer so I need it. Maybe I forgot some packages, just install them as you need them.

That was basically it, now I was able to start the GUI by executing

startx

i3wm
My window manager should be plain, simple and easy to configure, so I decided to use i3wm. It’s a tiling window manager which provides a lot of cool features. The first usage of i3wm might be a little bit unfamiliar but once you get used to it, it’s very powerful. Here is a quick introduction to i3wm.
You have one Super key, upon first start you can decide which one to use, either ALT-key or Windows-key (I simply refer to it as Super key). There are only a handful shortcuts you need to know in order to navigate through the system.

Super+d Start application
Super+Number Switch between workspaces
Super+cursor left/right Switch active window
Super+w window takes entire screen
Super+e windows side-by-side

For a more complete reference check the keybindings page on i3wm.org. For now I wanted to spawn a shell, so I hit Super+d, typed urxvt in the appearing bar and hit Enter.

The default installation of i3wm didn’t look very appealing, so I wrote my own config file. I stored it in ~/.i3/config and the config file for the i3status bar in /etc/i3status.conf. I overwrote the existing files. Now I was able to just hit Super+r to reload the GUI and everything looked a lot better. It might be necessary to install additional fonts (I don’t remember exactly =P). If so, just run

sudo apt-get install xfonts-base

I added the following line in my ~/.i3/config to show my wallpaper.

exec feh –bg-scale /home/jester/Pictures/24.jpg

zsh
Before I did any additional configuration work, I wanted to switch to a better shell. In the beginning I had already installed the zsh. Now I just wanted a good configuration. Luckily there is a guy (Robbie Russell) who does this for us. I had to fetch oh-my-zsh from Github (on the bottom of the Github page are further installation instructions). After installing this framework I opened my ~/.zsh and changed the following lines:

plugins=(git debian cp)

to enable the cool git feature which you will see in the screenshot below, and also some aliases for aptitude. Oh-my-zsh contains several themes, I decided to use geoffgarside. So I added the following line

ZSH_THEME=”geoffgarside”

All themes can also be browsed here. Just select the one you like.

~/.Xdefaults
For a consistent color scheme I had to write my own ~/.Xdefaults file to have cool colors and transparency in the urxvt terminal windows. After storing the file in ~/.Xdefaults I was able to apply the changes by calling

xrdb ~/.Xdefaults

When I spawned a new shell the background was transparent, the wallpaper was visible and the colors matched the ones in the i3bar.

Vim
Instead of installing vim I installed vim-gtk, because with vim-gtk allows to navigate with the mouse and copy/paste text into/out of vim easily by selecting the text. For an even better experience, I wrote my own ~/.vimrc. I just stored this file in ~/.vimrc to have a solid vim configuration.

Screenshots

The following screenshot shows my fully configured system. In the bottom right I have vim open so that you can see the colors, and the status bar in vim. On the top left you can see the zsh (with oh-my-zsh) and its git integration. I’m currently in a directory which contains a git tree (Linux kernel), so thanks to the plugin I can see on which branch I’m currently on. On the left side I simply run Firefox with my start page. On the bottom you can see the i3bar showing system information (e.g. IP address, battery level, CPU temperature, etc.). Also in the i3bar in the far right corner you can see that I’m running Pidgin and Dropbox. It’s pretty neat that the i3bar supports applications with notification icons.
screenshot_i3wm

Tips

Several parameters in my configuration files are device depended.

xinit
If the i3wm doesn’t start correctly check the file /etc/X11/xinit/xinitrc. Mine looks like

#!/bin/sh
# /etc/X11/xinit/xinitrc
#
# global xinitrc file, used by all X sessions started by xinit (startx)

# invoke global X session script
. /etc/X11/Xsession

Volume Up/Down keys
In my ~/.i3/config I have mapped two keys for volume up and down and another one to mute the sound

bindsym XF86AudioRaiseVolume exec amixer -c 0 — sset Master playback 3.22dB+
bindsym XF86AudioLowerVolume exec amixer -c 0 — sset Master playback 3.22dB-
bindsym XF86AudioMute exec /usr/local/bin/toggle-mute

These keys might differ depending on the used device. With the tool xev it is possible to capture the correct key events and compare them with the mapping table (xmodmap -pk). It might be necessary to write a new ~/.Xmodmap. I didn’t need to do this, therefore I can’t explain it. But there are plenty of information on the web about that.

Have fun!

Categories: tech foo Tags: , , ,

Debian on Android/Atrix with Debootstrap (Part III)

July 22, 2012 1 comment

As an extension to my previous post I will now explain how to make all the stuff persistent. You then do not need to retype the whole stuff to start the VNCServer every time you restart your phone. Just put the following script into the folder /etc/init.d/ of your chroot:

#!/bin/sh

export HOME=”/root”
export USER=”/root”

STARTCMD=”vncserver -geometry 960×540″
STOPCMD=”vncserver -kill :1″

case $1 in
    start)
        if [ -e /tmp/.X1-lock ]; then
            echo “VNCServer already running”
        else
            $STARTCMD
        fi
            ;;
    stop)
        $STOPCMD
        ;;
    restart)
        $STOPCMD
        $STARTCMD
        ;;
    *)
        echo “$0 start|stop|restart”
        exit 1
        ;;
esac

exit 0

Afterwards you are able to start and stop the VNCServer, with the commands

service vncserver start

and

service vncserver stop

This allows starting, stopping and restarting the server.
To actually start the server when you switch into your chroot, you have to autostart it. The following way is not best practice (don’t let a Linux guru know ;-)). But for us it is working:

echo “service vncserver start” >> /root/.bashrc

or (when you don’t want to get the “VNCServer started…” message everytime you log into your chroot)

echo “service vncserver start > /dev/null 2>&1” >> /root/.bashrc

When you call “bootdebian” in your shell, the VNCServer will automatically start and you can connect to it via your favorite VNCClient.
Have fun!

Debian on Android/Atrix with Debootstrap (Part II)

July 16, 2012 7 comments

When running Debian on Android in a chroot, you are bind to a Shell, but if you want a graphical user-interface to have a more comfortable usage experience you can also install a VNC server in the chroot and connect to it from the Android host system. This tutorial is an extension to my already published tutorial because someone asked me if I can write a little bit more on how to get the VNC Server to run. Here it is:

  • Follow my first tutorial (here)
  • Start the chroot environment
  • Before you execute the commands below keep the following things in mind,
    • You need around 38MBytes of free storage in your chroot
    • When first starting the vncserver you need to specify a password (Remember it!)
  • Now execute the commands to install the vnc server and a lightweight X-Window setup

    aptitude install –without-recommends lxde tightvncserver xfonts-base
    export USER=root
    vncserver -geometry 960×540

  • Switch back to Android and install the android-vnc-viewer
  • Start the app and put in the following settings:

    Nickname: *Whatever*
    Password: -the-vncserver-password-you-defined-before-
    Address: localhost
    Port: 5901
    Username: -empty-
    Color Format: 24-bit color (4bpp)

  • Make sure you set the port to 5901 not the default (5900).
  • You are done. With these steps you should be able to connect to the running VNC server inside the chroot.

Finally, here is a photo of my Atrix running LXDE:
20090101_001

Thank you, and have fun.

Debian on MacOSX with VirtualBox in Headless Mode

Orignally I was searching for a way to build Buildroot images on MacOSX. Because my IMac has much more power than my Thinkpad X220i (i5 Quad-Core vs. i3 Dual Core). Therefore I tried to install all “build-essentials” (the Debian/Ubuntu users know what I mean) via MacPorts. Unfortunately some packets aren’t available through MacPorts, and missing packets aren’t the only problem, the fact that MacOSX not always complies to standards makes it hard/impossible to create uImages with Buildroot on MacOSX. Thus I was searching for a way to have a full Debian system available on my Mac.

My First idea was a Debian Chroot, but in my knowledge there is no way to get a Debian Chroot to run on MacOSX (although there is a Debian port for the Mach Microkernel). My second thought was then a Virtual Machine. I know with a VM I loose a lot of performance. But I gave it a try, because while my Mac executes build tasks I still can use my Laptop without any constrains and do something else at the time.

Therefore I was looking for an approach to have an “always on” Debian on my Mac (By “always on” I mean, starts when I boot my system, and runs in the background without needing too much CPU cycles when idling). At first I tried to automate the start of the VirtualBox application during boot. But I don’t wanted to have the running application always in my sidebar (two times actually, first, the VirtualBox icon itself, and second the VM icon).

Luckily on a website I found an explanation on how to start a VM in headless mode with VirtualBox’s command line tools. First I downloaded the Debian Netboot image (16MBytes), then I started the VirtualBox application and set up a new Linux system (For the name I chose “debian_shell”, I set the amount of Ram to 2Gbytes (from my 4GBytes) and for the harddisk I selected 8GBytes “dynamically allocated”. Afterwards I booted the downloaded Debian Netboot image to install a minimal system. During installation, in the packet selection screen I deselected “Desktop” and selected “SSH Server”. It was important for me to only have a terminal based system no X window overhead. That was it for now, my system was installed, configured and ready to be used.
After finishing the installation I configured the network behavior of my guest system (In the VirtualBox application “Right Click->Settings” on the “debian_shell” entry, then “Click” on “Network->Adapter1->”Port Forwarding”). I added an entry like the following to forward SSH connection attempts on my host machine on port 9003 to the default SSH port (22) on the guest system.

vbox_port_forwarding

Then I created a small shell script with the following content to start my VM in headless mode.

#!/bin/bash
RUNNING=`ps aux | grep -v grep | grep VBoxHeadless | cut -d ' ' -f 1`

if [ x$RUNNING == "x" ]; then
    VBoxHeadless --startvm debian_shell --vrdp=off > /dev/null 2>&1 &
    sleep 10
fi
ssh death-jester@192.168.1.111 -p 9003

I stored this script under “/usr/local/bin” with the name “debian”. Now when I called the script, it checked if the VM was already running if not it started the VM, and then logged into the machine via SSH, if the VM already ran it just logged in. For a more comfortable login I also stored the public key of my host-machine on the guest system.

Now have fun with your new “headless” Virtual Machine.

L4Linux Patch for MV643xx Ethernet

April 12, 2012 2 comments

A while ago I posted a tutorial on how to run Linux virtualized on top of L4 on the Sheevaplug. But one problem with the solution is that Sheevaplug’s hardware components (e.g. network, sd-card, etc.) aren’t working out of the box. In the menuconfig of L4Linux you can’t even select the driver (…for L4 architecture). So for all who want to run L4Linux on the Sheevaplug and want to use the physical network interface, this patch is for you mv643xx.patch. Copy the patch beside your ‘L4Linux’ folder and call

patch -p0 < mv643xx_eth.patch

to patch your Linux tree. Then enable

Device Drivers -->
    Network device support -->
        Ethernet (1000 Mbit) -->
            Marvell Discovery (643XX) and Orion ethernet support

in your ‘menuconfig’ and use the following configuration when you build your L4 image (at least the *.io file)

modules.list:

modaddr 0x01100000

entry L4Linux ARM
kernel fiasco -serial_esc
roottask moe rom/l4lx.cfg
module l4re
module ned
module l4lx.cfg
module io
module arm-sheevaplug.io
module vmlinuz.arm
module ramdisk.rd

arm-sheevaplug.io:

hw-root
{
  NIC => new Device()
  {
    .hid = "mv643xx"; 
    new-res Mmio(0xF1000000 .. 0xF100FFFF);
    new-res Mmio(0xF1020000 .. 0xF102FFFF);
    new-res Mmio(0xF1070000 .. 0xF107FFFF);
    new-res Irq(46);
    new-res Irq(11);
  }

  DMA => new Device()
  {
    .hid = "dmamem";
    new-res Mmio_ram(8388608,0);
  }
}

l4lx_bus => new System_bus()
{
  DMA => wrap(hw-root.DMA);
  NIC => wrap(hw-root.NIC);
}

l4lx.cfg:

-- vim:set ft=lua:

require("L4");

local io_caps = {
    sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0);
    l4lx_bus = L4.default_loader:new_channel():svr();
    icu = L4.Env.icu;
};

local linux_caps = {
    log  = L4.Env.log:m("rws"),
    vbus = io_caps.l4lx_bus    
};

L4.default_loader:start(
{
    caps = io_caps,
    log = { "io", "blue" }
}, "rom/io -vvv rom/arm-sheevaplug.io");

L4.default_loader:start(
{
    caps = linux_caps,
    log = {"l4linux", "yellow"},
    l4re_dbg = L4.Dbg.Warn
}, "rom/vmlinuz.arm mem=64M console=ttyLv0 l4x_rd=rom/ramdisk.rd \
root=1:0 ramdisk_size=11000 rw");

Depending on the name/size of your ramdisk you have to adapt the parameters in the config files.

The patch is tested and working, I’m using the device every day. But sometimes L4Linux jumps into the debugger JDB with the message ‘IRET returned’, I’m not 100% sure if the problem arises from my patch but could be. When this happens, restarting the device is your only chance. When you are in the debugger hit ‘^^’ twice to restart.
Leave a comment when you have questions about the patch…

Have fun!

Categories: tech foo Tags: , , , ,