[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi,

I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:

U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
Trying to boot from MMC1
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I haven't debugged this yet.

Does anyone have any ideas?

Thanks,

Fabio Estevam

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Jagan Teki]

On Thu, May 16, 2019 at 11:02 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi,
>
> I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
>
> U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19

No device.

Is it DM-SPL-enabled? check with u-boot,dm-spl on associated nodes?

usdhc3 is  for sabresd, seems like gpio2 missing to add u-boot,dm-spl

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Jagan,

On Thu, May 16, 2019 at 2:37 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Thu, May 16, 2019 at 11:02 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > Hi,
> >
> > I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
> >
> > U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> > Trying to boot from MMC1
> > spl: could not find mmc device 0. error: -19
>
> No device.
>
> Is it DM-SPL-enabled? check with u-boot,dm-spl on associated nodes?

Yes, configs/mx6sabresd_defconfig has CONFIG_SPL_DM=y.

arch/arm/dts/imx6qp-sabresd-u-boot.dtsi passes u-boot,dm-spl to usdhc3.

>
> usdhc3 is  for sabresd, seems like gpio2 missing to add u-boot,dm-spl

I tried:

--- a/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
@@ -12,3 +12,7 @@
 &pinctrl_usdhc3 {
        u-boot,dm-spl;
 };
+
+&gpio2 {
+       u-boot,dm-spl;
+};

but still not booting.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 16, 2019 at 2:32 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi,
>
> I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
>
> U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> I haven't debugged this yet.
>
> Does anyone have any ideas?

SPL is able to load u-boot-dtb.img if I disable CONFIG_SPL_DM:

--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-CONFIG_SPL_DM=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x12000000
 CONFIG_FASTBOOT_BUF_SIZE=0x10000000

Do we really want to use DM within SPL?

If we do, does anyone know how to fix it?

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Lukasz Majewski]

On Thu, 16 May 2019 16:40:56 -0300
Fabio Estevam <festevam@gmail.com> wrote:

> On Thu, May 16, 2019 at 2:32 PM Fabio Estevam <festevam@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I get the following error when trying to boot mx6q sabresd with
> > 2019.07-rc2:
> >
> > U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> > Trying to boot from MMC1
> > spl: could not find mmc device 0. error: -19
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> >
> > I haven't debugged this yet.
> >
> > Does anyone have any ideas?  
> 
> SPL is able to load u-boot-dtb.img if I disable CONFIG_SPL_DM:
> 
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
>  CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -CONFIG_SPL_DM=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0x12000000
>  CONFIG_FASTBOOT_BUF_SIZE=0x10000000
> 
> Do we really want to use DM within SPL?
> 
> If we do, does anyone know how to fix it?

Please find following repository with DM/DTS conversion for TPC70 imx6q
board (it also has SPL DM conversion working - board boots from SD
card and eMMC):

https://github.com/lmajewski/u-boot-dfu/commits/DM-SPL-TPC70

My guess is that you need the pinctrl DM support in SPL, to make the
card detect pin working.

&pinctrl_usdhc4 {
	u-boot,dm-spl;
};

&pinctrl_usdhc2 {
	u-boot,dm-spl;
};

&gpio2 {
	u-boot,dm-spl;
};

And also the pinctrl-imx6q.c fix to:

static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info
__section(".data");


To sum up: TPC70 (imx6q) has support for DM/DTS in both SPL and u-boot
proper.

The issue with this port is that it uses Common Clock Framework from
Linux and would need SPL's OF_PLATDATA support in eMMC and uart drivers
to reduce SPL size.



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190516/ce5edb60/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Peng Fan]

Hi Fabio

Booting from SD3, it works for me. See below log.

"
U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
Trying to boot from MMC1


U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C)Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Smart Device Board
"

Regards,
Peng.

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: 2019年5月17日 1:33
> To: Stefano Babic <sbabic@denx.de>; dl-uboot-imx <uboot-imx@nxp.com>
> Cc: Lukasz Majewski <lukma@denx.de>; Jagan Teki
> <jagan@amarulasolutions.com>; Michael Trimarchi
> <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>
> Subject: Cannot boot mx6qsabred with 2019.07-rc2
> 
> Hi,
> 
> I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
> 
> U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from
> MMC1
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot from all boot devices ### ERROR ### Please RESET the
> board ###
> 
> I haven't debugged this yet.
> 
> Does anyone have any ideas?
> 
> Thanks,
> 
> Fabio Estevam

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Lukasz,

On Thu, May 16, 2019 at 6:49 PM Lukasz Majewski <lukma@denx.de> wrote:

> Please find following repository with DM/DTS conversion for TPC70 imx6q
> board (it also has SPL DM conversion working - board boots from SD
> card and eMMC):
>
> https://github.com/lmajewski/u-boot-dfu/commits/DM-SPL-TPC70
>
> My guess is that you need the pinctrl DM support in SPL, to make the
> card detect pin working.
>
> &pinctrl_usdhc4 {
>         u-boot,dm-spl;
> };
>
> &pinctrl_usdhc2 {
>         u-boot,dm-spl;
> };
>
> &gpio2 {
>         u-boot,dm-spl;
> };
>
> And also the pinctrl-imx6q.c fix to:
>
> static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info
> __section(".data");

I tried your suggestions and now it dies even earlier:

U-Boot SPL 2019.07-rc1-00427-g504bf790da-dirty (May 16 2019 - 23:17:43 -0300)
### ERROR ### Please RESET the board ###

Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Peng,

On Thu, May 16, 2019 at 11:17 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> Hi Fabio
>
> Booting from SD3, it works for me. See below log.
>
> "
> U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
> Trying to boot from MMC1
>
>
> U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
>
> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU:   Automotive temperature grade (-40C to 125C)Reset cause: POR
> Model: Freescale i.MX6 Quad SABRE Smart Device Board

Interesting.

It fails for me and for a customer with the same error log.

What could explain such difference?

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Peng Fan]

> Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> 
> Hi Peng,
> 
> On Thu, May 16, 2019 at 11:17 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > Hi Fabio
> >
> > Booting from SD3, it works for me. See below log.
> >
> > "
> > U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800) Trying to boot
> > from MMC1
> >
> >
> > U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
> >
> > CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> > CPU:   Automotive temperature grade (-40C to 125C)Reset cause: POR
> > Model: Freescale i.MX6 Quad SABRE Smart Device Board
> 
> Interesting.
> 
> It fails for me and for a customer with the same error log.
> 
> What could explain such difference?

You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds.
Then see what happends.
I have no idea, then. My board is REV C4, chip 1.5

Regards,
Peng.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com> wrote:

> You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds.
> Then see what happends.

Even without DEBUG enabled we get useful error messages:

U-Boot SPL 2019.07-rc2 (May 17 2019 - 09:30:33 -0300)
Trying to boot from MMC1
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

This means that
err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev); fails inside
common/spl/spl_mmc.c

Why does this happen?

About the size difference:

Original defconfig generates an SPL of 76800 bytes
With CONFIG_SPL_DM=y removed the SPL size goes to 68608 bytes.

> I have no idea, then. My board is REV C4, chip 1.5

Mine is rev C2 with i.MX6Q rev1.2

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Lukasz Majewski]

On Fri, 17 May 2019 09:39:31 -0300
Fabio Estevam <festevam@gmail.com> wrote:

> On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com> wrote:
> 
> > You could enable DEBUG in SPL, and disable SPL_SDP because of size
> > will exceeds. Then see what happends.  
> 
> Even without DEBUG enabled we get useful error messages:
> 
> U-Boot SPL 2019.07-rc2 (May 17 2019 - 09:30:33 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19

I had similar issue on imx53 (hsc). The problem was with not properly
set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card
detect, so the SPL code after checking this got the impression that the
card is missing -> hence the -19 error.

Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9


> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> This means that
> err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev); fails inside
> common/spl/spl_mmc.c
> 
> Why does this happen?
> 
> About the size difference:
> 
> Original defconfig generates an SPL of 76800 bytes
> With CONFIG_SPL_DM=y removed the SPL size goes to 68608 bytes.
> 
> > I have no idea, then. My board is REV C4, chip 1.5  
> 
> Mine is rev C2 with i.MX6Q rev1.2




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190517/d8dfc783/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Lukasz,

On Fri, May 17, 2019 at 9:58 AM Lukasz Majewski <lukma@denx.de> wrote:

> I had similar issue on imx53 (hsc). The problem was with not properly
> set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card
> detect, so the SPL code after checking this got the impression that the
> card is missing -> hence the -19 error.
>
> Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9

I have also tried passing  the 'non-removable' property and still get
the -19 error.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Jagan Teki]

On Mon, May 20, 2019 at 7:37 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Lukasz,
>
> On Fri, May 17, 2019 at 9:58 AM Lukasz Majewski <lukma@denx.de> wrote:
>
> > I had similar issue on imx53 (hsc). The problem was with not properly
> > set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card
> > detect, so the SPL code after checking this got the impression that the
> > card is missing -> hence the -19 error.
> >
> > Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9
>
> I have also tried passing  the 'non-removable' property and still get
> the -19 error.

