BPI-R64 current u-boot support

cafebabe · May 1, 2020, 9:35pm

Hi guys, could someone please explain how to run u-boot 64 bits on bpi-r64 ? I built frank-w branch 2020-04-bpi-all like this: changed build.conf board=bpi-r64 arch=arm64

./build.sh defconfig
./build.sh build
./build.sh install

I used an empty SD and flashed u-boot-mkt.bin at offset 768 thanks to last command.

I then got ATF BPI-R64 current u-boot support and flashed it as said here: BPI-R64 current u-boot support at offset 512.

Boot serial log:

F0: 102B 0000    
F6: 3800 00A0    
F3: 4000 0036    
F5: 4801 0000    
F5: 480A 0031    
00: 1005 0000    
F6: 3800 00A0    
F3: 4000 0036    
F5: 480A 0031    
F5: 480A 0031    
01: 102A 0001    
02: 1005 0000    
BP: 0000 00C0 [0001]    
T0: 0000 035E [000F]    
System halt!

I also have a clearfog gt-8k that runs u-boot 64bits without issue but the build process wraps u-boot with atf so I’m not sure I can apply this approach to this board. (see https://developer.solid-run.com/knowledge-base/armada-8040-machiatobin-u-boot-and-atf/) Thanks for help.

cafebabe · May 1, 2020, 11:44pm

I realized I was missing the preloader. I dded the first 512k of the official 4.19 image and added them just before ATF, looks like it worked:

[BLDR] Others, jump to ATF    

[BLDR] jump to 0x41E00000    
[BLDR] <0x41E00000>=0x1400000A    
[BLDR] <0x41E00004>=0xD503201F    


U-Boot 2020.04-rc2-bpi-all-10605-g0542be266c-dirty (May 01 2020 - 21:12:17 +0200)    

CPU:   MediaTek MT7622    
Model: mt7622-rfb    
DRAM:  256 MiB    
WDT:   Started with servicing (60s timeout)    
MMC:   mmc@11230000: 0, mmc@11240000: 1    
In:    serial@11002000    
Out:   serial@11002000    
Err:   serial@11002000    
Net:   error: unsupported switch    
No ethernet found.    

MT7622>

But I have the issue about RAM and switch so I’ll dig the patches. Thanks.

frank-w · May 2, 2020, 5:44am

The ram issue is caused by memory-node in ref-board dts…take a look to the bpi-r64 dts i used for 32bit mode to change it

For 64bit-mode you need a different atf like this: BPI-R64 current u-boot support preloader is same and you need to change arch in build.conf (i guess you already did). And you can use the 2020-04-bpi tree that should include some more patches (bpi-all was afair test-tree i uploaded accidentially) also switch-driver

frank-w · May 2, 2020, 2:03pm

xhci-driver itself is on the way to be merged but has no support for r2/r64 yet…support is reported to get added after base driver is merged

for r2 i know that driver in current state does not support xhci version below 1 (r2 has 0.96). for r64 i have a probe-error where i do not know where it happen (can be ssusbsys,xhci itself…checked both, but seem to happen anywhere else)

frank-w · December 19, 2020, 2:31pm

hi sam, there is a Patch for pwm command in uboot mainlinglist…is this compatible to mtk pwm-driver?

“cmd: Add a pwm command”

btw. have you seen ATF-issue (mmc not recognized on reboot) i wrote you via PM?

dangowrt · March 9, 2021, 12:39am

Did you ever get USB to work in U-Boot? I get the driver to load and probe ports, but never detect any storage devices (in Linux works fine).

frank-w · March 9, 2021, 6:25am

I got usb working on r2 and r64 with the patches i send upstream. But have not tested recent versions again

Should be these patches: https://github.com/frank-w/u-boot/commits/2020-10-upstream

To get uboot to work there were additional patches from chunfeng yun needed to add xhci 0.96 support. See the bpi branch

Output of tests in my wiki

https://www.fw-web.de/dokuwiki/doku.php?id=en/bpi-r2/uboot#usb

https://www.fw-web.de/dokuwiki/doku.php?id=en/bpi-r64/uboot#usb

And here in forum

dangowrt · March 11, 2021, 4:59pm

I’ve updated the U-Boot build for MediaTek targets in OpenWrt to U-Boot 2021.04-rc3 with patches from MediaTek on top. I’ve checked and the USB patches you mentioned, both yours and Chunfeng’s, have already been merged and made it into that version. Yet USB still doesn’t detect any devices. I suspect that switching to build for 64-bit may have broken things… Apart from that it now works great, @hackpascal had to help me to fix MMC a bit, but now it’s even fast

frank-w · March 11, 2021, 5:17pm

Yes they are already merged (imho 2020-10 only misses the xhci 0.96 patches,my dts were already in)

I had not tested it after changing to new bootchain…my tests were done with 32bit version. Maybe dts needs to be changed for 64bit-mode?

What problems do you have with mmc? Which patch fixes mmc?

edit made a quick test for USB on my R64 v1.1:

NOTICE:  BL2: v2.4(release):v2.4-15-g54397dca8
NOTICE:  BL2: Built : 19:09:59, Jan 15 2021
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.4(release):v2.4-15-g54397dca8
NOTICE:  BL31: Built : 19:10:01, Jan 15 2021
                                                                                
                                                                                
U-Boot 2021.01-bpi (Jan 13 2021 - 19:46:11 +0100)                               
                                                                                
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                                                          
Net:                                                                            
Warning: ethernet@1b100000 (eth0) using random MAC address - aa:ae:96:0b:a1:f7  
eth0: ethernet@1b100000                                                         
Hit any key to stop autoboot:  0                                                
switch to partitions #0, OK                                                     
mmc1 is current device                                                          
Boot from SD                                                                    
2bd17853-102b-4500-aa1a-8a21d4d7984d                                            
success!                                                                        
362 bytes read in 3 ms (117.2 KiB/s)                                            


  *** U-Boot Boot Menu ***

     1. Enter kernel-name to boot from SD/EMMC.
     2. Boot kernel from TFTP.
     3. Boot from SD/EMMC.
     U-Boot console


  Press UP/DOWN to move, ENTER to select

BPI-R64> usb start
starting USB...
Bus usb@1a0c0000: xhci-mtk usb@1a0c0000: hcd: 0x000000001a0c0000, ippc: 0x000000
xhci-mtk usb@1a0c0000: u2p:2, u3p:1
Register 300010f NbrPorts 3
Starting the controller
USB XHCI 0.96
scanning bus usb@1a0c0000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
BPI-R64> ls usb 0:1
            efi/
  1023582   ramdisk.img
  1365903   initrd.img
  2956137   install.img
 456908800   system.sfs
  4767728   kernel

5 file(s), 1 dir(s)

BPI-R64>

as you can see USB is working…maybe you miss only a config-option for mass storage devices (see last option)

github.com

frank-w/u-boot/blob/2021-01-bpi/configs/mt7622_bpi-r64_defconfig#L107


CONFIG_SCSI_AHCI=y
CONFIG_SCSI=y
CONFIG_CMD_SCSI=y
CONFIG_PHY=y
CONFIG_PHY_MTK_TPHY=y
CONFIG_MTK_AHCI=y


CONFIG_CMD_GPT=y
CONFIG_SUPPORT_EMMC_BOOT=y


CONFIG_DM_USB=y
CONFIG_DM_REGULATOR=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_MTK=y
CONFIG_CMD_USB=y
CONFIG_USB_STORAGE=y

dangowrt · March 11, 2021, 7:56pm

I got all the config options selected in the OpenWrt-build as well, see the defconfigs I create for eMMC and SD Card boot variants:

github.com

openwrt/openwrt/blob/9dfc2b3ca4dff28259576e21bc3ade910ff52a05/package/boot/uboot-mediatek/patches/403-add-bananapi_bpi-r64_defconfigs.patch

--- /dev/null
+++ b/configs/mt7622_bananapi_bpi-r64-sdmmc_defconfig
@@ -0,0 +1,124 @@
+CONFIG_ARM=y
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_ARCH_MEDIATEK=y
+CONFIG_SYS_TEXT_BASE=0x41e00000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_USE_DEFAULT_ENV_FILE=y
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0x11002000
+CONFIG_DEBUG_UART_CLOCK=25000000
+CONFIG_DEFAULT_DEVICE_TREE="mt7622-bananapi-bpi-r64"
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_ENV_FILE="bananapi_bpi-r64-sdmmc_env"
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SMBIOS_PRODUCT_NAME=""
+CONFIG_AUTOBOOT_KEYED=y

This file has been truncated. show original

@hackpascal figured out that MMC was broken recently by

So I’m reverting that. So also get SD Card back to work I always had to lower the max. clock to 12MHz as otherwise (at least with the no-name card I got here) things wouldn’t work. See the DTS changes I’m using for the Bananapi BPi-R64 with U-Boot:

github.com

openwrt/openwrt/blob/9dfc2b3ca4dff28259576e21bc3ade910ff52a05/package/boot/uboot-mediatek/patches/402-update-bananapi-bpi-r64-device-tree.patch

--- a/arch/arm/dts/mt7622-bananapi-bpi-r64.dts
+++ b/arch/arm/dts/mt7622-bananapi-bpi-r64.dts
@@ -20,6 +20,7 @@
 
 	aliases {
 		spi0 = &snfi;
+		ethernet0 = &eth;
 	};
 
 	memory@40000000 {
@@ -27,6 +28,42 @@
 		reg = <0x40000000 0x40000000>;
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		reset {
+			label = "reset";
+			gpios = <&gpio 0 GPIO_ACTIVE_LOW>;

This file has been truncated. show original

Limiting the max. clock frequency of the MMC bus used for the SD Card, however, was no longer possible after commit

So I had to fix that and made a patch

github.com

openwrt/openwrt/blob/9dfc2b3ca4dff28259576e21bc3ade910ff52a05/package/boot/uboot-mediatek/patches/000-mtk-21-mmc-mtk-sd-don-t-ignore-max-frequency-from-device-tr.patch

From 4bdab0ea008113dda4e001ab8d6863945000c1b2 Mon Sep 17 00:00:00 2001
From: Daniel Golle <[email protected]>
Date: Thu, 11 Mar 2021 14:58:26 +0000
Subject: [PATCH 21/21] mmc: mtk-sd: don't ignore max-frequency from device
 tree

commit e58e68d9 ("mmc: mtk-sd: assign plat->cfg.f_max with a correct value")
wrongly assumed that plat->cfg.f_max is always unset at the time
mscd_drv_probe() is run. This is not true in case max-frequency being
defined in device tree, as it is then already set by mmc_of_parser()
in msdc_of_to_plat().
Only set plat->cfg.f_max to the default maximum value in case it is
not already set to a sane value.

Signed-off-by: Daniel Golle <[email protected]>
---
 drivers/mmc/mtk-sd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/mmc/mtk-sd.c

This file has been truncated. show original

So that now all works. Just USB still doesn’t. As all that is part of OpenWrt, it should be easy for everyone to build everything from source themselves and (hopefully) help improving and fixing things where ever needed.

What I still miss in U-Boot right how:

USB edit: 2.0 working well enough to allow UEFI USB boot by default (for MemTest86 and such, already works fine on MMC). USB controller is detected, but USB 2.0 devices are not detected:

MT7622> usb start
starting USB...
Bus usb@1a0c0000: xhci-mtk usb@1a0c0000: hcd: 0x000000001a0c0000, ippc: 0x000000001a0c4700
xhci-mtk usb@1a0c0000: ports disabled mask: u3p-0x0, u2p-0x0
xhci-mtk usb@1a0c0000: u2p:2, u3p:1
Register 300010f NbrPorts 3
Starting the controller
USB XHCI 0.96
scanning bus usb@1a0c0000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

(that 1 USB Device which is found is the root hub and is always there, no matter if an actual USB device is plugged in or not)

PSTORE (formally/also known as ramoops) working with Linux and U-Boot. As hard reset through SoC reset controller also re-initializes the DDR controller, RAM content gets corrupted by crash/oops/reboot. Implementing reset through ATF pcsc for Linux to use rather than triggering register may be a good work-around.

frank-w · March 11, 2021, 8:07pm

Maybe you can try 2021-01 for usb. I guess something in 2021-04 breaks it…as you see in my log usb works with my 2021-01

dangowrt · March 11, 2021, 8:23pm

Do you actually try with a USB 3.0 device? Because that also works for me, just non-USB-3.0 devices don’t (they do work in Linux, of course)

frank-w · March 11, 2021, 9:46pm

I used an usb2.0 stick for testing

dangowrt · March 12, 2021, 12:32am

I got it working. Was some other CONFIG option missing, I enabled everything which could remotely make sense and now it all works:

frank-w · March 12, 2021, 11:40am

I wonder why usb3 was not working but usb2 before…the only related you’ve added should be tphy (also sata depends on it) and CONFIG_TARGET_MT7622

Ryder.Lee · March 12, 2021, 12:20pm

Great. Will you post those fixups to mainline uboot?

dangowrt · March 12, 2021, 1:53pm

Yes, I suspect either TPHY or DM_GPIO being the cause, I was too tired to isolate it at the point I got it working.

dangowrt · March 12, 2021, 2:55pm

The only fix relevant for upstream makes changes on top of https://github.com/mtk-openwrt/u-boot , hence it’d be great if @hackpascal would squash that one into his series:

github.com

openwrt/openwrt/blob/master/package/boot/uboot-mediatek/patches/000-mtk-21-mmc-mtk-sd-don-t-ignore-max-frequency-from-device-tr.patch

From 4bdab0ea008113dda4e001ab8d6863945000c1b2 Mon Sep 17 00:00:00 2001
From: Daniel Golle <[email protected]>
Date: Thu, 11 Mar 2021 14:58:26 +0000
Subject: [PATCH 21/21] mmc: mtk-sd: don't ignore max-frequency from device
 tree

commit e58e68d9 ("mmc: mtk-sd: assign plat->cfg.f_max with a correct value")
wrongly assumed that plat->cfg.f_max is always unset at the time
mscd_drv_probe() is run. This is not true in case max-frequency being
defined in device tree, as it is then already set by mmc_of_parser()
in msdc_of_to_plat().
Only set plat->cfg.f_max to the default maximum value in case it is
not already set to a sane value.

Signed-off-by: Daniel Golle <[email protected]>
---
 drivers/mmc/mtk-sd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/mmc/mtk-sd.c

This file has been truncated. show original

I’m not sure whether just reverting is an option for upstream or if we have to find a better fix for

github.com

openwrt/openwrt/blob/master/package/boot/uboot-mediatek/patches/000-mtk-01-Revert-clk-Add-debugging-for-return-values.patch

From 5efb7855a9d33ac897d6e2a7117e4e3d35d433a5 Mon Sep 17 00:00:00 2001
From: Daniel Golle <[email protected]>
Date: Thu, 11 Mar 2021 10:28:53 +0000
Subject: [PATCH 01/21] Revert "clk: Add debugging for return values"

This reverts commit 5c5992cb90cf9ca4d51e38d9a95a13c293904df5.
---
 drivers/clk/clk-uclass.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -84,7 +84,7 @@ static int clk_get_by_index_tail(int ret
 	if (ret) {
 		debug("%s: uclass_get_device_by_of_offset failed: err=%d\n",
 		      __func__, ret);
-		return log_msg_ret("get", ret);
+		return ret;
 	}

This file has been truncated. show original

(ie. introducing uint64_t log_msg_ret64(char *, uint64_t) would be the proper fix, I guess)

Regarding DTS for BPi-R64 (outdated in U-Boot tree) and default config (missing), @frank-w had been working on that before and I’m not sure what their plans are, if there is going to be a re-spin with fixes for upcoming U-Boot 2021.04:

frank-w · March 12, 2021, 2:58pm

upstream DTS should be same as mine except the mmc-change

I’m not sure using 64bit function/pointer here as this is used for 32 bit too (clk core)

Do you got a (silent) crash without revert? I do not fully understand macro

https://elixir.bootlin.com/u-boot/latest/source/include/log.h#L305

It should return the ret passed to it,i guess it’s the last line (_ret without anything else)

dangowrt · March 12, 2021, 10:04pm

I’ve added LEDs and buttons, had to lower MMC frequency to make SD Card work reliable (at least for the card I got here) and added the ethernet0 alias to make U-Boot pass down ethaddr to Linux. Should I send a patch for that you reckon?