[Tutorial] Build, customize and use MediaTek open-source U-Boot and ATF

This tutorial will help you to build, use and customize the official u-boot and atf (TF-A) from MediaTek SDK.

1. Source code

U-Boot: https://github.com/mtk-openwrt/u-boot\ ATF: GitHub - mtk-openwrt/arm-trusted-firmware: Read-only mirror of Trusted Firmware-A

2. Toolchain

This tutorial talks only about the ARM 64-bit platforms. So you need only the aarch64 toolchain. You can use the openwrt toolchain which can be found in staging_dir/toolchain-aarch64_XXXXX

You also need dtc tool to compile .dts files for ATF. It can be found in:

  1. device-tree-compiler package in Ubuntu for example
  2. scripts/dtc from a compiled u-boot/kernel source tree

3. Configure u-boot

Here is a list for all defconfigs supports MediaTek-specific features (Bootmenu with upgrading/booting support)

Name Boot device Description
mt7622_emmc_rfb_defconfig eMMC (dev 0)****
mt7622_nmbm_rfb_defconfig SPI-NAND (SNFI)* NMBM enabled. Uses squashfs + jffs2
mt7622_nmbm_ubi_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7622_nor_rfb_defconfig SPI-NOR***
mt7622_sd_rfb_defconfig SD (dev 1)****
mt7622_snand_ubi_rfb_defconfig SPI-NAND (SNFI) Uses UBI
mt7981_emmc_rfb_defconfig eMMC
mt7981_sd_rfb_defconfig SD
mt7981_snfi_nand_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7981_spim_nand_rfb_defconfig SPI-NAND** NMBM enabled. Uses UBI
mt7981_spim_nor_rfb_defconfig SPI-NOR
mt7986_snfi_nand_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7986_spim_nand_rfb_defconfig SPI-NAND NMBM enabled. Uses UBI
mt7986_spim_nor_rfb_defconfig SPI-NOR
mt7986a_bpir3_emmc_defconfig eMMC
mt7986a_bpir3_sd_defconfig SD
mt7988_snfi_nand_rfb_defconfig SPI-NAND (SNFI) NMBM enabled. Uses UBI
mt7988_spim_nand_rfb_defconfig SPI-NAND** NMBM enabled. Uses UBI
mt7988_spim_nor_rfb_defconfig SPI-NOR
mt7988_emmc_rfb_defconfig eMMC
mt7988_sd_rfb_defconfig SD

* SPI-NAND (SNFI) means the SPI-NAND is connected to the MediaTek SPI-NAND Flash Interface (SNFI), a dedicated controller for SPI-NAND flashes using MTK’s HW ECC engine instead of the On-die ECC engine from SPI-NAND chip.
** SPI-NAND without SNFI means the SPI-NAND is connected to the standard spi-mem controller.
*** MT7622 uses a dedicated SPI-NOR controller while MT7981/MT7986 use standard spi-mem controller.
**** MT7622 has two SD/eMMC controllers (called MSDC), the first one always connects to the eMMC and the second one always connects to SD.

To configure the u-boot, please run the following command in u-boot source directory:

make XXXXX_defconfig

4. Compile u-boot

Run the following command in u-boot source directory:

make CROSS_COMPILE=<toolchain-prefix>

Assume you have a toolchain located at ~/openwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0-musl, and a directory named aarch64-openwrt-linux is inside the toolchain base directory, the toolchain-prefix will be:

~/openwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0-musl/bin/aarch64-openwrt-linux-

If no error occurs, the target file is u-boot.bin.

5. Compile ATF

To compile ATF, we have to pass several configuration parameters to the make command line.

The overall command line is:

make -f Makefile PLAT=<plat> BOOT_DEVICE=<bootdevice> BL33=<path-to-u-boot.bin> <optional-options> all fip

If no error occurs, the target file are bl2.img and fip.bin located in

<atf-src-dir>/build/<plat>/release

a) Essential parameters:

PLAT=

Possible values: mt7622/mt7981/mt7986/mt7988

BOOT_DEVICE=

Value Boot device Description
nor SPI-NOR
snand SPI-NAND (SNFI) optional NAND_TYPE= may be needed
spim-nand SPI-NAND optional NAND_TYPE= may be needed
emmc eMMC
sdmmc SD optional DEVICE_HEADER_OFFSET= may be need by mt7622
ram - For debugging purpose only

b) Optional parameters:

NAND_TYPE=

This option is valid only when BOOT_DEVICE= is set to snand or spim-nand.

By default NAND_TYPE= will be set to default value if not specified.