Look very strange, I have checked sabresd which has similar configs
and dts changes as icorem6. Thought that it would be another issue wrt
spl changes on this board, bisect might help?

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Peng,

On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com> wrote:

> You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds.
> Then see what happends.
> I have no idea, then. My board is REV C4, chip 1.5

My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.

After further investigation we can confirm that the problem is caused
by SPL size being greater than the 68kB limit (4KB header + 64KB max
size)as explained in include/configs/imx6_spl.h:

---------------
#ifndef __IMX6_SPL_CONFIG_H
#define __IMX6_SPL_CONFIG_H

#ifdef CONFIG_SPL
/*
 * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
 *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
 *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as well
 *  - BOOT ROM stack is at 0x0091FFB8
 *  - if icache/dcache is enabled (eFuse/strapping controlled) then the
 *    IMX BOOT ROM will setup MMU table at 0x00918000, therefore we need to
 *    fit between 0x00907000 and 0x00918000.
 *  - Additionally the BOOT ROM loads what they consider the firmware image
 *    which consists of a 4K header in front of us that contains the IVT, DCD
 *    and some padding thus 'our' max size is really 0x00908000 - 0x00918000
 *    or 64KB
 */
#define CONFIG_SPL_MAX_SIZE             0x10000
#define CONFIG_SPL_STACK                0x0091FFB8
/*
 * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
 * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
 * boot media (given that boot media specific offset is configured properly).
 */
#define CONFIG_SPL_PAD_TO               0x11000
---------------

Here are the tests I ran:

Test 1: Original U-Boot 2019.07-rc2
-----------------------------------------------

SPL: 76800 (75 kB)
Result: does not boot

Test 2: Removing extra dtbs
-------------------------------------

--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
-CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
+CONFIG_OF_LIST="imx6q-sabresd"
 CONFIG_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
+CONFIG_SPL_OF_LIST="imx6q-sabresd"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_SPL_DM=y

SPL:68608 (67 kB)
Result: boots correctly

Test 3: Removing SPL_DM
------------------------------------

--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-CONFIG_SPL_DM=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x12000000
 CONFIG_FASTBOOT_BUF_SIZE=0x10000000

SPL: 68608 (67 kB)
Result: boots correctly

I will send a v2 removing CONFIG_SPL_DM.

Also, the SPL size check should be really done after the multi fit
image is concatenated so that we can have a chance to detect such size
overflow in build time.

Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Peng Fan]

Hi Fabio,

> Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> 
> Hi Peng,
> 
> On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com> wrote:
> 
> > You could enable DEBUG in SPL, and disable SPL_SDP because of size will
> exceeds.
> > Then see what happends.
> > I have no idea, then. My board is REV C4, chip 1.5
> 
> My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
> 
> After further investigation we can confirm that the problem is caused by SPL
> size being greater than the 68kB limit (4KB header + 64KB max size)as
> explained in include/configs/imx6_spl.h:
> 
> ---------------
> #ifndef __IMX6_SPL_CONFIG_H
> #define __IMX6_SPL_CONFIG_H
> 
> #ifdef CONFIG_SPL
> /*
>  * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
>  *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
>  *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as
> well
>  *  - BOOT ROM stack is at 0x0091FFB8
>  *  - if icache/dcache is enabled (eFuse/strapping controlled) then the
>  *    IMX BOOT ROM will setup MMU table at 0x00918000, therefore we
> need to
>  *    fit between 0x00907000 and 0x00918000.
>  *  - Additionally the BOOT ROM loads what they consider the firmware
> image
>  *    which consists of a 4K header in front of us that contains the IVT, DCD
>  *    and some padding thus 'our' max size is really 0x00908000 -
> 0x00918000
>  *    or 64KB
>  */
> #define CONFIG_SPL_MAX_SIZE             0x10000
> #define CONFIG_SPL_STACK                0x0091FFB8
> /*
>  * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
>  * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
>  * boot media (given that boot media specific offset is configured properly).
>  */
> #define CONFIG_SPL_PAD_TO               0x11000
> ---------------
> 
> Here are the tests I ran:
> 
> Test 1: Original U-Boot 2019.07-rc2
> -----------------------------------------------
> 
> SPL: 76800 (75 kB)
> Result: does not boot
> 
> Test 2: Removing extra dtbs
> -------------------------------------
> 
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
> CONFIG_OF_CONTROL=y  CONFIG_SPL_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
> +CONFIG_OF_LIST="imx6q-sabresd"
>  CONFIG_MULTI_DTB_FIT=y
>  CONFIG_SPL_MULTI_DTB_FIT=y
> -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> +CONFIG_SPL_OF_LIST="imx6q-sabresd"
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_SPL_DM=y
> 
> SPL:68608 (67 kB)
> Result: boots correctly
> 
> Test 3: Removing SPL_DM
> ------------------------------------
> 
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
> CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -CONFIG_SPL_DM=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0x12000000
>  CONFIG_FASTBOOT_BUF_SIZE=0x10000000
> 
> SPL: 68608 (67 kB)
> Result: boots correctly
> 
> I will send a v2 removing CONFIG_SPL_DM.

So what is the real direction moving to use SPL driver, non-dm is allowed in future?

> 
> Also, the SPL size check should be really done after the multi fit image is
> concatenated so that we can have a chance to detect such size overflow in
> build time.

Agree. I also meet that SPL size is too large on i.MX8/8M, although still have OCRAM for it.

Regards,
Peng.

> 
> Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Wed, May 22, 2019 at 01:38:44AM +0000, Peng Fan wrote:
> Hi Fabio,
> 
> > Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> > 
> > Hi Peng,
> > 
> > On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com> wrote:
> > 
> > > You could enable DEBUG in SPL, and disable SPL_SDP because of size will
> > exceeds.
> > > Then see what happends.
> > > I have no idea, then. My board is REV C4, chip 1.5
> > 
> > My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
> > 
> > After further investigation we can confirm that the problem is caused by SPL
> > size being greater than the 68kB limit (4KB header + 64KB max size)as
> > explained in include/configs/imx6_spl.h:
> > 
> > ---------------
> > #ifndef __IMX6_SPL_CONFIG_H
> > #define __IMX6_SPL_CONFIG_H
> > 
> > #ifdef CONFIG_SPL
> > /*
> >  * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
> >  *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
> >  *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as
> > well
> >  *  - BOOT ROM stack is at 0x0091FFB8
> >  *  - if icache/dcache is enabled (eFuse/strapping controlled) then the
> >  *    IMX BOOT ROM will setup MMU table at 0x00918000, therefore we
> > need to
> >  *    fit between 0x00907000 and 0x00918000.
> >  *  - Additionally the BOOT ROM loads what they consider the firmware
> > image
> >  *    which consists of a 4K header in front of us that contains the IVT, DCD
> >  *    and some padding thus 'our' max size is really 0x00908000 -
> > 0x00918000
> >  *    or 64KB
> >  */
> > #define CONFIG_SPL_MAX_SIZE             0x10000
> > #define CONFIG_SPL_STACK                0x0091FFB8
> > /*
> >  * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
> >  * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
> >  * boot media (given that boot media specific offset is configured properly).
> >  */
> > #define CONFIG_SPL_PAD_TO               0x11000
> > ---------------
> > 
> > Here are the tests I ran:
> > 
> > Test 1: Original U-Boot 2019.07-rc2
> > -----------------------------------------------
> > 
> > SPL: 76800 (75 kB)
> > Result: does not boot
> > 
> > Test 2: Removing extra dtbs
> > -------------------------------------
> > 
> > --- a/configs/mx6sabresd_defconfig
> > +++ b/configs/mx6sabresd_defconfig
> > @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
> > CONFIG_OF_CONTROL=y  CONFIG_SPL_OF_CONTROL=y
> > CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> > -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
> > +CONFIG_OF_LIST="imx6q-sabresd"
> >  CONFIG_MULTI_DTB_FIT=y
> >  CONFIG_SPL_MULTI_DTB_FIT=y
> > -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> > +CONFIG_SPL_OF_LIST="imx6q-sabresd"
> >  CONFIG_ENV_IS_IN_MMC=y
> >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> >  CONFIG_SPL_DM=y
> > 
> > SPL:68608 (67 kB)
> > Result: boots correctly
> > 
> > Test 3: Removing SPL_DM
> > ------------------------------------
> > 
> > --- a/configs/mx6sabresd_defconfig
> > +++ b/configs/mx6sabresd_defconfig
> > @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
> > CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> >  CONFIG_ENV_IS_IN_MMC=y
> >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > -CONFIG_SPL_DM=y
> >  CONFIG_USB_FUNCTION_FASTBOOT=y
> >  CONFIG_FASTBOOT_BUF_ADDR=0x12000000
> >  CONFIG_FASTBOOT_BUF_SIZE=0x10000000
> > 
> > SPL: 68608 (67 kB)
> > Result: boots correctly
> > 
> > I will send a v2 removing CONFIG_SPL_DM.
> 
> So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> 
> > 
> > Also, the SPL size check should be really done after the multi fit image is
> > concatenated so that we can have a chance to detect such size overflow in
> > build time.
> 
> Agree. I also meet that SPL size is too large on i.MX8/8M, although still have OCRAM for it.

