[BPI-R64] open source ATF


I forked Repo from MTK and we got ATF working for eMMC and SD. For install on emmc currently tftp is needed

I added build-script and some documentation

If anybody wants to try it out:

Currently i see this issue(s):

  • after reboot sdcard is not recognized by uboot, with old preloader+atf i have not this problem
  • write issues (slow down) in linux, unsure if it’s a linux/uboot/atf issue

For install see this

Regards Frank

1 Like

Nice work. Since I only boot the R64 from sd card, please let me know when
it works, thanks.

i got it booted with the help of @sam33

updated repo with bin for first 512 bytes of sdcard and instructions in README.md

have now added sdmmc build, emmc-header stripped from original gpt, gpt without the head, so we can use it for both devices

  • sd_header.bin + bpi-r64_headless.gpt + bl2_sdmmc.img + fip_sdmmc.bin
  • emmc_header.bin + bpi-r64_headless.gpt +fip_emmc.bin (and bl2_emmc.bin in boot0)

i recreated the kernel-partition named it BPI_BOOT (as FAT32 and resized to 100M) and added BPI-ROOT-Partiton.

updated also install-instructions to use the *_header.bin+headless gpt, this makes it also possible to leave own gpt and flash around it


just a small update: i have installed travis-ci for creating automatic build like for my kernel/uboot-repo. this also creates images which can be simply flashed to sdcard/emmc without struggling with offsets

for sdcard:

  • flash bpi-r64_sdmmc.img to offset 0 of sdcard, and create filesystems on kernel+root partition

for emmc:

  • flash bl2_emmc.img to boot0-block
  • flash bpi-r64_emmc.img to offset 0 of main hw partition (/dev/mmcblk0), and create filesystems on kernel+root partition

i hope this way it is as easy as possible…if you want to compile yourself maybe with own uboot/gpt you can use build.sh to archive same result

  • change build.conf to right device
  • ./build.sh
  • ./build.sh rename # renames bl2.img and fip.bin by adding device and put them in root-folder of repo
  • ./build.sh img

@sam33 we still have an issue on (software) reboot. Mmc is not recognized. Can you help here? Looks like mmc is somehow blocked…after switching to emmc and back i can load kernel from sdcard. Sometimes first access works (load of my uenv.txt) and second failes (kernel).

Also it looks like i have massive problems in linux reading sdcard when using new bootchain.

I am not familiar with emmc,
I will call our emmc owner for help…

Hi Frank, about software reboot issue, could you post boot log so we can see what actually happens here.

It looks like first file (my uenv.txt) can be loaded,but not the fit-image (mmc fail to send stop cmd). After switching to emmc and back i can load fit

CPU:   MediaTek MT7622                                                                                                                                                    
Model: mt7622-bpi-r64                                                                                                                                                     
DRAM:  1 GiB                                                                                                                                                              
WDT:   Started with servicing (60s timeout)                                                                                                                               
MMC:   mmc@11230000: 0, mmc@11240000: 1                                                                                                                                   
In:    serial@11002000                                                                                                                                                    
Out:   serial@11002000                                                                                                                                                    
Err:   serial@11002000                                                                                                                                                    
Warning: ethernet@1b100000 (eth0) using random MAC address - 1e:cb:35:4f:6a:74                                                                                            
eth0: ethernet@1b100000                                                                                                                                                   
Hit any key to stop autoboot:  0                                                                                                                                          
switch to partitions #0, OK                                                                                                                                               
mmc1 is current device                                                                                                                                                    
Boot from SD                                                                                                                                                              
88 bytes read in 1 ms (85.9 KiB/s) #my uenv.txt loaded from sdcard without problems
mmc fail to send stop cmd
mmc fail to send stop cmd
Error reading cluster
** Unable to read file bananapi/bpi-r64/linux/5.10.0-rc6.itb **
Failed to load 'bananapi/bpi-r64/linux/5.10.0-rc6.itb'
BPI-R64> mmc list
mmc@11230000: 0
mmc@11240000: 1 (SD)
BPI-R64> mmc dev 0 #switch to emmc
switch to partitions #0, OK
mmc0(part 0) is current device
BPI-R64> mmc dev 1                            #switch back to sdcard                                                                                                                            
switch to partitions #0, OK                                                                                                                                               
mmc1 is current device                                                                                                                                                    
BPI-R64> ls mmc 0:4                                                                                                                                                       
0 file(s), 1 dir(s)                                                                                                                                                       
BPI-R64> ls mmc 0:4 bananapi/bpi-r64/linux/                                                                                                                               
       28   uEnv.txt                                                                                                                                                      
 18019880   bpi-r64-5.4.77-main.itb                                                                                                                                       
