[参考译文] BEAGLEBK：针对&quot 的 BeagleBone Black GPIO 配置；mmc1_PINs&quot；

Matt、您好！

首先、请注意更改其他设备树文件中包含的设备树文件。 要读取的最后一个器件树文件将覆盖先前器件树文件中的设置。 例如、如果您设置 AM335x-bone-common.dtsi：nodex｛status = disabled｝、但 AM335x-bonebblack.dts：nodex｛status = ok｝、则您对 AM335x-bone-common 的更改将被后面的文件覆盖。

" Linux 内核无法正常启动"是什么意思？ 例如，您是否有可以附加到帖子的引导日志？

您想通过注释掉引脚复用设置来实现什么？

您是否将 mmc1用于任何用途？ 如果没有、您可能可以从更改 mmc1节点  

状态="正常"；

更改为  

STATUS ="禁用"；

现在、我看到您在  my_GPIO2_pins 下为引脚 mmc0_dat3定义了不同的引脚多路复用设置。

此致、

Nick

您好、Nick、

我想知道您对此是否有任何见解？ 或者、我要保留该 mmc1节点、只需以不同的方式为 mmc1节点下的 GPIO 配置引脚多路复用设置？

请提供建议。

谢谢！

Matt、您好！

感谢您的 Ping 操作。

让我们快速后退一步、通过 mmcblk0/1仔细检查您的系统含义。

对于 AM335x、mmc1 (器件树)= mmc0 (pinmux 设置/TRM)。 但 Linux 中的 mmcblk0不一定映射到器件树/pinmux 中的 mmc1/mmc0。 堆栈溢出文章 如何在嵌入式 Linux 上找到哪个分区映射到哪个内存设备类型？ 演示了使用 udev 来双重检查 Linux 系统调用/dev/mmcblk0和/dev/mmcblk1.的 MMC

例如、在我的 BeagleBone Black 上、/dev/mmcblk0会列出父设备 /devices/platform/ocp/48060000. 当我们查看 AM335x 技术参考手册"存储器映射"一章时、我们会看到 MMC0存储器空间与0x4806_0000相关联。

我认为您的设备树中有一些有趣的事情、因为从一个 MMC 接口引导不应依赖于另一个断开连接的 MMC 接口的设置。 我可以采用 BeagleBone Black、设置状态="disabled"；在 AM335x-bonebreblem-common.dtsi >&mmc2中、Linux 启动时仅使用/dev/mmcblk0 = SD 卡即可。

此致、

Nick

您好、Nick、

感谢您的建议。 阅读并进行更多的在线搜索后、我仍有一些问题、希望您能帮助您消除我的疑虑。

AM335x-bone-common.dtsi 中此 mmc1_pins 更改是来自原始 BeagleBone Black 器件树的唯一与 MMC 相关的修改。 因此、我认为我的 MMC 相关器件树与原始 BeagleBone Black 器件树没有太大差异。 但看起来、如果禁用 SD 卡器件树节点(mmc1)、Linux 内核死区会查找器件 mmcblk0。

问题：
我假设 SD 卡的 mmc0 (mmcblk0)与 eMMC 的 mmc1 (mmcblk1)之间的关联是固定的？
如果是、当禁用 SD 卡设备树节点时、Linux 内核应探测 mmcblk1。 为什么它继续探测 mmcblk0？ 是否有方法告诉 Linux 内核仅探测 mmcblk1？
如果不是、当禁用 SD 卡设备树节点时、是否有方法指定设备树或其他位置、以便 Linux 内核针对 mmcblk1进行探测？

2.感谢您提供有关 udev 的详细信息。 但是、在我的情况下、问题发生在 Linux 内核启动期间、而不是用户空间。 我认为这不适用于我的案例。 否则、您能解释一下吗？


感谢你的帮助！

Matt、您好！

1) 1)否、据我所知、mmcblk0和 mmcblk1未固定。 上面的 stackoverflow 文章声称、mmcblk0用于用于引导电路板的任何操作。 我没有自己运行测试来仔细检查该断言。

2) 2)您提到、如果您没有禁用任何功能、有一种引导至终端的方法、对吧？ 我想您可以在该用例中使用 udev。  

我们是否知道您的 EMMC 工作正常？ 我的理解是、设计中根本没有 SD 卡读取器。 是这样吗？

3) 3)您能否发布与 MMC 相关的所有 devicetree 节点？

4) 4) Uboot MMC 调试通常比 Linux MMC 调试更简单。 使用 MMC 命令在 uboot 中测试 EMMC 可能很有价值。 确保您可以与它实际通信。

此致、

Nick

您好、Nick、

