[U-Boot] [PATCH] imx_common: spl: Fix SPL boot from SD card

newer
[U-Boot] [PATCH] Revert "ARM: mx6:...

Breno Lima

30 Nov 2016 30 Nov '16

6:12 p.m.

Since commit 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") we can no longer boot from SD card on a mx6sx Udoo neo board:

U-Boot SPL 2016.11-32108-g9cd37b0 (Nov 30 2016 - 11:05:54) Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

Prior to this commit we had the following logic:

/* SD/eSD: 8.5.3, Table 8-15 */ case 0x4: case 0x5: return BOOT_DEVICE_MMC1; /* MMC/eMMC: 8.5.3 */ case 0x6: case 0x7: return BOOT_DEVICE_MMC1;

and in the case of MX6SX Udoo board we entered the case 0x5 (SD card boot) and returned BOOT_DEVICE_MMC1 as expected.

Now this does not happen anymore and BOOT_DEVICE_MMC2 is returned, which breaks the boot.

In order to fix this problem keep the original behavior for the SD card case by returning BOOT_DEVICE_MMC1.

Tested on mx6cuboxi and mx6sx UDOO neo boards.

Signed-off-by: Breno Lima breno.lima@nxp.com --- arch/arm/imx-common/spl.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c index 325ba26..cbcd936 100644 --- a/arch/arm/imx-common/spl.c +++ b/arch/arm/imx-common/spl.c @@ -58,6 +58,7 @@ u32 spl_boot_device(void) /* SD/eSD: 8.5.3, Table 8-15 */ case 0x4: case 0x5: + return BOOT_DEVICE_MMC1; /* MMC/eMMC: 8.5.3 */ case 0x6: case 0x7:

-- 2.7.4

Show replies by date

Fabio Estevam

30 Nov 30 Nov

6:43 p.m.

On Wed, Nov 30, 2016 at 3:12 PM, Breno Lima breno.lima@nxp.com wrote:

...

Since commit 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") we can no longer boot from SD card on a mx6sx Udoo neo board:

U-Boot SPL 2016.11-32108-g9cd37b0 (Nov 30 2016 - 11:05:54) Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

Prior to this commit we had the following logic:
    /* SD/eSD: 8.5.3, Table 8-15  */
    case 0x4:
    case 0x5:
            return BOOT_DEVICE_MMC1;
    /* MMC/eMMC: 8.5.3 */
    case 0x6:
    case 0x7:
            return BOOT_DEVICE_MMC1;
and in the case of MX6SX Udoo board we entered the case 0x5 (SD card boot) and returned BOOT_DEVICE_MMC1 as expected.

Now this does not happen anymore and BOOT_DEVICE_MMC2 is returned, which breaks the boot.

In order to fix this problem keep the original behavior for the SD card case by returning BOOT_DEVICE_MMC1.

Tested on mx6cuboxi and mx6sx UDOO neo boards.

Signed-off-by: Breno Lima breno.lima@nxp.com

Makes sense, thanks:

Reviewed-by: Fabio Estevam fabio.estevam@nxp.com

Marcin Niestroj

2 Dec 2 Dec

3:11 p.m.

Hi,

On 30.11.2016 18:12, Breno Lima wrote:

...

Since commit 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") we can no longer boot from SD card on a mx6sx Udoo neo board:

U-Boot SPL 2016.11-32108-g9cd37b0 (Nov 30 2016 - 11:05:54) Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

Prior to this commit we had the following logic:

/* SD/eSD: 8.5.3, Table 8-15 */ case 0x4: case 0x5: return BOOT_DEVICE_MMC1; /* MMC/eMMC: 8.5.3 */ case 0x6: case 0x7: return BOOT_DEVICE_MMC1;

and in the case of MX6SX Udoo board we entered the case 0x5 (SD card boot) and returned BOOT_DEVICE_MMC1 as expected.

Why is BOOT_DEVICE_MMC1 expected here? As I see in Udoo neo schematics the SD card is connected to uSDHC2 port, because uSDHC1 is used for something else.

...

Now this does not happen anymore and BOOT_DEVICE_MMC2 is returned, which breaks the boot.

In order to fix this problem keep the original behavior for the SD card case by returning BOOT_DEVICE_MMC1.

Tested on mx6cuboxi and mx6sx UDOO neo boards.

Signed-off-by: Breno Lima breno.lima@nxp.com

arch/arm/imx-common/spl.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c index 325ba26..cbcd936 100644 --- a/arch/arm/imx-common/spl.c +++ b/arch/arm/imx-common/spl.c @@ -58,6 +58,7 @@ u32 spl_boot_device(void) /* SD/eSD: 8.5.3, Table 8-15 */ case 0x4: case 0x5:
 return BOOT_DEVICE_MMC1;
