U-Boot DM device tree and Linux device tree - what are the differences and why?

[Rudolf J Streif]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200518/f5732b0e/attachment.sig>