As came up in another thread, CONFIG_MMC_TINY may be more widely useable
and should help with space.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190521/26068ba0/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Lukasz Majewski]

Hi Tom, Peng, Fabio,

> On Wed, May 22, 2019 at 01:38:44AM +0000, Peng Fan wrote:
> > Hi Fabio,
> >   
> > > Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> > > 
> > > Hi Peng,
> > > 
> > > On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com>
> > > wrote: 
> > > > You could enable DEBUG in SPL, and disable SPL_SDP because of
> > > > size will  
> > > exceeds.  
> > > > Then see what happends.
> > > > I have no idea, then. My board is REV C4, chip 1.5  
> > > 
> > > My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
> > > 
> > > After further investigation we can confirm that the problem is
> > > caused by SPL size being greater than the 68kB limit (4KB header
> > > + 64KB max size)as explained in include/configs/imx6_spl.h:
> > > 
> > > ---------------
> > > #ifndef __IMX6_SPL_CONFIG_H
> > > #define __IMX6_SPL_CONFIG_H
> > > 
> > > #ifdef CONFIG_SPL
> > > /*
> > >  * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
> > >  *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
> > >  *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support
> > > IMX6SDL as well
> > >  *  - BOOT ROM stack is at 0x0091FFB8
> > >  *  - if icache/dcache is enabled (eFuse/strapping controlled)
> > > then the
> > >  *    IMX BOOT ROM will setup MMU table at 0x00918000, therefore
> > > we need to
> > >  *    fit between 0x00907000 and 0x00918000.
> > >  *  - Additionally the BOOT ROM loads what they consider the
> > > firmware image
> > >  *    which consists of a 4K header in front of us that contains
> > > the IVT, DCD
> > >  *    and some padding thus 'our' max size is really 0x00908000 -
> > > 0x00918000
> > >  *    or 64KB
> > >  */
> > > #define CONFIG_SPL_MAX_SIZE             0x10000
> > > #define CONFIG_SPL_STACK                0x0091FFB8
> > > /*
> > >  * Pad SPL to 68KB (4KB header + 64KB max size). This allows to
> > > write the
> > >  * SPL/U-Boot combination generated with u-boot-with-spl.imx
> > > directly to a
> > >  * boot media (given that boot media specific offset is
> > > configured properly). */
> > > #define CONFIG_SPL_PAD_TO               0x11000
> > > ---------------
> > > 
> > > Here are the tests I ran:
> > > 
> > > Test 1: Original U-Boot 2019.07-rc2
> > > -----------------------------------------------
> > > 
> > > SPL: 76800 (75 kB)
> > > Result: does not boot
> > > 
> > > Test 2: Removing extra dtbs
> > > -------------------------------------
> > > 
> > > --- a/configs/mx6sabresd_defconfig
> > > +++ b/configs/mx6sabresd_defconfig
> > > @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y
> > > CONFIG_OF_CONTROL=y  CONFIG_SPL_OF_CONTROL=y
> > > CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
> > > -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
> > > +CONFIG_OF_LIST="imx6q-sabresd"
> > >  CONFIG_MULTI_DTB_FIT=y
> > >  CONFIG_SPL_MULTI_DTB_FIT=y
> > > -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> > > +CONFIG_SPL_OF_LIST="imx6q-sabresd"
> > >  CONFIG_ENV_IS_IN_MMC=y
> > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > >  CONFIG_SPL_DM=y
> > > 
> > > SPL:68608 (67 kB)
> > > Result: boots correctly
> > > 
> > > Test 3: Removing SPL_DM
> > > ------------------------------------
> > > 
> > > --- a/configs/mx6sabresd_defconfig
> > > +++ b/configs/mx6sabresd_defconfig
> > > @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y
> > > CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
> > >  CONFIG_ENV_IS_IN_MMC=y
> > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > -CONFIG_SPL_DM=y
> > >  CONFIG_USB_FUNCTION_FASTBOOT=y
> > >  CONFIG_FASTBOOT_BUF_ADDR=0x12000000
> > >  CONFIG_FASTBOOT_BUF_SIZE=0x10000000
> > > 
> > > SPL: 68608 (67 kB)
> > > Result: boots correctly
> > > 
> > > I will send a v2 removing CONFIG_SPL_DM.  
> > 
> > So what is the real direction moving to use SPL driver, non-dm is
> > allowed in future? 

I think that CONFIG_SPL_DM would be a natural, next step.

However, from my experience the size of SPL grows considerably when
e.g. fitImage is added (~4KiB), DM/DTB support (~8-12KiB), and the
OCRAM memory footprint (as we need space to have malloc).

Solution is to use all the CONFIG_*_TINY* options in SPL as well as
more widely use OF_PLATDATA. This however, would require further
changes in the DM aware (converted) drivers.

> > > 
> > > Also, the SPL size check should be really done after the multi
> > > fit image is concatenated so that we can have a chance to detect
> > > such size overflow in build time.  
> > 
> > Agree. I also meet that SPL size is too large on i.MX8/8M, although
> > still have OCRAM for it.  
> 
> As came up in another thread, CONFIG_MMC_TINY may be more widely
> useable and should help with space.
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/a7b20e89/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Tue, May 21, 2019 at 11:34 PM Tom Rini <trini@konsulko.com> wrote:

> As came up in another thread, CONFIG_MMC_TINY may be more widely useable
> and should help with space.

How it can be used exactly?

I tried it like this:

--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_TARGET_MX6SABRESD=y
-CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SPL=y
@@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_DM_VIDEO=y
 CONFIG_VIDEO_IPUV3=y
+CONFIG_SPL_MMC_TINY=y

, but the board does not boot:

U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300)
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
> On Tue, May 21, 2019 at 11:34 PM Tom Rini <trini@konsulko.com> wrote:
> 
> > As came up in another thread, CONFIG_MMC_TINY may be more widely useable
> > and should help with space.
> 
> How it can be used exactly?
> 
> I tried it like this:
> 
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
>  CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_SYS_MALLOC_F_LEN=0x4000
>  CONFIG_TARGET_MX6SABRESD=y
> -CONFIG_SPL_MMC_SUPPORT=y
>  CONFIG_SPL_SERIAL_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_SPL=y
> @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y
>  CONFIG_USB_ETHER_ASIX=y
>  CONFIG_DM_VIDEO=y
>  CONFIG_VIDEO_IPUV3=y
> +CONFIG_SPL_MMC_TINY=y
> 
> , but the board does not boot:
> 
> U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300)
> SPL: Unsupported Boot Device!
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###

Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how
to configure / use it, in the other thread.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/ed0f5f60/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/22/19 5:15 PM, Tom Rini wrote:
> On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
>> On Tue, May 21, 2019 at 11:34 PM Tom Rini <trini@konsulko.com> wrote:
>>
>>> As came up in another thread, CONFIG_MMC_TINY may be more widely useable
>>> and should help with space.
>>
>> How it can be used exactly?
>>
>> I tried it like this:
>>
>> --- a/configs/mx6sabresd_defconfig
>> +++ b/configs/mx6sabresd_defconfig
>> @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
>>  CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>  CONFIG_SYS_MALLOC_F_LEN=0x4000
>>  CONFIG_TARGET_MX6SABRESD=y
>> -CONFIG_SPL_MMC_SUPPORT=y
>>  CONFIG_SPL_SERIAL_SUPPORT=y
>>  CONFIG_NR_DRAM_BANKS=1
>>  CONFIG_SPL=y
>> @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y
>>  CONFIG_USB_ETHER_ASIX=y
>>  CONFIG_DM_VIDEO=y
>>  CONFIG_VIDEO_IPUV3=y
>> +CONFIG_SPL_MMC_TINY=y
>>
>> , but the board does not boot:
>>
>> U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300)
>> SPL: Unsupported Boot Device!
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
> 
> Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how
> to configure / use it, in the other thread.

Look at what the CI20 does ? That board boots from SD and uses the TINY
stuff.

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Ezequiel Garcia]

