Bpi-r64 quick start (boot from eMMC)

Banana Pi Router design
78

Yes I created ext4 fs on second partition with official SD 4.19. I even managed to check the eMMC filesystems in u-boot (using fatls and extls), it is okay. But latest kernels have troubles mounting eMMC filesystems in RW, it works ok in RO. But I need RW to use the ext4 fs as root filesystem. I compile kernels using your repo and branches 5.4-main, 5.6-main… Could it be a missing kernel parameter ?

My u-boot env: (SD boot)

BPI-R64> printenv
baudrate=115200
boot_kernel=bootm 0x44000000 - 0x47000000
bootargs=console=ttyS0,115200 root=/dev/mmcblk1p2 rw rootwait pci=nomsi
bootcmd=run load_kernel; run load_dtb; run boot_kernel;
bootdelay=2
fdtcontroladdr=7f7fd418
ipaddr=192.168.1.1
load_dtb=fatload mmc 1 0x47000000 bpi-r64.dtb
load_kernel=fatload mmc 1 0x44000000 uImage_nodt
loadaddr=0x4007ff28
serverip=192.168.1.3
stderr=serial@11002000
stdin=serial@11002000
stdout=serial@11002000
79

You still missing partition in fatload…

I guess fatload fails and you cannot boot kernel…uboot does not mount

80

Partition in fatload is ok, it takes the first as default which is the vfat partition, which contains kernel. I think my problem is within mediatek emmc kernel drivers but I’m not sure. Are you able to write to emmc with 5.4 ? At least mount it in RW.

81

Which uboot version do you use? Uboot 2014-04 in official images for r64 contain a bug with emmc (was fixed later in github,but images still have it).

Basicly it was this change (here in my repo because official was rebased at some time):

Can you post uboot-output of fatload+bootm…and maybe bootlog of kernel if it is started

82

I use u-boot branch 2020-04-bpi-all from your repo. The patch emmc-support is for old u-boot if I am right because this commit is not in 2020-04-bpi-all branch. I uploaded emmc bootlog (with switch to 0 and no SD) until kernel panic. Something in kernel prevents this device to be written correctly.boot.log (27,5 Ko)

83

Right, patch is for 2014-04…as far as i see in log,uboot is not the problem…have you added ext4-support in your kernel-config? How about booting your kernel from sdcard and then try to mount emmc from there?

Btw. I use this options for rootfs in cmdline:

rootfstype=ext4 rootwait

You use “rw” which i do not use…

84

Hi yes I have added ext4 and tried to mount emmc partitions from sd boot using same kernel and result is in my first post : Bpi-r64 quick start (boot from eMMC) I can mount the vfat but cannot write to it and there are errors, I can not mount ext4 at all. So to me this looks like mediatek kernel mmc driver bug, or could it be device tree ? Maybe related but /dev/mmcblk0,1 device id switched between 4.19 and 5.4 kernels.

85

Debugging further, this problem arises because of u-boot 64bits… When using old u-boot and same kernel, same dtb I don’t have issues with MMC. Note that the issue affects SD as well but differently, SD can be mounted (and booted as root filesystem) but everything is very slow, almost unusable. So I don’t know if this is a problem with 64bits or maybe my 2020.04 u-boot does not init MMC properly. I see that mmc init or mmcinit is not a command in u-boot 2020.04 but mmc init exists in old u-boot.

86

Do you build uboot from my repo? If not can you try build 32bit uboot from my repo (2020-04-bpi)

87

Yes I did. I tried 2020.04 32bits u-boot and I have same issue. So my bug is not related to 64bits but rather u-boot build. This is very strange because MMC (sd and emmc) works fine in u-boot shell, at least mmc part, mmc info and fs commands.

88

I don’t think it’s uboot related…i guess more kernel issue…

Which kernel do you use? I have no 5.6-r64-main branch. With beginning 5.4 i manage r2 and r64 in -main (only 5.4 has a separate r64 branch for my reference what to be merged)

i don’t know if i tested uboot with emmc on r64 much…afair only loaded kernel, but without rootfs on emmc

89

I’m pretty sure it’s u-boot now. Here is my scenario : I have 2 SD, one with old u-boot and one with 2020.04 (32bits to exclude the 64bits hypothesis). They both have the exact same kernel (5.1 checked with shasum) and dtb and with old u boot I manage to get emmc as root filesystem and I cannot with new u-boot. I have attached the two bootlogs. I also notice that mmc requires mmc init in old u-boot which is not required in latest (command is not there), I am suspecting something with that or maybe the patch you mentionned before. boot_new_uboot.log (25,3 Ko) boot_old_uboot.log (43,1 Ko)

90

Maybe different preloader/atf? Afair there was a issue in early preloaders

91

@cafebabe Not necessarily, I did a test where I did as follow:

  1. flash emmc_singleimage.img and then with u-boot option ‘2’ flash openwrt-mediatek-mt7622-bpi_bananapi-r64-squashfs-sysupgrade_419.bin - boot correct

  2. flash emmc_singleimage.img and then with u-boot option ‘2’ flash openwrt-mediatek-mt7622-bpi_bananapi-r64-squashfs-sysupgrade_54.bin - hang on rootfs mount.

in both cases u-boot, preloader and ATF stays the same. Squashfs images generated from Openwrt except change kernel version.

I also replaced mtk-sd.c in 5.4 with the one from 4.19 but that did not a difference.( Im not sure if that is a eMMc driver)

92

Hi ! Thanks for helping out. I thought about kernel bug at first but my tests so far have proven that it is latest u-boot that breaks emmc on bpi-r64. I successfully tested emmc with kernel 5.4 but old u-boot (see bootlog with few mount commands) boot_5.4.log (41,3 Ko) Looks like old uboot has external mediatek mmc drivers for emmc and sd. In new uboot, sd is taken care by mtk-sd.c as you pointed but emmc is handled by legacy mmc. So I’ll dig into that.

93

Hi. I have beginner level question. I have successfully built openwrt from scratch and ended up with the following files: bin/targets/mediatek/mt7622/openwrt-mediatek-mt7622-bpi_bananapi-r64-initramfs-kernel.bin bin/targets/mediatek/mt7622/openwrt-mediatek-mt7622-bpi_bananapi-r64-squashfs-sysupgrade.bin

I flashed the initramfs-kernel.bin to eMMC via TFTP.

How do I flash the sysupgrade.bin? Should I use the sysupgrade command after booting the kernel?

94

I will do some tests too,if i find some time…currently extremely limited because of corona (2 kids at home).

As far as i read

  • not kernel-related (makes it strange because uboot and linux using separate drivers that should work without the other and made a own initialization) => i guess problem is another subsysten (e.g. missing clock in linux,which is initialized by old uboot but not in new/linux)…but also here it’s strange that emmc in uboot works (loading kernel)
  • old uboot not affected

at least i get same errors with new uboot (2020-04-rc2, linux kernel 5.4.30-bpi-r64-main)

root@bpi-r64:~# mount /dev/mmcblk0p1 /mnt/emmc1                                                                                                                          
[   48.558600] mtk-msdc 11230000.mmc: phase: [map:7ffffff] [maxlen:27] [final:9]                                                                                         
[   48.573418] mtk-msdc 11230000.mmc: phase: [map:7ffffff] [maxlen:27] [final:9]                                                                                         
[   48.655068] mtk-msdc 11230000.mmc: phase: [map:7ffffff] [maxlen:27] [final:9]                                                                                         
[   48.664925] blk_update_request: I/O error, dev mmcblk0, sector 204800 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0                                              
[   48.676019] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write                                                                                  
root@bpi-r64:~# umount /mnt/emmc1                                                                                                                                        
[   51.373460] mtk-msdc 11230000.mmc: phase: [map:7ffffff] [maxlen:27] [final:9]                                                                                         
[   51.529173] mtk-msdc 11230000.mmc: phase: [map:7ffffff] [maxlen:27] [final:9]                                                                                         
[   51.544343] mtk-msdc 11230000.mmc: phase: [map:7ffffff] [maxlen:27] [final:9]                                                                                         
[   51.553281] blk_update_request: I/O error, dev mmcblk0, sector 204800 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0                                              
[   51.564494] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write

booting same kernel with 2014-uboot (including my patch, loaded by tftp out of the new one) brings same error, so it looks more like an linux-issue for me

95

Hi, Thanks for confirming :+1:

Can you try without the patch or u-boot from official image ? I think it’ll work.

I’m definitely thinking about some shady mmc init and tuning in u-boot that mess up kernel mmc afterwards. I tried to disable emmc0 in u-boot device tree and the bug was not there (I mean I could mount the emmc fs in linux while booting from SD)

I also tried syncing u-boot dts with kernel dts. By the way, bpi-r64 does not seem to be included in u-boot master so this leaves us a bit on our own crafting a dts. But I couldn’t find a workaround. I managed to get high speed mmc in u-boot with CONFIG_MMC_UHS_SUPPORT and mmc-hs200-1_8v + cap-mmc-highspeed in device tree but it didn’t fix kernel bug.

There’s some mmc tuning code in the driver (both kernel and u-boot) that looks interesting to debug but this takes a bit of time. Maybe mediatek could help here please ?

1 Like
96

You can use mt7622-rfb.dts…in my repo i copied it and changed only memory.

Interesting that disabling emmc in uboot fixed the kernel-bug…will try this later. This sounds like emmc has problems if init happens twice (uboot+kernel)…maybe in linux there is a reset missing

97

@frank-w you are probably right here.

Another two tests.

The same u-boot, preloader, ATF, kernel 5.4, rootFs (ext4) the only difference is with bootargs.

First

board=bpi-r64 console=ttyS0,115200n1 earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rootwait service=linux debug=7 initcall_debug=0 androidboot.hardware=mt7622 swiotlb=512

second:

board=bpi-r64 console=ttyS0,115200n1 earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rootwait block2mtd.block2mtd=/dev/mmcblk0,65536,eMMC,5 mtdparts=eMMC:512k(preloader)ro,256k(ATF),512k(Bootloader),512k(config),256k(factory) service=linux debug=7 initcall_debug=0 androidboot.hardware=mt7622 swiotlb=512

First one booting, second stops on:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

So The issue is definitely on kernel site.

Full logs attachedBoot_54_with MTD_failed.txt (26.3 KB) Boot_54_without MTD_ok.txt (31.1 KB)