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@denx.de