2 file(s), 2 dir(s)                                                                                                                                                       
BPI-R64> fatload mmc 1:4 $kaddr bananapi/bpi-r64/linux/5.10.0-rc6.itb     #now try loading file from sdcard.                                                                                                
12764264 bytes read in 726 ms (16.8 MiB/s)                                                                                                                                

sometimes i can trigger this problem also in uboot (reset-command). one time i see this:

mmc fail to send stop cmd
mmc fail to send stop cmd
*** ERROR: Can't read GPT Entries ***
GPT: Failed to allocate memory for PTE
find_valid_gpt: *** ERROR: Invalid GPT ***
find_valid_gpt: ***        Using Backup GPT ***
12764264 bytes read in 728 ms (16.7 MiB/s)
## Loading kernel from FIT Image at 44000000 ...

Problem is sdcard,not emmc

It’s ok to manually load itb file via TFTP here on my board when first time boot from SD. I guess that the process of loading itb may break something such as pinctrl settings of SD host controller.

Could you provide the whole SD card image or the way you generate & install bpi-r64-5.4.77-main.itb in SD card so that I can reproduce your environment?

I have the write issue in linux also on old atf,but on new it look worse.

Reboot-issue i see only on new atf. Itb is created by my build.sh and uploaded to github releases.

It is installed to BPI_BOOT partition (p4 of my gpt) in bananapi/bpi-r64/linux and can be loaded adding a uEnv.txt in same folder with


I can upload my rootfs/image,but maybe there is something broken due to hard shutdowns while mmc-hangs

Well, it’s ok that mmc hangs. I just need to reproduce this issue and check a few settings.

have send you link to my image via PM because i have not cleaned it (only for testing). poweroff/reboot-command are broken (don’t know why because imho i created an busterimage for old ATF with these working). you need to use “systemctl reboot” or “systemctl poweroff”

write issue is reproducable also on old bootchain

root@bpi-r64:~# time dd status=progress if=/dev/urandom of=/tmp/test.dat bs=1M count=200 && time sync                                                                 
209715200 bytes (210 MB, 200 MiB) copied, 444 s, 472 kB/s                                                                                                             
200+0 records in                                                                                                                                                      
200+0 records out                                                                                                                                                     
209715200 bytes (210 MB, 200 MiB) copied, 904.514 s, 232 kB/s                                                                                                         
real    15m7.461s                                                                                                                                                     
user    0m0.043s                                                                                                                                                      
sys     0m52.568s                                                                                                                                                     
real    5m21.157s                                                                                                                                                     
user    0m0.009s                                                                                                                                                      
sys     0m0.341s                                                                                                                                                      

with new bootchain i do not see the progressbar and write-process cannot be cancedled or put in background

Hi Frank, just summarize what we discussed earlier:

  1. On your board, you use Samsung’s micro SD card (8GB, SDHC, class 6). But it’s not stable and each test result differed. You can replace it with a brand new one, if possible.
  2. Frank’s image runs well on my ADATA 32GB SDHC-I SD card(class 10, UHS-I) image
  3. mt7622 SD/mmc host controller doesn’t support SD-3.0 (UHS mode). You can see cap-sd-highspeed in dts, which means only supporting high-speed(SD-2.0):
