I’ve scoured the forums, yet found no solution, so here’s how i did it.
The problem: flasing from NAND to EMMC does not utilize the full 8gb of storage. Only less than half a GB. /dev/mmcblk0p5is not an F2FS partition, but something that during the boot process becomes /dev/fit0 (a squashfs - /rom) and /dev/fitrw(an F2FS partition - /). I don’t understand how this works, but I figured that the BPI-R3 wiki with resize.f2fs fails. People in this thread also had issues.
Here’s my solution:
SOLVED
What worked for me required an extra step. Here's a detailed guide with all steps explicit for first-timers:
- write bananapi_bpi-r4-sdcard.img.gz to an sd card (unzip first) or whatever version is current.
- Boot from sdcard (SW3 pins to 1,1).
- connect a serial adapter, far easier than manually setting default boot options with
fw_setenvcommands, and you see the boot process. Also my BPI-R4 came with a serial adapter that's pretty good. - in the boot menu chose "9. Install bootloader, recovery and production to NAND." (@Miles28 calls this step Flash NAND).
- boot to NAND (SW3 pins to 0,1) (remove power cable and then change pins)
- in the boot menu chose "9. Install bootloader, recovery and production to EMMC." (@Miles28 calls this step Flash EMMC).
- then continue to boot in NAND
- install cfdisk and
cfdisk /dev/mmcblk0→ Resize /dev/mmcblk0p5 to something like 7.2G. This can be done withgdisk,parted,fdisk, yetcfdiskis easiest. - I couldn't make use of resize.f2fs -
mmcblk0p5is not an F2FS partition, but something that becomes/dev/fit0and/dev/fitrw, the second is an F2FS partition. But the process eludes me, so i don't know how to resizefitrw. My second idea is to hope the first boot on EMMC will resizefitrwautomatically. - boot to EMMC (SW3 pins to 1,0) (remove power cable and then change pins)
- I expected
fitrwto be 7.2G, yet it was 428MB. So the auto resizing fails. - What fixed it for me was to boot in EMMC and then
umount /dev/fitrwandfirstboot -y. If you don't umount first, fitrw survives, see logs below.
Relevant logs:
unsuccessful attempt
root@OpenWrt:~# firstboot -y
/dev/fitrw is mounted as /overlay, only erasing files
See how it only erases the files. That is not enough - fitrw survives with the old size.
successful attempt:
root@OpenWrt:~# umount /dev/fitrw
root@OpenWrt:~# firstboot -y
/dev/fitrw is not mounted
/dev/fitrw will be erased on next mount
See how fitrw will be erased "on next mount"? This is what makes the resizing work. Note: Of course in all cases you lose all your rw data, but that is expected.
dmesg logs:
[ 10.333417] mount_root: overlay filesystem in /dev/fitrw has not been formatted yet
[ 11.268669] F2FS-fs (fitrw): Found nat_bits in checkpoint
[ 11.302163] F2FS-fs (fitrw): Mounted with checkpoint version = d70cacb
[ 11.309183] mount_root: overlay filesystem has not been fully initialized yet
[ 11.316582] mount_root: switching to f2fs overlay
[ 11.322343] overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off.
I think here fitrw is created.
df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 11.0M 11.0M 0 100% /rom
tmpfs 1.9G 444.0K 1.9G 0% /tmp
/dev/fitrw 7.2G 191.8M 7.0G 3% /overlay
overlayfs:/overlay 7.2G 191.8M 7.0G 3% /
tmpfs 512.0K 0 512.0K 0% /dev
I still don't understand how this fitrw is created from the partition. If someone can explain, I'd be grateful.