Hi Baruch,

On 16/3/20 15:11, Baruch Siach wrote:
Hi Walter,

On Mon, Mar 16, 2020 at 02:53:58PM -0300, Walter Lozano wrote:
On 16/3/20 14:25, Baruch Siach wrote:
On Mon, Mar 16, 2020 at 02:05:57PM -0300, Walter Lozano wrote:
On 16/3/20 13:28, Baruch Siach wrote:
On Thu, Mar 12, 2020 at 01:52:13PM -0300, Walter Lozano wrote:
Thanks for sharing.

On 12/3/20 02:02, Baruch Siach wrote:
Hi Walter,

On Wed, Mar 11 2020, Walter Lozano wrote:
In SPL legacy code only one MMC device is created, based on BOOT_CFG
register, which can be either SD or eMMC. In this context
board_boot_order return always MMC1 when configure to boot from
SD/eMMC. After switching to DM both SD and eMMC devices are created
based on the information available on DT, but as board_boot_order
only returns MMC1 is not possible to boot from eMMC.

This patch customizes board_boot_order taking into account BOOT_CFG
register to point to correct MMC1 / MMC2 device. Additionally, handle
IO mux for the desired boot device.

Signed-off-by: Walter Lozano <walter.loz...@collabora.com>
---
     board/solidrun/mx6cuboxi/mx6cuboxi.c | 49 ++++++++++++++++++++++++++++
     1 file changed, 49 insertions(+)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 6a96f9ecdb..9bf3645f72 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -435,6 +435,7 @@ int board_early_init_f(void)
     #ifdef CONFIG_CMD_SATA
        setup_sata();
     #endif
+
This hunk should not be part of this commit.
Thanks for pointing to this silly hunk. I will prepare a V3.

Looks good to me, otherwise.

I can't test at the moment. Have you tested boot from both SD card and eMMC?
Most of the work was done booting from SD. In order to test booting from
eMMC, as I have some specific eFUSE configs, I tweaked board_boot_order to
force booting from eMMC.
But that does not cover SPL boot from eMMC, right?
Basically I think this approach should cover the necessary steps. To be more
clear about my tweak

1- BootROM loads SPL from SD

2- SPL is tweaked to load U-Boot from eMMC, and in this way test its support
on SPL
This is not exactly the same as SPL boot from eMMC. For example, your scenario
would work even without 'u-boot,dm-pre-reloc' property in the eMMC device
node.
I agree, it is not exactly the same and I really appreciate the time you
spent testing it. However I still don't understand your comments regarding
'u-boot,dm-pre-reloc', as without this property there wouldn't be a usdhc3
node in the DTB for SPL. Could you please clarify?
You are right. Bad example.

Thanks for clarifying.


Anyway I tested your patches here on real hardware with unfused SOM and
SD/eMMC boot select jumpers.
Thank you much for taking the time to test these patches in you board. I
really appreciate your help

Tested-by: Baruch Siach <bar...@tkos.co.il>
Thanks. I'll add the tag to the v3.
I think this series ready as is. No need to post v3 just for the test tag.
Patchwork collects patch tags automatically. See under the 'A/F/R/T' column
here:

    http://patchwork.ozlabs.org/project/uboot/list/?series=163738
I see, thanks for clarifying the issue related to "Tested-by" tag. Sorry for
asking but, is it not necessary to send a v3 to avoid the "silly hunk" you
pointed me?
I forgot about that. Maybe Stefano can make this trivial change when applying.
I would not respin the series just for that.

Thanks again for clarifying, you have been very helpful.

Regards,

Walter


baruch

Reply via email to