On Wed, 2019-05-22 at 11:15 -0400, Tom Rini wrote:
> On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
> > On Tue, May 21, 2019 at 11:34 PM Tom Rini <trini@konsulko.com> wrote:
> > 
> > > As came up in another thread, CONFIG_MMC_TINY may be more widely useable
> > > and should help with space.
> > 
> > How it can be used exactly?
> > 
> > I tried it like this:
> > 
> > --- a/configs/mx6sabresd_defconfig
> > +++ b/configs/mx6sabresd_defconfig
> > @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
> >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
> >  CONFIG_SYS_MALLOC_F_LEN=0x4000
> >  CONFIG_TARGET_MX6SABRESD=y
> > -CONFIG_SPL_MMC_SUPPORT=y
> >  CONFIG_SPL_SERIAL_SUPPORT=y
> >  CONFIG_NR_DRAM_BANKS=1
> >  CONFIG_SPL=y
> > @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y
> >  CONFIG_USB_ETHER_ASIX=y
> >  CONFIG_DM_VIDEO=y
> >  CONFIG_VIDEO_IPUV3=y
> > +CONFIG_SPL_MMC_TINY=y
> > 
> > , but the board does not boot:
> > 
> > U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300)
> > SPL: Unsupported Boot Device!
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> 
> Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how
> to configure / use it, in the other thread.
> 

I was planning to look at this, and planned to start with a Wandboard I just happen
to have on my desk.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Peng,

On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:

> > I will send a v2 removing CONFIG_SPL_DM.
>
> So what is the real direction moving to use SPL driver, non-dm is allowed in future?

We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.

With CONFIG_SPL_DM selected the size increase due to the three dtb's
is about 8kB.

Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
still want to optimize the size further.

Two options that I want also to remove are:

CONFIG_SPL_FS_EXT4=y
CONFIG_SPL_I2C_SUPPORT=y

We are at -rc2 now, and I would really like to have mx6sabresd booting again.

Please check my v2 series and see if it looks good.

Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> Hi Peng,
> 
> On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
> 
> > > I will send a v2 removing CONFIG_SPL_DM.
> >
> > So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> 
> We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
> 
> With CONFIG_SPL_DM selected the size increase due to the three dtb's
> is about 8kB.
> 
> Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
> still want to optimize the size further.

So with CONFIG_SPL_DM we're overflowing by ~7kB?

> Two options that I want also to remove are:
> 
> CONFIG_SPL_FS_EXT4=y
> CONFIG_SPL_I2C_SUPPORT=y
> 
> We are at -rc2 now, and I would really like to have mx6sabresd booting again.
> 
> Please check my v2 series and see if it looks good.

We certainly want to do something to fix the regression, agreed.

Looking at the config, can we just use a fake DTB for SPL that works on
all 3 boards, rather than 3 DTBs?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190523/c55607cc/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/23/19 3:59 PM, Tom Rini wrote:
> On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
>> Hi Peng,
>>
>> On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
>>
>>>> I will send a v2 removing CONFIG_SPL_DM.
>>>
>>> So what is the real direction moving to use SPL driver, non-dm is allowed in future?
>>
>> We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
>>
>> With CONFIG_SPL_DM selected the size increase due to the three dtb's
>> is about 8kB.
>>
>> Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
>> still want to optimize the size further.
> 
> So with CONFIG_SPL_DM we're overflowing by ~7kB?
> 
>> Two options that I want also to remove are:
>>
>> CONFIG_SPL_FS_EXT4=y
>> CONFIG_SPL_I2C_SUPPORT=y
>>
>> We are at -rc2 now, and I would really like to have mx6sabresd booting again.
>>
>> Please check my v2 series and see if it looks good.
> 
> We certainly want to do something to fix the regression, agreed.
> 
> Looking at the config, can we just use a fake DTB for SPL that works on
> all 3 boards, rather than 3 DTBs?

Mind you, all of that seems like a workaround. Removing functionality
just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use
DM/DT in SPL because it just won't fit and I believe that absolutely
makes sense ; why should we impose DM/DT in SPL on MX6 only to make it
less usable?

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Abel Vesa]

On 19-05-23 09:59:05, Tom Rini wrote:
> On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> > Hi Peng,
> > 
> > On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
> > 
> > > > I will send a v2 removing CONFIG_SPL_DM.
> > >
> > > So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> > 
> > We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
> > 
> > With CONFIG_SPL_DM selected the size increase due to the three dtb's
> > is about 8kB.
> > 
> > Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
> > still want to optimize the size further.
> 
> So with CONFIG_SPL_DM we're overflowing by ~7kB?
> 

Well, the mandatory requirements here are as follow (AFAIK):
1. keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
2. have DM support in SPL

So I guess we have to either prioritize the other needed configs and
leave out the one we can do without. That, ofcourse, if we still want
to fit in and we still want one binary for all three sabresd boards.

> > Two options that I want also to remove are:
> > 
> > CONFIG_SPL_FS_EXT4=y
> > CONFIG_SPL_I2C_SUPPORT=y
> > 
> > We are at -rc2 now, and I would really like to have mx6sabresd booting again.
> > 
> > Please check my v2 series and see if it looks good.
> 
> We certainly want to do something to fix the regression, agreed.
> 
> Looking at the config, can we just use a fake DTB for SPL that works on
> all 3 boards, rather than 3 DTBs?
> 
> -- 
> Tom



> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Flistinfo%2Fu-boot&amp;data=02%7C01%7Cabel.vesa%40nxp.com%7C54f9085be4bd4b141d4f08d6df86dfe8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636942167723464482&amp;sdata=%2B%2BpYTLntPp5vMtY0ImlL6FoM2X2m6NEn42HX6KxRz1s%3D&amp;reserved=0

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
> On 19-05-23 09:59:05, Tom Rini wrote:
> > On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> > > Hi Peng,
> > > 
> > > On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
> > > 
> > > > > I will send a v2 removing CONFIG_SPL_DM.
> > > >
> > > > So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> > > 
> > > We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
> > > 
> > > With CONFIG_SPL_DM selected the size increase due to the three dtb's
> > > is about 8kB.
> > > 
> > > Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
> > > still want to optimize the size further.
> > 
> > So with CONFIG_SPL_DM we're overflowing by ~7kB?
> 
> Well, the mandatory requirements here are as follow (AFAIK):
> 1. keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
> 2. have DM support in SPL
> 
> So I guess we have to either prioritize the other needed configs and
> leave out the one we can do without. That, ofcourse, if we still want
> to fit in and we still want one binary for all three sabresd boards.

Well, no, you don't have to use DM in SPL.  But what I'm wondering is if
we need qp/dl/q specific information at the SPL stage or if that can
wait until we're doing the real U-Boot.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190523/ba269c4b/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Michael Nazzareno Trimarchi]

Hi

On Thu, May 23, 2019 at 4:33 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
> > On 19-05-23 09:59:05, Tom Rini wrote:
> > > On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> > > > Hi Peng,
> > > >
> > > > On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
> > > >
> > > > > > I will send a v2 removing CONFIG_SPL_DM.
> > > > >
> > > > > So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> > > >
> > > > We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
> > > >
> > > > With CONFIG_SPL_DM selected the size increase due to the three dtb's
> > > > is about 8kB.
> > > >
> > > > Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
> > > > still want to optimize the size further.
> > >
> > > So with CONFIG_SPL_DM we're overflowing by ~7kB?
> >
> > Well, the mandatory requirements here are as follow (AFAIK):
> > 1. keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
> > 2. have DM support in SPL
> >
> > So I guess we have to either prioritize the other needed configs and
> > leave out the one we can do without. That, ofcourse, if we still want
> > to fit in and we still want one binary for all three sabresd boards.
>
> Well, no, you don't have to use DM in SPL.  But what I'm wondering is if
> we need qp/dl/q specific information at the SPL stage or if that can
> wait until we're doing the real U-Boot.
>

Is dcd table take space?

Michael

> --
> Tom
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Thu, May 23, 2019 at 04:47:59PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Thu, May 23, 2019 at 4:33 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
> > > On 19-05-23 09:59:05, Tom Rini wrote:
> > > > On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> > > > > Hi Peng,
> > > > >
> > > > > On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
> > > > >
> > > > > > > I will send a v2 removing CONFIG_SPL_DM.
> > > > > >
> > > > > > So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> > > > >
> > > > > We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
> > > > >
> > > > > With CONFIG_SPL_DM selected the size increase due to the three dtb's
> > > > > is about 8kB.
> > > > >
> > > > > Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
> > > > > still want to optimize the size further.
> > > >
> > > > So with CONFIG_SPL_DM we're overflowing by ~7kB?
> > >
> > > Well, the mandatory requirements here are as follow (AFAIK):
> > > 1. keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
> > > 2. have DM support in SPL
> > >
> > > So I guess we have to either prioritize the other needed configs and
> > > leave out the one we can do without. That, ofcourse, if we still want
> > > to fit in and we still want one binary for all three sabresd boards.
> >
> > Well, no, you don't have to use DM in SPL.  But what I'm wondering is if
> > we need qp/dl/q specific information at the SPL stage or if that can
> > wait until we're doing the real U-Boot.
> 
> Is dcd table take space?

The DCD table is included in that hard size limit, but yes, if there's
QP/DL/Q specific stuff that we could handle via the plugin mechanism or
similar, that might be part of the solution.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190523/bd825e62/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Thu, May 23, 2019 at 04:04:17PM +0200, Marek Vasut wrote:
> On 5/23/19 3:59 PM, Tom Rini wrote:
> > On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> >> Hi Peng,
> >>
> >> On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
> >>
> >>>> I will send a v2 removing CONFIG_SPL_DM.
> >>>
> >>> So what is the real direction moving to use SPL driver, non-dm is allowed in future?
> >>
> >> We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
> >>
> >> With CONFIG_SPL_DM selected the size increase due to the three dtb's
> >> is about 8kB.
> >>
> >> Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
> >> still want to optimize the size further.
> > 
> > So with CONFIG_SPL_DM we're overflowing by ~7kB?
> > 
> >> Two options that I want also to remove are:
> >>
> >> CONFIG_SPL_FS_EXT4=y
> >> CONFIG_SPL_I2C_SUPPORT=y
> >>
> >> We are at -rc2 now, and I would really like to have mx6sabresd booting again.
> >>
> >> Please check my v2 series and see if it looks good.
> > 
> > We certainly want to do something to fix the regression, agreed.
> > 
> > Looking at the config, can we just use a fake DTB for SPL that works on
> > all 3 boards, rather than 3 DTBs?
> 
> Mind you, all of that seems like a workaround. Removing functionality
> just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use
> DM/DT in SPL because it just won't fit and I believe that absolutely
> makes sense ; why should we impose DM/DT in SPL on MX6 only to make it
> less usable?

Setting aside that as I said you don't have to use DM in SPL, maybe it's
also worth noting you don't have to provide "describes the whole board"
DTB files.  If as far as SPL is concerned there's no difference between
board A, B and C, just make a DTS that describes the relevant hardware.

Also, platdata can help here too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190523/35244ca6/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Jagan Teki]

On Fri, May 17, 2019 at 6:09 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Thu, May 16, 2019 at 11:29 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> > You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds.
> > Then see what happends.
>
> Even without DEBUG enabled we get useful error messages:
>
> U-Boot SPL 2019.07-rc2 (May 17 2019 - 09:30:33 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> This means that
> err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev); fails inside
> common/spl/spl_mmc.c
>
> Why does this happen?
>
> About the size difference:
>
> Original defconfig generates an SPL of 76800 bytes
> With CONFIG_SPL_DM=y removed the SPL size goes to 68608 bytes.
>
> > I have no idea, then. My board is REV C4, chip 1.5
>
> Mine is rev C2 with i.MX6Q rev1.2

Don't know whether this is SPL size issue or not? can you try
SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
(one build issue on fdtdec_get_int undefined)

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:

> Don't know whether this is SPL size issue or not? can you try
> SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
> (one build issue on fdtdec_get_int undefined)

Yes, it does not build with CONFIG_SPL_OF_PLATDATA:

lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
/home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
drivers/built-in.o: In function `fsl_esdhc_probe':
/home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
to `fdtdec_get_int'
/home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
to `fdtdec_get_int'
/home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
to `fdtdec_get_int'
scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1

Thanks for the suggestions, but at this point I prefer to go with the
removal of CONFIG_SPL_DM.

For 2019.07 it would be really nice if we could fix these two issues:

1. Allow to load a FIT image via Serial Download Protocol

2. Detect the SPL size overflow in build-time

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Jagan Teki]

On Thu, May 23, 2019 at 10:18 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > Don't know whether this is SPL size issue or not? can you try
> > SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
> > (one build issue on fdtdec_get_int undefined)
>
> Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
>
> lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
> /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'

Couldn't dig much here, would be happy someone can find this?

> drivers/built-in.o: In function `fsl_esdhc_probe':
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
> to `fdtdec_get_int'
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
> to `fdtdec_get_int'
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference

These we can fix, by supporting platdata support into driver.

> to `fdtdec_get_int'
> scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1
>
> Thanks for the suggestions, but at this point I prefer to go with the
> removal of CONFIG_SPL_DM.

We have 45 days to release, I think we can make these fixes quite
normally what do you think? fsl_esdhc.c build I can mark a patch in
few days if required.

>
> For 2019.07 it would be really nice if we could fix these two issues:
>
> 1. Allow to load a FIT image via Serial Download Protocol
>
> 2. Detect the SPL size overflow in build-time

1) We are working on this, 2) can be done.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 23, 2019 at 2:07 PM Jagan Teki <jagan@amarulasolutions.com> wrote:

> We have 45 days to release, I think we can make these fixes quite
> normally what do you think? fsl_esdhc.c build I can mark a patch in
> few days if required.

Sure, bug fixes are always welcome :-)

> >
> > For 2019.07 it would be really nice if we could fix these two issues:
> >
> > 1. Allow to load a FIT image via Serial Download Protocol
> >
> > 2. Detect the SPL size overflow in build-time
>
> 1) We are working on this, 2) can be done.

Cool, please keep me in the loop for the Serial Download Protocol issue.

Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Schrempf Frieder]

On 23.05.19 19:07, Jagan Teki wrote:
> On Thu, May 23, 2019 at 10:18 PM Fabio Estevam <festevam@gmail.com> wrote:
>>
>> On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>
>>> Don't know whether this is SPL size issue or not? can you try
>>> SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
>>> (one build issue on fdtdec_get_int undefined)
>>
>> Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
>>
>> lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
>> /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
> 
> Couldn't dig much here, would be happy someone can find this?
> 
>> drivers/built-in.o: In function `fsl_esdhc_probe':
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
>> to `fdtdec_get_int'
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
>> to `fdtdec_get_int'
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
> 
> These we can fix, by supporting platdata support into driver.
> 
>> to `fdtdec_get_int'
>> scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>>
>> Thanks for the suggestions, but at this point I prefer to go with the
>> removal of CONFIG_SPL_DM.
> 
> We have 45 days to release, I think we can make these fixes quite
> normally what do you think? fsl_esdhc.c build I can mark a patch in
> few days if required.
> 
>>
>> For 2019.07 it would be really nice if we could fix these two issues:
>>
>> 1. Allow to load a FIT image via Serial Download Protocol
>>
>> 2. Detect the SPL size overflow in build-time
> 
> 1) We are working on this, 2) can be done.

As luck would have it, I needed to load a FIT via SDP today, so I came 
up with a quick patch (see below). There are probably better ways to do 
this, but it works.

#############################

commit 408b9d26eea48e6f85dd087750629f7a4095c73d
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
Date:   Thu May 23 14:52:47 2019 +0200

     Allow SPL to load and boot FIT via SDP

diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 807256e908..8f990a83a3 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -25,10 +25,13 @@ static int spl_sdp_load_image(struct spl_image_info 
*spl_image,
  		return -ENODEV;
  	}

-	/* This command typically does not return but jumps to an image */
-	sdp_handle(controller_index);
-	pr_err("SDP ended\n");
+	/*
+	 * This command either loads a legacy image, jumps and never returns,
+	 * or it loads a FIT image and returns it to be handled by the SPL code.
+	 */
+	ret = sdp_handle(controller_index, spl_image);
+	debug("SDP ended\n");

-	return -EINVAL;
+	return ret;
  }
  SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD, 
spl_sdp_load_image);
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index ae97ab2b49..5690060a2f 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -638,7 +638,18 @@ static u32 sdp_jump_imxheader(void *address)
  	return 0;
  }

-static void sdp_handle_in_ep(void)
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
+			  ulong count, void *buf)
+{
+	debug("%s: sector %lx, count %lx, buf %lx\n",
+	      __func__, sector, count, (ulong)buf);
+	memcpy(buf, (void *)(load->dev + sector), count);
+	return count;
+}
+#endif
+
+static void sdp_handle_in_ep(struct spl_image_info *spl_image)
  {
  	u8 *data = sdp_func->in_req->buf;
  	u32 status;
@@ -689,11 +700,25 @@ static void sdp_handle_in_ep(void)

  		/* If imx header fails, try some U-Boot specific headers */
  		if (status) {
+			image_header_t *header =
+				(void *)(u64)sdp_func->jmp_address;
  #ifdef CONFIG_SPL_BUILD
+#ifdef CONFIG_SPL_LOAD_FIT
+			if (image_get_magic(header) == FDT_MAGIC) {
+				struct spl_load_info load;
+
+				printf("Found FIT\n");
+				load.dev = (void *)(u64)sdp_func->jmp_address;
+				load.bl_len = 1;
+				load.read = sdp_fit_read;
+				spl_load_simple_fit(spl_image, &load, 0,
+						    header);
+				return;
+			}
+#endif
  			/* In SPL, allow jumps to U-Boot images */
  			struct spl_image_info spl_image = {};
-			spl_parse_image_header(&spl_image,
-				(struct image_header *)sdp_func->jmp_address);
+			spl_parse_image_header(&spl_image, header);
  			jump_to_image_no_args(&spl_image);
  #else
  			/* In U-Boot, allow jumps to scripts */
@@ -715,19 +740,23 @@ static void sdp_handle_in_ep(void)
  	};
  }

