This is caused by invalid value of ‘num of sectors’ of the MBR:
VERBOSE: MBR header entry has an invalid number of sectors
VERBOSE: Failed to access image id=28 (-22)
ERROR: Failed to parse partition with image id = 28
ERROR: Partition 'fip' not found
ERROR: FIP boot source initialization failed with -2
The ‘num of sectors’ is intended to be the total number of blocks of the eMMC user data area.
However the actual number of blocks varies between emmc chips.
That is, all GPT header generated by tool offline can’t know the number of blocks, and that’s why the value is invalid (Filled with ffffffff).
Of course you can recreate the MBR/GPT online using parted. But to make it always work, I have to patch the ATF to tell it the actual ‘num of sectors’ before parsing MBR.
Thx but it does not explain why sdmmc gpt works. But i have seen that the json from python tool now misses the “gpt” partition started from sector 0. Without bl2 partition i have different numbering of boot and rootfs so currently best way is to use sdmmc partition table. This also makes sdcard image compatibe with emmc
And i do not create gpt with python tool but sgdisk (so i guess not filled with 0xff),but still offline.
I also try to reproduce the mmc init error (read issue) in uboot but have not got it yesterday…have only increased my bootdelay before reading uenv.txt from boot partition and was not able to trigger it yet in ~ 10 cold starts + ~20 reboots (sometimes after linux loaded)
Thank you for your response.
I have checked the dram-configs.mk in ATF, and it shows that when using DDR3, AVAIL_DRAM_SIZE only has two options: 256 and 512. Additionally, in the old 20220606 ATF and U-boot source code we are using, DDR3 also has two options: 256 and 512, and there is an ‘auto’ option in menuconfig.
old 20220606 ATF and U-boot:
atf-20220606-637ba581b
uboot-mtk-20220606
The Qihoo 360T7 router (mt7981 DDR3 256MiB) was able to automatically recognize 512MiB after an memory upgrade, but when we soldered a 1GiB Micron D9STQ chip, it works, but only recognizes 512MiB. We have used the ‘auto’ option to compile and replace BL2 and FIP, but it had no effect. Therefore, we suspect that modifying ATF is necessary to support 1GiB memory for DDR3.
We also tried soldering an D9STQ on the NetCore N60 router(mt7986a DDR3 256MiB), it works, but only recognizes 512MiB.
BTW, the U-Boot link at the beginning of the article has an extra character ‘\’, preventing it from being accessed directly by clicking.
Hello, hackpascal. I have a question that I would like to ask you.
Can the Uboot of mt7981 or mt7986 support driving external 2.5G phy chips?
I have a MT7986 SOC device on hand. But the downside is that it only has one RTL8221B 2.5G Ethernet port.
I have seen similar products on the market, most of which come with a 1000M Ethernet port or an MT7531 switching chip.
You can drive these other Ethernet ports within Uboot instead of 2.5G Ethernet ports.
Looking forward to your reply! This has been bothering me for a long time.
imho it should work on mt7986 mac, if uboot has driver for the external phy…basicly r3mini is very similar and there it works…not very stable, but this should be the driver of airoha phy.
U-Boot is currently still missing support for those 2.5G RealTek PHYs – adding that should not be hard given that you can mostly copy & paste from the Linux driver and don’t require perfect performance in U-Boot (so using rate-adapter mode of the PHY for lower speeds and always using 2500Base-X interface mode is acceptable for U-Boot imho). Boils down to setup “2500Base-X with rate-adapter” mode and polling link status.
This looks like TF-A bl2 is built without support for loading bl3 from UBI, despite you correctly passing it the UBI=1 build argument. Which TF-A tree are you building from? Excuse my ignorance, you wrote it clearly. And there is a clear answer: you have to use TF-A from https://github.com/mtk-openwrt/arm-trusted-firmware
My mtk-atf branch is also based from mtk atf repo,but older state where the ubi patches are not in as i have not used this before, so it uses fixed offset for fip. If you flash fip there it should boot uboot correctly
I have done some more testing and I can confirm that both mtk-atf repos ( frank-w’s and mtk-openwrt’s) work if UBI=0, by placing the fip at the default value of 0x580000.
@dangowrt The new repo from mtk-openwrt does not work for me when compiling with UBI=1. It seems to be building an invalid bl2 (see below). Do I need to change anything else to get a valid bl2 when compiling with UBI=1? Perhaps in the uBoot config, or the ATF make commandline?
Where are these commands present? There is a custom U-boot that has these commands?
I have no clue where I can add these commands. Anybody has any idea?
These are commands from sdk,not upstreamed in u-boot…why do you need these commands? There is a bootmenu,so you do not need mtk specific implementation.load is maybe combination of load+bootm/go. mtkboardboot sounds similar and upgrade will only work with sdk image…openwrt has different structure and has its own upgrade mechanism.
So why do you need these commands? If you really miss any feature from it it should be added to mainline commands in a generic way.
I’ve checked the U-boot OpenWRT source and I found all these commands in boards/mediatek/common.
Anyway there are not portable to newer versions of U-boot mainly because ubi.c moved a lot of functions to static, functions used by one of the helpers.
As you says and also as I’ve noticed I don’t need them.
And i do not create gpt with python tool but sgdisk (so i guess not filled with 0xff),but still offline.