以下是与 MMC 相关的设备树节点：
am33xx.dtsi：不变、使用 BeagleBone Black 默认值
      mmc1：MMC@48060000｛
         兼容="ti、omAP4-hsmmc"；
         ti、hwmds ="mmc1"；
         TI、双电压；
         TI,需要特殊重置;
         TI、需要特殊处理；
         DMA =<&EDMA_Xbar 24 0
            EDMA_Xbar 25 0 0>；
         dma-names ="TX"、"Rx"；
         中断=<64>；
         REG =<0x48060000 0x1000>；
         STATUS ="禁用"；
      }；

      mmc2：MMC@481d8000｛
         兼容="ti、omAP4-hsmmc"；
         ti、hwmds ="mmc2"；
         TI,需要特殊重置;
         DMA =<&EDMA 2 0
            EDMA 3 0>(&E)；
         dma-names ="TX"、"Rx"；
         中断=<28>；
         reg =<0x481d8000 0x1000>；
         STATUS ="禁用"；
      }；

      mmc3：MMC@47810000｛
         兼容="ti、omAP4-hsmmc"；
         ti、hwmds ="mmc3"；
         TI,需要特殊重置;
         中断=<29>；
         REG =<0x47810000 0x1000>；
         STATUS ="禁用"；
      }；
   
