I see this commit adding mt7986 support only, does it depend on any other patches?
Mtk tree needs patches for mt7621 and 7981.
The commit you are referencing here is adding Linux support for MT7986 to Linux 5.15. If you can point me to updated Linux sources which include support for MT7981 I will happily integrate them into my tree.
Commits importing stuff from SDK to U-Boot are below:
Edit: Support for MT7621 MIPS SoC is already in upstream U-Boot and I backported it some weeks ago to OpenWrt’s U-Boot 2022.07.
1 Like
There is another trick of using gpt on emmc or sdmmc. I use it in my script. Stretch the bootloader image so that blocks 2-34 are empty. Now you can use parted as normal to partition the gpt.
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=bpir64-atf-git
Uboot’s mkimage Patched Here:
https://aur.archlinux.org/cgit/aur.git/tree/mtkimage-gpt-expand.patch?h=bpir64-mkimage
Initializing NMBM …
spi-nand: spi_nand spi_nand@1: unknown raw ID bface300
SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
Could not find a valid device for nmbm0
Lower MTD device ‘spi-nand0’ not found
spim-nor and spim-nand share the same spi bus and the same chip select. Apparently your u-boot configuration is intended for spi-nand.
Yes,i use same defconfig for nand and nor in uboot. I’m not sure nmbm is needed. Afaik daniel use only mtd and can write to mtd partitions which will be enough for me in uboot. Basicly nor is recognized now.
In linux i still struggle with it (sent binary kernel image to skylake), but this is offtopic here.
NMBM is a MediaTek-specific solution for transparently handling NAND bad blocks. It allows you to not care about potential bad blocks and is mostly needed in case you want to use filesystems which are not designed for use on NAND (like JFFS2). If all you do is load bl2 and fip from fixed offsets there is no real need to use NMBM, simply skipping bad blocks is enough.
For everything other than bl2 and fip you then have to use UBI (or YAFFS2, but lets not go there…) which handles bad blocks much better and also does wear leveling. U-Boot fully supports UBI and UBIFS, so does the Linux kernel.
Unfortunately having it both (NMBM for some area of the flash and UBI for all the rest) is a bit tricky: you need to exclude the region used by UBI from NMBM handling, we got a patch in OpenWrt which allows us to do that. Otherwise a newly broken block handled by NMBM will corrupt all of UBI because UBI assumes that addresses/offsets remain intact.
As NMBM is a MediaTek-specific solution which is imho inferior (lacking wear-leveling, …) to UBI, I prefer to just use UBI.
Thx for explanation, i only need nand/nor for bl2+fip (i have not figured out how exactly you did compress fip for nor…only see the makefile patch where you send fip through xz). Kernel can be loaded from usb storage or mmc.
Maybe you can explain fip compress in detail and maybe the ubi way? I can drop nmbm as it works only for NAND and not NOR and gives no partition access (afaik mtd does? Corrently have only flashed to fixed offsets).
Infact if you call block_markbad to NMBM’s mtd to mark a block bad, NMBM will not remap the block since we don’t want to break the logic of normal bad block handling. So the block on NMBM’s mtd will remain bad state. Only bad blocks detected by NMBM first will be remapped.
I tried v2 on 2022.10-rc4 with my defconfig (sd) and got only initcall error on loading fip. 2022.7 works so far with v1. Any idea whats wrong?
https://github.com/frank-w/u-boot/tree/2022.10-r3
Is there any size limitation which bl2 can load except fip partition size (not changed)?
ATF v2.7 (default now at mtk-openwrt, before v2.4) has decompression support.
The decompression buffer size is a limit, even when loading an uncompressed image.
#define FIP_DECOMP_TEMP_SIZE (0x400000)
You can compress BL31, BL32 and BL33 images with
xz -e -k -9 -C crc32
Then add them to the FIP with the fiptool.
But decompression is much slower then loading the uncompressed image. So If the size is not a problem, then compressing is not very usefull.
Compressing BL2 itself works in another way, using BL2PL. Have not tried this.
I used same atf source and no compression yet.
Only changed To uboot 2022.10+v2 of patches and rebuilt.
Need to add compression later somehow to atf build chain…currently it takes the uboot.bin and builds the fip from it…do not have the bl31 alone.
When I boot ATF with v2.7 on my R64 (the default of openwrt/arm-trusted-firmware then it boots OK.
However when I reboot it get’s stuck, just before I should see the hex numbers, but I never get to see them.
Ok, I have patched it a little (see here), but branch mtksoc-20210508 boots just fine.
Any ideas why?
V2.4:
[65344.944234] shutdown[1]: All filesystems unmounted. +-----------------------------+
[65344.949190] shutdown[1]: Deactivating swaps. | |
[65344.953577] shutdown[1]: All swaps deactivated. | Cannot open /dev/ttyUSB0! |
[65344.958125] shutdown[1]: Detaching loop devices. | |
[65344.963145] shutdown[1]: All loop devices detached. +-----------------------------+
[65344.968055] shutdown[1]: Stopping MD devices.
[65344.972658] shutdown[1]: All MD devices stopped.
[65344.977294] shutdown[1]: Detaching DM devices.
[65344.981961] shutdown[1]: All DM devices detached.
[65344.986685] shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
[65344.995668] watchdog: watchdog0: watchdog did not stop!
[65345.005007] shutdown[1]: Syncing filesystems and block devices.
[65345.011212] shutdown[1]: Rebooting.
[65345.015497] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[65345.041227] reboot: Restarting system
F0: 102B 0000
F5: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 036D [000F]
Jump to BL
V2.7:
[ 118.715769] shutdown[1]: All filesystems unmounted.
[ 118.720725] shutdown[1]: Deactivating swaps.
[ 118.725127] shutdown[1]: All swaps deactivated.
[ 118.729677] shutdown[1]: Detaching loop devices.
[ 118.734716] shutdown[1]: All loop devices detached.
[ 118.739637] shutdown[1]: Stopping MD devices.
[ 118.744262] shutdown[1]: All MD devices stopped.
[ 118.748897] shutdown[1]: Detaching DM devices.
[ 118.753568] shutdown[1]: All DM devices detached.
[ 118.758292] shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
[ 118.767282] watchdog: watchdog0: watchdog did not stop!
[ 118.776579] shutdown[1]: Syncing filesystems and block devices.
[ 118.782772] shutdown[1]: Rebooting.
[ 118.787022] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 118.819974] reboot: Restarting system
And then stuck...
Only changed ATF, nothing else…
hi @hackpascal i try to get CMD_NAND in my 2022-07 uboot, but this depends on CONFIG_SYS_MAX_NAND_DEVICE (i set to 1) and CONFIG_SYS_NAND_BASE (which value should this be?)
can you help here? it is for detection if NAND or NOR is active in hardware
CMD_NAND is only available for parallel NAND framework (i.e. raw nand in mtd). Parallel NAND is not supported by MT7629/7981/7986. MT7622 does support it but never used. The only command exists in mainline to access SPI-NAND is CMD_MTD. Or you can use my customized command for NAND debugging: https://github.com/mtk-openwrt/u-boot/commit/037df45a3648d96c99d190970d315a4a89a21767
Thx for clarification. I only need a command to check if nand or nor is available and so i cannot use “nand info”. Mtd is used for both. I do not need any special debugging only need to know if nand or nor for loading right dto for linux
Or maybe i need to use sf probe for checking nor and set nand as fallback
Sf probe works. Needed to set
tick_dly = <2>;
To 1 to get nor detected on my r3…maybe r3 needs an own dts?
Still trying to get ATF v2.7 to reboot on R64… See above.
Do you guys think there is a kernel/dts patch that I’m missing, which will cause the kernel not to reboot, when starting from ATF v2.7?
Perhapse a Mhz setting in the operating-points? Or perhapse the L2 cache patch in dts? Anyone knows?
Sorry for late response…maybe this:
https://lore.kernel.org/all/[email protected]/T/#rdf4176e65da050b8125edf90ab2f0753147bff90
Do you use the ddr_flyby option for r64 (in my r64 atf repo i do not use it afaik)? I try to integrate weijis current state into my uboot repo to have one atf branch for r64 and r3…
@ericwoud can you confirm that it fixes your issue?
@dangowrt can you please repost this fix?
@hackpascal daniel mentioned that this should be fixed in TF-A too…have you done this already? it looks like we have similar issue on r3/mt7986…reboot hangs in uboot and it cannot access sdcard (but i have not tried your new source from here as i struggle with correct flags)
tried to use the new TF-A code for bpi-r3 (and created gpt with sgdisk instead of flashing the broken gpt img)
F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 300C 0028
F5: 480C 0000
00: 1005 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 300C 0028
01: 102A 0001
02: 1005 0000
BP: 2000 00C0 [0001]
EC: 0000 0000 [3000]
T0: 0000 0182 [010F]
System halt!
built u-boot.bin from 2022-10-r3 branch, switched to mtk-atf branch, build it and created image with createimg command (using values 100 for boot and 6144 for root to have same sectors as my current gpt created by your py2-script)
partitiontable looks good for me:
non-working:
Number Start (sector) End (sector) Size Code Name
1 34 8191 4.0 MiB 8300 bl2
2 8192 9215 512.0 KiB 8300 u-boot-env
3 9216 13311 2.0 MiB 8300 factory
4 13312 17407 2.0 MiB 8300 fip
5 17408 222207 100.0 MiB 8300 boot
6 222208 12805120 6.0 GiB 8300 rootfs
working (from py2 gpt-img):
Number Start (sector) End (sector) Size Code Name
1 34 8191 4.0 MiB 8300 bl2
2 8192 9215 512.0 KiB 8300 u-boot-env
3 9216 13311 2.0 MiB 8300 factory
4 13312 17407 2.0 MiB 8300 fip
5 17408 222207 100.0 MiB 8300 kernel
6 222208 12805120 6.0 GiB 8300 rootfs
content of bl2-partition looks a bit different (maybe caused by mkimage usage?):
non-working:
00000000 53 44 4d 4d 43 5f 42 4f 4f 54 00 ff 01 00 00 00 |SDMMC_BOOT......|
00000010 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 42 52 4c 59 54 00 00 00 01 00 00 00 00 4a 00 00 |BRLYT........J..|
00000210 88 51 03 00 42 42 42 42 08 00 01 00 00 06 00 00 |.Q..BBBB........|
00000220 88 51 03 00 ff ff ff ff ff ff ff ff ff ff ff ff |.Q..............|
00000230 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000600 4d 4d 4d 01 38 00 00 00 46 49 4c 45 5f 49 4e 46 |MMM.8...FILE_INF|
00000610 4f 00 00 00 01 00 00 00 01 00 05 01 00 0d 20 00 |O............. .|
00000620 88 07 03 00 88 0d 03 00 00 03 00 00 20 00 00 00 |............ ...|
00000630 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |........MMM.....|
00000640 01 00 00 00 4d 4d 4d 01 14 00 02 00 00 00 00 00 |....MMM.........|
00000650 10 00 00 00 80 00 00 00 4d 4d 4d 01 14 02 03 00 |........MMM.....|
00000660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
working (old bpi-atf source):
00000000 53 44 4d 4d 43 5f 42 4f 4f 54 00 ff 01 00 00 00 |SDMMC_BOOT......|
00000010 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 42 52 4c 59 54 00 00 00 01 00 00 00 00 06 00 00 |BRLYT...........|
00000210 88 fd 02 00 42 42 42 42 08 00 01 00 00 06 00 00 |....BBBB........|
00000220 88 fd 02 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000230 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000600 4d 4d 4d 01 38 00 00 00 46 49 4c 45 5f 49 4e 46 |MMM.8...FILE_INF|
00000610 4f 00 00 00 01 00 00 00 01 00 05 01 00 0d 20 00 |O............. .|
00000620 88 f7 02 00 88 fd 02 00 00 03 00 00 20 00 00 00 |............ ...|
00000630 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |........MMM.....|
00000640 01 00 00 00 4d 4d 4d 03 64 00 07 00 90 11 00 00 |....MMM.d.......|
00000650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
mhm, flashed old bl2/fip to the new parttable, and got same system-halt…so maybe i miss something in gpt (flags??)…old gpt with new atf works…so anything i miss in gpt-creation
took me some time to read out the information, but it looks like the legacy bootable flag is needed…do not know yet how to set it with sgdisk, but gdisk prints this when i read the working gpt
Expert command (? for help): a
Partition number (1-6): 1
Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)
seems that was the problem…got it set by this
sudo sgdisk --attributes=1:set:2 ${LDEV}
after that bl2 got loaded 
I’ve tried the opp 3000000 fix before, did not work. I just tried it again, to make sure, but it does not help.
I am building with DDR3_FLYBY=1
The only thing I change is the branch I build, everything else is exactly the same. v2.7 hangs at reboot while v2.4 does not.
So _gitbranch=“mtksoc” Hangs at reboot
And _gitbranch=“mtksoc-20210508” Does not hang at reboot.
On the R64 that is. And I don’t hang at u-boot, but it hangs totally not restarting from the very first visible byte on the uart output. Sounds like a different hang then the one you were experiencing.
tried this ATF on r64 (needed some time to get it working due to the strange MBR/GPT mix)…
at least after booting into uboot and issue “reset” board boots into uboot again…so i guess it is a linux setting breaking reboot in ATF (similar to the Patch from Daniel i’m pointing above). do not have a rootfs on my new card…i hope i find time to check this.
at least uboot 2022-10 with this ATF is completely build in my github for r64/r3 including sd-card images (bootchain only, no rootfs)
https://github.com/frank-w/u-boot/tree/2022-10-bpi (+ mtk-atf branch)
- Below command should miss the CROSS_COMPILE option.
make -f Makefile PLAT= BOOT_DEVICE= BL33=<path-to-u-boot.bin> all fip
ENABLE_JTAG=
This option is valid only when PLAT is mt7981/mt7988
Typo? I think it’s mt7986 instead of mt7988. Here is the grep output of ATF code.
% grep ENBLE_JTAG . -r
./plat/mediatek/mt7981/platform.mk:ENABLE_JTAG ?= 0
./plat/mediatek/mt7981/platform.mk:ifeq ($(ENABLE_JTAG), 1)
./plat/mediatek/mt7981/platform.mk:CPPFLAGS += -DENABLE_JTAG
./plat/mediatek/mt7981/platform.mk:$(call MAKE_DEP,bl2,mt7981_gpio,ENABLE_JTAG)
./plat/mediatek/mt7981/drivers/gpio/mt7981_gpio.c:#ifdef ENABLE_JTAG
./plat/mediatek/mt7986/platform.mk:ENABLE_JTAG ?= 0
./plat/mediatek/mt7986/platform.mk:ifeq ($(ENABLE_JTAG), 1)
./plat/mediatek/mt7986/platform.mk:CPPFLAGS += -DENABLE_JTAG
./plat/mediatek/mt7986/platform.mk:$(call MAKE_DEP,bl2,mt7986_gpio,ENABLE_JTAG)
./plat/mediatek/mt7986/drivers/gpio/mt7986_gpio.c:#ifdef ENABLE_JTAG
Have you tested the JTAG in the BPI-R3? I compiled the ATF with option ENABLE_JTAG=1.