[Banana Pi BPI-R64] Mainline OpenWRT image

While the idea of getting rid of U-Boot is charming in a way I don’t see that ATF offers the flexibility (loading firmware via TFTP, dual-boot, …) needed to build a robust headless unattended system.

So imho even U-Boot without networking is still better than just ATF loading Linux (as BL3 FIP image) straight away as then one can at least have automated fall-back to recovery firmware using dual-boot.

(if you want secure boot simply build U-Boot with only hard-coded built-in environment and without CLI, make it load only signed FIT image and sign U-Boot itself using ATF fiptool. In that way you can still have dual-boot, recovery via TFTP, …)

1 Like

I like uboots flexibility too,so it is not my preferred way,but for “static system” like openwrt which do not boot different kernels or use netboot it can be an option.most user will not do anything in uboot.

And uboot seems the only system that has problems with the cards…maybe a clock/timing issue?

Also OpenWrt needs to be updated and that can go wrong, which leaves you with a brick which can only be fixed by physical access in case of ATF loading Linux (and hence no dual-boot fall-back using U-Boot).

But we always can load from SD through debug console.

… 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% /dev

This looks like system has booted into recovery, probably the image you flashed got damaged somehow :frowning: 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 :cry:

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?