Important notice: NAND_TYPE must match the memory organization of the SPI-NAND chip otherwise the device will not boot.

Value Boot device Platform Description
2k+64 snand mt7622 Page size: 2K, Spare size: 64 (default)
2k+128 snand mt7622 Page size: 2K, Spare size: 128
4k+256 snand mt7622 Page size: 4K, Spare size: 256
hsm:2k+64 snand mt7981/mt7986 Page size: 2K, Spare size: 64 (default)
hsm:2k+128 snand mt7981/mt7986 Page size: 2K, Spare size: 128
hsm:4k+256 snand mt7981/mt7986 Page size: 4K, Spare size: 256
hsm20:2k+64 snand mt7988 Page size: 2K, Spare size: 64 (default)
hsm20:2k+128 snand mt7988 Page size: 2K, Spare size: 128
hsm20:4k+256 snand mt7988 Page size: 4K, Spare size: 256
spim:2k+64 spim-nand mt7981/mt7986/mt7988 Page size: 2K, Spare size: 64 (default)
spim:2k+128 spim-nand mt7981/mt7986/mt7988 Page size: 2K, Spare size: 128
spim:4k+256 spim-nand mt7981/mt7986/mt7988 Page size: 4K, Spare size: 256

NMBM=

This option is valid only when BOOT_DEVICE= is set to snand or spim-nand.
This option is incompatible with UBI=1

Value Description
0 Disable NMBM (default)
1 Enable NMBM

UBI=

Enable this option if FIP is located in a volume of UBI.
This option is valid only when BOOT_DEVICE= is set to snand or spim-nand.
This option is incompatible with NMBM=1

Value Description
0 Disable Full-UBI layout (default)
1 Enable Full-UBI layout

DRAM_USE_DDR4=

This option is valid only for mt7981/mt7986/mt7988.
MT7988: this is used for single DDR4 chip.

Value Description
0 The DRAM chip is DDR3 (default)
1 The DRAM chip is DDR4

DRAM_USE_COMB=

When this option suppresses DRAM_USE_DDR4.
This option is valid only for mt7988.

Value Description
0 No effect (default)
1 The MT7988 CPU uses KGD DDR die, or the board is using two DDR chips

DDR4_4BG_MODE=

This option must be used with DRAM_USE_COMB=1.
This option is valid only for mt7988.

Value Description
0 No effect (default)
1 Enable DDR4 32-bit 8GBytes mode

DDR3_FLYBY=

This option is valid only for mt7622.

Value Description
0 The board uses only one DRAM chip (default)
1 The board uses two dram chips (For BPI-R64)

BOARD_BGA=

This option is valid only for mt7981.

Value Description
0 The chip package is QFN (MT7981C) (default)
1 The chip package is BGA (MT7981A/MT7981B)

RAM_BOOT_DEBUGGER_HOOK=

This option is valid only when BOOT_DEVICE= is set to ram.
By using this option, the bl2.bin can be load by OpenOCD for debricking.
Please refer to: https://github.com/mtk-openwrt/openocd-scripts/tree/main/mt7622

Value Description
0 Disable debugger hook (default)
1 Enable debugger hook

DEVICE_HEADER_OFFSET=

This option is valid only when PLAT is mt7622 and BOOT_DEVICE= is set to sdmmc.
This option specify the absolute address of the BL2 in the SD card.
This value must match the real address of the BL2 in the SD card otherwise the device will not boot.
The default value is 0x80000.

ENABLE_JTAG=

This option is valid only when PLAT is mt7981/mt7988.
By default JTAG will be disabled in BL2.

Value Description
0 Disable JTAG (default)
1 Enable JTAG

USE_MKIMAGE= and MKIMAGE=

If you don’t want to use the closed-source program bromimage to generate bl2.img, you can use the open-source replacement —— The mkimage from u-boot.

To enable using mkimage, these two parameters must be used together:

USE_MKIMAGE=1 MKIMAGE=<path-to-mkimage>

OVERRIDE_FIP_BASE= and OVERRIDE_FIP_SIZE=

If both specified, they will override the default FIP base & size provided by each platform.
These options have no effect if UBI=1.

OVERRIDE_UBI_START_ADDR=

These options is only valid for UBI=1.
If specified, it will override the default UBI partition start address, which is 0x200000.

OVERRIDE_UBI_END_ADDR=

These options is only valid for UBI=1 and OVERRIDE_UBI_START_ADDR is set.
If specified, it will override the default UBI partition end address, which is 0, meaning the end of NAND.