&mmc1 {
	pinctrl-names = "default", "state_uhs";
	pinctrl-0 = <&sd0_pins_default>;
	pinctrl-1 = <&sd0_pins_uhs>; //we won't switch to this pin setting on mt7622
	status = "okay";
	bus-width = <4>;
	max-frequency = <50000000>;
	r_smpl = <1>;
	cd-gpios = <&pio 81 GPIO_ACTIVE_LOW>;
	vmmc-supply = <&reg_3p3v>;
	vqmmc-supply = <&reg_3p3v>;
	assigned-clocks = <&topckgen CLK_TOP_MSDC30_1_SEL>;
	assigned-clock-parents = <&topckgen CLK_TOP_UNIV48M>;
  1. Due to that other MTK platforms(chips) use the same driver (mtk-sd.c), we use two pinctrl groups for compatibility. However, pinctrl-1 settings are not supported on mt7622. We can see that if we set 3.3V for mmc1 in dts, we won’t switch to uhs pin settings:
/* Apply different pinctrl settings for different signal voltage */
if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
    pinctrl_select_state(host->pinctrl, host->pins_uhs);
    pinctrl_select_state(host->pinctrl, host->pins_default);
  1. I think it’s not appropriate to test bad sectors of SD cards with badblocks/fsck command. Since SD card’s internal controller(reference) hides real block mapping, you can’t detect all physical bad sectors inside SD cards. (similar discussion here)
1 Like

i tried to set uhs-mode by changing the vqmmc-supply and seems to be right, but real speed is still bad

--- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -232,10 +232,12 @@ &mmc1 {
        bus-width = <4>;
        max-frequency = <50000000>;
+       mmc-hs200-1_8v;
        r_smpl = <1>;
        cd-gpios = <&pio 81 GPIO_ACTIVE_LOW>;
        vmmc-supply = <&reg_3p3v>;
-       vqmmc-supply = <&reg_3p3v>;
+       vqmmc-supply = <&reg_1p8v>;
+       //vqmmc-supply = <&reg_3p3v>;
        assigned-clocks = <&topckgen CLK_TOP_MSDC30_1_SEL>;
        assigned-clock-parents = <&topckgen CLK_TOP_UNIV48M>;

--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1459,9 +1459,13 @@ static int msdc_ops_switch_volt(struct mmc_host *mmc, struct mmc_ios *ios)
                /* Apply different pinctrl settings for different signal voltage */
                if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
+               {
                        pinctrl_select_state(host->pinctrl, host->pins_uhs);
-               else
+                       dev_err(host->dev, "using uhs pins (%d)!\n",ios->signal_voltage);
+               } else {
                        pinctrl_select_state(host->pinctrl, host->pins_default);
+                       dev_err(host->dev, "using default pins (%d)!\n",ios->signal_voltage);
+               }
        return 0;

root@bpi-r64:~# dmesg | grep pins                                               
[    1.233061] mtk-msdc 11230000.mmc: using uhs pins (1)!                       
[    1.243422] mtk-msdc 11240000.mmc: using uhs pins (1)!                       
[    1.377499] mtk-msdc 11230000.mmc: using uhs pins (1)!

currently only writing 50MB, but this takes already 10 minutes

for emmc i see a message like this, but not for sdcard (maybe it’s related to dma):

[    1.374748] mtk-msdc 11230000.mmc: phase: [map:fffffff] [maxlen:28] [final:9]

i think i’ve fixed it by adding reset to sdcard-controller like emmc (new bootchain/ATF+FIT of 5.11-rc1)


But with other const


root@bpi-r64:~# dd status=progress if=/dev/urandom of=/tmp/test.dat bs=1M count=200 && time sync
200+0 records in                                                                
200+0 records out                                                               
209715200 bytes (210 MB, 200 MiB) copied, 4.33725 s, 48.4 MB/s                  
real    0m4.348s                                                                
user    0m0.000s                                                                
sys     0m4.301s                                                                
real    0m15.774s                                                               
user    0m0.000s                                                                
sys     0m0.027s                                                                

so additional to patch above (change to uhs by set vqmmc-supply)

--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -698,6 +698,8 @@ mmc1: mmc@11240000 {
                clocks = <&pericfg CLK_PERI_MSDC30_1_PD>,
                         <&topckgen CLK_TOP_AXI_SEL>;
                clock-names = "source", "hclk";
+               resets = <&pericfg MT7622_PERI_MSDC1_SW_RST>;
+               reset-names = "hrst";
                status = "disabled";

@skype @onlyfly34 can you confirm this? I guess uboot sets any wrong mode not compatible to linux initialization like for emmc

Posted patch without debug in driver to mailinglist

Not sure if regulator on BPI R64 connected to mmc1 can switch between 1.8V and 3.3V or not. But even if 1.8V is supported, mmc1’s bus speed can only operate at 48M at most. (This is HW limitation.) That means, even if you switch to “UHS-1 mode”, you still get “high-speed mode” bus speed.

Not to mention that mmc1 pins only support 3.3V.

So I think that original setting for mmc1 is enough.

BTW, my ADATA UFS-I card can still operate with this host controller because it supports to run at high-speed mode.

At least the reset was needed to fix the extrem slow speed.

My thought was why define the uhs pins if they cannot work, so i only have activated them :slight_smile:

i just added the following code to the device tree, and now this problem has been solved.

resets = <&pericfg MT7622_PERI_MSDC1_SW_RST>;
reset-names = "hrst";

thanks for testing, got response on mailinglist, that mt7622 does not support uhs1-mode so i dropped that change and posted v2

btw. i’ve updated uboot to 2021-01 and ATF source to 2.4 in separate branch for testing…did only a quick bootup

1 Like

what has been modified by uboot and atf, I will test it in the next few days.

Only update

The default branch is ATF 2.2,upgraded to more recent 2.4. Uboot is already 2021-01, source in my uboot repo

btw. upcoming 2021-04 contains 2 timing Patches related to mt7622/r64:

maybe these fixing rootcause of sdcard-problems, you can try these without my reset-patch in linux if you have time :slight_smile: