From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Wed, 22 May 2019 07:52:21 +0200 Subject: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2 In-Reply-To: <20190522023410.GS22232@bill-the-cat> References: <20190522023410.GS22232@bill-the-cat> Message-ID: <20190522075221.7295d453@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > > 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: