[U-Boot] U-boot for Banana Pi

[Michal Suchanek]

Hello,

On 20 August 2014 21:19, TooMeeK Admin <maps at toomeek.waw.pl> wrote:
> Hello,
>
> I'm getting some troubles booting FreeBSD on Banana Pi.
> I wrote simple script that creates bootable SD card image for FreeBSD OS.
>
> #!/bin/bash
> cd /root/banana
> rm /root/banana/banana.img
> truncate -s 940M banana.img
> mdconfig -f banana.img -u0
> gpart create -s mbr md0
> gpart add -b 1m -s 64m -t fat16 md0
> gpart set -a active -i 1 md0
> newfs_msdos -F 16 /dev/md0s1
> mount_msdosfs /dev/md0s1 /mnt
> cp /usr/obj/arm.armv6/usr/src/sys/BANANAPI/kernel /mnt
> cd /usr/src/sunxi-tools
> echo "fatload mmc 0 0x40200000 kernel; go 0x40200100" > boot.cmd
> /usr/src/u-boot-bananapi/tools/mkimage -C none -A arm -T script -d
> boot.cmd boot.scr
> cp boot.scr /mnt
> umount /mnt
> mdconfig -d -u0
> cd /root/banana
> # Original Banana Pi U-boot loader
> #dd if=/usr/src/u-boot-sunxi/spl/sunxi-spl.bin conv=notrunc of=banana.img
> bs=1024 seek=8
> #dd if=/usr/src/u-boot-sunxi/u-boot.bin conv=notrunc of=banana.img bs=1024
> seek=40
> # Lemaker's U-boot loader
> dd if=/usr/src/u-boot-bananapi/spl/sunxi-spl.bin conv=notrunc of=banana.img
> bs=1024 seek=8
> dd if=/usr/src/u-boot-bananapi/u-boot.bin conv=notrunc of=banana.img bs=1024
> seek=40
>
> The script output:
>
> root at freebsd:~/banana # bash prepare_boot.sh
> md0 created
> md0s1 added
> active set on md0s1
> /dev/md0s1: 130888 sectors in 16361 FAT16 clusters (4096 bytes/cluster)
> BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512
> Media=0xf0 FATsecs=64 SecPerTrack=17 Heads=255 HiddenSecs=0
> HugeSectors=131053
> Image Name:
> Created:      Tue Aug 19 02:20:04 2014
> Image Type:   ARM Linux Script (uncompressed)
> Data Size:    55 Bytes = 0.05 kB = 0.00 MB
> Load Address: 00000000
> Entry Point:  00000000
> Contents:
>    Image 0: 47 Bytes = 0.05 kB = 0.00 MB
> 23+1 records in
> 23+1 records out
> 24064 bytes transferred in 0.003972 secs (6058691 bytes/sec)
> 235+1 records in
> 235+1 records out
> 241544 bytes transferred in 0.003128 secs (77224557 bytes/sec)
>
>
> Original Banana Pi U-boot loader output:
>
> U-Boot SPL 2014.04-10704-gf625d1d (Aug 16 2014 - 23:44:23)
> Board: Bananapi
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
> spl: not an uImage at 1600
> spl: not an uImage at 80
> ### ERROR ### Please RESET the board ###
>
> And Lemaker's:
>
> U-Boot SPL 2014.04-10693-gf954935 (Aug 17 2014 - 21:41:27)
> Board: Bananapi
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
> spl: not an uImage at 1600
> spl: not an uImage at 80
> ### ERROR ### Please RESET the board ###
>
> The only way it works is:
> # Cubieboard's 2 U-boot loader from FreeBSD Wiki
> dd if=sunxi-spl.bin conv=notrunc of=banana.img bs=1024 seek=8
> dd if=u-boot.bin conv=notrunc of=banana.img bs=1024 seek=32
>
> And according to https://github.com/linux-sunxi/u-boot-sunxi/wiki
> "If using v2013.07 or earlier then the procedure is slightly different
> dd if=spl/sunxi-spl.bin of=/dev/sdX bs=1024 seek=8
> dd if=u-boot.bin of=/dev/sdX bs=1024 seek=32"
> but I'm using newer version.
>
> I'm getting problems with addressing all available memory (0x40000000, size:
> 0x40000000 = 1024MB), I belive it's caused by Cubieboard's version of
> u-boot.
> The only way it works is 0x40000000 size 0x20000000 in kernel's memory
> addressing which is half of all available memory.
> So I have to use Cubieboard's 2 version of u-boot to start my board.

Hello,

currently memory controller paramaters are set from constants defined
in u-boot at compile time. U-boots needs to configure the memory
controller so it has some place to load the kernel binary.

If your memory configuration is incorrect you might have stability
problems or may not be able to access all memory. There is a10-meminfo
tool http://linux-sunxi.org/Retrieving_device_information#Reading_memory_information_from_registers
which you can run on the original Android or GNU/Linux installation
(if any) to determine what memory parameters the manufacturer used and
configure your u-boot accordingly. Note that cubieboard1 and
cubieboard2 use a different SoC so u-boot compiled for one might not
configure the other correctly. Especially the SMP on a20 works
correctly only with recent u-boot. You should use u-boot compiled for
your SoC a10/a20/...

HTH

Michal