-void sdp_handle(int controller_index)
+int sdp_handle(int controller_index, struct spl_image_info *spl_image)
  {
  	printf("SDP: handle requests...\n");
  	while (1) {
  		if (ctrlc()) {
  			puts("\rCTRL+C - Operation aborted.\n");
-			return;
+			return -EINVAL;
+		}
+
+		if (spl_image->flags & SPL_FIT_FOUND) {
+			return 0;
  		}

  		WATCHDOG_RESET();
  		usb_gadget_handle_interrupts(controller_index);

-		sdp_handle_in_ep();
+		sdp_handle_in_ep(spl_image);
  	}
  }

diff --git a/include/sdp.h b/include/sdp.h
index f6252d027f..f30e2bca19 100644
--- a/include/sdp.h
+++ b/include/sdp.h
@@ -9,7 +9,9 @@
  #ifndef __SDP_H_
  #define __SDP_H_

+#include <spl.h>
+
  int sdp_init(int controller_index);
-void sdp_handle(int controller_index);
+int sdp_handle(int controller_index, struct spl_image_info *spl_image);

  #endif /* __SDP_H_ */

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Schrempf,

On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:

> As luck would have it, I needed to load a FIT via SDP today, so I came
> up with a quick patch (see below). There are probably better ways to do
> this, but it works.

Thanks for your patch!

I would like to give it a try, but it does not apply against U-Boot mainline.

I manually applied it, but failed to build:

cmd/usb_gadget_sdp.c: In function ‘do_sdp’:
cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’
  sdp_handle(controller_index);

Could you please rebase it against U-Boot mainline and post it like a
formal patch?

Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/23/19 4:50 PM, Tom Rini wrote:
> On Thu, May 23, 2019 at 04:47:59PM +0200, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Thu, May 23, 2019 at 4:33 PM Tom Rini <trini@konsulko.com> wrote:
>>>
>>> On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
>>>> On 19-05-23 09:59:05, Tom Rini wrote:
>>>>> On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
>>>>>> Hi Peng,
>>>>>>
>>>>>> On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
>>>>>>
>>>>>>>> I will send a v2 removing CONFIG_SPL_DM.
>>>>>>>
>>>>>>> So what is the real direction moving to use SPL driver, non-dm is allowed in future?
>>>>>>
>>>>>> We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
>>>>>>
>>>>>> With CONFIG_SPL_DM selected the size increase due to the three dtb's
>>>>>> is about 8kB.
>>>>>>
>>>>>> Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
>>>>>> still want to optimize the size further.
>>>>>
>>>>> So with CONFIG_SPL_DM we're overflowing by ~7kB?
>>>>
>>>> Well, the mandatory requirements here are as follow (AFAIK):
>>>> 1. keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
>>>> 2. have DM support in SPL
>>>>
>>>> So I guess we have to either prioritize the other needed configs and
>>>> leave out the one we can do without. That, ofcourse, if we still want
>>>> to fit in and we still want one binary for all three sabresd boards.
>>>
>>> Well, no, you don't have to use DM in SPL.  But what I'm wondering is if
>>> we need qp/dl/q specific information at the SPL stage or if that can
>>> wait until we're doing the real U-Boot.
>>
>> Is dcd table take space?
> 
> The DCD table is included in that hard size limit, but yes, if there's
> QP/DL/Q specific stuff that we could handle via the plugin mechanism or
> similar, that might be part of the solution.

You do need Q/DL/S specific stuff in SPL for e.g. pinmux .
And you want to minimize the DCD table and move all that logic into SPL,
since the DCD is rather limited.

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/23/19 5:17 PM, Tom Rini wrote:
> On Thu, May 23, 2019 at 04:04:17PM +0200, Marek Vasut wrote:
>> On 5/23/19 3:59 PM, Tom Rini wrote:
>>> On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
>>>> Hi Peng,
>>>>
>>>> On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com> wrote:
>>>>
>>>>>> I will send a v2 removing CONFIG_SPL_DM.
>>>>>
>>>>> So what is the real direction moving to use SPL driver, non-dm is allowed in future?
>>>>
>>>> We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
>>>>
>>>> With CONFIG_SPL_DM selected the size increase due to the three dtb's
>>>> is about 8kB.
>>>>
>>>> Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I
>>>> still want to optimize the size further.
>>>
>>> So with CONFIG_SPL_DM we're overflowing by ~7kB?
>>>
>>>> Two options that I want also to remove are:
>>>>
>>>> CONFIG_SPL_FS_EXT4=y
>>>> CONFIG_SPL_I2C_SUPPORT=y
>>>>
>>>> We are at -rc2 now, and I would really like to have mx6sabresd booting again.
>>>>
>>>> Please check my v2 series and see if it looks good.
>>>
>>> We certainly want to do something to fix the regression, agreed.
>>>
>>> Looking at the config, can we just use a fake DTB for SPL that works on
>>> all 3 boards, rather than 3 DTBs?
>>
>> Mind you, all of that seems like a workaround. Removing functionality
>> just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use
>> DM/DT in SPL because it just won't fit and I believe that absolutely
>> makes sense ; why should we impose DM/DT in SPL on MX6 only to make it
>> less usable?
> 
> Setting aside that as I said you don't have to use DM in SPL

Right, that's an important concensus .

>, maybe it's
> also worth noting you don't have to provide "describes the whole board"
> DTB files.

That's what u-boot,dm-spl and CONFIG_OF_SPL_REMOVE_PROPS is for, yes ?

> If as far as SPL is concerned there's no difference between
> board A, B and C, just make a DTS that describes the relevant hardware.

Right

> Also, platdata can help here too.
> 


-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/23/19 7:45 PM, Fabio Estevam wrote:
> Hi Schrempf,
> 
> On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder
> <frieder.schrempf@kontron.de> wrote:
> 
>> As luck would have it, I needed to load a FIT via SDP today, so I came
>> up with a quick patch (see below). There are probably better ways to do
>> this, but it works.
> 
> Thanks for your patch!
> 
> I would like to give it a try, but it does not apply against U-Boot mainline.
> 
> I manually applied it, but failed to build:
> 
> cmd/usb_gadget_sdp.c: In function ‘do_sdp’:
> cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’
>   sdp_handle(controller_index);
> 
> Could you please rebase it against U-Boot mainline and post it like a
> formal patch?

And add a SoB line .

Why do you need to load fitImage via SDP btw ?

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Marek,

On Thu, May 23, 2019 at 2:54 PM Marek Vasut <marek.vasut@gmail.com> wrote:

> Why do you need to load fitImage via SDP btw ?

Let's suppose a i.MX6 board that boots from eMMC is bricked and we
need to load a new U-Boot to repair it.

imx_usb_loader is a very convenient tool to achieve this.

This method has been working well for a long time, but after DM
transition we can no longer load and run SPL + u-boot-dtb.img via SDP.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Jagan Teki]

On Thu, May 23, 2019 at 11:29 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Marek,
>
> On Thu, May 23, 2019 at 2:54 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> > Why do you need to load fitImage via SDP btw ?
>
> Let's suppose a i.MX6 board that boots from eMMC is bricked and we
> need to load a new U-Boot to repair it.
>
> imx_usb_loader is a very convenient tool to achieve this.
>
> This method has been working well for a long time, but after DM
> transition we can no longer load and run SPL + u-boot-dtb.img via SDP.

To be prescribe,  the issue with FIT formatted u-boot-dtb.img not the DM alone.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 23, 2019 at 3:01 PM Jagan Teki <jagan@amarulasolutions.com> wrote:

> To be prescribe,  the issue with FIT formatted u-boot-dtb.img not the DM alone.

Correct, what I meant to say is that after DM conversion we started
using FIT image on imx6sabresd board, which prevented SDP download to
work.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Adam Ford]

On Thu, May 23, 2019 at 12:59 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Marek,
>
> On Thu, May 23, 2019 at 2:54 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> > Why do you need to load fitImage via SDP btw ?
>
> Let's suppose a i.MX6 board that boots from eMMC is bricked and we
> need to load a new U-Boot to repair it.
>
> imx_usb_loader is a very convenient tool to achieve this.

I have been following this thread, because I have been working through
attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which
requires SPL_DM.

To working around the issue you're describing, I played with disabling
 SPL_DM_USB.  With that removed, I can still use nearly all the
benefits of SPL_DM without losing access to imx_usb_loader.
See log:

U-Boot SPL 2019.07-rc2-05214-g3c328a45af (May 23 2019 - 13:24:26 -0500)
Trying to boot from USB SDP
SDP: initialize...
SDP: handle requests...
Downloading file of size 626728 to 0x177fffc0... done
Jumping to header at 0x177fffc0
Header Tag is not an IMX image


