GPIO 90 is connected to Asmedia chip which is used to switch between PCIe@1,0 and SATA functions. i.e. output-high: PCIe, output-low: SATA. Below is my way to set GPIO90 to high for your reference, thanks.
pcie_sata_mux_pin_default: pcie_stat_mux_default {
pins_gpio90 {
pinmux = <MT7622_PIN_90_AUXIN3__FUNC_GPIO90>;
output-high;
};
};Yes, I know that. I use gpio-hog for that:
asm_sel {
gpio-hog;
gpios = <90 GPIO_ACTIVE_HIGH>;
output-high;
};
But I want to make a way, to switch that function any time (PCI-E/SATA/SATA-in-PCI-E-slot).
But GPIO90, even whole group 87-90, behave weird. So I want to know:
Currently I see preloader can set that pin, but from u-boot I can’t.
Maybe, you can give me source of GPIO control of preloader? Think it is not much secret thing 
AUXIN0 pin = gpio87
AUXIN1 pin = gpio88
AUXIN2 pin = gpio89
AUXIN3 pin = gpio90
and default value of 0x10211CF0 [GPIO_G4_MISC] is 0000000C.
bit3: AUX IN3 AGPIO Digital Pad Enable bit2: AUXIN2 AGPIO Digital Pad Enable bit1: AUXIN1 AGPIO Digital Pad Enable bit0: AUXIN0 AGPIO Digital Pad Enable 0: Disabled 1: Enabled
so you need to set 0x10211CF0[3:0]=0’b1111 if you want to make gpio87-90 can work at gpio mode, thanks.
Thanks a lot, @moore!
I’m tried, still no luck with read back.
But I did test, that makes me sure it works:
U-Boot MT7622> gpio clear 90
gpio: pin 90 (gpio 90) value is 0
U-Boot MT7622> gpio set 90
gpio: pin 90 (gpio 90) value is 1
Warning: value of pin is still 0
U-Boot MT7622> gpio clear 90
gpio: pin 90 (gpio 90) value is 0
U-Boot MT7622> scsi scan
Let’s hope we have only two states :)))))
@sinovoip do you able to use PCI-E (not USB with pcie connector) device in pcie1 slot?
I can’t find any proofs that this works for anybody.
Thanks!
UPD: @frank-w tested it and got working module on both slots.
With same SD image my two cards (SATA and WiFi) detected in 1st slot, but not in second 
have tried now a fullsize card and got same issue like you…it’s recognized on cn25 but not on cn8
if no card is inserted or card is inserted in cn8 lspci does not show pcie host controller, if card is inserted in cn25 i got this output
root@bpi-r64:~# lspci
00:00.0 PCI bridge: MEDIATEK Corp. Device 3258
01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Netr
root@bpi-r64:~#
i think at least the first entry should be listed if no card is inserted or card in cn8
if i insert a halfsize-card (intel wifi card with model number: 633ANHMW) in the cn8 it is recognized:
root@bpi-r64:~# lspci
00:01.0 PCI bridge: MEDIATEK Corp. Device 3258
01:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
root@bpi-r64:~#
i wonder why pci-bus of the card is same as above because it’s the other slot and pcie-controller bus address differs
but i think we should create a new topic for this pcie-issue
will submit it before 12/E
Hi ray,
Due to mt7622 hardware is different from others SoC like mt7629/mt7623…
(mt7622 gpio pinmux function in pinctrl registers is mode 1, not mode 0 )
So we need to upgrade the common part of mediatek pinctrl to fix this problem.
I’ve been busy recently and I just finished patches today,
We still working on ethernet and mediatek switch.
https://patchwork.ozlabs.org/project/uboot/list/?series=146912
Hi Sam,
yeah, got it while ago. But did not help. Maybe your pinctrl patches will help.
@sam33 @moore @Ryder.Lee can’t get it, why are you guys using FDT as local config for u-boot, instead of put it full and pass to kernel?
Thanks!
Patches based on this series: http://patchwork.ozlabs.org/cover/1191085/
have applied them to this tree for testing (build.sh not yet changed to support r64):
compiled it with aarch64 crosscompiler works except warning about CONFIG_OF_EMBED (Please use CONFIG_OF_SEPARATE for boards in mainline), tried booting it via my 2014 uboot over tftp results in crash
BPI-R64> setenv ufile u-boot_2020.01-rc4-bpi-r64-v1.bin
BPI-R64> run ubootnet
ETH already turn on and power on flow will be skipped...
Waitting for RX_DMA_BUSY status Start... done
mt7531: mt7531_sw_init
mt7531: mt7531_core_pll_setup, hwstrap = 000000ff
mt7531: mt7531_mac_port_setup, port = 6
mt7531: mt7531_set_port_sgmii_force_mode, port = 6
mt7531: timeout waiting for SGMII_LINK
mt7531: mt7531_mac_port_setup, PMCR6 = f805633b
0x1b000014 = 0x00110214
Using mtk_eth device
TFTP from server 192.168.0.10; our IP address is 192.168.0.19
Filename 'u-boot_2020.01-rc4-bpi-r64-v1.bin'.
Load address: 0x41dffe00
Loading: T ################################
85.9 KiB/s
done
Bytes transferred = 463504 (71290 hex)
get filesize 0x71290
## Starting application at 0x41E00000 ...
data abort
pc : [<41e0000c>] lr : [<7ef3bc48>]
sp : 7cf32be0 ip : 00000030 fp : 7ef3bbfc
r10: 00000002 r9 : 7cf32f40 r8 : 7cf36e88
r7 : 7ef7883c r6 : 41e00000 r5 : 00000002 r4 : 7cf36e8c
r3 : 41e00000 r2 : 7cf36e8c r1 : 7cf36e8c r0 : 00000001
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
is this caused by loading the 64bit uboot out of a 32bit (armhf) one?
The 2014 u-boot is 32bits, I think loading an 64 bits u-boot binary to dram, and running in 32 bits CPU mode will cause unexpected results…
I will send our ATF image for upstream u-boot to you in a few days, this ATF image is able to start u-boot in 64 bits CPU mode (default: stating 64 bits u-boot, and can keep holding the WPS button during boot-up to start 32 bits u-boot)
We use CONFIG_OF_EMBED for debug, and forgot to disable it in mt7622 rfb defconfig, But I haven’t tested that it can work with CONFIG_OF_SEPARATE or not
if i understand you right, currently we cannot test uboot due to missing ATF right? can i change arch in uboot before calling go command (after loading the binary)? currently i don’t want to flash it because i need ethernet-support for kernel-testing
I think it is hard to change 32/64 bits in u-boot from my limited knowledge of Arm Cortex-A53.
If we want to change 32/64 bits cpu instruction set, We should use SPSR_EL3 registers to do that.
This register can only be used under ARM Secured World, In our case here, only ATF and pre-loader
are running in the Secured World.
mhm, seems like our ATF does not support 64bit uboot…
F0: 102B 0000
F5: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
T0: 0000 03BB [000F]
Jump to BL
UNIVPLL_CON0 = 0xFE000000!!!
mt_pll_init: Set pll frequency for 25M crystal
[PMIC_WRAP]wrap_init pass,the return value=0.
[pmic_init] Preloader Start..................
[pmic_init] MT6380 CHIP Code, reg_val = 0, 1:E2 0:E3
[pmic_init] Done...................
Chip part number:7622A
MT7622 Version: 1.2.7, (iPA)
SSC OFF
mt_pll_post_init: mt_get_cpu_freq = 1350000Khz
mt_pll_post_init: mt_get_mem_freq = 1600000Khz
mt_pll_post_init: mt_get_bus_freq = 1119920Khz
[PLFM] Init I2C: OK(0)
[BLDR] Build Time: 20181123-214255
==== Dump RGU Reg ========
RGU MODE: 4D
RGU LENGTH: FFE0
RGU STA: 0
RGU INTERVAL: FFF
RGU SWSYSRST: 8000
==== Dump RGU Reg End ====
RGU: g_rgu_satus:0
mtk_wdt_mode_config mode value=10, tmp:22000010
PL P ON
WDT does not trigger reboot
WDT NONRST=0x20000000
WDT IRQ_EN=0x340003
RGU mtk_wdt_init:MTK_WDT_DEBUG_CTL(590200F3)
[EMI] MDL number = 2
[EMI] DRAMC calibration start
[EMI] DRAMC calibration end
[EMI]rank0 size: 0x40000000
[MEM] complex R/W mem test pass
RAM_CONSOLE wdt status (0x0)=0x0
[mmc_init]: msdc1 start mmc_init_host() in PL...
[msdc_init]: msdc1 Host controller intialization start
[SD1] Pins mode(1), none(0), down(1), up(2), keep(3)
[SD1] Pins mode(2), none(0), down(1), up(2), keep(3)
[info][msdc_config_clksrc] input clock is 200000kHz
[SD1] Bus Width: 1
[info][msdc_config_clksrc] input clock is 200000kHz
[SD1] SET_CLK(260kHz): SCLK(259kHz) MODE(0) DDR(0) DIV(193) DS(0) RS(0)
[msdc_init]: msdc1 Host controller intialization done
[mmc_init]: msdc1 start mmc_init_card() in PL...
[mmc_init_card]: start
[SD1] Bus Width: 4
[SD1] Size: 30436 MB, Max.Speed: 25000 kHz, blklen(512), nblks(62333952), ro(0)
[mmc_init_mem_card 3140][SD1] Initialized, SD10
before host->cur_bus_clk(259067)
[info][msdc_config_clksrc] input clock is 200000kHz
[SD1] SET_CLK(25000kHz): SCLK(25000kHz) MODE(0) DDR(0) DIV(2) DS(0) RS(0)
host->cur_bus_clk(25000000)
[mmc_init_card]: finish successfully
[PLFM] Init Boot Device: OK(0)
[GPT_PL](BPI)Parsing Primary GPT now...
[GPT_PL]check header, err(signature 0x00000054594C5242!=0x5452415020494645)
[GPT_PL]Success to find valid GPT.
[PART] blksz: 512B
[PART] [0x0000000000020000-0x000000000007FFFF] "preloader" (768 blocks)
[PART] [0x0000000000080000-0x00000000000BFFFF] "tee1" (512 blocks)
[PART] [0x00000000000C0000-0x000000000013FFFF] "lk" (1024 blocks)
Device APC domain init setup:
Domain Setup (0x0)
Domain Setup (0x0)
Device APC domain after setup:
Domain Setup (0x0)
Domain Setup (0x0)
[get_part] part->nr_sects=768, part->info->name=preloader
[get_part] part->nr_sects=512, part->info->name=tee1
[get_part] part->nr_sects=1024, part->info->name=lk
[PART] Image with part header
[PART] name : U-Boot
[PART] addr : 41E00000h mode : -1
[PART] size : 462976
[PART] magic: 58881688h
[PART] load "lk" from 0x00000000000C0200 (dev) to 0x41E00000 (mem) [SUCCESS]
[PART] load speed: 3532KB/s, 462976 bytes, 128ms
load lk (ret=0)
[get_part] part->nr_sects=768, part->info->name=preloader
[get_part] part->nr_sects=512, part->info->name=tee1
[PART] Image with part header
[PART] name : atf
[PART] addr : FFFFFFFFh mode : -1
[PART] size : 62032
[PART] magic: 58881688h
[PART] load "tee1" from 0x0000000000080200 (dev) to 0x43000DC0 (mem) [SUCCESS]
[PART] load speed: 2752KB/s, 62032 bytes, 22ms
load tee1 (ret=0)
[BLDR] bldr load tee part ret=0x0, addr=0x43001000
[get_part] part->nr_sects=768, part->info->name=preloader
[get_part] part->nr_sects=512, part->info->name=tee1
[get_part] part->nr_sects=1024, part->info->name=lk
[BLDR] boot part. not found
[BLDR] part_load_images ret=0x0
[BLDR] Others, jump to ATF
[BLDR] jump to 0x41E00000
[BLDR] <0x41E00000>=0x1400000A
[BLDR] <0x41E00004>=0xD503201FSeems that part is for me
Maybe linux even start with such limited tree, but w/o USB/PCI/Ethernet.
Idea to use FDT is just like PCs use ACPI. You don’t need own copy of ACPI ASL for each PC model. Bootloader (BIOS) pass it to OS. It just works and every modern OS parse it and find where is UART/PCI-RC/watchdog/etc.
i tried using the existing jump64smc function to load 64bit uboot binary from old uboot over tftp
this my quick&dirty way (uboot 2014-04):
diff --git a/common/cmd_boot.c b/common/cmd_boot.c
index 8f2e0701b5..540f504d34 100644
--- a/common/cmd_boot.c
+++ b/common/cmd_boot.c
@@ -45,6 +45,17 @@ static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
return rcode;
}
+static int do_go64(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ ulong addr;
+ addr = simple_strtoul(argv[1], NULL, 16);
+#if defined(CONFIG_MTK_ATF)
+ extern void jumparch64_smc(ulong addr, ulong arg1, ulong arg2);
+ jumparch64_smc(addr, 0, 0);
+#endif
+ //return do_go(cmdtp, flag, argc,argv);
+ return 0;
+}
/* -------------------------------------------------------------------- */
U_BOOT_CMD(
@@ -54,6 +65,13 @@ U_BOOT_CMD(
" passing 'arg' as arguments"
);
+U_BOOT_CMD(
+ go64, CONFIG_SYS_MAXARGS, 1, do_go64,
+ "start 64bit application at address 'addr'",
+ "addr [arg ...]\n - start 64bit application at address 'addr'\n"
+ " passing 'arg' as arguments"
+);
+
#endif
U_BOOT_CMD(
results in this:
BPI-R64> setenv uboot64net 'tftp ${umtkaddr} ${ufile};go64 $uaddr'
BPI-R64> setenv ufile u-boot_2020.01-rc4-bpi-r64-v1.bin
BPI-R64> run uboot64net
ETH already turn on and power on flow will be skipped...
Waitting for RX_DMA_BUSY status Start... done
mt7531: mt7531_sw_init
mt7531: mt7531_core_pll_setup, hwstrap = 000000ff
mt7531: mt7531_mac_port_setup, port = 6
mt7531: mt7531_set_port_sgmii_force_mode, port = 6
mt7531: timeout waiting for SGMII_LINK
mt7531: mt7531_mac_port_setup, PMCR6 = f805633b
0x1b000014 = 0x00110214
Using mtk_eth device
TFTP from server 192.168.0.10; our IP address is 192.168.0.19
Filename 'u-boot_2020.01-rc4-bpi-r64-v1.bin'.
Load address: 0x41dffe00
Loading: T ################################
86.9 KiB/s
done
Bytes transferred = 463504 (71290 hex)
get filesize 0x71290
[ATF][ 55.625586]save kernel info
[ATF][ 55.628626]Kernel_EL2
[ATF][ 55.631382]Kernel is 64Bit
[ATF][ 55.634570]pc=0x41e00000, r0=0x0, r1=0x0
INFO: BL3-1: Preparing for EL3 exit to normal world, Kernel
INFO: BL3-1: Next image address = 0x41e00000
INFO: BL3-1: Next image spsr = 0x3c9
[ATF][ 55.652234]el3_exit
U-Boot 2020.01-rc4-bpi-r64-v1-00023-g8cc6bfc180-dirty (Dec 07 2019 - 10:53:57 +)
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: No ethernet found.
MT7622>
DRAM seems to be wrong…
i can access both mmc devices (need FS_GENERIC and CMD_FAT)
MT7622> ls mmc 1:1
bananapi/
0 sd.txt
8841288 uImage_5.4
23721 bpi-r64-5.4.dtb
3 file(s), 1 dir(s)
MT7622> ls mmc 0:1
bananapi/
0 emmc.txt
1 file(s), 1 dir(s)
MT7622>
tried now loading kernel, but it seems not working (maybe because it is wrapped into 32bit container via mkimage)
MT7622> setenv kaddr 0x44000000
MT7622> setenv dtaddr 0x47000000
MT7622> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait ipp
MT7622> fatload mmc 1:1 ${kaddr} uImage_5.4
8841288 bytes read in 613 ms (13.8 MiB/s)
MT7622> fatload mmc 1:1 ${dtaddr} bpi-r64-5.4.dtb
23721 bytes read in 4 ms (5.7 MiB/s)
MT7622> bootm ${kaddr} - ${dtaddr}
## Booting kernel from Legacy Image at 44000000 ...
Image Name: Linux Kernel 5.4.0-rc1-r64
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 8841224 Bytes = 8.4 MiB
Load Address: 40080000
Entry Point: 40080000
Verifying Checksum ... OK
## Flattened Device Tree blob at 47000000
Booting using the fdt blob at 0x47000000
Loading Kernel Image
Loading Device Tree to 000000004f7f3000, end 000000004f7fbca8 ... OK
Starting kernel ...
F0: 102B 0000
F5: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
T0: 0000 0342 [000F]
Jump to BL
it hangs on “starting kernel” till watchdog reset occours
after changing the mkimage-command in my kernels build.sh this way:
mkimage -A arm64 -O linux -T kernel -C none -a 40080000 -e 40080000 -n "Linux Kernel $kernver$gitbranch" -d arch/arm64/boot/Image ./uImage_nodt
i’m able to boot kernel
MT7622> setenv kaddr 0x44000000
MT7622> setenv dtaddr 0x47000000
MT7622> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk1p2 rw rootwait
MT7622> fatload mmc 1:1 ${kaddr} uImage_5.4_64
8581192 bytes read in 588 ms (13.9 MiB/s)
MT7622> fatload mmc 1:1 ${dtaddr} bpi-r64-5.4_64.dtb
24264 bytes read in 3 ms (7.7 MiB/s)
MT7622> bootm ${kaddr} - ${dtaddr}
for wrong DRAM value i tried modifying the memory-node in arch/arm/dts/mt7622-rfb.dts matching same reg as in linux (except in linux memory-node is 64bit by globally #address-cells = <2>;#size-cells = <2>; in mt7622.dtsi)
memory@40000000 {
device_type = "memory";
- reg = <0x40000000 0x10000000>;
+ reg = <0x40000000 0x40000000>;
};
now i see
DRAM: 1 GiB
but after this is printed board hangs i tried to adjust CONFIG_NR_DRAM_BANKS to 2 and 4 without success
ATF image for 64 bits u-boot
(default: stating 64 bits u-boot, and can keep holding the WPS button during boot-up to start 32 bits u-boot)
mt7622_ATF_32_64_release.img (61.1 KB)
thank you
i was able to start new uboot directly with this ATF
[BLDR] part_load_images ret=0x0
[BLDR] Others, jump to ATF
[BLDR] jump to 0x41E00000
[BLDR] <0x41E00000>=0x1400000A
[BLDR] <0x41E00004>=0xD503201F
U-Boot 2020.01-rc4-bpi-r64-v1 (Dec 09 2019 - 07:43:54 +0100)
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: No ethernet found.
MT7622>
steps to write ATF if anyone else also want to test it
ATF=~/Downloads/mt7622_ATF_32_64_release.img
O=/dev/sdb
sudo dd if=$ATF of=$O bs=1k seek=512
made a quick test with WPS-button to start old uboot using this ATF…works…is it possible to invert the button-handling (not press boot 32,press boot 64)?
[BLDR] jump to 0x41E00000
[BLDR] <0x41E00000>=0xEA00000F
[BLDR] <0x41E00004>=0xE59FF014
U-Boot 2014.04-rc1-00045-g955f02c553 (Dec 09 2019 - 07:53:38)
DRAM: 1008 MiB
relocation Offset is: 3d134000
WARNING: Caches not enabled
Now running in RAM - U-Boot at: 7ef34000
any idea about DRAM?