From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Date: Thu, 21 Aug 2014 21:31:50 +0100 Subject: [U-Boot] U-boot for Banana Pi In-Reply-To: References: <53F27EB9.3090805@toomeek.waw.pl> <53F4F4B1.5080200@toomeek.waw.pl> Message-ID: <1408653110.7363.12.camel@hellion.org.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, 2014-08-21 at 10:48 +0200, Michal Suchanek wrote: > Hello, > > On 20 August 2014 21:19, TooMeeK Admin 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/... Support for BananaPi is currently available in the u-boot-arm.git tree. Ian.