Booting a recent kernel on the ARM RealView series

Last tested with kernel v4.20+ (linux-next) 2018-12-18

RealView PB11MP
RealView PB11MP penguin prompt

ARM RealView PB11MPCore reference design and the four-penguin (four CPUs) on this quadcore ARM11 machine.

Toolchain

The latest Linaro GCC toolchain is what I usually use to compile recent kernels. Also for the userspace, if it is a Cortex-A9 machine. For older RealViews like PB1176JZF-S or PB11MPCore you need to use a compiler built for ARMv6 or the stuff just won't work. You can use Rob Landleys precompiled ARMv6 binary if you like, it works for me.

Download the toolchain and install it such that it is always in your path. Sometimes the toolchain has been compiled for i686 and then you need to install a i686 multipath library to execute it on an x86_64 machine. A good way to get the cross compiler into your $PATH is to install it in /var/linus/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/ and then add this to a file called /etc/profile.d/crosscompilers.sh

CS_BASE=/var/linus/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/
export PATH=$PATH:${CS_BASE}/bin
export MANPATH=$MANPATH:${CS_BASE}/share/doc/gcc-linaro-arm-linux-gnueabihf/man/

Building the upstream kernel

Here are some files that I use to configure and build RealView kernels out-of-the box. These use a minimal initramfs root filesystem placed in your home directory. (This is to get you to a prompt without a root filesystem installed in the flash, such as the ArchLinux method described below.) These root filesystems are created using this script. Prebuilt versions can be obtained here:

Copy the rootfs to you home directory and the *.mak file to your linux/ git tree or base dir and simply:

> make -f realview.mak config
> make -f realview.mak build

Pre-built kernels

Here are a bunch of pre-built kernels with initramfs that can be used to test that the RealView machine is working. They should give prompt and graphics.

Running in QEMU

You can run a certain QEMU model of RealView like this (this assumes appended device tree, like my realview.mak will produce. All you need is the zImage binary.

#!/bin/bash
# RealView PBX A9
qemu-system-arm -M realview-pbx-a9 -smp cpus=2 -no-reboot -kernel ${HOME}/zImage -append "console=ttyAMA0" -serial stdio

Install ArchLinux

I made an ArchLinux installtion based on the Rapberry Pi installation which is ARMv6 based.

Boot a rootfs from a USB stick

This is the preferred solution I guess. The RealView PB1176 has two USB ports controlled by an ISP11761 USB host controller that you can stick a USB disk into. The USB host ports are next to the serial lines. Since the Raspberry Pi is ARMv6 we simply reuse that rootfs with the ARMv6 RealViews.

Boot a rootfs from the SD card

After booting

Running JTAG on the PB1176JZF-S

PB1176 board with J-Link JTAG dongle

At one point I managed to wipe the flash on my PB1176JZF-S, even flushing the Boot Monitor. NOT GOOD. What to do? The manual says I should re-flash the boot monitor from the support CD. I found the right .axf file, but needed a JTAG to get this into the RAM and execute it.

ARM recommends using their own RealView debugger and a JTAG box from Kiel, and I actually had one of these around. However the support pages and the license registration page for this debugger is gone already, so it has bitrotted away, this isn't working anymore, atleast not for me.

The path of least resistance proved to be to set up OpenOCD to work with this board. I used a J-Link JTAG adapter instead of the Kiel thing, but I suspect any 20-pin JTAG adapter will work just as fine.

HOWTO reflash the Boot Monitor using JTAG and OpenOCD:

JTAG can be used for other things and real hardcore debugging too of course. I use it to restart U-Boot when the kernel crashes, just go to the OpenOCD prompt and:

    > reset halt
    JTAG tap: tc1176.cpu tap/device found: 0x07b76477 (mfg: 0x23b, part: 0x7b76, ver: 0x0)
    found ARM1176
    tc1176.cpu: ran after reset and before halt ...
    tc1176.cpu: target state: halted
    target halted in ARM state due to debug-request, current mode: Supervisor
    cpsr: 0x00000153 pc: 0x07c0b718
    > resume 0x06000000