I solved the problem with u-boot not recognizing the eMMC. The device tree is working now for u-boot.
However, i.MX6 is using SPL which is loaded into OCRAM. If I flash SPL and u-boot to a boot partition on the eMMC the boot ROM loads SPL just fine but then SPL cannot load u-boot from eMMC: Trying to boot from MMC1 MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### If I enable CONFIG_SPL_DM=y and CONFIG_SPL_DM_MMC=y then I am getting this undefined reference (and a whole slew of other related to DM): common/built-in.o:(.u_boot_list_2_uclass_2_usb_hub+0x8): undefined reference to `dm_scan_fdt_dev' Even if I get this to link then the next question of course is if it will fit into the 68k OCRAM that the SoC has (the whole device tree infrastructure has a rather large footprint). It is hard to follow why the DM now is essentially enforced for storage media but does not seem to be tested with SPL. Once again, I appreciate any pointer to a possible solution. Rudi On 5/18/20 4:45 PM, Rudolf J Streif wrote: > I have a custom board that is similar to the i.MX6UL 14x14. One > difference is that it has an eMMC rather than a SD card. Most recently I > upgraded from u-boot 2019.07 to u-boot 2020.01 and now u-boot cannot > detect the eMMC anymore. > > For the 2019.07 version I did use CONFIG_FSL_ESDHC=y without > CONFIG_DM_MMC. That does not work anymore. Compilation fails with > "CONFIG_SYS_FSL_ESDHC_ADDR undefined". What has changed here and why? > > Then I tried using CONFIG_FSL_USDHC=y and CONFIG_DM_MMC=y. I simply used > the device tree from the Linux kernel which works just fine for the > kernel. But it does not work for u-boot. It's hard to understand why. > Why would the u-boot device tree be different than the kernel device > tree? If that is even the issue. > > It's an eMMC with 8-bit bus. Here are the definitions that work > perfectly well for the Linux kernel: > > &usdhc2 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_usdhc2>; > bus-width = <8>; > max-frequency = <200000000>; > vmmc-supply = <&sw2_reg>; > mmc-ddr-1_8v; > cap-mmc-highspeed; > non-removable; > keep-power-in-suspend; > status = "okay"; > }; > > pinctrl_usdhc2: usdhc2grp { > fsl,pins = < > MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x1b0d9 /* > eMMC_CLK */ > MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x1b0d9 /* > eMMC_CMD */ > MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x1b0d9 /* eMMC_RST */ > MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x1b0d9 /* > eMMC_DAT0 */ > MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x1b0d9 /* > eMMC_DAT1 */ > MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x1b0d9 /* > eMMC_DAT2 */ > MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x1b0d9 /* > eMMC_DAT3 */ > MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x1b0d9 /* > eMMC_DAT4 */ > MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x1b0d9 /* > eMMC_DAT5 */ > MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x1b0d9 /* > eMMC_DAT6 */ > MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x1b0d9 /* > eMMC_DAT7 */ > >; > }; > > Every time the eMMC is probed e.g 'mmc dev 1' it takes about a second > and then the response is 'MMC: no card present'. > > I appreciate the help. > > Thank you, > Rudi > -- ----- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700
signature.asc
Description: OpenPGP digital signature