Linux – How to create boot SD card for Banana Pi manually

embeddedlinuxu-boot

It seems that I have a lack of understanding how booting SD-Card images on devices like the Banana Pi work. The situation is as follows.

I have a Banana Pi and a Banana Pro. Every device has an image of some distribution on a SD card plugged into the device (Banana Pro -> Arch Linux, Banana Pi -> Bananian). The images can be downloaded from here and here. This works fine.

But since the Banana Pi / Pro has a SATA port, it would be nice if the root system could be booted from an attached Hard Drive. As can be read here this can be accomplished quite simple.

But now comes the part I'm struggling with. Flashing an entire 4GB SD card (or even larger ones) with the distributions image and using just a 50MB partition seems a bit wasteful. So I tried to use a smaller SD card.

I created a partiton with fdisk (50MB size) and used mkfs.vfat -F 16 /dev/sdXX to create the filesystem on the partiton. I made it FAT 16 because of the parted output while examining the image file.

enter image description here .

After that I mounted the partion from the image to /tmp/boot with sudo mount -o loop,offset=1048576 ArchLinux_For_BananaPro_v1412.img /tmp/boot. The offset value is the Start value in the parted output.

Copied the files (script.bin, uEnv.txt, uImage) to my SD card partition, changed the root path in uEnv.txt. Made a sync and dismounted the SD card.

Everything seems fine. Even when comparing the boot partitons on a SD card flashed with the entire image and my SD card with only the boot partiton, they are identical (according to fdisk)

enter image description here

But the Banana Pi / Pro won't boot with the SD card with just a boot partition providing the u-boot files.

Has anyone a clue on that behaviour?

UPDATE:

Thanks to @BananaFreak I recognized my mistake. The bootloader was indeed missing but even after following that guide from lemaker the BananaPro does not boot. One weird thing on the lemaker wiki page is the first sentence stating:

Note: these instructions are for a Linux computer, not the Banana Pro/Pi!!

Best Answer

I think you've missed bootloader. U-Boot has to be present on your SD. Take a look at how the SD layout should be for the Banana Pi / Pro:

http://wiki.lemaker.org/BananaPro/Pi:Setting_up_the_bootable_SD_card#SD_Card_Layout

Related Solutions

What does this dd command do exactly

I am guessing here, as I have no Kobo Glo (I wish my Bookeen HD was reprogrammable).
You seem to have a 2Gb SD memory internally ( 60352 cylinders of 32K each)

The dd does skip 2048 blocks of 512 (1048576), which is less than the 305 cylinder offset (9994240). In fact have to write more than 8Mb to reach the /dev/mmcblk0p1 partition that way.

How the device boots depends on its firmware, but it is likely that there is some basic bootstrapping done via the first 1Mb on the SD memory, that in turn then calls the image written with dd.

/dev/mmcblk0p1 is 256Mb ( (8497 - 305)*32768 ) and that seems to be mounted as / with maybe a backup of it on /dev/mmcblk0p2 or vv.

Filesystems – How to Create Small Disk Image with Large Partitions

Firstly, writing a sparse image to a disk will not result in anything but the whole of the size of that image file - holes and all - covering the disk. This is because handling of sparse files is a quality of the filesystem - and a raw device (such as the one to which you write the image) has no such thing yet. A sparse file can be stored safely and securely on a medium controlled by a filesystem which understands sparse files (such as an ext4 device) but as soon as you write it out it will envelop all that you intend it to. And so what you should do is either:

Simply store it on an fs which understands sparse files until you are prepared to write it.
Make it two layers deep...
- Which is to say, write out your main image to a file, create another parent image with an fs which understands sparse files, then copy your image to the parent image, and...
- When it comes time to write the image, first write your parent image, then write your main image.

Here's how to do 2:

Create a 1GB sparse file...
```
dd bs=1kx1k seek=1k of=img </dev/null
```
Write two ext4 partitions to its partition table: 1 200MB, 2 800MB...
```
printf '%b\n\n\n\n' n '+200M\nn\n' 'w\n\c' | fdisk img
```

