Can't access mmc #0 on mt7623 when booted from external SD
The Banana Pi R2 bootloader will load U-Boot from either the internal eMMC, or the external SD card if the latter is present.
If booted from the eMMC (and an SD card is subsequently inserted), both work from U-Boot. Both also work from Linux, whichever device is booted from.
If booted from SD, the internal eMMC cannot be accessed from U-Boot. This makes it slightly difficult for me to write a U-Boot script which installs OpenWRT from the SD card to the internal eMMC...
From SD:
U-Boot 2020.07-rc4-00057-gc622afb087 (Jun 16 2020 - 17:05:55 +0100)
CPU: MediaTek MT7623 E3 DRAM: 2 GiB WDT: Started with servicing (60s timeout) MMC: mmc@11230000: 0, mmc@11240000: 1 Loading Environment from FAT... ** No device specified ** ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 U-Boot> mmc list mmc@11230000: 0 mmc@11240000: 1 U-Boot> mmc dev 0 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 MMC_RSP_R3,4 0xffffffff CMD_SEND:2 ARG 0x00000000 RET -110 U-Boot> mmc dev 1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa MMC_RSP_R1,5,6,7 0x000001aa CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x80ff8000 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x744a6055 0x53442020 0x104059f3 0x34013be5
DUMPING DATA 000 - 74 4a 60 55 004 - 53 44 20 20 008 - 10 40 59 f3 012 - 34 01 3b e5 CMD_SEND:3 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x59b40520 CMD_SEND:9 ARG 0x59b40000 MMC_RSP_R2 0x007f0032 0x5b5a83bd 0x6db7ff80 0x0a80008d
DUMPING DATA 000 - 00 7f 00 32 004 - 5b 5a 83 bd 008 - 6d b7 ff 80 012 - 0a 80 00 8d CMD_SEND:7 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:51 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00000002 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x80fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:13 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:16 ARG 0x00000200 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc1 is current device
From MMC:
U-Boot 2020.07-rc4-00057-gc622afb087 (Jun 16 2020 - 17:05:55 +0100)
CPU: MediaTek MT7623 E3 DRAM: 2 GiB WDT: Started with servicing (60s timeout) MMC: mmc@11230000: 0, mmc@11240000: 1 Loading Environment from FAT... ** No device specified ** ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 U-Boot> mmc list mmc@11230000: 0 mmc@11240000: 1 U-Boot> mmc dev 0 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0xc0ff8080 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x15010038 0x47544634 0x5206071b 0x48de461d
DUMPING DATA 000 - 15 01 00 38 004 - 47 54 46 34 008 - 52 06 07 1b 012 - 48 de 46 1d CMD_SEND:3 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000500 CMD_SEND:9 ARG 0x00010000 MMC_RSP_R2 0xd0270132 0x0f5903ff 0xf6dbffef 0x8e40400d
DUMPING DATA 000 - d0 27 01 32 004 - 0f 59 03 ff 008 - f6 db ff ef 012 - 8e 40 40 0d CMD_SEND:7 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:6 ARG 0x03b70200 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:6 ARG 0x03b90100 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:16 ARG 0x00000200 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc0(part 0) is current device U-Boot> mmc dev 1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa MMC_RSP_R1,5,6,7 0x000001aa CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x80ff8000 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x744a6055 0x53442020 0x104059f3 0x34013be5
DUMPING DATA 000 - 74 4a 60 55 004 - 53 44 20 20 008 - 10 40 59 f3 012 - 34 01 3b e5 CMD_SEND:3 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x59b40520 CMD_SEND:9 ARG 0x59b40000 MMC_RSP_R2 0x007f0032 0x5b5a83bd 0x6db7ff80 0x0a80008d
DUMPING DATA 000 - 00 7f 00 32 004 - 5b 5a 83 bd 008 - 6d b7 ff 80 012 - 0a 80 00 8d CMD_SEND:7 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:51 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00000002 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x80fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:13 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:16 ARG 0x00000200 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc1 is current device U-Boot>
Hi David
On Tue, Jun 16, 2020 at 6:16 PM David Woodhouse dwmw2@infradead.org wrote:
The Banana Pi R2 bootloader will load U-Boot from either the internal eMMC, or the external SD card if the latter is present.
If booted from the eMMC (and an SD card is subsequently inserted), both work from U-Boot. Both also work from Linux, whichever device is booted from.
If booted from SD, the internal eMMC cannot be accessed from U-Boot. This makes it slightly difficult for me to write a U-Boot script which installs OpenWRT from the SD card to the internal eMMC...
I'm thinking that bootrom do the right job for you when both are working.
Michael
From SD:
U-Boot 2020.07-rc4-00057-gc622afb087 (Jun 16 2020 - 17:05:55 +0100)
CPU: MediaTek MT7623 E3 DRAM: 2 GiB WDT: Started with servicing (60s timeout) MMC: mmc@11230000: 0, mmc@11240000: 1 Loading Environment from FAT... ** No device specified ** ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 U-Boot> mmc list mmc@11230000: 0 mmc@11240000: 1 U-Boot> mmc dev 0 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 MMC_RSP_R3,4 0xffffffff CMD_SEND:2 ARG 0x00000000 RET -110 U-Boot> mmc dev 1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa MMC_RSP_R1,5,6,7 0x000001aa CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x80ff8000 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x744a6055 0x53442020 0x104059f3 0x34013be5
DUMPING DATA 000 - 74 4a 60 55 004 - 53 44 20 20 008 - 10 40 59 f3 012 - 34 01 3b e5CMD_SEND:3 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x59b40520 CMD_SEND:9 ARG 0x59b40000 MMC_RSP_R2 0x007f0032 0x5b5a83bd 0x6db7ff80 0x0a80008d
DUMPING DATA 000 - 00 7f 00 32 004 - 5b 5a 83 bd 008 - 6d b7 ff 80 012 - 0a 80 00 8dCMD_SEND:7 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:51 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00000002 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x80fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:13 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:16 ARG 0x00000200 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc1 is current device
From MMC:
U-Boot 2020.07-rc4-00057-gc622afb087 (Jun 16 2020 - 17:05:55 +0100)
CPU: MediaTek MT7623 E3 DRAM: 2 GiB WDT: Started with servicing (60s timeout) MMC: mmc@11230000: 0, mmc@11240000: 1 Loading Environment from FAT... ** No device specified ** ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' ## Warning: Unknown environment variable type 'i' In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 U-Boot> mmc list mmc@11230000: 0 mmc@11240000: 1 U-Boot> mmc dev 0 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0xc0ff8080 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x15010038 0x47544634 0x5206071b 0x48de461d
DUMPING DATA 000 - 15 01 00 38 004 - 47 54 46 34 008 - 52 06 07 1b 012 - 48 de 46 1dCMD_SEND:3 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000500 CMD_SEND:9 ARG 0x00010000 MMC_RSP_R2 0xd0270132 0x0f5903ff 0xf6dbffef 0x8e40400d
DUMPING DATA 000 - d0 27 01 32 004 - 0f 59 03 ff 008 - f6 db ff ef 012 - 8e 40 40 0dCMD_SEND:7 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:6 ARG 0x03b70200 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:6 ARG 0x03b90100 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:16 ARG 0x00000200 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc0(part 0) is current device U-Boot> mmc dev 1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa MMC_RSP_R1,5,6,7 0x000001aa CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x00ff8000 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000120 CMD_SEND:41 ARG 0x40300000 MMC_RSP_R3,4 0x80ff8000 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x744a6055 0x53442020 0x104059f3 0x34013be5
DUMPING DATA 000 - 74 4a 60 55 004 - 53 44 20 20 008 - 10 40 59 f3 012 - 34 01 3b e5CMD_SEND:3 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x59b40520 CMD_SEND:9 ARG 0x59b40000 MMC_RSP_R2 0x007f0032 0x5b5a83bd 0x6db7ff80 0x0a80008d
DUMPING DATA 000 - 00 7f 00 32 004 - 5b 5a 83 bd 008 - 6d b7 ff 80 012 - 0a 80 00 8dCMD_SEND:7 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:51 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x00000002 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:6 ARG 0x80fffff1 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:55 ARG 0x59b40000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:13 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000920 CMD_SEND:16 ARG 0x00000200 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc1 is current device U-Boot>
On Tue, 2020-06-16 at 18:21 +0200, Michael Nazzareno Trimarchi wrote:
Hi David
On Tue, Jun 16, 2020 at 6:16 PM David Woodhouse dwmw2@infradead.org wrote:
The Banana Pi R2 bootloader will load U-Boot from either the internal eMMC, or the external SD card if the latter is present.
If booted from the eMMC (and an SD card is subsequently inserted), both work from U-Boot. Both also work from Linux, whichever device is booted from.
If booted from SD, the internal eMMC cannot be accessed from U-Boot. This makes it slightly difficult for me to write a U-Boot script which installs OpenWRT from the SD card to the internal eMMC...
I'm thinking that bootrom do the right job for you when both are working.
Yes. It does seem likely that when loading U-Boot from the eMMC, the preloader is initialising it for us. But when the preloader loads U-Boot from the SD card, it possibly doesn't initialise the eMMC controller at all.
The Linux driver does cope with this, and drives the internal eMMC. Perhaps there's just some init code missing from the U-Boot mtk-sd driver?
On Tue, Jun 16, 2020 at 6:57 PM David Woodhouse dwmw2@infradead.org wrote:
On Tue, 2020-06-16 at 18:21 +0200, Michael Nazzareno Trimarchi wrote:
Hi David
On Tue, Jun 16, 2020 at 6:16 PM David Woodhouse dwmw2@infradead.org wrote:
The Banana Pi R2 bootloader will load U-Boot from either the internal eMMC, or the external SD card if the latter is present.
If booted from the eMMC (and an SD card is subsequently inserted), both work from U-Boot. Both also work from Linux, whichever device is booted from.
If booted from SD, the internal eMMC cannot be accessed from U-Boot. This makes it slightly difficult for me to write a U-Boot script which installs OpenWRT from the SD card to the internal eMMC...
I'm thinking that bootrom do the right job for you when both are working.
Yes. It does seem likely that when loading U-Boot from the eMMC, the preloader is initialising it for us. But when the preloader loads U-Boot from the SD card, it possibly doesn't initialise the eMMC controller at all.
The Linux driver does cope with this, and drives the internal eMMC. Perhaps there's just some init code missing from the U-Boot mtk-sd driver?
what dts are you using and config? I don't find Banana PI R2
Micheal
On Tue, 2020-06-16 at 18:59 +0200, Michael Nazzareno Trimarchi wrote:
On Tue, Jun 16, 2020 at 6:57 PM David Woodhouse dwmw2@infradead.org wrote:
On Tue, 2020-06-16 at 18:21 +0200, Michael Nazzareno Trimarchi wrote:
Hi David
On Tue, Jun 16, 2020 at 6:16 PM David Woodhouse dwmw2@infradead.org wrote:
The Banana Pi R2 bootloader will load U-Boot from either the internal eMMC, or the external SD card if the latter is present.
If booted from the eMMC (and an SD card is subsequently inserted), both work from U-Boot. Both also work from Linux, whichever device is booted from.
If booted from SD, the internal eMMC cannot be accessed from U-Boot. This makes it slightly difficult for me to write a U-Boot script which installs OpenWRT from the SD card to the internal eMMC...
I'm thinking that bootrom do the right job for you when both are working.
Yes. It does seem likely that when loading U-Boot from the eMMC, the preloader is initialising it for us. But when the preloader loads U-Boot from the SD card, it possibly doesn't initialise the eMMC controller at all.
The Linux driver does cope with this, and drives the internal eMMC. Perhaps there's just some init code missing from the U-Boot mtk-sd driver?
what dts are you using and config? I don't find Banana PI R2
It's mt7623n_bpir2_defconfig
Hi
On Tue, Jun 16, 2020 at 7:07 PM David Woodhouse dwmw2@infradead.org wrote:
On Tue, 2020-06-16 at 18:59 +0200, Michael Nazzareno Trimarchi wrote:
On Tue, Jun 16, 2020 at 6:57 PM David Woodhouse dwmw2@infradead.org wrote:
On Tue, 2020-06-16 at 18:21 +0200, Michael Nazzareno Trimarchi wrote:
Hi David
On Tue, Jun 16, 2020 at 6:16 PM David Woodhouse dwmw2@infradead.org wrote:
The Banana Pi R2 bootloader will load U-Boot from either the internal eMMC, or the external SD card if the latter is present.
If booted from the eMMC (and an SD card is subsequently inserted), both work from U-Boot. Both also work from Linux, whichever device is booted from.
If booted from SD, the internal eMMC cannot be accessed from U-Boot. This makes it slightly difficult for me to write a U-Boot script which installs OpenWRT from the SD card to the internal eMMC...
I'm thinking that bootrom do the right job for you when both are working.
Yes. It does seem likely that when loading U-Boot from the eMMC, the preloader is initialising it for us. But when the preloader loads U-Boot from the SD card, it possibly doesn't initialise the eMMC controller at all.
The Linux driver does cope with this, and drives the internal eMMC. Perhaps there's just some init code missing from the U-Boot mtk-sd driver?
what dts are you using and config? I don't find Banana PI R2
It's mt7623n_bpir2_defconfig
Have you already tried to dump the pinmux using the cmd? in both situation?
Micahel
On Tue, 2020-06-16 at 21:38 +0200, Michael Nazzareno Trimarchi wrote:
Have you already tried to dump the pinmux using the cmd? in both situation?
U-Boot> pinmux status -a -------------------------- pinctrl@10005000: Ops get_pin_muxing error (-38) Can't display pin muxing for pinctrl@10005000 exit not allowed from main input shell.
On Tue, 2020-06-16 at 22:12 +0100, David Woodhouse wrote:
On Tue, 2020-06-16 at 21:38 +0200, Michael Nazzareno Trimarchi wrote:
Have you already tried to dump the pinmux using the cmd? in both situation?
U-Boot> pinmux status -a
pinctrl@10005000: Ops get_pin_muxing error (-38) Can't display pin muxing for pinctrl@10005000 exit not allowed from main input shell.
I found a datasheet...
Booted from SD, not working...
U-Boot> md 0x10005cc0 c 10005cc0: 00000111 00000111 00000111 00000111 ................ 10005cd0: 00000111 00000111 00000111 00000111 ................ 10005ce0: 00000011 00000011 00000011 00000011 ................
Booted from eMMC, working...
U-Boot> md 0x10005cc0 c 10005cc0: 00000910 00000910 00000910 00000910 ................ 10005cd0: 00000c10 00000c10 00000c10 00000c10 ................ 10005ce0: 00000010 00000010 00000010 00000010 ................
Now when I start U-Boot from the SD card I can make it work...
U-Boot> mmc list mmc@11230000: 0 mmc@11240000: 1 (SD) U-Boot> mmc dev 0 U-Boot> mw 0x10005cc0 0x910 U-Boot> mw 0x10005cd0 0xc10 U-Boot> mw 0x10005ce0 0x10 U-Boot> mmc dev 0 switch to partitions #0, OK mmc0(part 0) is current device U-Boot> mmc list mmc@11230000: 0 (eMMC) mmc@11240000: 1 (SD) U-Boot>
So... whose bug is that? :)
On Thu, 2020-06-18 at 16:52 +0100, David Woodhouse wrote:
So... whose bug is that? :)
Looks like the pinctrl driver. This *ought* to work (with the caveat that I really ought to make two pinctrl setups and change between them according to the voltage, like the Linux DT and mtk-sd driver do).
--- a/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts +++ b/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts @@ -133,12 +133,14 @@ "MSDC0_DAT2", "MSDC0_DAT3", "MSDC0_DAT4", "MSDC0_DAT5", "MSDC0_DAT6", "MSDC0_DAT7"; input-enable; - bias-pull-up; + drive-strength = <2>; + bias-pull-up = <3>; };
conf-clk { pins = "MSDC0_CLK"; - bias-pull-down; + drive-strength = <2>; + bias-pull-down = <3>; };
conf-rst {
But it doesn't work. Partly because the U-Boot mtk pinctrl driver doesn't support the R0 R1 bits encoded in that <3>, and partly because it doesn't *even* get pullup/pulldown right at all; it sets the bit in the GPIO_PULLSEL registers but *not* the PUPD bit in the correct register for MSDC and other pins.
Hi David
On Thu, Jun 18, 2020 at 9:21 PM David Woodhouse dwmw2@infradead.org wrote:
On Thu, 2020-06-18 at 16:52 +0100, David Woodhouse wrote:
So... whose bug is that? :)
Looks like the pinctrl driver. This *ought* to work (with the caveat that I really ought to make two pinctrl setups and change between them according to the voltage, like the Linux DT and mtk-sd driver do).
--- a/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts +++ b/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts @@ -133,12 +133,14 @@ "MSDC0_DAT2", "MSDC0_DAT3", "MSDC0_DAT4", "MSDC0_DAT5", "MSDC0_DAT6", "MSDC0_DAT7"; input-enable;
bias-pull-up;
drive-strength = <2>;bias-pull-up = <3>; }; conf-clk { pins = "MSDC0_CLK";
bias-pull-down;
drive-strength = <2>;bias-pull-down = <3>; }; conf-rst {But it doesn't work. Partly because the U-Boot mtk pinctrl driver doesn't support the R0 R1 bits encoded in that <3>, and partly because it doesn't *even* get pullup/pulldown right at all; it sets the bit in the GPIO_PULLSEL registers but *not* the PUPD bit in the correct register for MSDC and other pins.
So change them manually, make it work, You have the board. I don't have any MediaTek board at the moment. Can you implement the missed part?
Michael
On Thu, 2020-06-18 at 21:34 +0200, Michael Nazzareno Trimarchi wrote:
Looks like the pinctrl driver. This *ought* to work (with the caveat that I really ought to make two pinctrl setups and change between them according to the voltage, like the Linux DT and mtk-sd driver do).
--- a/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts +++ b/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts @@ -133,12 +133,14 @@ "MSDC0_DAT2", "MSDC0_DAT3", "MSDC0_DAT4", "MSDC0_DAT5", "MSDC0_DAT6", "MSDC0_DAT7"; input-enable;
bias-pull-up;
drive-strength = <2>;bias-pull-up = <3>; }; conf-clk { pins = "MSDC0_CLK";
bias-pull-down;
drive-strength = <2>;bias-pull-down = <3>; }; conf-rst {But it doesn't work. Partly because the U-Boot mtk pinctrl driver doesn't support the R0 R1 bits encoded in that <3>, and partly because it doesn't *even* get pullup/pulldown right at all; it sets the bit in the GPIO_PULLSEL registers but *not* the PUPD bit in the correct register for MSDC and other pins.
So change them manually, make it work, You have the board. I don't have any MediaTek board at the moment. Can you implement the missed part?
I think I'd rather let the MediaTek folks handle it, as it affects other SoCs too.
It turns out Linux has a pinctrl-mt7623.c driver which looks a lot like the U-Boot one, but *isn't* actually the one being used, because in Linux it only matches "mediatek,mt7623-moore-pinctrl" which isn't in this board's DT.
Linux also has a pinctrl-mt2701.c driver that matches the "mediatek,mt7623-pinctrl" that *is* on this board, and which *does* work correctly.
So I don't know if we just have the wrong driver in U-Boot. Or if the mediatek,mt7623-moore-pinctrl compatible string is a temporary name for the *same* hardware, to invoke the new driver that isn't complete yet so it isn't being used in Linux... but is in U-Boot?
Sean?
The pins for the MMC controller weren't being set up correctly because the pinctrl driver only sets the GPIO pullup/pulldown config and doesn't handle the special cases with PUPD/R0/R1 control.
Signed-off-by: David Woodhouse dwmw2@infradead.org --- And now the eMMC on my Banana Pi R2 actually works, even when booted from SD and the preloader hasn't initialised the pins for the eMMC.
The really key thing is actually putting the clock pin in pull-down mode when we're asked to.
This is inspired by the Linux driver but I'm not sure the Linux driver is doing the right thing for GPIO pins, since AFAICT the mtk_pinconf_adv_pull_set() function will bail out completely without doing anything for pins without R0/R1 support. And won't set the PULLEN/PULLSEL GPIO config for pins which *do* have PUPD support, so doesn't that mean if you're using them in GPIO mode they don't work either? My code sets PULLEN/PULLSEL *and* sets PUPD/R0/R1 if those exist.
I note the Linux mtk-sd driver (and DT) has a separate pinctrl configuration for 1.8v mode. which explicitly sets the driver strength to 2mA and the R0/R1 enables. That would work now if we wanted to support that too, but doesn't seem to be necessary.
drivers/pinctrl/mediatek/pinctrl-mt7623.c | 129 ++++++++++++++++++ drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 19 ++- drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 3 + 3 files changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c b/drivers/pinctrl/mediatek/pinctrl-mt7623.c index d58d840e08..0f5dcb2c63 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mt7623.c +++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c @@ -262,6 +262,132 @@ static const struct mtk_pin_field_calc mt7623_pin_drv_range[] = { PIN_FIELD16(278, 278, 0xf70, 0x10, 8, 4), };
+static const struct mtk_pin_field_calc mt7623_pin_pupd_range[] = { + /* MSDC0 */ + PIN_FIELD16(111, 111, 0xd00, 0x10, 12, 1), + PIN_FIELD16(112, 112, 0xd00, 0x10, 8, 1), + PIN_FIELD16(113, 113, 0xd00, 0x10, 4, 1), + PIN_FIELD16(114, 114, 0xd00, 0x10, 0, 1), + PIN_FIELD16(115, 115, 0xd10, 0x10, 0, 1), + PIN_FIELD16(116, 116, 0xcd0, 0x10, 8, 1), + PIN_FIELD16(117, 117, 0xcc0, 0x10, 8, 1), + PIN_FIELD16(118, 118, 0xcf0, 0x10, 12, 1), + PIN_FIELD16(119, 119, 0xcf0, 0x10, 8, 1), + PIN_FIELD16(120, 120, 0xcf0, 0x10, 4, 1), + PIN_FIELD16(121, 121, 0xcf0, 0x10, 0, 1), + /* MSDC1 */ + PIN_FIELD16(105, 105, 0xd40, 0x10, 8, 1), + PIN_FIELD16(106, 106, 0xd30, 0x10, 8, 1), + PIN_FIELD16(107, 107, 0xd60, 0x10, 0, 1), + PIN_FIELD16(108, 108, 0xd60, 0x10, 10, 1), + PIN_FIELD16(109, 109, 0xd60, 0x10, 4, 1), + PIN_FIELD16(110, 110, 0xc60, 0x10, 12, 1), + /* MSDC1 */ + PIN_FIELD16(85, 85, 0xda0, 0x10, 8, 1), + PIN_FIELD16(86, 86, 0xd90, 0x10, 8, 1), + PIN_FIELD16(87, 87, 0xdc0, 0x10, 0, 1), + PIN_FIELD16(88, 88, 0xdc0, 0x10, 10, 1), + PIN_FIELD16(89, 89, 0xdc0, 0x10, 4, 1), + PIN_FIELD16(90, 90, 0xdc0, 0x10, 12, 1), + /* MSDC0E */ + PIN_FIELD16(249, 249, 0x140, 0x10, 0, 1), + PIN_FIELD16(250, 250, 0x130, 0x10, 12, 1), + PIN_FIELD16(251, 251, 0x130, 0x10, 8, 1), + PIN_FIELD16(252, 252, 0x130, 0x10, 4, 1), + PIN_FIELD16(253, 253, 0x130, 0x10, 0, 1), + PIN_FIELD16(254, 254, 0xf40, 0x10, 12, 1), + PIN_FIELD16(255, 255, 0xf40, 0x10, 8, 1), + PIN_FIELD16(256, 256, 0xf40, 0x10, 4, 1), + PIN_FIELD16(257, 257, 0xf40, 0x10, 0, 1), + PIN_FIELD16(258, 258, 0xcb0, 0x10, 8, 1), + PIN_FIELD16(259, 259, 0xc90, 0x10, 8, 1), + PIN_FIELD16(261, 261, 0x140, 0x10, 8, 1), +}; + +static const struct mtk_pin_field_calc mt7623_pin_r1_range[] = { + /* MSDC0 */ + PIN_FIELD16(111, 111, 0xd00, 0x10, 13, 1), + PIN_FIELD16(112, 112, 0xd00, 0x10, 9, 1), + PIN_FIELD16(113, 113, 0xd00, 0x10, 5, 1), + PIN_FIELD16(114, 114, 0xd00, 0x10, 1, 1), + PIN_FIELD16(115, 115, 0xd10, 0x10, 1, 1), + PIN_FIELD16(116, 116, 0xcd0, 0x10, 9, 1), + PIN_FIELD16(117, 117, 0xcc0, 0x10, 9, 1), + PIN_FIELD16(118, 118, 0xcf0, 0x10, 13, 1), + PIN_FIELD16(119, 119, 0xcf0, 0x10, 9, 1), + PIN_FIELD16(120, 120, 0xcf0, 0x10, 5, 1), + PIN_FIELD16(121, 121, 0xcf0, 0x10, 1, 1), + /* MSDC1 */ + PIN_FIELD16(105, 105, 0xd40, 0x10, 9, 1), + PIN_FIELD16(106, 106, 0xd30, 0x10, 9, 1), + PIN_FIELD16(107, 107, 0xd60, 0x10, 1, 1), + PIN_FIELD16(108, 108, 0xd60, 0x10, 9, 1), + PIN_FIELD16(109, 109, 0xd60, 0x10, 5, 1), + PIN_FIELD16(110, 110, 0xc60, 0x10, 13, 1), + /* MSDC2 */ + PIN_FIELD16(85, 85, 0xda0, 0x10, 9, 1), + PIN_FIELD16(86, 86, 0xd90, 0x10, 9, 1), + PIN_FIELD16(87, 87, 0xdc0, 0x10, 1, 1), + PIN_FIELD16(88, 88, 0xdc0, 0x10, 9, 1), + PIN_FIELD16(89, 89, 0xdc0, 0x10, 5, 1), + PIN_FIELD16(90, 90, 0xdc0, 0x10, 13, 1), + /* MSDC0E */ + PIN_FIELD16(249, 249, 0x140, 0x10, 1, 1), + PIN_FIELD16(250, 250, 0x130, 0x10, 13, 1), + PIN_FIELD16(251, 251, 0x130, 0x10, 9, 1), + PIN_FIELD16(252, 252, 0x130, 0x10, 5, 1), + PIN_FIELD16(253, 253, 0x130, 0x10, 1, 1), + PIN_FIELD16(254, 254, 0xf40, 0x10, 13, 1), + PIN_FIELD16(255, 255, 0xf40, 0x10, 9, 1), + PIN_FIELD16(256, 256, 0xf40, 0x10, 5, 1), + PIN_FIELD16(257, 257, 0xf40, 0x10, 1, 1), + PIN_FIELD16(258, 258, 0xcb0, 0x10, 9, 1), + PIN_FIELD16(259, 259, 0xc90, 0x10, 9, 1), + PIN_FIELD16(261, 261, 0x140, 0x10, 9, 1), +}; + +static const struct mtk_pin_field_calc mt7623_pin_r0_range[] = { + /* MSDC0 */ + PIN_FIELD16(111, 111, 0xd00, 0x10, 14, 1), + PIN_FIELD16(112, 112, 0xd00, 0x10, 10, 1), + PIN_FIELD16(113, 113, 0xd00, 0x10, 6, 1), + PIN_FIELD16(114, 114, 0xd00, 0x10, 2, 1), + PIN_FIELD16(115, 115, 0xd10, 0x10, 2, 1), + PIN_FIELD16(116, 116, 0xcd0, 0x10, 10, 1), + PIN_FIELD16(117, 117, 0xcc0, 0x10, 10, 1), + PIN_FIELD16(118, 118, 0xcf0, 0x10, 14, 1), + PIN_FIELD16(119, 119, 0xcf0, 0x10, 10, 1), + PIN_FIELD16(120, 120, 0xcf0, 0x10, 6, 1), + PIN_FIELD16(121, 121, 0xcf0, 0x10, 2, 1), + /* MSDC1 */ + PIN_FIELD16(105, 105, 0xd40, 0x10, 10, 1), + PIN_FIELD16(106, 106, 0xd30, 0x10, 10, 1), + PIN_FIELD16(107, 107, 0xd60, 0x10, 2, 1), + PIN_FIELD16(108, 108, 0xd60, 0x10, 8, 1), + PIN_FIELD16(109, 109, 0xd60, 0x10, 6, 1), + PIN_FIELD16(110, 110, 0xc60, 0x10, 14, 1), + /* MSDC2 */ + PIN_FIELD16(85, 85, 0xda0, 0x10, 10, 1), + PIN_FIELD16(86, 86, 0xd90, 0x10, 10, 1), + PIN_FIELD16(87, 87, 0xdc0, 0x10, 2, 1), + PIN_FIELD16(88, 88, 0xdc0, 0x10, 8, 1), + PIN_FIELD16(89, 89, 0xdc0, 0x10, 6, 1), + PIN_FIELD16(90, 90, 0xdc0, 0x10, 14, 1), + /* MSDC0E */ + PIN_FIELD16(249, 249, 0x140, 0x10, 2, 1), + PIN_FIELD16(250, 250, 0x130, 0x10, 14, 1), + PIN_FIELD16(251, 251, 0x130, 0x10, 10, 1), + PIN_FIELD16(252, 252, 0x130, 0x10, 6, 1), + PIN_FIELD16(253, 253, 0x130, 0x10, 2, 1), + PIN_FIELD16(254, 254, 0xf40, 0x10, 14, 1), + PIN_FIELD16(255, 255, 0xf40, 0x10, 10, 1), + PIN_FIELD16(256, 256, 0xf40, 0x10, 6, 1), + PIN_FIELD16(257, 257, 0xf40, 0x10, 5, 1), + PIN_FIELD16(258, 258, 0xcb0, 0x10, 10, 1), + PIN_FIELD16(259, 259, 0xc90, 0x10, 10, 1), + PIN_FIELD16(261, 261, 0x140, 0x10, 10, 1), +}; + static const struct mtk_pin_reg_calc mt7623_reg_cals[] = { [PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt7623_pin_mode_range), [PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt7623_pin_dir_range), @@ -272,6 +398,9 @@ static const struct mtk_pin_reg_calc mt7623_reg_cals[] = { [PINCTRL_PIN_REG_PULLSEL] = MTK_RANGE(mt7623_pin_pullsel_range), [PINCTRL_PIN_REG_PULLEN] = MTK_RANGE(mt7623_pin_pullen_range), [PINCTRL_PIN_REG_DRV] = MTK_RANGE(mt7623_pin_drv_range), + [PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt7623_pin_pupd_range), + [PINCTRL_PIN_REG_R0] = MTK_RANGE(mt7623_pin_r0_range), + [PINCTRL_PIN_REG_R1] = MTK_RANGE(mt7623_pin_r1_range), };
static const struct mtk_pin_desc mt7623_pins[] = { diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c index 5fdc150295..f5199fc574 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c @@ -296,7 +296,7 @@ static const struct pinconf_param mtk_conf_params[] = { };
-int mtk_pinconf_bias_set_v0(struct udevice *dev, u32 pin, u32 arg) +int mtk_pinconf_bias_set_v0(struct udevice *dev, u32 pin, u32 arg, u32 val) { int err, disable, pullup;
@@ -323,12 +323,14 @@ int mtk_pinconf_bias_set_v0(struct udevice *dev, u32 pin, u32 arg) return 0; }
-int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin, u32 arg) +int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin, u32 arg, u32 val) { - int err, disable, pullup; + int err, disable, pullup, r0, r1;
disable = (arg == PIN_CONFIG_BIAS_DISABLE); pullup = (arg == PIN_CONFIG_BIAS_PULL_UP); + r0 = !!(val & 1); + r1 = !!(val & 2);
if (disable) { err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PULLEN, 0); @@ -344,6 +346,13 @@ int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin, u32 arg) return err; }
+ /* Also set PUPD/R0/R1 if the pin has them */ + err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup); + if (err != -EINVAL) { + mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0); + mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1); + } + return 0; }
@@ -419,9 +428,9 @@ static int mtk_pinconf_set(struct udevice *dev, unsigned int pin, case PIN_CONFIG_BIAS_PULL_UP: case PIN_CONFIG_BIAS_PULL_DOWN: if (rev == MTK_PINCTRL_V0) - err = mtk_pinconf_bias_set_v0(dev, pin, param); + err = mtk_pinconf_bias_set_v0(dev, pin, param, arg); else - err = mtk_pinconf_bias_set_v1(dev, pin, param); + err = mtk_pinconf_bias_set_v1(dev, pin, param, arg); if (err) goto err; break; diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h index e815761450..5e51a9a90c 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h @@ -51,6 +51,9 @@ enum { PINCTRL_PIN_REG_PULLEN, PINCTRL_PIN_REG_PULLSEL, PINCTRL_PIN_REG_DRV, + PINCTRL_PIN_REG_PUPD, + PINCTRL_PIN_REG_R0, + PINCTRL_PIN_REG_R1, PINCTRL_PIN_REG_MAX, };
Hi,
Problem seems to be board-specific, on my bananapi-r2 v1.0 i had no problems with accessing emmc if booted from sdcard.
but with the Patch i can still access any mmc-device (tried booting from emmc and sd)
Tested-By: Frank Wunderlich frank-w@public-files.de
regards Frank
On Fri, 2020-06-19 at 12:40 +0100, David Woodhouse wrote:
The pins for the MMC controller weren't being set up correctly because the pinctrl driver only sets the GPIO pullup/pulldown config and doesn't handle the special cases with PUPD/R0/R1 control.
Signed-off-by: David Woodhouse dwmw2@infradead.org
Ping?
On Fri, Jun 19, 2020 at 12:40:20PM +0100, David Woodhouse wrote:
The pins for the MMC controller weren't being set up correctly because the pinctrl driver only sets the GPIO pullup/pulldown config and doesn't handle the special cases with PUPD/R0/R1 control.
Signed-off-by: David Woodhouse dwmw2@infradead.org Tested-By: Frank Wunderlich frank-w@public-files.de
Applied to u-boot/master, thanks!
Hi David,
1. mt7623-moore-pinctrl is written for introducing more supports for new mediatek soc like mt7622, mt7629, mt8183 and so on and even more easily maintained than before
2. mt7623-moore-pinctrl/mt2701-pinctrl drives the same hardware, but with different driver style, the latter one is already hard to extend to newer and variety mediatek SoC.
3. mt7623 pinctrl on uboot would prefer to apply mt7623-moore-pinctrl just since pinctrl on uboot is developed later than mt7623-moore-pinctrl. mt7623 pinctrl on linux still would prefer to apply mt2701-pinctrl since they have been supported for a while and be stable enough.
4. it's still welcome to submit patches to mt7623-moore-pinctrl from your experiences in mt7623 uboot to make it complete.
Thanks, Sean
-----Original Message----- From: David Woodhouse [mailto:dwmw2@infradead.org] Sent: Thursday, June 18, 2020 2:03 PM To: Michael Nazzareno Trimarchi michael@amarulasolutions.com Cc: U-Boot-Denx u-boot@lists.denx.de; Ryder Lee (李庚諺) Ryder.Lee@mediatek.com; Weijie Gao (高惟杰) Weijie.Gao@mediatek.com; frank wunderlich frank-w@public-files.de; Sean Wang Sean.Wang@mediatek.com Subject: Re: Can't access mmc #0 on mt7623 when booted from external SD
On Thu, 2020-06-18 at 21:34 +0200, Michael Nazzareno Trimarchi wrote:
Looks like the pinctrl driver. This *ought* to work (with the caveat that I really ought to make two pinctrl setups and change between them according to the voltage, like the Linux DT and mtk-sd driver do).
--- a/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts +++ b/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts @@ -133,12 +133,14 @@ "MSDC0_DAT2", "MSDC0_DAT3", "MSDC0_DAT4", "MSDC0_DAT5", "MSDC0_DAT6", "MSDC0_DAT7"; input-enable;
bias-pull-up;
drive-strength = <2>;bias-pull-up = <3>; }; conf-clk { pins = "MSDC0_CLK";
bias-pull-down;
drive-strength = <2>;bias-pull-down = <3>; }; conf-rst {But it doesn't work. Partly because the U-Boot mtk pinctrl driver doesn't support the R0 R1 bits encoded in that <3>, and partly because it doesn't *even* get pullup/pulldown right at all; it sets the bit in the GPIO_PULLSEL registers but *not* the PUPD bit in the correct register for MSDC and other pins.
So change them manually, make it work, You have the board. I don't have any MediaTek board at the moment. Can you implement the missed part?
I think I'd rather let the MediaTek folks handle it, as it affects other SoCs too.
It turns out Linux has a pinctrl-mt7623.c driver which looks a lot like the U-Boot one, but *isn't* actually the one being used, because in Linux it only matches "mediatek,mt7623-moore-pinctrl" which isn't in this board's DT.
Linux also has a pinctrl-mt2701.c driver that matches the "mediatek,mt7623-pinctrl" that *is* on this board, and which *does* work correctly.
So I don't know if we just have the wrong driver in U-Boot. Or if the mediatek,mt7623-moore-pinctrl compatible string is a temporary name for the *same* hardware, to invoke the new driver that isn't complete yet so it isn't being used in Linux... but is in U-Boot?
Sean?
participants (5)
-
David Woodhouse -
Frank Wunderlich -
Michael Nazzareno Trimarchi -
Sean Wang -
Tom Rini