U-Boot 2019.07-rc2-05214-g3c328a45af (May 23 2019 - 13:24:26 -0500)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: POR
Model: Logic PD i.MX6QD SOM-M3 (HDMI)
DRAM:  2 GiB
NAND:  0 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from FAT... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet at 2188000
Hit any key to stop autoboot:  0
i.MX6 Logic #

Having said that, I haven't posted all my updates yet, because I am
working on MMC start issues between MMC1 and MMC2.  If you'd like to
see some patches, etc. I can share them with you.

adam
>
> This method has been working well for a long time, but after DM
> transition we can no longer load and run SPL + u-boot-dtb.img via SDP.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Adam,

On Thu, May 23, 2019 at 3:28 PM Adam Ford <aford173@gmail.com> wrote:

> I have been following this thread, because I have been working through
> attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which
> requires SPL_DM.
>
> To working around the issue you're describing, I played with disabling
>  SPL_DM_USB.  With that removed, I can still use nearly all the
> benefits of SPL_DM without losing access to imx_usb_loader.
> See log:

I took a look at the configs/imx6q_logic_defconfig file and it does
not use FIT support like we do in mx6sabresd.

If I remove FIT support then imx_usb_loader works fine here too.

imx6q_logic_defconfig only supports the mx6q variant, whereas sabresd
needs to support mx6q/dl/qp variants , so we use FIT image that
contains therese 3 dtbs.

So the problem with SDP at the moment is when trying to load a FIT image.

Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Adam Ford]

On Thu, May 23, 2019 at 1:35 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Adam,
>
> On Thu, May 23, 2019 at 3:28 PM Adam Ford <aford173@gmail.com> wrote:
>
> > I have been following this thread, because I have been working through
> > attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which
> > requires SPL_DM.
> >
> > To working around the issue you're describing, I played with disabling
> >  SPL_DM_USB.  With that removed, I can still use nearly all the
> > benefits of SPL_DM without losing access to imx_usb_loader.
> > See log:
>
> I took a look at the configs/imx6q_logic_defconfig file and it does
> not use FIT support like we do in mx6sabresd.
>
> If I remove FIT support then imx_usb_loader works fine here too.
>
> imx6q_logic_defconfig only supports the mx6q variant, whereas sabresd
> needs to support mx6q/dl/qp variants , so we use FIT image that
> contains therese 3 dtbs.
>
> So the problem with SDP at the moment is when trying to load a FIT image.

Sorry.  I misunderstood the problem.

>
> Thanks

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/23/19 8:37 PM, Adam Ford wrote:
> On Thu, May 23, 2019 at 1:35 PM Fabio Estevam <festevam@gmail.com> wrote:
>>
>> Hi Adam,
>>
>> On Thu, May 23, 2019 at 3:28 PM Adam Ford <aford173@gmail.com> wrote:
>>
>>> I have been following this thread, because I have been working through
>>> attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which
>>> requires SPL_DM.
>>>
>>> To working around the issue you're describing, I played with disabling
>>>  SPL_DM_USB.  With that removed, I can still use nearly all the
>>> benefits of SPL_DM without losing access to imx_usb_loader.
>>> See log:
>>
>> I took a look at the configs/imx6q_logic_defconfig file and it does
>> not use FIT support like we do in mx6sabresd.
>>
>> If I remove FIT support then imx_usb_loader works fine here too.
>>
>> imx6q_logic_defconfig only supports the mx6q variant, whereas sabresd
>> needs to support mx6q/dl/qp variants , so we use FIT image that
>> contains therese 3 dtbs.
>>
>> So the problem with SDP at the moment is when trying to load a FIT image.
> 
> Sorry.  I misunderstood the problem.

Would it rather make sense to just stick with non-DM/DT SPL for iMX6 for
now?

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/23/19 7:59 PM, Fabio Estevam wrote:
> Hi Marek,
> 
> On Thu, May 23, 2019 at 2:54 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> 
>> Why do you need to load fitImage via SDP btw ?
> 
> Let's suppose a i.MX6 board that boots from eMMC is bricked and we
> need to load a new U-Boot to repair it.
> 
> imx_usb_loader is a very convenient tool to achieve this.
> 
> This method has been working well for a long time, but after DM
> transition we can no longer load and run SPL + u-boot-dtb.img via SDP.

Ah, can't you just use either non-DM/DT SPL (which is OK to do) or
combine SPL+DT into a single file , like some other boards do ?

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 23, 2019 at 7:04 PM Marek Vasut <marek.vasut@gmail.com> wrote:

> Ah, can't you just use either non-DM/DT SPL (which is OK to do) or
> combine SPL+DT into a single file , like some other boards do ?

There are two orthogonal issues we are discussing:

1. DM SPL size is beyond the limit for mx6sabresd. Yes, not using DM
SPL solves the issue here.

2. Not possible to boot FIT image via SDP. This problem is unrelated
to number 1 above.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Marek Vasut]

On 5/24/19 12:08 AM, Fabio Estevam wrote:
> On Thu, May 23, 2019 at 7:04 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> 
>> Ah, can't you just use either non-DM/DT SPL (which is OK to do) or
>> combine SPL+DT into a single file , like some other boards do ?
> 
> There are two orthogonal issues we are discussing:
> 
> 1. DM SPL size is beyond the limit for mx6sabresd. Yes, not using DM
> SPL solves the issue here.

I think it makes sense to go this way and fix the MX6 before too many
people get cranky about this forcible DM/DT push , which cripples the
boards left and right.

> 2. Not possible to boot FIT image via SDP. This problem is unrelated
> to number 1 above.

Right

-- 
Best regards,
Marek Vasut

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

On Thu, May 23, 2019 at 7:11 PM Marek Vasut <marek.vasut@gmail.com> wrote:

> I think it makes sense to go this way and fix the MX6 before too many
> people get cranky about this forcible DM/DT push , which cripples the
> boards left and right.

Yes, patch has been sent:
https://lists.denx.de/pipermail/u-boot/2019-May/370224.html

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Tom Rini]

On Thu, May 23, 2019 at 01:48:21PM -0300, Fabio Estevam wrote:
> On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> 
> > Don't know whether this is SPL size issue or not? can you try
> > SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
> > (one build issue on fdtdec_get_int undefined)
> 
> Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
> 
> lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
> /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
> drivers/built-in.o: In function `fsl_esdhc_probe':
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
> to `fdtdec_get_int'
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
> to `fdtdec_get_int'
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
> to `fdtdec_get_int'
> scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1
> 
> Thanks for the suggestions, but at this point I prefer to go with the
> removal of CONFIG_SPL_DM.
> 
> For 2019.07 it would be really nice if we could fix these two issues:
> 
> 1. Allow to load a FIT image via Serial Download Protocol
> 
> 2. Detect the SPL size overflow in build-time

For #2, I am very hopeful we can pull in Simon Goldschmidt's patch that
allows us to set the size limit in such ways as to catch overflows like
this.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190524/bd971409/attachment.sig>

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Simon Goldschmidt]

Am 24.05.2019 um 19:43 schrieb Tom Rini:
> On Thu, May 23, 2019 at 01:48:21PM -0300, Fabio Estevam wrote:
>> On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>
>>> Don't know whether this is SPL size issue or not? can you try
>>> SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
>>> (one build issue on fdtdec_get_int undefined)
>>
>> Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
>>
>> lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
>> /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
>> drivers/built-in.o: In function `fsl_esdhc_probe':
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
>> to `fdtdec_get_int'
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
>> to `fdtdec_get_int'
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
>> to `fdtdec_get_int'
>> scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>>
>> Thanks for the suggestions, but at this point I prefer to go with the
>> removal of CONFIG_SPL_DM.
>>
>> For 2019.07 it would be really nice if we could fix these two issues:
>>
>> 1. Allow to load a FIT image via Serial Download Protocol
>>
>> 2. Detect the SPL size overflow in build-time
> 
> For #2, I am very hopeful we can pull in Simon Goldschmidt's patch that
> allows us to set the size limit in such ways as to catch overflows like
> this.

Hehe, right, I'm feeling the pressure ;-)

Cheers,
Simon

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Schrempf Frieder]

Hi Fabio,

On 23.05.19 19:45, Fabio Estevam wrote:
> Hi Schrempf,
> 
> On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder
> <frieder.schrempf@kontron.de> wrote:
> 
>> As luck would have it, I needed to load a FIT via SDP today, so I came
>> up with a quick patch (see below). There are probably better ways to do
>> this, but it works.
> 
> Thanks for your patch!
> 
> I would like to give it a try, but it does not apply against U-Boot mainline.
> 
> I manually applied it, but failed to build:
> 
> cmd/usb_gadget_sdp.c: In function ‘do_sdp’:
> cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’
>    sdp_handle(controller_index);

Sorry, I just picked the patch from my messy working tree and it's based 
on 2019.04 and some other changes.

