BPI R64 debian ext4 filesystem read only

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

I compiled the official linux kernel and divided it into 6 GPT areas, all of which were formatted with ext4, and then all started normally, but the file system showed that it was read-only and could not be written. The following is my problem, I am not sure about the need for linux kernel Is it configured?

EXT4-fs (mmcblk0p6): mounted filesystem with ordered data mode. Opts: (null)

VFS: Mounted root (ext4 filesystem) readonly on device 179:14.

Starting kernel ...
omit ...
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258000
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p6 rootfstype=ext4 rootwait
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
omit ...
[    1.789289] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[    1.796264] rtc_mt7622 10212800.rtc: setting system clock to 2000-01-01T05:05:07 UTC (946703107)
[    1.805202] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    1.814308] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    1.820928] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    1.829552] cfg80211: failed to load regulatory.db
[    1.841512] EXT4-fs (mmcblk0p6): mounted filesystem with ordered data mode. Opts: (null)
[    1.849664] VFS: Mounted root (ext4 filesystem) readonly on device 179:14.
[    1.861131] devtmpfs: mounted
[    1.864262] Freeing unused kernel memory: 320K
   omit ...
Linux mt7622 5.4.63-BPI-R64-Kernel #5 SMP PREEMPT Tue Sep 15 11:14:29 +03 2020 aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@mt7622:~# 
root@mt7622:~# mkdir test
mkdir: cannot create directory ‘test’: Read-only file system
root@mt7622:~#
2

Hi,

you created GPT areas in linux kernel? :slight_smile: you mean you created/modified a debian image like this…which image do you use (or how did you created it), how does your fstab looks like and what does blkid output?

most likely you try to mount with uuid, but uuid is not found, and so rootfs (passed to linux via cmdline) is mounted ro

3

This is the SD startup view：

root@bpi-iot-ros-ai:~# fdisk -l
Disk /dev/mmcblk1: 7.2 GiB, 7746879488 bytes, 15130624 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: 0x1f9b70ec

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk1p1      204800   729087   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk1p2      729088 14940159 14211072  6.8G 83 Linux


Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 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: gpt
Disk identifier: 1FFEE274-8552-4C54-8BE0-FD2A626D7297

Device         Start      End  Sectors  Size Type
/dev/mmcblk0p1  1024     1535      512  256K Linux filesystem
/dev/mmcblk0p2  1536     3071     1536  768K Linux filesystem
/dev/mmcblk0p3  3072     4095     1024  512K Linux filesystem
/dev/mmcblk0p4  4096     4607      512  256K Linux filesystem
/dev/mmcblk0p5  4608    70143    65536   32M Linux filesystem
/dev/mmcblk0p6 70144 15269824 15199681  7.3G Linux filesystem
root@bpi-iot-ros-ai:~# 
root@bpi-iot-ros-ai:~# cat /etc/fstab 
UUID=c1401c29-e4d8-4924-8799-8b0f3a77b79b / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0
proc ./rootfs/proc proc defaults 0 0
sysfs ./rootfs/sys sysfs defaults 0 0
root@bpi-iot-ros-ai:~#

MMC starts because the file system is read-only, so view:

#UNCONFIGURED FSTAB FOR BASE SYSTEM

4

The kernel is compiled by itself in 5.4.63. How to find this problem?

5

i see you use (rootfs of) official image…

you boot emmc (0) or sd-card (1)? your gpt seems to be on emmc

just show blkid of your desired rootfs (e.g. /dev/mmcblk0p6) :wink:

6

Yes. On emmc, I’m currently in the SD system. You can enter the SD system and mount the image on emmc, and you can read and write at will. Then you can start the p6 of emmc through UBOOT on emmc and it will be read-only.

root@bpi-iot-ros-ai:~/images/update_emmc# mount /dev/mmcblk0p6 ./mmcroot/
root@bpi-iot-ros-ai:~/images/update_emmc# ls ./mmcroot/
bin   dev  home  lost+found  media  opt   root  sbin  sys  usr
boot  etc  lib   md5sum.txt  mnt    proc  run   srv   tmp  var
root@bpi-iot-ros-ai:~/images/update_emmc# mkdir ./mmcroot/test  
root@bpi-iot-ros-ai:~/images/update_emmc# ls ./mmcroot/       
bin   dev  home  lost+found  media  opt   root  sbin  sys   tmp  var
boot  etc  lib   md5sum.txt  mnt    proc  run   srv   test  usr
root@bpi-iot-ros-ai:~/images/update_emmc#
7

Your fstab on emmc is empty (except comment)? I guess you need to add rootfs entry (with right uuid or dev)

8

