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)
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…
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.
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.
Do you build uboot from my repo? If not can you try build 32bit uboot from my repo (2020-04-bpi)
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.
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
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)
Maybe different preloader/atf? Afair there was a issue in early preloaders
@cafebabe Not necessarily, I did a test where I did as follow:
-
flash emmc_singleimage.img and then with u-boot option ‘2’ flash openwrt-mediatek-mt7622-bpi_bananapi-r64-squashfs-sysupgrade_419.bin - boot correct
-
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)
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.
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?
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
Hi,
Thanks for confirming 
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
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
@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)
Hi, could https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt be applied to emmc dt node ? I would like to test but I have no clue about the right GPIO reset pin.
Also can this be used ?https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/mmc/mmc-controller.yaml#L159 ?
According schematic it is NCEB pin (V15) but looks like it is not used in bpiR64 dts
If you have no mtd partitions (like me) don’t use the cmdline-arguments.
I can boot without problems,but mounting emmc gives errors
I did that to check if I will be able to dd MT7622_EEPROM.bin into mtd3. I do have a problem with wifi
mt7622-wmac 18000000.wmac: Failed to get patch semaphore
I know now that it is problem with FW loading issue rather than calibration.