> Could you please rebase it against U-Boot mainline and post it like a
> formal patch?

I need to do some rebasing and cleanup, but I'm definitely planning to 
send this as a patch for upstream.

Thanks,
Frieder

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Fabio Estevam]

Hi Schrempf,

On Mon, May 27, 2019 at 3:40 AM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:

> I need to do some rebasing and cleanup, but I'm definitely planning to
> send this as a patch for upstream.

Excellent, thanks!

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Peng Fan]

> Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> 
> On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com>
> wrote:
> 
> > Don't know whether this is SPL size issue or not? can you try
> > SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
> > (one build issue on fdtdec_get_int undefined)
> 
> Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
> 
> lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
> /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
> drivers/built-in.o: In function `fsl_esdhc_probe':
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to
> `fdtdec_get_int'
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to
> `fdtdec_get_int'
> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference to
> `fdtdec_get_int'
> scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1

Need the following patch.

diff --git a/lib/Makefile b/lib/Makefile
index 09c45b8122..66ab6295a5 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -88,7 +88,7 @@ obj-y += crc32.o
 obj-$(CONFIG_CRC32C) += crc32c.o
 obj-y += ctype.o
 obj-y += div64.o
-obj-$(CONFIG_OF_LIBFDT) += fdtdec.o
+obj-$(CONFIG_OF_LIBFDT) += fdtdec.o fdtdec_common.o
 obj-y += hang.o
 obj-y += linux_compat.o
 obj-y += linux_string.o

> 
> Thanks for the suggestions, but at this point I prefer to go with the removal of
> CONFIG_SPL_DM.

Some drivers needs converted to use OF_PLATDATA, with remove the libfdt
api in fsl_esdhc driver, the size shrinked from ~70KB to ~60KB with OF_PLATDATA.

Regards,
Peng.

> 
> For 2019.07 it would be really nice if we could fix these two issues:
> 
> 1. Allow to load a FIT image via Serial Download Protocol
> 
> 2. Detect the SPL size overflow in build-time

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Peng Fan]

Hi Tom,

> Subject: Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
> 
> On Thu, May 23, 2019 at 04:04:17PM +0200, Marek Vasut wrote:
> > On 5/23/19 3:59 PM, Tom Rini wrote:
> > > On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
> > >> Hi Peng,
> > >>
> > >> On Tue, May 21, 2019 at 10:38 PM Peng Fan <peng.fan@nxp.com>
> wrote:
> > >>
> > >>>> I will send a v2 removing CONFIG_SPL_DM.
> > >>>
> > >>> So what is the real direction moving to use SPL driver, non-dm is
> allowed in future?
> > >>
> > >> We are very limited in space when CONFIG_SPL_DM is used on
> imx6q-sabresd.
> > >>
> > >> With CONFIG_SPL_DM selected the size increase due to the three
> > >> dtb's is about 8kB.
> > >>
> > >> Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so
> > >> I still want to optimize the size further.
> > >
> > > So with CONFIG_SPL_DM we're overflowing by ~7kB?
> > >
> > >> Two options that I want also to remove are:
> > >>
> > >> CONFIG_SPL_FS_EXT4=y
> > >> CONFIG_SPL_I2C_SUPPORT=y
> > >>
> > >> We are at -rc2 now, and I would really like to have mx6sabresd booting
> again.
> > >>
> > >> Please check my v2 series and see if it looks good.
> > >
> > > We certainly want to do something to fix the regression, agreed.
> > >
> > > Looking at the config, can we just use a fake DTB for SPL that works
> > > on all 3 boards, rather than 3 DTBs?
> >
> > Mind you, all of that seems like a workaround. Removing functionality
> > just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't
> > use DM/DT in SPL because it just won't fit and I believe that
> > absolutely makes sense ; why should we impose DM/DT in SPL on MX6 only
> > to make it less usable?
> 
> Setting aside that as I said you don't have to use DM in SPL, 

I recalled that TPL could be allowed for non-DM, SPL and U-Boot
need to migrate to DM, so now/future we non-DM SPL is ok?

Thanks,
Peng.

maybe it's also
> worth noting you don't have to provide "describes the whole board"
> DTB files.  If as far as SPL is concerned there's no difference between board
> A, B and C, just make a DTS that describes the relevant hardware.
> 
> Also, platdata can help here too.
> 
> --
> Tom

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Peng Fan]

Hi Jagan
> Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
> 
> On Thu, May 23, 2019 at 10:18 PM Fabio Estevam <festevam@gmail.com>
> wrote:
> >
> > On Thu, May 23, 2019 at 1:11 PM Jagan Teki <jagan@amarulasolutions.com>
> wrote:
> >
> > > Don't know whether this is SPL size issue or not? can you try
> > > SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512
> > > bytes (one build issue on fdtdec_get_int undefined)
> >
> > Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
> >
> > lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
> > /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to
> `fdtdec_get_int'
> 
> Couldn't dig much here, would be happy someone can find this?
> 
> > drivers/built-in.o: In function `fsl_esdhc_probe':
> > /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
> > to `fdtdec_get_int'
> > /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
> > to `fdtdec_get_int'
> > /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
> 
> These we can fix, by supporting platdata support into driver.
> 
> > to `fdtdec_get_int'
> > scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
> > make[1]: *** [spl/u-boot-spl] Error 1
> >
> > Thanks for the suggestions, but at this point I prefer to go with the
> > removal of CONFIG_SPL_DM.
> 
> We have 45 days to release, I think we can make these fixes quite normally
> what do you think? fsl_esdhc.c build I can mark a patch in few days if
> required.

Are you working on converting the driver to support OF_PLATDATA?

Regards,
Peng.

> 
> >
> > For 2019.07 it would be really nice if we could fix these two issues:
> >
> > 1. Allow to load a FIT image via Serial Download Protocol
> >
> > 2. Detect the SPL size overflow in build-time
> 
> 1) We are working on this, 2) can be done.

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Shyam Saini]

Hi Schrempf,

As of now imx usb loader does not process FIT images.
Have you added some patch or support on imx usb loader side ?

Thanks and regards,
Shyam

On Mon, May 27, 2019 at 12:10 PM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:
>
> Hi Fabio,
>
> On 23.05.19 19:45, Fabio Estevam wrote:
> > Hi Schrempf,
> >
> > On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder
> > <frieder.schrempf@kontron.de> wrote:
> >
> >> As luck would have it, I needed to load a FIT via SDP today, so I came
> >> up with a quick patch (see below). There are probably better ways to do
> >> this, but it works.
> >
> > Thanks for your patch!
> >
> > I would like to give it a try, but it does not apply against U-Boot mainline.
> >
> > I manually applied it, but failed to build:
> >
> > cmd/usb_gadget_sdp.c: In function ‘do_sdp’:
> > cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’
> >    sdp_handle(controller_index);
>
> Sorry, I just picked the patch from my messy working tree and it's based
> on 2019.04 and some other changes.
>
> > Could you please rebase it against U-Boot mainline and post it like a
> > formal patch?
>
> I need to do some rebasing and cleanup, but I'm definitely planning to
> send this as a patch for upstream.
>
> Thanks,
> Frieder
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

[Schrempf Frieder]

Hi Shyam,

On 31.05.19 11:10, Shyam Saini wrote:
> Hi Schrempf,
> 
> As of now imx usb loader does not process FIT images.
> Have you added some patch or support on imx usb loader side ?

No, I'm using imx_usb_loader only to load the FIT image to DRAM in SPL 
via SDP. The SPL is then processing the FIT image and loading U-Boot 
proper from the image.

Regards,
Frieder

> 
> Thanks and regards,
> Shyam
> 
> On Mon, May 27, 2019 at 12:10 PM Schrempf Frieder
> <frieder.schrempf@kontron.de> wrote:
>>
>> Hi Fabio,
>>
>> On 23.05.19 19:45, Fabio Estevam wrote:
>>> Hi Schrempf,
>>>
>>> On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder
>>> <frieder.schrempf@kontron.de> wrote:
>>>
>>>> As luck would have it, I needed to load a FIT via SDP today, so I came
>>>> up with a quick patch (see below). There are probably better ways to do
>>>> this, but it works.
>>>
>>> Thanks for your patch!
>>>
>>> I would like to give it a try, but it does not apply against U-Boot mainline.
>>>
>>> I manually applied it, but failed to build:
>>>
>>> cmd/usb_gadget_sdp.c: In function ‘do_sdp’:
>>> cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’
>>>     sdp_handle(controller_index);
>>
>> Sorry, I just picked the patch from my messy working tree and it's based
>> on 2019.04 and some other changes.
>>
>>> Could you please rebase it against U-Boot mainline and post it like a
>>> formal patch?
>>
>> I need to do some rebasing and cleanup, but I'm definitely planning to
>> send this as a patch for upstream.
>>
>> Thanks,
>> Frieder
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot