you can forward this problem to uboot emmc owner firstname.lastname@example.org or other linux emmc dedicated owner (grep the commit message)
What are the downsides of 4.19 kernel?
My goal is to make WiFi work (both internal and PCIe MTK7615E board) + opkg packages. Will 4.19 allow me this?
PCIe MTK7615E board works for me.
Openwrt with kernel 4.19 afaik does not support mt7622 wifi. Mt7615 should be in,but mt7622 was developed later,so i guess you need to include it by yourself
It’s worse than that because bootdevice ils always sd on reboot/reset for R64.
Have you set bootswitch to proper device? Btw.you can modify your sdcard uboot to always boot from emmc just set device/partition where kernel gets loaded and bootargs (cmdline for linux)
Yes, I use position 0 to boot from emmc, it works when power is switched on. But reboots and resets always uses SD. In practice this means that you cannot remove SD and must have - at least - headers, preloader and u-boot flashed to it.
Ok,it behaves a bit different to r2 where it always boots device accessed on poweron (if emmc booted first,reboot also boots emmc,also if sd is inserted). This behaviour of r64 is odd…maybe @sinovoip can explain cause…i guess it can be sd-preloader which is also in emmc bootchain
@cafebabe @kalminlee @deema can you please test the Fix-Patch for emmc-issue i’ve linked here: Add latest U-boot support for BPI R2 & BPI R64 (not yet) ?
In relese brunch set that relese was 5 days ago. I think it don’t contain your patch.
And can you explain how to use it with SD card (I dont want flash eMMC)? In readme you had wrote “you can also install direct to sd-card which makes a backup of kernelfile, here you have to change your uEnv.txt if you use a new filename (by default it’s containing kernelversion)”. But I don’t understand, can you write sep by step manual.
I linked directly to the patch itself https://github.com/frank-w/BPI-R2-4.14/commit/f644b6766b28c72fb6ccef5832201032808dc2ca it is only applied to 5.4-mmctest branch. But you can make same change to any other branch. Compile it and install to sdcard (both can be done via build.sh)
latest patch i got confirms my assumption
have added it to 5.4-main too (which gets compiled by travis and put to github-releases), because it will be posted to mailinglist soon
Hi, Thanks it fixes emmc linux boot for me.
But for R64 there is still reboot issue that prevents the sd to be removed.
@sinovoip Do you know why sd preloader (Build Time: 20180625-214655) is boot when the board is reset instead of emmc preloader (Build Time: 20190927-141930) in /dev/mmcblk0boot0 ? Also why is the SD preloader image necessary in /dev/mmcblk0 offset 2k ? It seems it is not even booted.
Yes this is another issue…we focused on emmc write issue because it results in data-corruption.
I guess emmc-preloader stores wrong bootdevice in memory and bootswitch is only checked on poweron
yes, I will test it in a few days
Can you build openwrt kernel 5.4 into R64 EMMC? How? I have try the patch from @frank-w， https://github.com/frank-w/BPI-R2-4.14/commit/c83b2a27dad867951fbd157b1bd0a9d9cd551f7a，Not working for me.
I have no openwrt…as far as i know there is still an mtd-problem in 5.4. I had tested mount of emmc in debian which is working with the patch you linked
@bourne_hlm have you got it working? I have also got a patch for uboot, where sometimes (not with my v1.0 board) emmc is not working
@kalminlee have you tested it?
@sinovoip have you took a look on reboot-always-to-sdcard issue?
@frank-w @bourne_hlm the OpenWRT 5.4 kernel’s mtd driver have some issue. when I assign the MTD pattion on SD card or EMMC, the kernel can’t mount the rootfs. I think that it should be one kernel’s mtd driver issue. But you may don’t use the MTD partiotn on the EMMC, you can use the standard linux partition structure, then mount the mmc0blk0p1 block device. the path can work fine.
Basicly it sounds like a generic issue because it is mtd layer which should not be mtk related, am i right? Have you any more information?
Openwrt allows to create (packed) rootfs which can be used on additional partition on my debian-image. This needs only some uboot justification to pass different rootfs-partition to kernel (if you don’t overwrite my debian rootfs)