This is the information obtained after starting emmc, because the file system cannot be written, so other functions are correct.

root@mt7622:~# blkid
/dev/mmcblk1: PTUUID="1f9b70ec" PTTYPE="dos"
/dev/mmcblk1p1: LABEL_FATBOOT="BPI-BOOT" LABEL="BPI-BOOT" UUID="1539-6609" TYPE="vfat" PARTUUID="1f9b70ec-01"
/dev/mmcblk1p2: LABEL="BPI-ROOT" UUID="80463388-3170-483b-ac00-378b69a7a277" TYPE="ext4" PARTUUID="1f9b70ec-02"
/dev/mmcblk0: PTUUID="1ffee274-8552-4c54-8be0-fd2a626d7297" PTTYPE="gpt"
/dev/mmcblk0p1: PARTLABEL="tee1" PARTUUID="fced5d76-af29-4554-87a6-dafd2c358b0d"
/dev/mmcblk0p2: PARTLABEL="lk" PARTUUID="0000f11f-5aa2-4904-8450-b92300e6d622"
/dev/mmcblk0p3: PARTLABEL="nvram" PARTUUID="c0ab7643-fd28-457e-b95d-f401072a074c"
/dev/mmcblk0p4: PARTLABEL="rf" PARTUUID="e0fa13ed-8444-4c09-8dc2-9abed2335b6a"
/dev/mmcblk0p5: LABEL="boot" UUID="ea7155d4-7499-4f86-96ef-b1b84d547d57" TYPE="ext4" PARTLABEL="boot" PARTUUID="a481ffd3-7a5d-4c42-b2f5-ac7c413f0288"
/dev/mmcblk0p6: LABEL="root" UUID="7c8f9e44-4ca2-448b-9841-d676f10cfe4e" TYPE="ext4" PARTLABEL="root" PARTUUID="e8e3afb9-7597-4c32-9d92-a3e14c0aa5dc"
root@mt7622:~#

This is the fstab I wrote, and it is still the same after startup：

root@mt7622:~# cat /etc/fstab 
# UNCONFIGURED FSTAB FOR BASE SYSTEM
UUID=7c8f9e44-4ca2-448b-9841-d676f10cfe4e / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0
proc ./rootfs/proc proc defaults 0 0
sysfs ./rootfs/sys sysfs defaults 0 0
root@mt7622:~# 
root@mt7622:~#
9

I use emmc to load the SD file system, and the same problem occurs. My startup parameters are as follows:

setenv bootargs'root=/dev/mmcblk1p2 rootfstype=ext4 rootwait'

It seems that it should be a kernel problem, right? If it is a kernel problem, please tell me how I need to configure it. I have looked at the linux kernel on your github. It seems that there is not much difference compared to.

10

I found the problem. It is indeed a kernel problem. There is no problem if the official firmware starts the file system created by myself. Excluding other possibilities, there is only the kernel problem. Where can this problem be affected?

11

there was a recent problem with emmc-access on r64 in kernel, maybe this is the cause

basicly this series: https://patchwork.kernel.org/project/linux-mediatek/list/?series=332521

but you can just try my kernel to test if its affected…and then compare code with yours

but latest 5.4 (i guess .64) had this included…

12

I tried your branch, which is also same problem. Is it necessary to configure when uboot is started? I set the startup parameters：

root=/dev/mmcblk0p6 rootfstype=ext4 rw rootwait