Create two ext4 filesystems on a -Partitioned loop device and put a copy of the second on the first...

sudo sh -c '
    for p in "$(losetup --show -Pf img)p"*        ### the for loop will iterate
    do    mkfs.ext4 "$p"                          ### over fdisks two partitions
          mkdir -p ./mnt/"${p##*/}"               ### and mkfs, then mount each
          mount "$p" ./mnt/"${p##*/}"             ### on dirs created for them
    done; sync; cd ./mnt/*/                       ### next we cp a sparse image
    cp --sparse=always "$p" ./part2               ### of part2 onto part1
    dd bs=1kx1k count=175 </dev/zero >./zero_fill ### fill out part1 w/ zeroes
    sync; cd ..; ls -Rhls .                       ### sync, and list contents
    umount */; losetup -d "${p%p*}"               ### last umount, destroy
    rm -rf loop*p[12]/ '                          ### loop devs and mount dirs

mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 204800 1k blocks and 51200 inodes
Filesystem UUID: 2f8ae02f-4422-4456-9a8b-8056a40fab32
Superblock backups stored on blocks:
    8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 210688 4k blocks and 52752 inodes
Filesystem UUID: fa14171c-f591-4067-a39a-e5d0dac1b806
Superblock backups stored on blocks:
    32768, 98304, 163840

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

175+0 records in
175+0 records out
183500800 bytes (184 MB) copied, 0.365576 s, 502 MB/s
./:
total 1.0K
1.0K drwxr-xr-x 3 root root 1.0K Jul 16 20:49 loop0p1
   0 drwxr-xr-x 2 root root   40 Jul 16 20:42 loop0p2

./loop0p1:
total 176M
 12K drwx------ 2 root root  12K Jul 16 20:49 lost+found
 79K -rw-r----- 1 root root 823M Jul 16 20:49 part2
176M -rw-r--r-- 1 root root 175M Jul 16 20:49 zero_fill

./loop0p1/lost+found:
total 0

./loop0p2:
total 0

Now that's a lot of output - mostly from mkfs.ext4 - but notice especially the ls bits at the bottom. ls -s will show the actual -size of a file on disk - and it is always displayed in the first column.

Now we can basically reduce our image to only the first partition...

fdisk -l img

Disk img: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc455ed35

Device Boot  Start     End Sectors  Size Id Type
img1          2048  411647  409600  200M 83 Linux
img2        411648 2097151 1685504  823M 83 Linux

There fdisk tells us there are 411647 +1 512 byte sectors in the first partition of img...
```
dd seek=411648 of=img </dev/null
```

That truncates the img file to only its first partition. See?

ls -hls img

181M -rw-r--r-- 1 mikeserv mikeserv 201M Jul 16 21:37 img

...but we can still mount that partition...

sudo mount "$(sudo losetup -Pf --show img)p"*1 ./mnt

...and here are its contents...

ls -hls ./mnt

total 176M
 12K drwx------ 2 root root  12K Jul 16 21:34 lost+found
 79K -rw-r----- 1 root root 823M Jul 16 21:34 part2
176M -rw-r--r-- 1 root root 175M Jul 16 21:34 zero_fill

And we can append the stored image of the second partition to the first...

sudo sh -c '
    dd seek=411648 if=./mnt/part2 of=img
    umount ./mnt; losetup -D
    mount "$(losetup -Pf --show img)p"*2 ./mnt
    ls ./mnt; umount ./mnt; losetup -D'

1685504+0 records in
1685504+0 records out
862978048 bytes (863 MB) copied, 1.96805 s, 438 MB/s
lost+found

Now that has grown our img file: it's no longer sparse...

ls -hls img

1004M -rw-r--r-- 1 mikeserv mikeserv 1.0G Jul 16 21:58 img

...but removing that is as simple the second time as it was the first, of course...

dd seek=411648 of=img </dev/null
ls -hls img

181M -rw-r--r-- 1 mikeserv mikeserv 201M Jul 16 22:01 img

Best Answer

Related Solutions

What does this dd command do exactly

Filesystems – How to Create Small Disk Image with Large Partitions

Related Question