Tag Archive: u-boot

As the Banana Pi has mainline support in both U-boot and the Linux kernel, it should be fairly simple to make it run. ArchLinuxARM does not have u-boot for the Banana Pi compiled, but compiling it myself should be trivial. I am using the gcc cross compiler binaries provided by ArchLinuxARM. ( https://archlinuxarm.org/wiki/Distcc_Cross-Compiling )

The process to compile U-boot is explained at the sunxi website. When using the cross compiler from the ArchLinuxARM website, be sure to add it to the path. Furthermore, CROSS_COMPILE=arm-unknown-linux-gnueabihf- should be used. This is the thing that differs from most guides, which use a different cross compiler. After compiling, use the guide for the CubieBoard 2, and replace the u-boot-sunxi-with-spl.bin file with the file we compiled ourselves.

But it is still not working! The bootloader cannot find the kernel and is attempting netboot. When investivating I’ve found the following:

=> ext4ls mmc 0:1 /boot
<DIR>          0 .
<DIR>       4096 ..
=> ext4ls mmc 0:1 /etc
<DIR>       4096 .
<DIR>       4096 ..
            4096 zImage
<DIR>       4096 dtbs
               0 boot.scr

The bootloader has trouble reading the ext4 file system. When looking at the SD card from my laptop, everything looks fine

[root@8570w bananapi]# ls mnt/boot
boot.scr  dtbs	zImage

So… what is wrong? It seems there are file system features enabled that are not supported by U-boot, and that U-boot is not checking feature flags to detect this. When I realised this was the probable problem, I was able to verify this conclusion by a quick search. Therefore, the guide for the CubieBoard 2 should have one additional thing altered.

mkfs.ext4 -O ^metadata_csum,^64bit /dev/mmcblk0p2

With these alterations, running a mainline u-boot and kernel works fine. Nevertheless, the mainline kernel has no video acceleration support yet. As I was thinking to replace my Raspberry Pi (first generation Mobel B, the 256 MB RAM model) by the BananaPi, I might try running an AllWinner/sunxi kernel. But getting those compiled…. is yet another struggle. That’s why I prefer mainline support. If the code is in the main repository, the code is clean, and it will compile fine, but the code released by AllWinner is basically a mess. I suppose it’s easier to extract a kernel from an image then compiling it myself.

I must say, the quality of the composite output on the Banana Pi looks better then the output generated by the Raspberry Pi. I’ve only been looking at the console and an X session (with only xterm running)

I know, I have written about this before, but, here it is again. Installing ArchLinuxARM on the BeagleBoard, this time, taking a fresh SD card, and now it works like a sunshine. Yesterday, on the 8 GB card, I’d done exactly the same, without any result.

So, let’s see how to install the January 2013 ArchLinux OMAP3 rootfs to an SD card for use with a BeagleBoard.

Download the bootloader http://archlinuxarm.org/os/omap/BeagleBoard-bootloader.tar.gz
Download the rootfs http://archlinuxarm.org/os/ArchLinuxARM-omap-smp-latest.tar.gz

This says the latest rootfs, which would usually be the right thing to do. But to ensure you’re using the same rootfs as I do, you can use http://os.archlinuxarm.org/os/omap/ArchLinuxARM-2013.01-omap-smp-rootfs.tar.gz in stead.

extract the bootloader tarball. This tarball contains a mkcard.sh script which will partition the card for you. As I’ve had problems with the instructions on the ArchLinuxARM site last time, I will use this script instead, as it worked perfectly.

[root@hplaptop bootloader]# ./mkcard.sh /dev/mmcblk0
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 1.13529 s, 924 kB/s
DISK SIZE - 16130244608 bytes
Checking that no-one is using this disk right now ...

Disk /dev/mmcblk0: 1961 cylinders, 255 heads, 63 sectors/track
sfdisk: /dev/mmcblk0: unrecognized partition table type

Please note it also says

./mkcard.sh: line 37: kpartx: command not found

But this ain’t a fatal error. It seems this is a tool to re-read the partition table and create device maps. However, it seems it works without on my system. Anyhow, let’s continue. The said script only partitions the SD card and creates file systems, but nothing else. (unlike the script for the CubieBoard, which I will discuss later)

[root@hplaptop bootloader]# mount /dev/mmcblk0p1 /mnt/a
[root@hplaptop bootloader]# cp MLO /mnt/a
[root@hplaptop bootloader]# cp u-boot.bin /mnt/a
[root@hplaptop bootloader]# cp uEnv.txt /mnt/a
[root@hplaptop bootloader]# mount /dev/mmcblk0p2 /mnt/b
[root@hplaptop bootloader]# cd /mnt/b
[root@hplaptop b]# tar -xvf /run/media/andre/DataBlaat/arm/beagleboard/archlinux/ArchLinuxARM-omap-smp-20130118.tar.gz

It is important for the BeagleBoard that you copy the MLO file first to the FAT parition. This is a pre-boot-loader, “X-loader”, which will load the bootloader “U-Boot”. Then copy the other files to the FAT partition, “u-boot.bin”, the bootloader, and “uEnv.txt”, a configuration file.

Next extract the root file system to the ext3 parition. I usually include the v to the tar arguments to see what’s going on. When this is done, copy the kernel over to the FAT partition

[root@hplaptop b]# cp boot/uImage /mnt/a

This can take longer then expected. When this is done, create a boot script. This boot script will be like the one on the ArchLinuxARM site, but the mmc init line needs to be ommited. It was needed for ancient versions of U-Boot, but has been obsolete for quite a while. So, the boot script will look like

setenv bootargs 'console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait'
fatload mmc 0 0x80300000 uImage
bootm 0x80300000

write this bootscript to bootscr, and run mkimage to convert it to an U-boot script. Even though the current version supports the uEnv.txt file, I didn’t manage to get it to boot using the uEnv.txt only. I kept attemption to boot from NAND, but I want to boot from the SD card. I probably only have to set a certain variable to tell it to boot from SD in stead. However, with the boot.scr file present, it boots fine from the SD card.

[root@hplaptop b]# cd /mnt/a
[root@hplaptop a]# vim bootcmd
[root@hplaptop a]# mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Beagleboard boot script" -d bootcmd boot.scr
Image Name: Beagleboard boot script
Created: Fri Jan 25 11:05:47 2013
Image Type: ARM Linux Script (uncompressed)
Data Size: 151 Bytes = 0.15 kB = 0.00 MB
Load Address: 00000000
Entry Point: 00000000
Image 0: 143 Bytes = 0.14 kB = 0.00 MB
[root@hplaptop mnt]# cd ..
[root@hplaptop mnt]# umount a
[root@hplaptop mnt]# umount b
[root@hplaptop mnt]# sync

Please note: If you’re missing mkimage is available in the AUR repository as package “uboot-mkimage”. Last time when I made an BeagleBoard SD card, I compiled it from source. After this is all done, unmount the file systems, flush the caches, and just put the card into the BeagleBoard, connect to the serial console, and plug in the power. It boots up fine.

P.S. In the rootfs there are some boot.scr files, but they won’t work. First of all, they appear to be for the TrimSlice. But that’s not the problem. They appear to be configured to load the kernel from the rootfs. In the directory /boot there is uImage, so, perfectly fine. However, U-Boot only supports ext2 and not ext3, therefore these files won’t work.

We might need to adjust the kernel parameters later if we want to set something like hdmi or svideo to work. As stated before, when specifying 1280×1024@60Hz, the BeagleBoard is only capable to deliver 57Hz, which my Compaq 1720 monitor refuses to accept. As I have found out with some CubieBoard tests, which I will write about later, the monitor might be a little more tolerant when the input is analogue. Therefore I tried the mentioned HDMI->VGA adaptor also on the BeagleBoard.

When I had my old BeagleBoard installation running, I experienced lots of USB problems, mostly related to the USB Ethernet adaptor. Lots of errors in the pegasus driver. So, I wonder, are the problems really hardware or are they caused by a crappy driver. Anyhow, I’ve bought an SPI Ethernet adaptor for testing purposes.