[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258000
[    0.000000] Kernel command line: root=/dev/mmcblk0p6 rootfstype=ext4 rw rootwait
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
...
[    1.913934] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[    1.920922] rtc_mt7622 10212800.rtc: setting system clock to 2000-01-01T01:12:21 UTC (946689141)
[    1.938482] mtk-msdc 11230000.mmc: phase: [map:ffffffff] [maxlen:32] [final:10]
[    1.948244] mtk-msdc 11230000.mmc: phase: [map:ffffffff] [maxlen:32] [final:10]
[    2.021236] mtk-msdc 11230000.mmc: phase: [map:ffffffff] [maxlen:32] [final:10]
[    2.029996] blk_update_request: I/O error, dev mmcblk0, sector 70144 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0
[    2.040972] Buffer I/O error on dev mmcblk0p6, logical block 0, lost sync page write
[    2.048740] EXT4-fs (mmcblk0p6): I/O error while writing superblock
[    2.055045] EXT4-fs (mmcblk0p6): mount failed
[    2.059768] VFS: Cannot open root device "mmcblk0p6" or unknown-block(179,14): error -5
[    2.067790] Please append a correct "root=" boot option; here are the available partitions:
[    2.076162] b300         7565312 mmcblk1 
[    2.076164]  driver: mmcblk
[    2.082981]   b301          262144 mmcblk1p1 1f9b70ec-01
[    2.082983] 
[    2.089799]   b302         7105536 mmcblk1p2 1f9b70ec-02
[    2.089801] 
[    2.096610] b308         7634944 mmcblk0 
[    2.096612]  driver: mmcblk
[    2.103428]   b309             256 mmcblk0p1 fced5d76-af29-4554-87a6-dafd2c358b0d
[    2.103430] 
[    2.112410]   b30a             768 mmcblk0p2 0000f11f-5aa2-4904-8450-b92300e6d622
[    2.112412] 
[    2.121404]   b30b             512 mmcblk0p3 c0ab7643-fd28-457e-b95d-f401072a074c
[    2.121406] 
[    2.130395]   b30c             256 mmcblk0p4 e0fa13ed-8444-4c09-8dc2-9abed2335b6a
[    2.130396] 
[    2.139376]   b30d           32768 mmcblk0p5 a481ffd3-7a5d-4c42-b2f5-ac7c413f0288
[    2.139378] 
[    2.148357]   b30e         7599840 mmcblk0p6 e8e3afb9-7597-4c32-9d92-a3e14c0aa5dc
[    2.148358] 
[    2.157354] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,14)
[    2.165885] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.65-bpi-r64 #1
[    2.172499] Hardware name: Bananapi BPI-R64 (DT)
[    2.177114] Call trace:
[    2.179564]  dump_backtrace+0x0/0x160
[    2.183225]  show_stack+0x14/0x1c
[    2.186540]  dump_stack+0xac/0x110
[    2.189941]  panic+0x13c/0x324
[    2.192994]  mount_block_root+0x1c0/0x2a0
[    2.197002]  mount_root+0x120/0x178
[    2.200489]  prepare_namespace+0x164/0x190
[    2.204584]  kernel_init_freeable+0x1fc/0x248
[    2.208940]  kernel_init+0x10/0xfc
[    2.212340]  ret_from_fork+0x10/0x18
[    2.215915] SMP: stopping secondary CPUs
[    2.219837] Kernel Offset: disabled
[    2.223322] CPU features: 0x0002,24002004
[    2.227328] Memory Limit: none
[    2.230383] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,14) ]---
13

which branch have you tried? this is the same problem the Patches fix

15

booted 5.4.65 from tftp and rootfs from sdcard and mount emmc without any errors (have no rootfs on emmc yet)

root@bpi-r64:~# mount /dev/mmcblk0p1 /mnt/emmc1                                 
root@bpi-r64:~# mount /dev/mmcblk0p2 /mnt/emmc2                                 
[   59.399424] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. )
root@bpi-r64:~# uname -a                                                        
Linux bpi-r64 5.4.65-bpi-r64-main #1 SMP PREEMPT Wed Sep 16 12:13:16 CEST 2020 x
root@bpi-r64:~# ls /mnt/emmc2                                                   
lost+found                                                                      
root@bpi-r64:~#

have you different hw-version (i have 1.1) of r64?

17

mhm, is source of this official kernel avalable? then we can compare sd-driver code…

else i have no idea, because i cannot reproduce it…

18

UBOOT URL

https://github.com/u-boot/u-boot

export ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
make mt7622_rfb_defconfig

make menuconfig
Command line interface  ---> Filesystem commands  ---> ext4 command support
Partition Types  ---> Enable EFI GPT partition table

Linux kernel:

https://www.kernel.org/ (https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.65.tar.xz)]

make ARCH=arm64 mt7622_evb_bpi_defconfig
make -j8
cp Image(64bit) to boot

Debian filesystem

apt-get install debian-archive-keyring
apt-get install qemu qemu-user-static binfmt-support debootstrap
debootstrap --arch=arm64 --foreign --no-check-gpg buster http://ftp.cn.debian.org/debian/
echo "proc ./rootfs/proc proc defaults 0 0" >> /etc/fstab
mount proc ./rootfs/proc -t proc
echo "sysfs ./rootfs/sys sysfs defaults 0 0" >> /etc/fstab
mount sysfs ./rootfs/sys -t sysfs
cp /etc/hosts ./rootfs/etc/hosts
cp /proc/mounts ./rootfs/etc/mtab
chroot ./rootfs /bin/bash
debootstrap/debootstrap --second-stage

atf and preload use is yours,I think this should be fine。

19

i know kernel from kernel.org :slight_smile: i mean the source of kernel which is working

20

This is what can run source：

http://wiki.banana-pi.org/Banana_Pi_BPI-R64#Resources

* 2020-05-08 updae ,Debian10 with kernel 5.4.0

