imho he does not build uboot with atf…atf is flashed separately to storage.
If you want to stay on bpi atf (to load 64bit kernel in 32bit container) you can try rays patch-config to build 32bit uboot. You find it also on my repo…
imho he does not build uboot with atf…atf is flashed separately to storage.
If you want to stay on bpi atf (to load 64bit kernel in 32bit container) you can try rays patch-config to build 32bit uboot. You find it also on my repo…
i uploaded 2020-04-rc1 with changes for r2/r64 (change board in build.conf) to my uboot-repo (branch 2020-04-bpi-all).
disabled binman_fdt due to the boot-error (have not got any response to bug-report yet)
my fix for mtk-eth-driver (warnings if built for aarch64) and mt7622 ethernet-support-patches (without switch) are merged.
got response from simon regarding the binman-issue…i guess we need something like this:
but i do not know what are the right files for r64…maybe an empty binman-node is enough, cause breaking code only looks for binman-node, but not for its content
Edit february 16th: Good news: i’ve got uboot ethernet driver from landen chao and on my quick tests it is working well on r64 (and r2)
Btw. Also r2 is affected from binman-issue so i have disabled it there too
edit february 23: @sam33 posted a series adding pwm-support and fixing binman-issue
added this series to current state (including mt7531 driver) and reverting my changes to defconfig regarding binman
submitted patch:
https://patchwork.ozlabs.org/patch/1242081/
https://patchwork.ozlabs.org/patch/1242083/
diff --git a/arch/arm/dts/mt7622-rfb.dts b/arch/arm/dts/mt7622-rfb.dts
index 05502bddec..165496e8d9 100644
--- a/arch/arm/dts/mt7622-rfb.dts
+++ b/arch/arm/dts/mt7622-rfb.dts
@@ -69,6 +69,13 @@
};
};
+ pwm_pins: pwm1 {
+ mux {
+ function = "pwm";
+ groups = "pwm_ch1_0" ;
+ };
+ };
+
watchdog_pins: watchdog-default {
mux {
function = "watchdog";
@@ -155,6 +162,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_pins>;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_default>;
In this example, we use bpir64 pin 11 (UART1-TXD/GPIO51/TXD2/PWM_CH1) as PWM channel 1 (pwm_id=0), and connect this pin to a LED.
pwm 0 config 1000000000 500000000
pwm 0 enable
LED on (0.5 seconds) --> LED off (0.5 seconds) --> LED on (0.5 seconds) --> …
diff --git a/cmd/pwm.c b/cmd/pwm.c
new file mode 100644
index 0000000000..efd2f4590d
--- /dev/null
+++ b/cmd/pwm.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Sam Shih <[email protected]>
+ */
+
+#include <common.h>
+#include <command.h>
+#include <dm.h>
+#include <pwm.h>
+#include <dm/uclass-internal.h>
+
+int do_pwm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct udevice *dev;
+ unsigned long pwm_id, period, duty;
+
+ if (uclass_get_device(UCLASS_PWM, 0, &dev)) {
+ printf("unable to find pwm driver\n");
+ return CMD_RET_FAILURE;
+ }
+ if (argc < 2)
+ return CMD_RET_USAGE;
+ pwm_id = simple_strtoul(argv[1], NULL, 0);
+
+ if (strncmp(argv[2], "config", 10) == 0) {
+ if (argc < 4)
+ return CMD_RET_USAGE;
+ period = simple_strtoul(argv[3], NULL, 0);
+ duty = simple_strtoul(argv[4], NULL, 0);
+ if (pwm_set_config(dev, pwm_id, period, duty)) {
+ printf("unable to config pwm driver\n");
+ return CMD_RET_FAILURE;
+ }
+ }
+ else if (strncmp(argv[2], "enable", 10) == 0) {
+ pwm_set_enable(dev, pwm_id, true);
+ }
+ else if (strncmp(argv[2], "disable", 10) == 0) {
+ pwm_set_enable(dev, pwm_id, false);
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ pwm, 5, 1, do_pwm,
+ "manage PWMs\n",
+ "<pwm_id> [config|enable|disable]\n"
+ "config: <pwm_id> config <period_in_ns> <duty_in_ns>\n"
+ "enable: <pwm_id> enable\n"
+ "disable: <pwm_id> disable\n"
+);
After i changed the right dts pwm is working (~1s blinking), using pins 9 (gnd)+11 (pwm)
maybe you can help adding the other pwm in linux dts?
Hi Sam, Would you please provide a ATF file just for 64bit u-boot, regardless of whether the WPS key is pressed or not? Thank you a lot !
why do you need this? sams ATF is capable for booting 64bit uboot without WPS-button press, so you can boot 64bit uboot…
i only need the reverse way (default 32 with jumparch64,wps => 64), @sam33 can you post it to me? so i’m able to test 64bit-mode too and do not break current 32bit-uboot-behaviour
I am debugging another custom board of mt7622. The WPS button on this board has other uses. The initial value on this pin is not sure.
Hi Frank, I got ATF file which you want from MTK, please try it.mt7622_atf_push_wps_uboot_64.img (61.1 KB)
hi,
thank you for the ATF
made a quick test…boots 32bit-uboot like the BPI-ATF and contains the jumparch64-target to load 64bit kernel from 32bit uImage (build by mkimage -a armhf). also tried booting with WPS-Button (left from Ethernet-Ports) and it does not load 32bit uboot…like i expected…need to find some time to flash 64bit uboot (have not much time currently because of SARS-CoV2 Limitations - 2 kids at home).
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.
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.
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
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)
hi sam, there is a Patch for pwm command in uboot mainlinglist…is this compatible to mtk pwm-driver?
btw. have you seen ATF-issue (mmc not recognized on reboot) i wrote you via PM?
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).
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
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
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)
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:
@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:
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
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:
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.