imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

PATCH New Eran Matityahu 3 participants 13 messages Jan 3, 2018 – Jan 4, 2018

Subsystems (3)

Arm (32-bit) Arm sub-architectures Arm i.MX and Layerscape

lore

Share & tools

lore

Eran Matityahu

author

2018-01-03 10:53 UTC #0 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Use only one SPL MMC device, similarly to the iMX6 code

Signed-off-by Eran Matityahu <[email protected]>

---
 arch/arm/mach-imx/spl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/arm/mach-imx/spl.c +1 -2

index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
 	switch (boot_device_spl) {
 	case SD1_BOOT:
 	case MMC1_BOOT:
-		return BOOT_DEVICE_MMC1;
 	case SD2_BOOT:
 	case MMC2_BOOT:
-		return BOOT_DEVICE_MMC2;
+		return BOOT_DEVICE_MMC1;
 	case SPI_NOR_BOOT:
 		return BOOT_DEVICE_SPI;
 	default:

Signature · 1 line

2.16.0-rc0

Uri Mashiach

2018-01-03 11:42 UTC #1 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Hello Eran,

Quoted 1 line · Eran Matityahu

Use only one SPL MMC device, similarly to the iMX6 code

What is the reason for not using MMC2?

Quoted 23 lines

Signed-off-by Eran Matityahu <[email protected]>

---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

arch/arm/mach-imx/spl.c +1 -2

index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
  	switch (boot_device_spl) {
  	case SD1_BOOT:
  	case MMC1_BOOT:
-		return BOOT_DEVICE_MMC1;
  	case SD2_BOOT:
  	case MMC2_BOOT:
-		return BOOT_DEVICE_MMC2;
+		return BOOT_DEVICE_MMC1;
  	case SPI_NOR_BOOT:
  		return BOOT_DEVICE_SPI;
  	default:

Signature · 2 lines

Regards,
Uri

Eran Matityahu

author

2018-01-03 13:58 UTC #2 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Hi Uri.

Quoted 8 lines

Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?

The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.

Quoted 20 lines

Signed-off-by Eran Matityahu <[email protected]>

---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

arch/arm/mach-imx/spl.c +1 -2

index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:
-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;

Quoted 8 lines

arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 4 lines
arch/arm/mach-imx/spl.c +0 -0
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:
--
Regards,
Uri

Regards,
Eran

Uri Mashiach

2018-01-04 08:36 UTC #3 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 6 lines · Eran Matityahu

Hi Uri.
Quoted 4 lines
Hello Eran,
Quoted 1 line · Eran Matityahu

Quoted 9 lines

Quoted 4 lines
Quoted 1 line
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.

A problematic scenario is a detection, by the boot ROM, of the SPL image at MMC2.
If the U-Boot image is located at MMC2, the boot sequence will be terminated.

Quoted 17 lines

Signed-off-by Eran Matityahu <[email protected]>

---
   arch/arm/mach-imx/spl.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

arch/arm/mach-imx/spl.c +0 -1

index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
         switch (boot_device_spl) {
         case SD1_BOOT:
         case MMC1_BOOT:
-               return BOOT_DEVICE_MMC1;
         case SD2_BOOT:

[...]

Signature · 2 lines

Regards,
Uri

Stefano Babic

2018-01-04 09:14 UTC #4 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

In reply to Eran Matityahu

Hi Eran,

Quoted 22 lines · Eran Matityahu

Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

Quoted 16 lines

Quoted 8 lines

arch/arm/mach-imx/spl.c +0 -0

index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:

Quoted 8 lines

arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114

Quoted 8 lines

arch/arm/mach-imx/spl.c +1 -2

-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:

The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.

According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.

If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.

Best regards,
Stefano Babic

Signature · 5 lines

=====================================================================
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 at denx.de
=====================================================================

Eran Matityahu

author

2018-01-04 10:02 UTC #5 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 51 lines · Stefano Babic

Hi Eran,
Quoted 22 lines · Eran Matityahu
Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.

Quoted 5 lines

If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic

The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.

In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation.
Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.

With this patch I can use get_boot_device() inside board_mmc_init() and only initialize the MMC device I want to load the next image from (usually the same device).

I know I can approach it differently and change the spl_boot_list[0] device to BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change the iMX6 code to do the same.

Quoted 7 lines

--
=====================================================================
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 at denx.de
=====================================================================

Eran Matityahu

author

2018-01-04 10:11 UTC #6 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 77 lines · Eran Matityahu

Quoted 51 lines · Stefano Babic
Hi Eran,
Quoted 22 lines · Eran Matityahu
Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation.
Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and only initialize the MMC device I want to load the next image from (usually the same device).

Quoted 7 lines

I know I can approach it differently and change the spl_boot_list[0] device to BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change the iMX6 code to do the same.

By the way, in my opinion, the iMX6 way (and this patch also), is the preferred way,
since usually you'll only need one MMC device in SPL.

Regards,
Eran

Quoted 7 lines

Quoted 7 lines
--
=====================================================================
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 at denx.de
=====================================================================

Stefano Babic

2018-01-04 10:42 UTC #7 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 78 lines · Eran Matityahu

Quoted 77 lines · Eran Matityahu
Quoted 51 lines · Stefano Babic
Hi Eran,
Quoted 22 lines · Eran Matityahu
Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation.
Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and only initialize the MMC device I want to load the next image from (usually the same device).

Quoted 8 lines

Quoted 7 lines
I know I can approach it differently and change the spl_boot_list[0] device to BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change the iMX6 code to do the same.
By the way, in my opinion, the iMX6 way

The imx6 way is the right way to do - rather, i.MX7 does not follow the same approach.

In i.MX6 code, spl_boot_device() returns the type of boot device instead of the instance of the peripheral. In fact. it returns a imx6_bmode (let's away the serial rom, it is messy to detect).

A following board_boot_order() then choose which is the instance for that detected type, and this is then used to load u-boot.img. This is, at the end, board specific. Even if in most cases, u-boot.img resides on the same storage as SPL, there are cases where this is not true.

And just a single MMC is instantiated in SPL - this is decided inside board code. See for example pcm058.c (but there are plenty of other examples), just a single MMC is initialized by SPL.

On i.MX7, the same approach was not followed. A single spl_boot_device() tries to do all.

I agree that i.MX6 approach is better, and I will glad if you would move i.MX7 to have the same behavior as i.MX6.

Quoted 1 line

(and this patch also),

No, even if it does not depend from the patch - see above.

Quoted 4 lines

is the
preferred way,
since usually you'll only need one MMC device in SPL.

Best regards,
Stefano Babic

Signature · 5 lines

=====================================================================
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 at denx.de
=====================================================================

Eran Matityahu

author

2018-01-04 10:56 UTC #8 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 107 lines · Stefano Babic

Quoted 78 lines · Eran Matityahu
Quoted 77 lines · Eran Matityahu
Quoted 51 lines · Stefano Babic
Hi Eran,
Quoted 22 lines · Eran Matityahu
Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation.
Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and only initialize the MMC device I want to load the next image from (usually the same device).
Quoted 8 lines
Quoted 7 lines
I know I can approach it differently and change the spl_boot_list[0] device to BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change the iMX6 code to do the same.
By the way, in my opinion, the iMX6 way
The imx6 way is the right way to do - rather, i.MX7 does not follow the same approach.
In i.MX6 code, spl_boot_device() returns the type of boot device instead of the instance of the peripheral. In fact. it returns a imx6_bmode (let's away the serial rom, it is messy to detect).
A following board_boot_order() then choose which is the instance for that detected type, and this is then used to load u-boot.img. This is, at the end, board specific. Even if in most cases, u-boot.img resides on the same storage as SPL, there are cases where this is not true.
And just a single MMC is instantiated in SPL - this is decided inside board code. See for example pcm058.c (but there are plenty of other examples), just a single MMC is initialized by SPL.
On i.MX7, the same approach was not followed. A single spl_boot_device() tries to do all.

Quoted 12 lines

I agree that i.MX6 approach is better, and I will glad if you would move i.MX7 to have the same behavior as i.MX6.
Quoted 1 line
(and this patch also),
No, even if it does not depend from the patch - see above.
Quoted 4 lines
is the
preferred way,
since usually you'll only need one MMC device in SPL.

We are saying the same thing.
Except, you are wrong in one little thing: the i.MX6 version of spl_boot_device() doesn't return an imx6_bmode. It detects the imx6_bmode and returns a BOOT_DEVICE_*.
In case of an MMC/.SD boot mode it returns BOOT_DEVICE_MMC1. This patch indeed makes the i.MX7 behaviour the same as i.MX6.

Regards,
Eran

Quoted 11 lines

Best regards,
Stefano Babic
--
=====================================================================
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 at denx.de
=====================================================================

Stefano Babic

2018-01-04 11:37 UTC #9 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 114 lines · Eran Matityahu

Quoted 113 lines · Stefano Babic
Quoted 78 lines · Eran Matityahu
Quoted 77 lines · Eran Matityahu
Quoted 51 lines · Stefano Babic
Hi Eran,
Quoted 22 lines · Eran Matityahu
Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
  arch/arm/mach-imx/spl.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
        switch (boot_device_spl) {
        case SD1_BOOT:
        case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
        case SD2_BOOT:
        case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
        case SPI_NOR_BOOT:
                return BOOT_DEVICE_SPI;
        default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation.
Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and only initialize the MMC device I want to load the next image from (usually the same device).
Quoted 8 lines
Quoted 7 lines
I know I can approach it differently and change the spl_boot_list[0] device to BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change the iMX6 code to do the same.
By the way, in my opinion, the iMX6 way
The imx6 way is the right way to do - rather, i.MX7 does not follow the same approach.
In i.MX6 code, spl_boot_device() returns the type of boot device instead of the instance of the peripheral. In fact. it returns a imx6_bmode (let's away the serial rom, it is messy to detect).
A following board_boot_order() then choose which is the instance for that detected type, and this is then used to load u-boot.img. This is, at the end, board specific. Even if in most cases, u-boot.img resides on the same storage as SPL, there are cases where this is not true.
And just a single MMC is instantiated in SPL - this is decided inside board code. See for example pcm058.c (but there are plenty of other examples), just a single MMC is initialized by SPL.
On i.MX7, the same approach was not followed. A single spl_boot_device() tries to do all.
I agree that i.MX6 approach is better, and I will glad if you would move i.MX7 to have the same behavior as i.MX6.
Quoted 1 line
(and this patch also),

Quoted 7 lines

Quoted 6 lines
No, even if it does not depend from the patch - see above.
Quoted 4 lines
is the
preferred way,
since usually you'll only need one MMC device in SPL.
We are saying the same thing.

:-)

Quoted 3 lines

Except, you are wrong in one little thing: the i.MX6 version of spl_boot_device() doesn't return an imx6_bmode. It detects the imx6_bmode and returns a BOOT_DEVICE_*.

True, but this is used as "type" for i.MX6, it is a real device for i.MX7 (get_boot_device() in arch/arm/mach-imx/mx7/soc.c). This is also due to differences in SOC, I admit.

Quoted 2 lines

In case of an MMC/.SD boot mode it returns BOOT_DEVICE_MMC1. This patch indeed makes the i.MX7 behaviour the same as i.MX6.

The thing is if this patch breaks some boards. As far as I can see, there is just 2 i.MX7 with SPL support: colibri_imx7 (it has just USDHC1, no problem) and cl-som-imx7 that initialize MMC3 (but I do not know if it boots from it, in any case it is not MMC2). Uri, you commented this patch and you are the maintainer for cl-som-imx7. Do you see any problem with that ?

Best regards,
Stefano

Signature · 5 lines

=====================================================================
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 at denx.de
=====================================================================

Uri Mashiach

2018-01-04 12:02 UTC #10 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 136 lines · Stefano Babic

Quoted 114 lines · Eran Matityahu
Quoted 113 lines · Stefano Babic
Quoted 78 lines · Eran Matityahu
Quoted 77 lines · Eran Matityahu
Quoted 51 lines · Stefano Babic
Hi Eran,
Quoted 22 lines · Eran Matityahu
Hi Uri.
Quoted 8 lines
Hello Eran,
Quoted 2 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
   arch/arm/mach-imx/spl.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
         switch (boot_device_spl) {
         case SD1_BOOT:
         case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
         case SD2_BOOT:
         case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
         case SPI_NOR_BOOT:
                 return BOOT_DEVICE_SPI;
         default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation.
Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and only initialize the MMC device I want to load the next image from (usually the same device).
Quoted 8 lines
Quoted 7 lines
I know I can approach it differently and change the spl_boot_list[0] device to BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change the iMX6 code to do the same.
By the way, in my opinion, the iMX6 way
The imx6 way is the right way to do - rather, i.MX7 does not follow the same approach.
In i.MX6 code, spl_boot_device() returns the type of boot device instead of the instance of the peripheral. In fact. it returns a imx6_bmode (let's away the serial rom, it is messy to detect).
A following board_boot_order() then choose which is the instance for that detected type, and this is then used to load u-boot.img. This is, at the end, board specific. Even if in most cases, u-boot.img resides on the same storage as SPL, there are cases where this is not true.
And just a single MMC is instantiated in SPL - this is decided inside board code. See for example pcm058.c (but there are plenty of other examples), just a single MMC is initialized by SPL.
On i.MX7, the same approach was not followed. A single spl_boot_device() tries to do all.
I agree that i.MX6 approach is better, and I will glad if you would move i.MX7 to have the same behavior as i.MX6.
Quoted 1 line
(and this patch also),
Quoted 7 lines
Quoted 6 lines
No, even if it does not depend from the patch - see above.
Quoted 4 lines
is the
preferred way,
since usually you'll only need one MMC device in SPL.
We are saying the same thing.
:-)
Quoted 3 lines
Except, you are wrong in one little thing: the i.MX6 version of spl_boot_device() doesn't return an imx6_bmode. It detects the imx6_bmode and returns a BOOT_DEVICE_*.
True, but this is used as "type" for i.MX6, it is a real device for i.MX7 (get_boot_device() in arch/arm/mach-imx/mx7/soc.c). This is also due to differences in SOC, I admit.
Quoted 2 lines
In case of an MMC/.SD boot mode it returns BOOT_DEVICE_MMC1. This patch indeed makes the i.MX7 behaviour the same as i.MX6.

Quoted 6 lines

The thing is if this patch breaks some boards. As far as I can see, there is just 2 i.MX7 with SPL support: colibri_imx7 (it has just USDHC1, no problem) and cl-som-imx7 that initialize MMC3 (but I do not know if it boots from it, in any case it is not MMC2). Uri, you commented this patch and you are the maintainer for cl-som-imx7. Do you see any problem with that ?

The cl-som-imx7 board doesn't boot from MMC3, so the patch doesn't influence the board.

I prefer the approach of using the spl_boot_list instead of "loosing" the boot instance, that might be used in other future boards.

Signature · 2 lines

Regards,
Uri

Eran Matityahu

author

2018-01-04 12:05 UTC #11 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 170 lines · Uri Mashiach

Quoted 159 lines · Stefano Babic
Quoted 133 lines · Eran Matityahu
Quoted 131 lines · Stefano Babic
Quoted 100 lines · Eran Matityahu
Quoted 88 lines · Eran Matityahu
Quoted 57 lines · Stefano Babic
Hi Eran,
Quoted 26 lines · Eran Matityahu
Hi Uri.
Quoted 10 lines
Hello Eran,
Quoted 3 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
   arch/arm/mach-imx/spl.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
         switch (boot_device_spl) {
         case SD1_BOOT:
         case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
         case SD2_BOOT:
         case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
         case SPI_NOR_BOOT:
                 return BOOT_DEVICE_SPI;
         default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation. Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img
on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and
only initialize the MMC device I want to load the next image from (usually
the same device).
Quoted 9 lines
I know I can approach it differently and change the spl_boot_list[0] device to
BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change
the iMX6 code to do the same.
Quoted 1 line
By the way, in my opinion, the iMX6 way
The imx6 way is the right way to do - rather, i.MX7 does not follow the same approach.
In i.MX6 code, spl_boot_device() returns the type of boot device instead of the instance of the peripheral. In fact. it returns a imx6_bmode (let's away the serial rom, it is messy to detect).
A following board_boot_order() then choose which is the instance for that detected type, and this is then used to load u-boot.img. This is, at the end, board specific. Even if in most cases, u-boot.img resides on the same storage as SPL, there are cases where this is not true.
And just a single MMC is instantiated in SPL - this is decided inside board code. See for example pcm058.c (but there are plenty of other examples), just a single MMC is initialized by SPL.
On i.MX7, the same approach was not followed. A single spl_boot_device() tries to do all.
I agree that i.MX6 approach is better, and I will glad if you would move i.MX7 to have the same behavior as i.MX6.
Quoted 1 line
(and this patch also),
Quoted 7 lines
Quoted 6 lines
No, even if it does not depend from the patch - see above.
Quoted 4 lines
is the
preferred way,
since usually you'll only need one MMC device in SPL.
We are saying the same thing.
:-)
Quoted 3 lines
Except, you are wrong in one little thing: the i.MX6 version of spl_boot_device() doesn't return an imx6_bmode. It detects the imx6_bmode and returns a BOOT_DEVICE_*.
True, but this is used as "type" for i.MX6, it is a real device for i.MX7 (get_boot_device() in arch/arm/mach-imx/mx7/soc.c). This is also due to differences in SOC, I admit.
Quoted 2 lines
In case of an MMC/.SD boot mode it returns BOOT_DEVICE_MMC1. This patch indeed makes the i.MX7 behaviour the same as i.MX6.
Quoted 6 lines
The thing is if this patch breaks some boards. As far as I can see, there is just 2 i.MX7 with SPL support: colibri_imx7 (it has just USDHC1, no problem) and cl-som-imx7 that initialize MMC3 (but I do not know if it boots from it, in any case it is not MMC2). Uri, you commented this patch and you are the maintainer for cl-som-imx7. Do you see any problem with that ?

Quoted 5 lines

The cl-som-imx7 board doesn't boot from MMC3, so the patch doesn't influence the board.
I prefer the approach of using the spl_boot_list instead of "loosing" the boot instance, that might be used in other future boards.

You do not actually lose the boot instance.
You can always use get_boot_device().

Regards,
Eran

Quoted 4 lines

--
Regards,
Uri

Stefano Babic

2018-01-04 12:16 UTC #12 lore raw

PATCH 1/2 imx7: spl: Use SPL boot device MMC1 for all of the SOCs MMC/SD boot devices

Quoted 172 lines · Eran Matityahu

Quoted 170 lines · Uri Mashiach
Quoted 165 lines · Stefano Babic
Quoted 133 lines · Eran Matityahu
Quoted 131 lines · Stefano Babic
Quoted 100 lines · Eran Matityahu
Quoted 88 lines · Eran Matityahu
Quoted 57 lines · Stefano Babic
Hi Eran,
Quoted 26 lines · Eran Matityahu
Hi Uri.
Quoted 10 lines
Hello Eran,
Quoted 3 lines · Eran Matityahu
Use only one SPL MMC device, similarly to the iMX6 code
What is the reason for not using MMC2?
The reason is so that you won't have to initialize more than one MMC device in SPL.
Also, to be consistent with the iMX6 SPL code.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Eran Matityahu <[email protected]>
---
   arch/arm/mach-imx/spl.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-imx/spl.c +0 -0
index d0d1b73aa6..6b5bd8990c 100644
@@ -106,10 +106,9 @@ u32 spl_boot_device(void)
         switch (boot_device_spl) {
         case SD1_BOOT:
         case MMC1_BOOT:
Quoted 8 lines
arch/arm/mach-imx/spl.c u32 spl_boot_device(void) · line 114
Quoted 8 lines
arch/arm/mach-imx/spl.c +1 -2
-               return BOOT_DEVICE_MMC1;
         case SD2_BOOT:
         case MMC2_BOOT:
-               return BOOT_DEVICE_MMC2;
+               return BOOT_DEVICE_MMC1;
         case SPI_NOR_BOOT:
                 return BOOT_DEVICE_SPI;
         default:
The reason to have spl_boot_device() is not to initialize more as one MMC device, but to find which storage contains the next image to be started (u-boot.img). This is generally (but not in all projects) the same storage from where the BootROM has loaded SPL.
According to this, this patch seems wrong. If SPL / u-boot.img are stored on MMC2 (and maybe MMC2 is the only MMC device for the board), your patch breaks booting.
Quoted 5 lines
If you have special case, you can write a board_boot_order() in your board code to overwrite the behavior.
Best regards,
Stefano Babic
The iMX6 spl_boot_device() doesn't even check which MMC device the BootROM has loaded SPL from. It just returns BOOT_DEVICE_MMC1 in case the boot device was any MMC/SD device, and leaves it to the board code to detect the exact device and init the appropriate device with the next image (u-boot,img), accordingly.
My suggestion is to do the same here.
In my iMX7 board, I can boot from MMC1 (SD card) and MMC3 (eMMC), but let's say it's MMC2 in sake of this explanation. Without this patch, in order to boot from MMC2 (with both SPL and u-boot.img
on MMC2), I have to initialize both MMC1 and MMC2 devices because SPL loops on all devices until it finds a match, and it halts if the first device is not
initialized.
With this patch I can use get_boot_device() inside board_mmc_init() and
only initialize the MMC device I want to load the next image from (usually
the same device).
Quoted 9 lines
I know I can approach it differently and change the spl_boot_list[0] device to
BOOT_DEVICE_MMC1 in board_boot_order(), but I figured the behaviour should be the same for iMX6 and iMX7.
If you think the correct way is to return BOOT_DEVICE_MMC2, then we should probably also add a BOOT_DEVICE_MMC3 definition, and also change
the iMX6 code to do the same.
Quoted 1 line
By the way, in my opinion, the iMX6 way
The imx6 way is the right way to do - rather, i.MX7 does not follow the same approach.
In i.MX6 code, spl_boot_device() returns the type of boot device instead of the instance of the peripheral. In fact. it returns a imx6_bmode (let's away the serial rom, it is messy to detect).
A following board_boot_order() then choose which is the instance for that detected type, and this is then used to load u-boot.img. This is, at the end, board specific. Even if in most cases, u-boot.img resides on the same storage as SPL, there are cases where this is not true.
And just a single MMC is instantiated in SPL - this is decided inside board code. See for example pcm058.c (but there are plenty of other examples), just a single MMC is initialized by SPL.
On i.MX7, the same approach was not followed. A single spl_boot_device() tries to do all.
I agree that i.MX6 approach is better, and I will glad if you would move i.MX7 to have the same behavior as i.MX6.
Quoted 1 line
(and this patch also),
Quoted 7 lines
Quoted 6 lines
No, even if it does not depend from the patch - see above.
Quoted 4 lines
is the
preferred way,
since usually you'll only need one MMC device in SPL.
We are saying the same thing.
:-)
Quoted 3 lines
Except, you are wrong in one little thing: the i.MX6 version of spl_boot_device() doesn't return an imx6_bmode. It detects the imx6_bmode and returns a BOOT_DEVICE_*.
True, but this is used as "type" for i.MX6, it is a real device for i.MX7 (get_boot_device() in arch/arm/mach-imx/mx7/soc.c). This is also due to differences in SOC, I admit.
Quoted 2 lines
In case of an MMC/.SD boot mode it returns BOOT_DEVICE_MMC1. This patch indeed makes the i.MX7 behaviour the same as i.MX6.
The thing is if this patch breaks some boards. As far as I can see, there is just 2 i.MX7 with SPL support: colibri_imx7 (it has just USDHC1, no problem) and cl-som-imx7 that initialize MMC3 (but I do not know if it boots from it, in any case it is not MMC2). Uri, you commented this patch and you are the maintainer for cl-som-imx7. Do you see any problem with that ?

Quoted 8 lines

Quoted 5 lines
The cl-som-imx7 board doesn't boot from MMC3, so the patch doesn't influence the board.
I prefer the approach of using the spl_boot_list instead of "loosing" the boot instance, that might be used in other future boards.
You do not actually lose the boot instance.
You can always use get_boot_device().

Yes, I see the same (and this is the major difference with i.MX6). Boards requiring to do internal logic based on the booting device can still run get_boot_device() and we are not missing anything. As result of this discussion and taking into account that we are neither losing features nor breaking boards, I agree the patch can be merged.

Best regards,
Stefano Babic

Signature · 5 lines

=====================================================================
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 at denx.de
=====================================================================