[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 at 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>