… if you got physical access. If the machine is somewhere in a remote location (think: PoE-powered on top of a pole with some radios mounted and some directional antennas connected to it) it may get very complicated…
Sorry for the late reply. I don’t have such an old SD card to reproduce the issue. But I believe the mmc framework of TF-A may cause this issue since it’s extermely simple. May be we can add some log to the mmc framework and/or the mmc driver to check which command caused this issue.
Talking about weird things happening in bl2:
What should we do about that [email protected] operating point? So first of all it was wrongly assigned 30MHz in dts, patch by Alan Swanson is pending
However, even with that fix applied reboot hangs in TF-A bl2 if happened while at [email protected] opp. Experiments have shown that rising voltage to 1.00V solves the problem, but maybe cpufreq should be properly reset in bl2 rather than relying on the OS to avoid some values before reset?
Also note that MT7622 seemed to operate stable with [email protected] as well as [email protected] under Linux, problem only occurs inside proprietary DRAM calibration embedded in TF-A bl2 which results in hang when running @0.95V…
I am not familiar with this. I’ll consult relevant personnel to see if there’s a solution
1 Like
Anything new regarding mmc issue? I got a report from another user falling into it
Output in uboot is as follow when access sdcard
unable to read ssr
unable to read ssr
unable to select a mode
mmc_init: -524, time 600
I was told that only cpufreq at 1.35Ghz was tested by MTK, and all other opps are not guaranteed.
So as a workaround, please just don’t let CPU running at such low frequencies.
if i understand @dangowrt the problem is in mtk ATF source, and so it needs a change, same for mmc-issue
Does the old u-boot (v2014, 32-bit one) work on the sdcard?
with old bootchain (32bit preloader + uboot) there was no problem, also not with new uboot and old preloader…@ntech can you confirm? if not sure, please retry with same card (failing with new image) booting with old buster image
I’m not the original developer of the mtk-sd driver. The driver in mtk atf is maintained by other guys.
Currently I can only provide one idea to continue debugging: If old images work, add log to print every mmc commands and their responses (including cmd, cmd_arg, resp_type and response data), and do the same thing for the sd driver in mtk atf. Then we compare both logs to find the difference.
We do not have source of old preloader,so we could only debug in uboot
Yes I meant exactly debugging in u-boot.
Hi. Today I update OpenWRT to last image. I update throgh web iterface image openwrt-mediatek-mt7622-bananapi_bpi-r64-squashfs-sysupgrade.itb. And after this I have got:
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 496.4M 14.2M 482.2M 3% /
tmpfs 496.4M 1.1M 495.3M 0% /tmp
tmpfs 512.0K 0 512.0K 0% /dev
No one settings don’t save.
This is what must be (image from 19.10.2021):
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 4.5M 4.5M 0 100% /rom
tmpfs 496.3M 76.0K 496.2M 0% /tmp
/dev/mmcblk0p66 968.4M 150.6M 817.9M 16% /overlay
overlayfs:/overlay 968.4M 150.6M 817.9M 16% /
tmpfs 512.0K 0 512.0K 0% /devThis looks like system has booted into recovery, probably the image you flashed got damaged somehow 
There have been problems in the past with sysupgrade corrupting in case of kernel partition table reload failing, usually because umount had failed and some filesystem remained mounted.
This has been adressed by and then further improved into a generic method by Enrico Mioso and this is what is now used since
So at least it shouldn’t happen again once you upgraded to a more recent version which contains the above fixes.
To go ahead, first of all, check that the system has indeed booted into recovery/initramfs system.
ubus call system board
Should tell you about it (check the version, it should be old/on the level which you used to create the SD card or install to eMMC; also check that rootfstype should be initramfs when booted into recovery).
If so, first of all try again flashing the sysupgrade.itb image. You will have to redo you configuration 
All work, after I have update image from SD. Maybe this thrables because uboot not updated through web interface.
I have been going through the wiki and forum, but have not found a solution.
is there a procedure to compile a custom mainline OpenWRT 21.01 image for sdcard?
I have tried to customise working sdcard image with newly compiled rootfs.tar.gz but can’t seem to mount the image with loopback.
I’ve tried mounting the partition with this:
loopdev=$(losetup -f)
sudo losetup ${loopdev} bpi-r64.img
sudo partprobe ${loopdev}
But does not seem possible.
Is there a way to take mainline openwrt and compile a sdcard image or a procedure to alter a working sdcard image?
Thanks
Hello everyone I was struggling to change the network managed by my newly installed router (BananaPI BPI-R2 + Banana Pi BPI-R2 19.07.7 OpenWRT Router image Kernel 4.14.112 2021-04-15). I saw a quote on the wiki and didn’t understood what it meant.
Is it possible on the last OpenWRT Image to change the lan address from 192.168.1.1/24 to 192.168.10.1/24 to create a separate subnet?
You are my last chance with this card…
My Banana pi also seems to be reset every time I reboot, I may have failed my install, I don’t know
thanks everyone
This thread is about BPI-R64 but i guess all openwrt images from bpi have problem with saving the settings. BPI-R2 and R64 should be still supported by mainline openwrt.
Hi. Today I upgrade my R64 to new OpenWRT. And what I see.
OpenWrt 23.05.0, r23497-6637af95aa
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 5.0M 5.0M 0 100% /rom
tmpfs 496.5M 80.0K 496.4M 0% /tmp
/dev/mmcblk0p66 92.2M 38.4M 53.9M 42% /overlay
overlayfs:/overlay 92.2M 38.4M 53.9M 42% /
tmpfs 512.0K 0 512.0K 0% /dev
Now overlay have volume only 92.2M but early It was 1Gb. Why in new version OpenWRT memory has been reduced?
Added: I don’t know but even If I return to latest firmware I have only 92M. Maybe eMMC chip on my R64 degradate.
The default size for the firmware and rootfilesystem has always been 102 MiB which is a common default for many OpenWrt boards with block storage.
You can increase the size the production partition (e.g. using gparted) and after a subsequent sysupgrade you should enjoy increased rootfs_overlay size.