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. ( )

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)