c) Examples

Build for BPI-R64 booting from SPI-NAND:

make -f Makefile PLAT=mt7622 BOOT_DEVICE=snand DDR3_FLYBY=1 all fip

Build for MT7986 booting from SD using DDR4:

make -f Makefile PLAT=mt7986 BOOT_DEVICE=sdmmc DRAM_USE_DDR4=1 all fip

6. Upgrade the new U-Boot and ATF

The final files are bl2.img and fip.bin. You can upgrade them from anywhere, e.g. from u-boot bootmenu or from linux shell of OpenWrt.

7. Breif introduction of MediaTek-specific u-boot features

Five commands are added:

Command Description
mtkautoboot Display MediaTek-specific bootmenu
mtkupgrade Start interactive prompt for firmware/bootlaoder upgrading
mtkload Start interactive prompt for loading data to ram
mtkboardboot Automatically boot the firmware
httpd Start Web-based failsafe for upgrading firmware

mtkautoboot

This command is also the autoboot command for u-boot.

A menu will be displayed like this:

  *** U-Boot Boot Menu ***
      1. Startup system (Default)
      2. Upgrade firmware
      3. Upgrade ATF BL2
      4. Upgrade ATF FIP
      5.   Upgrade ATF BL31 only
      6.   Upgrade bootloader only
      7. Upgrade single image
      8. Load image
      9. Start Web failsafe

You can choose whatever you want.

mtkupgrade

This command has one optional parameter:

mtkupgrade [part]
Part Description
bl2 Upgrade BL2
fip Upgrade FIP
bl31 Upgrade BL31 of ATF FIP
bl33 Upgrade BL33 (Bootloader) of ATF FIP
gpt Upgrade GPT for SD/eMMC
simg Upgrade single image (ROM dump), not recommended for use

If mtkupgrade is called without parameter, it will first ask you to choose a part:

Available parts to be upgraded:
    0 - ATF BL2
    1 - ATF FIP
    2 - BL31 of ATF FIP
    3 - BL33 of ATF FIP
    4 - Firmware
    5 - Single image

Select a part:

Just press a number to select a part.

Note: FIP contains both bl31 and bl33. bl33 is normally the bootloader, i.e. u-boot.bin here.
If you choose to upgrade bl31 or bl33, mtkupgrade will read FIP into memory, replace the bl31/bl33 of the FIP, and then write FIP back to flash.

After you select the part, or you just called this command with the part parameter, it will ask you to choose a transmission method:

*** Upgrading ATF BL2 ***

Available load methods:
    0 - TFTP client (Default)
    1 - Xmodem
    2 - Ymodem
    3 - Kermit
    4 - S-Record

Select (enter for default):

Again, press a number to select a method. You can also press enter directly to select TFTP client.

If you selected TFTP client, it will then ask you for some network configurations:

Input U-Boot's IP address: 192.168.1.1
Input TFTP server's IP address: 192.168.1.2
Input IP netmask: 255.255.255.0
Input file name: bl2.img

After all prompts above, this command will start to receive file data and then write it to the flash device:

Using ethernet@15100000 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.1
Filename 'bl2.img'.
Load address: 0x46000000
Loading: ##############
         94.7 KiB/s
done
Bytes transferred = 200888 (310b8 hex)
Saving Environment to MTD... Erasing on MTD device 'u-boot-env'... OK
Writing to MTD device 'u-boot-env'... OK
OK

*** Loaded 200888 (0x310b8) bytes at 0x46000000 ***

Erasing 'bl2' from 0x0, size 0x32000 ... OK
Writing 'bl2' from 0x46000000 to 0x0, size 0x310b8 ... OK

*** ATF BL2 upgrade completed! ***

mtkload

This command is similar to mtkupgrade, but only load data into memory.

mtkboardboot

This command will boot firmware according to configuration:

a) Bootmenu type is set to SD/eMMC:

  • Try to boot kernel from the partition named kernel defined in GPT.

b) Bootmenu type is set to MTD:

  • If both kernel and ubi partition exist, it will boot kernel from mtd partition kernel.
  • If only ubi partition exists, it will try to load and boot kernel from ubi volume named kernel.
  • If only firmware partition exists, it will boot kernel from mtd partition firmware.

httpd

This command will start a HTTP server listening on port 80. You can access to it to upgrade firmware image instead of using tftp.

8. Customization of U-Boot

After running defconfig command for u-boot, you can use menuconfig to modify the MediaTek-specific features:

Bootmenu

> MediaTek specific configurations > Enable bootmenu framework

