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.
Thanks, but Im using OpenWRT and there is no rfkill here. Also it is a 7622 driver build into 7615. Regular OpenWRT squashfs was not working so I mount ext4 rootfs. First I thought that it is a problem with filesystem but modules themselves are loaded. Is Firmware loading need some specials like partition name or others unusual bits rather than just regular path to firmware files? I do have them in /lib/firmware/ and also /lib/firmware/mediatek just in case.
but you use mt7615/22 as module, right? imho rootfs is probed for some paths like /lib/firmware for a file in folder mediatek
Yes Im using mt7615e.ko. Like I mention there is /lib/firmware/mediatek folder and can be accessed. I try to unload and load mt7615e but that did not help. I guess I need to trace module that race with mt7615e like you mention with rfkill.
@frank-w I read your wiki about R2 storage and emmc and also halh of this forum and I remember that I sow somewhere that you mention about writing fstab on Openwrt mounts should looks like:
mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
but I do have:
mount
/dev/root on / type ext4 (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup on /sys/fs/cgroup type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,pids)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
so clearly first line with rootfs is missing.Got that working finally. The issue with mt7615e module was that bluetooth module block firmware loading.It was build into kernel and loaded before rootfs so no chance to get firmware file. Making bluetooth as a module instead build into kernel solved the problem So now I do have fully working OpenWRT from eMMC.
By the way. Problems with mt7622 WiFi TX power stuck at 6 dbm are because of missing wifi EEPROM. If it is provided TX power work correct.
1 Like
How do you build image for emmc? which uboot,which kernel…
we experienced issues acessing emmc on bpi-r64 where uboot and kernel have emmc enabled…
Kerenel (5.4.38), device tree and ext4 rootfs are build with OpenWRT, ext4 are not default image so need to be turned on in menuconfig. Standard squashFs was not working.
u-boot is yours
U-Boot 2014.04-rc1-00040-gc49719fe04-dirty (Oct 17 2019 - 17:51:44)
u-boot-mtk_r64_emmc_mt7531_gcc8.3.bin
Can you write step by step, how you build OpenWrt on 5.4.38 kernel?
Yes, but I need to get that all together