/* MMC/eMMC: 8.5.3 */ case 0x6: case 0x7:

-- Marcin Niestroj

Fabio Estevam

4:03 p.m.

Hi Marcin,

On Fri, Dec 2, 2016 at 12:11 PM, Marcin Niestroj m.niestroj@grinn-global.com wrote:

...

Why is BOOT_DEVICE_MMC1 expected here? As I see in Udoo neo schematics the SD card is connected to uSDHC2 port, because uSDHC1 is used for something else.

Yes, Udoo Neo boots from the SDHC2 port.

However BOOT_DEVICE_MMC1 does not mean "boot from the SDHC1 port". BOOT_DEVICE_MMC1 just tells SPL to boot from the first registered mmc device.

Please take a look at common/spl/spl_mmc.c

int spl_mmc_get_device_index(u32 boot_device) { switch (boot_device) { case BOOT_DEVICE_MMC1: return 0; case BOOT_DEVICE_MMC2: case BOOT_DEVICE_MMC2_2: return 1; }

,so we should return BOOT_DEVICE_MMC1 as we always did.

mx6cuboxi is also broken for the same reason.

If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1 port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") I suggest we need to revert it.

Marcin Niestroj

6:16 p.m.

On 02.12.2016 16:03, Fabio Estevam wrote:

...

Hi Marcin,

On Fri, Dec 2, 2016 at 12:11 PM, Marcin Niestroj m.niestroj@grinn-global.com wrote:

...
Why is BOOT_DEVICE_MMC1 expected here? As I see in Udoo neo schematics the SD card is connected to uSDHC2 port, because uSDHC1 is used for something else.

Yes, Udoo Neo boots from the SDHC2 port.

However BOOT_DEVICE_MMC1 does not mean "boot from the SDHC1 port". BOOT_DEVICE_MMC1 just tells SPL to boot from the first registered mmc device.

Please take a look at common/spl/spl_mmc.c

int spl_mmc_get_device_index(u32 boot_device) { switch (boot_device) { case BOOT_DEVICE_MMC1: return 0; case BOOT_DEVICE_MMC2: case BOOT_DEVICE_MMC2_2: return 1; }

,so we should return BOOT_DEVICE_MMC1 as we always did.

mx6cuboxi is also broken for the same reason.

If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1 port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") I suggest we need to revert it.

Indeed it was my assumption. I agree it should be reverted then.

So to support booting from two SD/MMC devices one should create board_boot_order() function? That way BOOT_CFG2[3:4] can be read there to figure out which MMC1 or MMC2 should be configured as the first boot device.

-- Marcin Niestroj

Fabio Estevam

8:05 p.m.

On Fri, Dec 2, 2016 at 3:16 PM, Marcin Niestroj m.niestroj@grinn-global.com wrote:

...

...
If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1 port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") I suggest we need to revert it.

Indeed it was my assumption. I agree it should be reverted then.

Thanks for confirming.

Stefano, would you like to take Breno's original patch with the revert? Or would you like me to resend it with an improved commit log explaining the reason for the breakage?

...

So to support booting from two SD/MMC devices one should create board_boot_order() function? That way BOOT_CFG2[3:4] can be read there to figure out which MMC1 or MMC2 should be configured as the first boot device.

If you want to determine the SD/MMC port dynamically it seems like a solution.

Or if you always know the SD/MMC port you will boot from then you can simply register the associated SDHC port first.

Stefano Babic

5 Dec 5 Dec

12:47 p.m.

Hi Fabio,

On 02/12/2016 20:05, Fabio Estevam wrote:

...

On Fri, Dec 2, 2016 at 3:16 PM, Marcin Niestroj m.niestroj@grinn-global.com wrote:

...
...
If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1 port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection support in SPL") I suggest we need to revert it.

Indeed it was my assumption. I agree it should be reverted then.

Thanks for confirming.

Stefano, would you like to take Breno's original patch with the revert?

I think it is ok to take Breno's original patch. It was just a misunderstanding and how boot device order is set was cleared in this thread.

Best regards, Stefano Babic

...

Or would you like me to resend it with an improved commit log explaining the reason for the breakage?

...
So to support booting from two SD/MMC devices one should create board_boot_order() function? That way BOOT_CFG2[3:4] can be read there to figure out which MMC1 or MMC2 should be configured as the first boot device.

If you want to determine the SD/MMC port dynamically it seems like a solution.

Or if you always know the SD/MMC port you will boot from then you can simply register the associated SDHC port first.

-- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================

3075

Age (days ago)

3080

Last active (days ago)

List overview

Download

6 comments

4 participants

tags (0)

participants (4)

Breno Lima
Fabio Estevam
Marcin Niestroj
Stefano Babic