Use default bootmenu: You can deselect this to use a customized bootmenu implementation (entries, command actions, …).
Default bootmenu implementation file is:
board/mediatek/common/bootmenu_mmc.c
board/mediatek/common/bootmenu_mtd.c
board/mediatek/common/bootmenu_mtd_legacy.c (for MT7629, which uses only one bootloader)

Device type for bootmenu:

a) MTD (NOR/NAND/UBI): Based on mtdparts:

  • If both kernel and ubi partition exist → Upgrade kernel to kernel partition, upgrade rootfs to rootfs vaolume in ubi partition.
  • If only ubi partition exists → Upgrade both kernel and rootfs to volumes in ubi partition.
  • If only firmware partition exists → Upgrade firmware image to firmware partition

b) SD/eMMC

  • If mmc device is eMMC → Upgrade BL2 to boot0 hw partition.
  • If mmc device is SD → Upgrade BL2 to bl2 partition defined in GPT.
  • Upgrade both kernel and rootfs to partitions defined in GPT.

Enable bootmenu countdown: You can deselect this to make u-boot stop booting on this menu. This is mainly used for debugging (Load by OpenOCD)

MediaTek bootmenu delay time: This is an idependent to standard bootmenu and autoboot. Specify the delay time for bootmenu displayed by mtkautoboot command.

Enable support for loading from SD card: When both mmc support, partition support and FS support are enabled, enabling this option will add a new file loading method for mtkupgrade command to support load file from SD partition.

MMC device index for SD card: The mmc device index of the SD card. 1 for mt7622, 0 for other chips.

Enable Web-based failsafe for firmware upgrading: When enabled, Web-based failsafe will start if mtkboardboot command fails. The bootmenu will also have an entry for starting Web-based failsafe.

Enable support for UBI-based images: Enable this option to allow mtkupgrade and mtkautoboot commands to deal with ubi volume and tarball sysupgrade image.

NMBM

> MediaTek specific configurations > Enable NAND bad block mapping management

Lower MTD device name: The raw nand mtd device. Currently spi-nand0 for all chips.

You should also define proper mtdparts described in next section.

MTD partition table

The bootmenu type MTD requires mtd partition table be defined properly.

> Command line interface > Filesystem commands

Default MTD IDs:

  • nor0=nor0 for SPI-NOR
  • spi-nand0=spi-nand0 for SPI-NAND without NMBM
  • nmbm0=nmbm0 for SPI-NAND with NMBM

Default MTD partition:

  • For SPI-NOR, firmware partition must be defined
  • For SPI-NAND + UBI: define only ubi partition if both kernel and rootfs are stored as ubi volumes; define both kernel and ubi partition if only rootfs is stored as ubi volume.

9. Customization of ATF

There are two sets of configurations:

a) The offset and size of FIP (for nor, or snand/spim-nand with NMBM=1):
All platforms have their own default FIP offsets and sizes.
You can override them by passing the following arguments to the make command:

OVERRIDE_FIP_BASE=xxx \
OVERRIDE_FIP_SIZE=xxx

b) The start and end addresses of UBI partition (for snand/spim-nand with UBI=1)
By default the start address of UBI partition is 0x200000, and its end address is 0, which means end of flash.
You can override the start address by passing the following argument to the make command:

OVERRIDE_UBI_START_ADDR=xxx

You can also override the end address by passing the following argument to the make command if OVERRIDE_UBI_START_ADDR has been set:

OVERRIDE_UBI_END_ADDR=xxx

10. Generating GPT data

A tool is provided in the ATF repo: tools/dev/gpt_editor

mtk_gpt.py requires python 2.7

A quick start command line:

python mtk_gpt.py --i <gpt-json> --o <output-gpt>

<gpt-json> defines each partition. Examples can be found in example folder. <output-gpt> is the actual GPT raw data that can be written to the start of SD/eMMC data region, or be upgraded by mtkupgrade command.

Notes:

  • The only difference for SD and eMMC partitions is that bl2 partition does not exist for eMMC.
  • There is no limit for bl2 partition for SD cards of MT7981/mt7986. You can modify its start offset and size at will.

GPT for MT7622 SD

The GPT for MT7622 booting from SD is special:

Although we uses GPT, the bootrom of MT7622 actually uses MBR. And an additional limit is that the device header offset in BL2 header must match the real offset of BL2 in SD card.

One can generate valid GPT data for MT7622 SD, with the following steps:

  1. Use the example file mt7986-sd.json to generate the initial GPT data