download link : https://download.banana-pi.dev/d/3ebbfa04265d4dddb81b/?p=%2FImages%2FBPI-R64%2FDebian10&mode=list

discuss on forum : http://forum.banana-pi.org/t/bpi-r64-new-image-debian10-and-ubuntu18-04-linux-kernel-5-4-0-2020-05-08/11106
21

cloned the official repo and compared mmc-driver with my 5.4-main:

$ diff -ru BPI-R2-4.14/drivers/mmc/host/mtk-sd.c BPI-R64-bsp-5.4/linux-mt/drivers/mmc/host/mtk-sd.c 
--- BPI-R2-4.14/drivers/mmc/host/mtk-sd.c	2020-09-16 12:12:25.197761756 +0200
+++ BPI-R64-bsp-5.4/linux-mt/drivers/mmc/host/mtk-sd.c	2020-09-16 14:09:44.373624185 +0200
@ @ -22,7 +22,6 @ @
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
-#include <linux/reset.h>
 
 #include <linux/mmc/card.h>
 #include <linux/mmc/core.h>
@ @ -229,7 +228,6 @ @
 #define MSDC_PATCH_BIT_SPCPUSH    (0x1 << 29)	/* RW */
 #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)	/* RW */
 
-#define MSDC_PATCH_BIT1_CMDTA     (0x7 << 3)    /* RW */
 #define MSDC_PATCH_BIT1_STOP_DLY  (0xf << 8)    /* RW */
 
 #define MSDC_PATCH_BIT2_CFGRESP   (0x1 << 15)   /* RW */
@ @ -413,7 +411,6 @ @
 	struct pinctrl_state *pins_uhs;
 	struct delayed_work req_timeout;
 	int irq;		/* host interrupt */
-	struct reset_control *reset;
 
 	struct clk *src_clk;	/* msdc source clock */
 	struct clk *h_clk;      /* msdc h_clk */
@ @ -1476,12 +1473,6 @ @
 	u32 val;
 	u32 tune_reg = host->dev_comp->pad_tune_reg;
 
-	if (host->reset) {
-		reset_control_assert(host->reset);
-		usleep_range(10, 50);
-		reset_control_deassert(host->reset);
-	}
-
 	/* Configure to MMC/SD mode, clock free running */
 	sdr_set_bits(host->base + MSDC_CFG, MSDC_CFG_MODE | MSDC_CFG_CKPDN);
 
@ @ -1890,7 +1881,6 @ @
 
 	/* select EMMC50 PAD CMD tune */
 	sdr_set_bits(host->base + PAD_CMD_TUNE, BIT(0));
-	sdr_set_field(host->base + MSDC_PATCH_BIT1, MSDC_PATCH_BIT1_CMDTA, 2);
 
 	if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
 	    mmc->ios.timing == MMC_TIMING_UHS_SDR104)
@ @ -2240,11 +2230,6 @ @
 	if (IS_ERR(host->src_clk_cg))
 		host->src_clk_cg = NULL;
 
-	host->reset = devm_reset_control_get_optional_exclusive(&pdev->dev,
-								"hrst");
-	if (IS_ERR(host->reset))
-		return PTR_ERR(host->reset);
-
 	host->irq = platform_get_irq(pdev, 0);
 	if (host->irq < 0) {
 		ret = -EINVAL;

so this repo does not have the emmc-patch, so i wonder why it works better than with…afair we needed the reset because upstream-uboot initializes the emmc a bit different which shows up the bug (no problem with 2014-04 uboot)

only one line (and one in the defines) is not from the reset-patch:

sdr_set_field(host->base + MSDC_PATCH_BIT1, MSDC_PATCH_BIT1_CMDTA, 2);

this is also “removed”…

you have now 2 possible ways:

  • revert the 2 reset-patches (which i guess brings no change because your 5.4.63 mainline had also the problem…without the patch which comes in with .64)
  • remove the line above and test again

do have also problems with mounting emmc if booted from sd like my test above? are you sure you using 5.4.65 from my repo (not an older state)?

Does official image use 64bit uboot and kernel in 64bit package? My image/uboot/kernel uses 32bit uboot and uImage and elevates to 64bit after unpacking to boot 64bit kernel…but this should not be the problem because kernel boots and then uboot is no more the problem (except different initialisation which should be fixed with reset)

btw. git clone of a tree does not work…so make sure you have cloned last version of 5.4-main and not using an other tree

22

thank you very much. i made changes based on your suggestions and it succeeded. according to what you said, there was indeed a problem with the main line, and the official version did not modify the problems that have been found. Follow reset-patch to patch. Thank you again!