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

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

[Rudolf J Streif]

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

-------------- 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/94fe42d0/attachment.sig>

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>

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

[Fabio Estevam]

Hi Rudolf,

On Tue, May 19, 2020 at 1:28 AM Rudolf J Streif
<rudolf.streif@ibeeto.com> wrote:
>
> 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.

I had a similar issue on a pico-imx6ul board. I preferred to put the
MMC initialization code in SPL rather than relying on DM as in SPL we
are very tight in memory.

Please see this commit:
https://gitlab.denx.de/u-boot/u-boot/-/commit/9b8d9ec41a6f161d53d32bf71f79332236b44ba1

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

[Rudolf J Streif]

Hi Fabio

On 5/19/20 5:23 AM, Fabio Estevam wrote:
> Hi Rudolf,
>
> On Tue, May 19, 2020 at 1:28 AM Rudolf J Streif
> <rudolf.streif@ibeeto.com> wrote:
>> 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.
> I had a similar issue on a pico-imx6ul board. I preferred to put the
> MMC initialization code in SPL rather than relying on DM as in SPL we
> are very tight in memory.
>
> Please see this commit:
> https://gitlab.denx.de/u-boot/u-boot/-/commit/9b8d9ec41a6f161d53d32bf71f79332236b44ba1

Thank you so much. You pointed me into the right direction. I was able
to find a solution for my board.

Much appreciated.

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/20200519/21d9fa26/attachment.sig>