Can you get env variables from u-boot?
This error is happening in ATF, trying to load fip image that holds BL31 + U-Boot. So it is before uboot is started…
Make sure you have wiped all remains of previous MBR or GPT partitions before, ie. use
wipefs -a /dev/sdc
before writing to the SD card using
gzip -cd openwrt-mediatek-mt7622-bananapi_bpi-r64-sdcard.img.gz | dd of=/dev/sdc
(both assuming that the SD card was mapped to /dev/sdc on your system)
Running wipefs didn’t make a difference unfortunately. However, using another (much) newer SD card did work using exactly the same image. The other older SD cards were pre-SDHC/SDXC but still working without errors so it may indeed have been a compatibility issue.
Now to see if I can get my untested second hand WLE900VX card recognised given it’s known PCI compatibility issues.
1 Like
As the in-SoC bootrom was able to load ARM Trusted Firmware bl2 even from the older/slower SD card, I wonder if we can improve the mmc driver in TF-A (and possibly U-Boot) to also be a bit more tolerant… @hackpascal ?
Seems to be similar to this: [BPI-R64] New bootchain without U-Boot
Maybe skipping uboot (by using patched atf) is an option?
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.