[BPI-R64] Tip - how to make full use of eMMC in OpenWrt

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
1

So I found that while the BPI-R64 has a 7.2GB eMMC, only 900MB are allocated for OpenWrt in the default sdcard image (from downloads.openwrt.org/snapshots).

It turns out this is hard-coded in the makefile, but you can patch it: /target/linux/mediatek/image/mt7622.mk

 		$(if $(findstring emmc,$1), \
-			-t 0x2e -N production		-p 980M@40M \
+			-t 0x2e -N production		-p 7373M@40M \
 		)

According to fdisk there are 15187935 sectors total available for the main partition, which is about 7373MB (sector size: 512B).

You can re-build the stock OpenWrt image as follows:

  1. Download the image_builder package from downloads.openwrt.org/snapshots
  2. Extract into Linux/WSL environment, set up as per openwrt instructions
  3. Patch the makefile with 01-full-partition-size.patch (365 Bytes):
    $ patch -p1 -i 01-full-partition-size.patch
  4. Build:
    $ make image
  5. Write to SD card and rewrite eMMC via uboot

Now OpenWrt will utilize the full eMMC space:

df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                58.0M     58.0M         0 100% /rom
tmpfs                   496.3M     60.0K    496.2M   0% /tmp
/dev/mmcblk0p66           7.1G    410.2M      6.7G   6% /overlay
overlayfs:/overlay        7.1G    410.2M      6.7G   6% /
tmpfs                   512.0K         0    512.0K   0% /dev

If someone is familiar with submitting patches to OpenWrt, it would be great to get this mainlined for BPI-R64 since the stock image just throws away all that eMMC space otherwise…

2

Hi,thanks for the patch.but maybe its better to use the additional space for a separate data partition,so that this is not overwritten on reflash an image. Currently only the entry in partition table needs to be restored as it got overwritten by flashing the image. Idk if there is a way to leave image size at 900MB,but including the partition entry…of course on first flash you have to create a filesystem,but on further updates you can simply flash the new image without touching the data partition

3

True, maybe it would be better to include another data partition, but my particular case I needed the larger overlay space (to install docker + images).

4

Images should be outside of system for my understanding of a rootfs (i have moved /var completely onto a extra partition/device).

Maybe using 1.5-2G for overlay and ~5G for data not related to system itself

5

Having overlay larger than RAM doesn’t make sense as what ever you store there then won’t survive sysupgrade. Better use an additional partition for data, if you are looking for an easy automated way to make use of extra space take a look at the autopart package in OpenWrt (and uvol as a wrapper around LVM2 or UBI to manage additional storage volumes).

6

Ah, I wasn’t aware of this limitation. I think it will be better to create a new partition then and redirect docker to use that for its storage (ie, /opt/docker)

Does OpenWRT silently truncate the image if overlay is larger than RAM, or does it fail the update?

7

No, you are just limited in what survives sysupgrade. Basically only /etc/config and things listed in /etc/sysuprgade.conf get carried over, all the rest is gone as rootfs_overlay is formatted after sysupgrade and repopulated with the backup files. In order to restore the backup on the first boot after sysupgrade, the backup archive needs to fit into tmpfs, ie. limit is the size of RAM.

Having additional partition for persistent data is hence in any case a good idea. And overlayfs cannot be used for Docker, as it cannot serve as the lowerdir of another overlayfs…