btw. i added (locally) the mmc-patches and the dts-patch…sdmmc seems slower (~1 sec on ls fat-partition) compared to my 2021-01 uboot (content is directly shown…not much delay)
4954a8a54c 2021-03-13 dts64: update bananapi-bpi-r64 device-tree (HEAD -> 2021-04-bpi)
4a0b6999d0 2021-03-11 mmc: mtk-sd: don't ignore max-frequency from device tree
642d801e05 2021-03-02 mmc: mtk-sd: increase the minimum bus frequency
have not done the revert (why do you need to revert the clk-patch?)…usb working without additional patch
U-Boot 2021.04-rc3-bpi (Mar 13 2021 - 14:36:36 +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 - 12:48:4a:61:a2:29
eth0: ethernet@1b100000
Hit any key to stop autoboot: 0
BPI-R64> 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... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
BPI-R64> ls usb 0
efi/
1023582 ramdisk.img
1365903 initrd.img
2956137 install.img
456908800 system.sfs
4767728 kernel
5 file(s), 1 dir(s)
At least my SD Card (cheap, no-name 16 GiB, reads with about 10MiB/s) doesn’t probe in U-Boot if leaving the max-frequency at the default (48 MHz on that board). If I set values higher than 12MHz, it fails to be detected. Might be the card, of course, but I figured it doesn’t hurt much and reliability is kinda more important than performance in U-Boot imho. (loading 10MiB uImage.FIT from a partition takes around 1.5s, I’m ok with that. Not planning to use any larger files or even filesystems from the 80’s in my bootchain.)
The clk: Add debugging for return values patch breaks MMC on 64-bit builds, I also haven’t figured from the code why it truncates the parameter passed to it to 32-bits, but that’s what it does (all the implicit sizes of types in U-Boot are too much for me. Just using int everywhere rather than uint32_t, uint64_t, …). @hackpascal recommended to revert it for now, and yes, that fixes the problem.
Regarding USB, as you have AHCI selected in your build (I don’t, not seeing it as something I’d ever want to boot OpenWrt from given that I already got SD Card and eMMC), that implicitly also fixes USB 2.0 (by selecting needed config symbols). (And USB is nice for bootable UEFI pendrive, like Memtest86)
I activated sata in uboot because using sata drive with kernel and full rootfs is imho more usable in uboot than 2 pcie slots (maybe filled with wifi cards not having an uboot driver). But this is a personal thing and if anyone needs pcie the other slot still can be used. And this configurations matches my kernel where also 1 pcie and sata is activated. if mtk-tphy fixed your problem (gpio imho only needed for sata-mode) then maybe kconfig should be changed to depend on it (at least on target/arch)
Strange that my mmc (you mean sd not emmc,right) is not broken…
edit: reverted it too and my delay is gone for sdcard
btw. i use an 32gb sandisk card
BPI-R64> mmc info
Device: mmc@11240000
Manufacturer ID: 3
OEM: 5054
Name: SL32G
Bus Speed: 12000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
have you/weijie reported the clk-patch as regression? so that it got fixed before 2021-04 release…as it is in core it is likely that other users has similar problems
For me ahci-mtk.c doesn’t build with U-Boot 2021.04-rc3, now that I tried.
Regarding mmc, yes this is a problem only with SD Card (eMMC works well without the patches).
Maybe the mtk-sd driver kranks up the frequency before querying the card’s capabilities?
Or maybe MMC isn’t reset to state which allows probing the card after it has already been used by ATF?
The card I got here gives me this:
MT7622> mmc info
Device: mmc@11240000
Manufacturer ID: 28
OEM: 4245
Name: 00000
Bus Speed: 12000000
Mode: MMC legacy
Rd Block Len: 512
SD version 1.0
High Capacity: Yes
Capacity: 29.7 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
(with the patch)
unable to read ssr
unable to read ssr
unable to select a mode
mmc_init: -524, time 22
(without the patch)
I’m not aware if Weijie has reported the regression caused by starting to use log_msg_ret(). I’m currently trying (not for the first time in the past decade) to get access to U-Boot’s mailing list and gitlab, which would allow me to report things. As it has (unfortunately) always been with that project, I may (also not for the first time) decide to give up in case the list moderator never accepts my request to be added to the list or my posts to show (and thereby make it to patchwork). At least I did receive a confirmation email this time, I did not when I tried last time (2014?).
in past there were problems with some mailing-servers (e.g. from mtk) where a misconfiguration (reverse dns) resulted in mail-drops…maybe you can use another mail-provider? i had no problem with my gmx-account…but it is a german provider
aarch64-openwrt-linux-musl-ld.bfd: drivers/built-in.o: in function `mtk_ahci_parse_property':
/home/daniel/openwrt/build_dir/target-aarch64_cortex-a53_musl/u-boot-mt7622_bananapi_bpi-r64-emmc/u-boot-2021.04-rc3/drivers/ata/mtk_ahci.c:65: undefined reference to `dev_err'
aarch64-openwrt-linux-musl-ld.bfd: drivers/built-in.o: in function `mtk_ahci_probe':
/home/daniel/openwrt/build_dir/target-aarch64_cortex-a53_musl/u-boot-mt7622_bananapi_bpi-r64-emmc/u-boot-2021.04-rc3/drivers/ata/mtk_ahci.c:92: undefined reference to `dev_err'
Segmentation fault
make[3]: *** [Makefile:1768: u-boot] Error 139
make[3]: *** Deleting file 'u-boot'
Not exactly obvious what’s happening here, but it looks bad (toolchain segfaulting…) and I didn’t feel like digging into it as AHCI may not even be available due to user choosing to use mPCIe slot instead, and it is not really needed to boot that device anyway (ie. I have a hard time imagining the use-case for that).
I’m using my own mailserver, reverse DNS (and SPFv1, DKIM not yet) should be setup correctly, at least I never had problems communicating with other mailservers in the wild in the past 14 years which I have been running it. Ok, some very shitty ones in autocratic places don’t count; and there is united internet in germany with their deMAIL nationalist, deptconomy driven, re-interpretation of RFC822 going on (it’s all about proving a due-date has been received and seen, right?), there you got to have some of their clients to allow-list your server. users of of united internet services had to do that in order to be able to SEND mail TO me, but that’s another story, more than 10 years ago…
Anyway. Regarding the U-Boot mailing list this seems to be no longer an issue, I’m now receiving mails from the lists and just my own post with the patch is apparently still awaiting moderator approval.
Something magic has happened. I realized my previous patch was dropped by the list moderator (ticket for approval was no longer valid) but sending to the list now makes my patches arrives on u-boot patchwork:
and if anyone needs pcie the other slot still can be used. And this configurations matches my kernel where also 1 pcie and sata is activated. if mtk-tphy fixed your problem (gpio imho only needed for sata-mode) then maybe kconfig should be changed to depend on it (at least on target/arch)