python mtk_gpt.py --i example/mt7986-sd.json --o GPT_SD
  1. Use the start block num of BL2 to calculate device header offset:
        "bl2" : {
                "start": 1024,
                "end" : 8191,
                "attributes": 4,
                "uuid" : "{19a4763a-6b19-4a4b-a0c4-8cc34f4c2b8a}"
        },

So the start block of BL2 is 1024, device header offset is 1024 * 512 = 0x80000.

When compiling the ATF, pass DEVICE_HEADER_OFFSET=0x80000 to the make command line.

You can actually omit this if the offset id the default value 0x80000.

  1. Use WinHex or other editor to add the second partition to MBR partition table: * 7168 = 8191 -1024 + 1

Edit history

Date Description
2023/07/05 Update for new ATF release
2023/07/20 Update for new U-Boot release
3 Likes

Thx For the explanations

Is Install (bl2,fip) to spim nand/nor supported?

Sam told me that clock driver needs to be changed (compared to v1 in Mailinglist), is this already done in your repo?

Currently nor is not detected on my board (have wrote sam already). But have only tried bpi Source.

“Install kernel” writes it directly to partition (not as file referenced in uEnv.txt or similar)? My current usecase is that boot partition is fat where multiple kernel-files are located. Maybe a check for partition type is a good idea to avoid overwriting such partition.

Do you set partconf and maybe the bootbus (daniel needed this) for emmc?

mmc partconf 0 1 1 1
mmc bootbus 0 0 0 0

If not it is now documented here :slight_smile:

Hi Frank,

Is Install (bl2,fip) to spim nand/nor supported?

Of course supported. Total five boot devices (SNFI/SPIM-NAND/SPIM-NOR/SD/eMMC) are supported and tested.

Sam told me that clock driver needs to be changed (compared to v1 in Mailinglist), is this already done in your repo?

Current clock driver v1 is ok to use. You don’t have to wait for the v2 driver. v2 is not ready yet.

Currently nor is not detected on my board

Have you turned all three switches to the right position? I’ve test it on bpi-r3. %E6%97%A0%E6%A0%87%E9%A2%98 %E6%97%A0%E6%A0%87%E9%A2%982

Maybe a check for partition type is a good idea to avoid overwriting such partition.

Currently we didn’t implement FAT32 r/w in the SDK u-boot. What version of u-boot are you using?

Do you set partconf and maybe the bootbus (daniel needed this) for emmc?

It’s supported. If you use the default bootmenu from the SDK u-boot, these setting will be set after upgrade to bl2.

Please refer to:

I have boot-option from sdcard with sw5 in nor-position (nand is recognized if changed).

Daniel reports Nor-build is not working via mkimage in v1 (needs bromimage tool, maybe fixed in repo).

My source is rebased variant from bpi’s repo

https://github.com/frank-w/BPI-R3-bsp/tree/r3-uboot

( https://github.com/BPI-SINOVOIP/BPI-R3-bsp/tree/mtk_vendor_src )

U19 is solded, what should i verify on top picture (behind usb3 connector),i guess only boot switches, makes only sense after i got it recognized to write bootheaders?

Edit: i use this defconfig for sdcard:

https://github.com/frank-w/BPI-R3-bsp/blob/r3-uboot/configs/mt7986a_bpi-r3-sd_defconfig

And for spim-nor/nand/emmc:

https://github.com/frank-w/BPI-R3-bsp/blob/r3-uboot/configs/mt7986a_bpi-r3-emmc_defconfig

For nand/nor i disable the env-options. I see you create now own defconfigs in your repo.maybe i miss something. I tried nor from sdcard.

Edit: After comparing daniels defconfig with mine i guess i miss these options:

CONFIG_SPI_FLASH_MTD=y
CONFIG_SPI_FLASH_WINBOND=y

edit2:

with these 2 options i see something:

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

This was my mistake and has been resolved. I’ve now tested all 4 boot methods with using mkimage and it works fine. See my updated staging tree https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/heads/r3-mt7986 which allows generating a SD card image with installation option to SPI-NOR and SPI-NAND, and once booting from SPI-NAND allows installation to eMMC.

I consider bootchain complete, the only missing feature in Linux atm is using mtk_sgmii also for the (apparently identical) SGMII of MT7531, so we can know link speed and status of the module plugged into SFP2 cage.

I see this commit adding mt7986 support only, does it depend on any other patches?

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=5c0919b0931a2e95bf1a935ff039ce76dfb46cc0

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: image

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?

https://github.com/frank-w/u-boot/commits/2022-10-r3