友善FriendlyARM NanoPi K1 Plus移植之增加emmc支持 续前，因为使用的是nanopi_neo2_defconfig配置的编译，而neo2上是没有将mmc2的emmc引出的，故用这个配置编译出的u-boot是检测不到mmc2上连接的emmc的，打印信息如下： U-Boot 2019.04 (May 23 2019 - 09:47:22 +0800) Allwinner Technology
CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 2 GiB MMC: mmc@1c0f000: 0 Loading Environment from FAT… In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB… USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices… 1 USB Device(s) found scanning bus 1 for devices… 1 USB Device(s) found scanning bus 2 for devices… 1 USB Device(s) found scanning bus 3 for devices… 1 USB Device(s) found scanning usb for storage devices… 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** Invalid partition 1 ** MMC Device 1 not found no mmc device at slot 1
从上可以看到mmc2，也就是slot1上是没有识别到emmc芯片的。
开始有点犯傻了，在board.c里面去找初始化函数，然后还找去了mmc.c的驱动那边，确实一度也发现了一点问题，在分支u-boot的mmc初始化的源码中：
#if CONFIG_IS_ENABLED(DM_MMC) && defined(CONFIG_SPL_BUILD) static int mmc_probe(bd_t *bis) { return 0; } #elif CONFIG_IS_ENABLED(DM_MMC) static int mmc_probe(bd_t *bis) { int ret, i; struct uclass *uc; struct udevice *dev;
ret = uclass_get(UCLASS_MMC, &uc); if (ret) return ret; /* * Try to add them in sequence order. Really with driver model we * should allow holes, but the current MMC list does not allow that. * So if we request 0, 1, 3 we will get 0, 1, 2. */ for (i = 0; ; i++) { ret = uclass_get_device_by_seq(UCLASS_MMC, i, &dev); if (ret == -ENODEV) break; } uclass_foreach_dev(dev, uc) { ret = device_probe(dev); if (ret) printf("%s - probe failed: %d\n", dev->name, ret); } return 0;} #else static int mmc_probe(bd_t *bis) { if (board_mmc_init(bis) < 0) cpu_mmc_init(bis);
return 0;} #endif
int mmc_initialize(bd_t bis) { static int initialized = 0; int ret; if (initialized) / Avoid initializing mmc multiple times */ return 0; initialized = 1;
#if !CONFIG_IS_ENABLED(BLK) #if !CONFIG_IS_ENABLED(MMC_TINY) mmc_list_init(); #endif #endif ret = mmc_probe(bis); if (ret) return ret;
#ifndef CONFIG_SPL_BUILD print_mmc_devices(’,’); #endif
mmc_do_preinit(); return 0;}
显示会对mmc的列表进行初始化，然后再对mmc节点操作，这里追踪了一下2019.04的u-boot，在probe节点操作的流程和分支不一样，分支会在判断CONFIG_IS_ENABLED(DM_MMC)非有效后进入最后一个含有board_mmc_init(bis)初始化操作的流程，而2019.04则只会进到上一个判断的流程中，实在是追踪不下去了是哪里导致这个判断的，一度限于绝望中。 #else static int mmc_probe(bd_t *bis) { if (board_mmc_init(bis) < 0) cpu_mmc_init(bis);
return 0;}
然鹅，在arch文件夹中搜索的时候，突然注意到dts这个东西，恍然大悟，卧槽。。。是不是dts文件里没有配置mmc2这个设备啊。。。果然2019.04的u-boot中由于把h5和h3这两个芯片用了一个新的dts基础配置文件（#include <sunxi-h3-h5.dtsi>），sun50i-h5-nanopi-neo2.dts中只配置了mmc0，而在分支u-boot中，h5还是和h3共用的基础配置文件（#include “sun8i-h3.dtsi”），然后在dts中加入一下mmc2的配置 &mmc2 { pinctrl-names = “default”; pinctrl-0 = <&mmc2_8bit_pins>; vmmc-supply = <®_vcc3v3>; bus-width = <8>; non-removable; cap-mmc-hw-reset; status = “okay”; };
重新编译，就可以看到识别出mmc2上的emmc芯片了