在 AM335x-bone-common.dtsi 中：不变、使用 BeagleBone Black 默认值
 mmc1_pins：pinmux_mmc1_pins｛
   pinctrl-single、pins =<
     AM33XX_IOPAD (0x960、PIN_INPUT | MUX_MODE7)         /* spio0_CS1.GPIO0_6 *
     AM33XX_IOPAD (0x8fc、PIN_INPUT_PULLUP | MUX_MODE0)  /* mmc0_data0.mmc0_data0 */
     AM33XX_IOPAD (0x8f8、PIN_INPUT_PULLUP | MUX_MODE0)  /* mmc0_data1.mmc0_data1 *
     AM33XX_IOPAD (0x8f4、PIN_INPUT_PULLUP | MUX_MODE0)  /* mmc0_data2.mmc0_data2 *
     AM33XX_IOPAD (0x8f0、PIN_INPUT_PULLUP | MUX_MODE0)  /* mmc0_dat3.mmc0_data3 *
     AM33XX_IOPAD (0x904、PIN_INPUT_PULLUP | MUX_MODE0)  /* mmc0_cmd.mmc0_cmd *
     AM33XX_IOPAD (0x900、PIN_INPUT_PULLUP | MUX_MODE0)  /* mmc0_clk.mmc0_clk *
     AM33XX_IOPAD (0x9a0、PIN_INPUT | MUX_MODE4)         /* McASP0_aclkr.mmc0_sdwp *
   >；
 }；

   eMMC_Pins：pinmux_eMMC_Pins｛
      pinctrl-single、pins =<
         AM33XX_IOPAD (0x880、PIN_INPUT_PULLUP | MUX_MODE2)/* GPMC_csn1.mmc1_clk *
         AM33XX_IOPAD (0x884、PIN_INPUT_PULLUP | MUX_MODE2)/* GPMC_csn2.mmc1_cmd *
         AM33XX_IOPAD (0x800、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_ad0.mmc1_data0 *
         AM33XX_IOPAD (0x804、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_AD1.mmc1_DAT1 *
         AM33XX_IOPAD (0x808、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_AD2.mmc1_DAT2 *
         AM33XX_IOPAD (0x80c、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_ad3.mmc1_dat3 *
         AM33XX_IOPAD (0x810、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_AD4.mmc1_dat4 *
         AM33XX_IOPAD (0x814、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_ad5.mmc1_dat5 *
         AM33XX_IOPAD (0x818、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_AD6.mmc1_dat6 *
         AM33XX_IOPAD (0x81c、PIN_INPUT_PULLUP | MUX_MODE1)/* GPMC_AD7.mmc1_dat7 *
      >；
   }；
 
 (笑声)

mmc1｛(&M)
   状态="正常"；
   总线宽度=<0x4>；
   pinctrl-names ="default"；
   pinctrl-0 =<&mmc1_PINs>；
   CD-GPIO =<&GPIO0 6 GPIO_ACTIVE_LOW>；
}；

在 AM335x-bone-black-common.dtsi 中：禁用 mmc1 (SD 卡)
mmc1｛(&M)
   VMMC-SUPPLY =<&vmmcsd_fixed>；
 STATUS ="禁用"；
}；

mmc2｛(&M)
   VMMC-SUPPLY =<&vmmcsd_fixed>；
   pinctrl-names ="default"；
   pinctrl-0 =<&eMMC_PINs>；
   总线宽度=<8>；
   状态="正常"；
}；

Linux 从 eMMC (mmc2或 mmcblk1)引导、如果 mmc1 (SD 卡)和 mmc2 (eMMC)的状态均为"正常"、则运行到用户应用程序。 因此、我确信 eMMC 工作正常。 是的、设计中没有 SD 卡。

当我为 mmc1 (SD 卡)设置状态="禁用"或移除 mmc1节点时、Linux 不会从 eMMC (mmc2或 mmcblk1)引导。 这是我先前发送的引导日志。

谢谢你。

Matt、您好！

我假设您已经在执行此操作、但只需确保：pinmux 设置仅在与引导期间探测到的节点关联时才适用。 因此、禁用 MMC1后、将不再应用 mmc1_pins 中的任何引脚多路复用设置。 同样、my_GPIO2_Pins 必须与一个器件树节点关联、该节点需要探测才能进行设置。

如果您访问 AM335x-bone-common.dtsi 并在此处设置 mmc1的状态="禁用"、它会发生什么变化吗？

如果没有任何变化、我会很想看到正在运行和不工作的引导转储

dmesg | grep mmc 

此致、

Nick

您好、Nick、

是的、我认为我要配置的引脚多路复用设置位于启用的节点内。

我没有尝试在 AM335x-bone-common.dtsi 中设置 status ="disabled"、因为我能够在 AM335x-bone-blue-common.dtsi 中禁用 mmc1节点。 如果需要、我会尝试。

以下是工作案例的 dmesg 日志：(启用了 mmc1和 mmc2)
# dmesg | grep mmc
[0.000000]   内核命令行：console=ttyS0、115200 root=/dev/mmcblk1p3 rootwait RW IP=DHCP
[1.123807]   OMAP-Hsmmc 48060000.MMC：消费类 CD 的 GPIO 查找
[1.123815]   omap_hsmmc 48060000.mmc：使用器件树进行 GPIO 查找
[1.123849]   of _get_named_gpio_FLAGS：解析了节点'/ocp/mmc@48060000[0]'的'CD-GPIO'属性-状态(0)
[1.123913]   omap_hmc 48060000.mmc：获得 CD GPIO
[1.128560]   omap_hsmmc 48060000.mmc：GPIO 查找消费类 WP
[1.128565]   omap_hsmmc 48060000.mmc：使用器件树进行 GPIO 查找
[1.128573]   of _get_named_gpio_FLAGS：无法解析节点'/ocp/mmc@48060000[0]的'WP-GPIO'属性
[1.128581]   of_get_named_gpio_FLAGS：无法解析节点'/ocp/mmc@48060000[0]的'WP-GPIO'属性
[1.128587]   OMAP_hsmmc 48060000.MMC：使用查找表进行 GPIO 查找
[1.128595]   OMAP-Hsmmc 48060000.MMC：查找 GPIO WP 失败
[1.181396]   omap_hsmmc 481d8000.mmc：消费类 CD 的 GPIO 查找
[1.181408]   OMAP_hsmmc 481d8000.MMC：使用器件树进行 GPIO 查找
[1.181423]   of _get_named_gpiod_flags：无法解析节点'/ocp/mmc@481d8000[0]的'CD-GPIO'属性
[1.181430]   of _get_named_gpio_FLAGS：无法解析节点'/ocp/mmc@481d8000[0]的'CD-GPIO'属性
[1.181436]   omap_hsmmc 481d8000.mmc：使用查找表进行 GPIO 查找
[1.181443]   omap_hsmmc 481d8000.mmc：查找 GPIO CD 失败
[1.181451]   OMAP-Hsmmc 481d8000.MMC：用于消费类 WP 的 GPIO 查找
[1.181456]   omap_hsmmc 481d8000.mmc：使用器件树进行 GPIO 查找
[1.181463]   of _get_named_gpio_FLAGS：无法解析节点'/ocp/mmc@481d8000[0]的'wP-GPIO'属性
[1.181470]   of _get_named_gpio_FLAGS：无法解析节点'/ocp/mmc@481d8000[0]的'wP-GPIO'属性
[1.181475]   omap_hsmmc 481d8000.mmc：使用查找表进行 GPIO 查找
[1.181480]   omap_hsmmc 481d8000.mmc：查找 GPIO WP 失败
[1.318683]   mmc1：地址0001处的新高速 MMC 卡
[1.324655]   mmcblk1：mmc1：0001 IS004G 3.64 GiB
[1.329371]   mmcblk1boot0：mmc1：0001 IS004G 分区1 2.00 mib
[1.335570]   mmcblk1boot1：mmc1：0001 IS004G 分区2 2.00 mib
[1.341716]   mmcblk1rpmb：mmc1：0001 IS004G 分区3 512 KiB
[1.349035]    mmcblk1：P1 P2 P3
[4.047617]   EXT4-FS (mmcblk1p3)：恢复完成
[4.053236]   EXT4-FS (mmcblk1p3)：已安装文件系统、具有有序数据模式。 OPTS：(空)
[6.863648]   EXT4-FS (mmcblk1p3)：已重新安装。 opts：data= ordered
[8.080763]   FAT-FS (mmcblk1p1)：卷未正确卸载。 某些数据可能已损坏。 请运行 fsck。

以下是不起作用的情况的 Linux 内核日志：(禁用 mmc1、启用 mmc2)。 我在这里引导时发送 Linux 内核日志、因为系统没有引导到我可以运行 dmesg 的位置。
# grep "MMC" remove_mmc1_node_log.txt
[51.919721]  EXT4-FS (mmcblk1p3)：已重新安装。 opts：data= ordered
[0.000000]   内核命令行：console=ttyS0、115200 root=/dev/mmcblk1p2 rootwait RW           IP=DHCP
[1.258188]   mmc0：地址0001处的新高速 MMC 卡
[1.264138]   mmcblk0：mmc0：0001 IS004G 3.64 GiB
[1.268854]   mmcblk0boot0：mmc0：0001 IS004G 分区1 2.00 mib
[1.275056]   mmcblk0boot1：mmc0：0001 IS004G 分区2 2.00 mib
[1.2812]   mmcblk0rpmb：mmc0：0001 IS004G 分区3 512 KiB
[1.288520]    mmcblk0：P1 P2 P3
[3.767134]   正在等待根设备/dev/mmcblk1p2...

我怀疑如果我设置 u-boot env mmcdev = 0而不是 mmcdev = 1、不起作用的情况可能会成功引导？ 但我想知道、我们是否可以告诉 Linux 内核仅探测 mmc2 (mmcblk1)、而不探测 mmc1 (mmcblk0)？ 或者、如果您有更多见解、请告诉我。


非常感谢您的帮助！

Matt、您好！

是的、查看日志、我认为开始测试的最佳方法是将 u-boot env 变量更改为指向 mmcblk0而不是 mmcblk1。

在器件树文件注释：TLDR 上、我们似乎不必担心状态=已启用的设置、这些设置在以后的 DTS 文件中被覆盖。

我知道编译器从自上而下读取 DTS 文件(我认为这是将包含的文件放在 DTS 文件顶部的一个原因、因此可以按预期覆盖这些文件)。 但是、我不确定输出 DTB 文件是否结构类似于 DTS 文件(例如、DTB 具有单独的 node1｛｝设置、然后是 node1｛｝设置、然后是 node1｛｝设置)、或者是否所有设置都被压缩到单个节点中(例如、应用 node1｛｝设置、然后应用 node1｛｝设置、node1｛｝设置、node1｝设置、node1｝设置、node1｛1｝设置、node1｝设置、node1、 但在 DTB 文件中、将其压缩为单个节点1)。 仔细观察后、DTB 似乎将所有节点1设置压缩到单个节点、而不是在不同时间点读取的多个设置。

此致、

Nick

您好、Nick、

因此、在这种情况下、如果禁用了 mmc1 (SD 卡)、Linux 内核无法将 MMC 器件分配为 mmcblk1 (eMMC)。 它始终为启用的 MMC 设备分配 mmcblk0。 是这样吗？ 请确认。

感谢你的帮助！

Matt、您好！

默认情况下、Linux 开始使用0对 mmcblk 进行编号。 可能有一种方法可以更改 Linux 的编号方案、但这超出了我可以支持的范围。 只调整 uboot env 变量可能更容易。

此致、

Nick

您好、Nick、

非常感谢您的支持。 我尝试更改 u-boot env 变量 mmcdev = 0。 但是、看起来我仍然缺少一些东西。

当 u-boot 引导时、它仍然将 SD 卡称为 MMC 0、eMMC 作为 MMC 1。 因此、我会遇到以下错误。

=> MMC DEV 0
=> MMC 重新扫描
=> MMC 列表
OMAP SD/MMC：0
OMAP SD/MMC：1 (eMMC)
=> Fatload MMC 0 80200000 dtb
**设备 MMC 0 **错误

需要在 u-boot 中更改什么以将 MMC 0指向 eMMC？

或者、这可能看起来很奇怪。 但是、也许我可以让所有 u-boot 命令使用 mmcdev = 1、但只需更改命令行以指向 mmcblk0？

非常感谢！

Matt、您好！

让我将其重新分配给 Uboot 所有者。 他们将能够更好地评论如何在 Uboot 中使用 mmcdev。

此致、

Nick

谢谢、Nick。

我要感谢你的所有支持。 它可以帮助我了解有关 Linux 设备树的更多详细信息并找到问题的解决方案。 是的、请帮助转发 u-boot 相关问题所有者。

再次感谢！