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, …)
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).
… 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.
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…
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.
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
This 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
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?
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.