* [PATCH v2 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL @ 2020-03-11 14:30 Walter Lozano 2020-03-11 14:30 ` [PATCH v2 1/4] mx6cuboxi: enable MMC and eMMC in DT for SPL Walter Lozano ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: Walter Lozano @ 2020-03-11 14:30 UTC (permalink / raw) To: u-boot Make an additional step to add full DM support to mx6cuboxi, including its support for SPL With this new configuration SPL image is 50 KB, higher than the 38 KB from the previous version, but it still under the 68 KB limit. Walter Lozano (4): mx6cuboxi: enable MMC and eMMC in DT for SPL mx6cuboxi: customize board_boot_order to access eMMC mx6cuboxi: enable OF_CONTROL and DM in SPL mx6cuboxi: remove unused code ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 8 ++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 114 ++++++++---------- configs/mx6cuboxi_defconfig | 3 + 3 files changed, 60 insertions(+), 65 deletions(-) -- 2.20.1 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 1/4] mx6cuboxi: enable MMC and eMMC in DT for SPL 2020-03-11 14:30 [PATCH v2 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL Walter Lozano @ 2020-03-11 14:30 ` Walter Lozano 2020-03-11 14:30 ` [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC Walter Lozano ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Walter Lozano @ 2020-03-11 14:30 UTC (permalink / raw) To: u-boot Signed-off-by: Walter Lozano <walter.lozano@collabora.com> --- .../dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi index d302b2e275..400b885e43 100644 --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi @@ -34,3 +34,11 @@ &usdhc1 { status = "disabled"; }; + +&usdhc2 { + u-boot,dm-pre-reloc; +}; + +&usdhc3 { + u-boot,dm-pre-reloc; +}; -- 2.20.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-11 14:30 [PATCH v2 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 1/4] mx6cuboxi: enable MMC and eMMC in DT for SPL Walter Lozano @ 2020-03-11 14:30 ` Walter Lozano 2020-03-12 5:02 ` Baruch Siach 2020-03-11 14:30 ` [PATCH v2 3/4] mx6cuboxi: enable OF_CONTROL and DM in SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 4/4] mx6cuboxi: remove unused code Walter Lozano 3 siblings, 1 reply; 15+ messages in thread From: Walter Lozano @ 2020-03-11 14:30 UTC (permalink / raw) To: u-boot 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.lozano@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 + return 0; } @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name) return strcmp(name, tmp_name); } +void board_boot_order(u32 *spl_boot_list) +{ + struct src *psrc = (struct src *)SRC_BASE_ADDR; + unsigned int reg = readl(&psrc->sbmr1) >> 11; + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK; + unsigned int bmode = readl(&src_base->sbmr2); + + /* If bmode is serial or USB phy is active, return serial */ + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) { + spl_boot_list[0] = BOOT_DEVICE_BOARD; + return; + } + + switch (boot_mode >> IMX6_BMODE_SHIFT) { + case IMX6_BMODE_SD: + case IMX6_BMODE_ESD: + case IMX6_BMODE_MMC: + case IMX6_BMODE_EMMC: + /* + * Upon reading BOOT_CFG register the following map is done: + * Bit 11 and 12 of BOOT_CFG register can determine the current + * mmc port + * 0x1 SD2 + * 0x2 SD3 + */ + + reg &= 0x3; /* Only care about bottom 2 bits */ + switch (reg) { + case 1: + SETUP_IOMUX_PADS(usdhc2_pads); + spl_boot_list[0] = BOOT_DEVICE_MMC1; + break; + case 2: + SETUP_IOMUX_PADS(usdhc3_pads); + spl_boot_list[0] = BOOT_DEVICE_MMC2; + break; + } + break; + default: + /* By default use USB downloader */ + spl_boot_list[0] = BOOT_DEVICE_BOARD; + break; + } + + /* As a last resort, use serial downloader */ + spl_boot_list[1] = BOOT_DEVICE_BOARD; +} + #ifdef CONFIG_SPL_BUILD #include <asm/arch/mx6-ddr.h> static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = { -- 2.20.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-11 14:30 ` [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC Walter Lozano @ 2020-03-12 5:02 ` Baruch Siach 2020-03-12 16:52 ` Walter Lozano 0 siblings, 1 reply; 15+ messages in thread From: Baruch Siach @ 2020-03-12 5:02 UTC (permalink / raw) To: u-boot 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.lozano@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. Looks good to me, otherwise. I can't test at the moment. Have you tested boot from both SD card and eMMC? In the future, please keep i.MX maintainers (Stefano, Fabio) in Cc. Thanks, baruch > return 0; > } > > @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name) > return strcmp(name, tmp_name); > } > > +void board_boot_order(u32 *spl_boot_list) > +{ > + struct src *psrc = (struct src *)SRC_BASE_ADDR; > + unsigned int reg = readl(&psrc->sbmr1) >> 11; > + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK; > + unsigned int bmode = readl(&src_base->sbmr2); > + > + /* If bmode is serial or USB phy is active, return serial */ > + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) { > + spl_boot_list[0] = BOOT_DEVICE_BOARD; > + return; > + } > + > + switch (boot_mode >> IMX6_BMODE_SHIFT) { > + case IMX6_BMODE_SD: > + case IMX6_BMODE_ESD: > + case IMX6_BMODE_MMC: > + case IMX6_BMODE_EMMC: > + /* > + * Upon reading BOOT_CFG register the following map is done: > + * Bit 11 and 12 of BOOT_CFG register can determine the current > + * mmc port > + * 0x1 SD2 > + * 0x2 SD3 > + */ > + > + reg &= 0x3; /* Only care about bottom 2 bits */ > + switch (reg) { > + case 1: > + SETUP_IOMUX_PADS(usdhc2_pads); > + spl_boot_list[0] = BOOT_DEVICE_MMC1; > + break; > + case 2: > + SETUP_IOMUX_PADS(usdhc3_pads); > + spl_boot_list[0] = BOOT_DEVICE_MMC2; > + break; > + } > + break; > + default: > + /* By default use USB downloader */ > + spl_boot_list[0] = BOOT_DEVICE_BOARD; > + break; > + } > + > + /* As a last resort, use serial downloader */ > + spl_boot_list[1] = BOOT_DEVICE_BOARD; > +} > + > #ifdef CONFIG_SPL_BUILD > #include <asm/arch/mx6-ddr.h> > static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = { -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-12 5:02 ` Baruch Siach @ 2020-03-12 16:52 ` Walter Lozano 2020-03-16 16:28 ` Baruch Siach 0 siblings, 1 reply; 15+ messages in thread From: Walter Lozano @ 2020-03-12 16:52 UTC (permalink / raw) To: u-boot Hi Baruch, 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.lozano@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. Regarding booting from SD/eMMC, I also wonder if having a list of boot devices would be useful, like switch (boot_mode >> IMX6_BMODE_SHIFT) { case IMX6_BMODE_SD: case IMX6_BMODE_ESD: case IMX6_BMODE_MMC: case IMX6_BMODE_EMMC: SETUP_IOMUX_PADS(usdhc2_pads); SETUP_IOMUX_PADS(usdhc3_pads); /* * Upon reading BOOT_CFG register the following map is done: * Bit 11 and 12 of BOOT_CFG register can determine the current * mmc port * 0x1 SD2 * 0x2 SD3 */ reg &= 0x3; /* Only care about bottom 2 bits */ switch (reg) { case 1: spl_boot_list[0] = BOOT_DEVICE_MMC1; spl_boot_list[1] = BOOT_DEVICE_MMC2; break; case 2: spl_boot_list[0] = BOOT_DEVICE_MMC2; spl_boot_list[1] = BOOT_DEVICE_MMC1; break; } break; What do you think? > In the future, please keep i.MX maintainers (Stefano, Fabio) in Cc. Thanks for the advice. You are totally right. Regards, Walter > Thanks, > baruch > >> return 0; >> } >> >> @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name) >> return strcmp(name, tmp_name); >> } >> >> +void board_boot_order(u32 *spl_boot_list) >> +{ >> + struct src *psrc = (struct src *)SRC_BASE_ADDR; >> + unsigned int reg = readl(&psrc->sbmr1) >> 11; >> + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK; >> + unsigned int bmode = readl(&src_base->sbmr2); >> + >> + /* If bmode is serial or USB phy is active, return serial */ >> + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) { >> + spl_boot_list[0] = BOOT_DEVICE_BOARD; >> + return; >> + } >> + >> + switch (boot_mode >> IMX6_BMODE_SHIFT) { >> + case IMX6_BMODE_SD: >> + case IMX6_BMODE_ESD: >> + case IMX6_BMODE_MMC: >> + case IMX6_BMODE_EMMC: >> + /* >> + * Upon reading BOOT_CFG register the following map is done: >> + * Bit 11 and 12 of BOOT_CFG register can determine the current >> + * mmc port >> + * 0x1 SD2 >> + * 0x2 SD3 >> + */ >> + >> + reg &= 0x3; /* Only care about bottom 2 bits */ >> + switch (reg) { >> + case 1: >> + SETUP_IOMUX_PADS(usdhc2_pads); >> + spl_boot_list[0] = BOOT_DEVICE_MMC1; >> + break; >> + case 2: >> + SETUP_IOMUX_PADS(usdhc3_pads); >> + spl_boot_list[0] = BOOT_DEVICE_MMC2; >> + break; >> + } >> + break; >> + default: >> + /* By default use USB downloader */ >> + spl_boot_list[0] = BOOT_DEVICE_BOARD; >> + break; >> + } >> + >> + /* As a last resort, use serial downloader */ >> + spl_boot_list[1] = BOOT_DEVICE_BOARD; >> +} >> + >> #ifdef CONFIG_SPL_BUILD >> #include <asm/arch/mx6-ddr.h> >> static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = { > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-12 16:52 ` Walter Lozano @ 2020-03-16 16:28 ` Baruch Siach 2020-03-16 17:05 ` Walter Lozano 0 siblings, 1 reply; 15+ messages in thread From: Baruch Siach @ 2020-03-16 16:28 UTC (permalink / raw) To: u-boot Hi Walter, On Thu, Mar 12, 2020 at 01:52:13PM -0300, Walter Lozano wrote: > Hi Baruch, > > 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.lozano@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? Anyway I tested your patches here on real hardware with unfused SOM and SD/eMMC boot select jumpers. Tested-by: Baruch Siach <baruch@tkos.co.il> > Regarding booting from SD/eMMC, I also wonder if having a list of boot > devices would be useful, like > > switch (boot_mode >> IMX6_BMODE_SHIFT) { > case IMX6_BMODE_SD: > case IMX6_BMODE_ESD: > case IMX6_BMODE_MMC: > case IMX6_BMODE_EMMC: > SETUP_IOMUX_PADS(usdhc2_pads); > SETUP_IOMUX_PADS(usdhc3_pads); > > /* > * Upon reading BOOT_CFG register the following map is done: > * Bit 11 and 12 of BOOT_CFG register can determine the current > * mmc port > * 0x1 SD2 > * 0x2 SD3 > */ > > reg &= 0x3; /* Only care about bottom 2 bits */ > switch (reg) { > case 1: > spl_boot_list[0] = BOOT_DEVICE_MMC1; > spl_boot_list[1] = BOOT_DEVICE_MMC2; > break; > case 2: > spl_boot_list[0] = BOOT_DEVICE_MMC2; > spl_boot_list[1] = BOOT_DEVICE_MMC1; > break; > } > break; > > What do you think? This might cause surprising results when the U-Boot image on the SPL boot device is damaged for some reason. This kind of fallback device (other than USB boot) should not be enabled by default, in my opinion. baruch > > In the future, please keep i.MX maintainers (Stefano, Fabio) in Cc. > > > Thanks for the advice. You are totally right. > > Regards, > > Walter > > > Thanks, > > baruch > > > > > return 0; > > > } > > > @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name) > > > return strcmp(name, tmp_name); > > > } > > > +void board_boot_order(u32 *spl_boot_list) > > > +{ > > > + struct src *psrc = (struct src *)SRC_BASE_ADDR; > > > + unsigned int reg = readl(&psrc->sbmr1) >> 11; > > > + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK; > > > + unsigned int bmode = readl(&src_base->sbmr2); > > > + > > > + /* If bmode is serial or USB phy is active, return serial */ > > > + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) { > > > + spl_boot_list[0] = BOOT_DEVICE_BOARD; > > > + return; > > > + } > > > + > > > + switch (boot_mode >> IMX6_BMODE_SHIFT) { > > > + case IMX6_BMODE_SD: > > > + case IMX6_BMODE_ESD: > > > + case IMX6_BMODE_MMC: > > > + case IMX6_BMODE_EMMC: > > > + /* > > > + * Upon reading BOOT_CFG register the following map is done: > > > + * Bit 11 and 12 of BOOT_CFG register can determine the current > > > + * mmc port > > > + * 0x1 SD2 > > > + * 0x2 SD3 > > > + */ > > > + > > > + reg &= 0x3; /* Only care about bottom 2 bits */ > > > + switch (reg) { > > > + case 1: > > > + SETUP_IOMUX_PADS(usdhc2_pads); > > > + spl_boot_list[0] = BOOT_DEVICE_MMC1; > > > + break; > > > + case 2: > > > + SETUP_IOMUX_PADS(usdhc3_pads); > > > + spl_boot_list[0] = BOOT_DEVICE_MMC2; > > > + break; > > > + } > > > + break; > > > + default: > > > + /* By default use USB downloader */ > > > + spl_boot_list[0] = BOOT_DEVICE_BOARD; > > > + break; > > > + } > > > + > > > + /* As a last resort, use serial downloader */ > > > + spl_boot_list[1] = BOOT_DEVICE_BOARD; > > > +} > > > + > > > #ifdef CONFIG_SPL_BUILD > > > #include <asm/arch/mx6-ddr.h> > > > static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = { -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-16 16:28 ` Baruch Siach @ 2020-03-16 17:05 ` Walter Lozano 2020-03-16 17:25 ` Baruch Siach 0 siblings, 1 reply; 15+ messages in thread From: Walter Lozano @ 2020-03-16 17:05 UTC (permalink / raw) To: u-boot On 16/3/20 13:28, Baruch Siach wrote: > Hi Walter, > > On Thu, Mar 12, 2020 at 01:52:13PM -0300, Walter Lozano wrote: >> Hi Baruch, >> >> 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.lozano@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 > 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 <baruch@tkos.co.il> Thanks. I'll add the tag to the v3. >> Regarding booting from SD/eMMC, I also wonder if having a list of boot >> devices would be useful, like >> >> switch (boot_mode >> IMX6_BMODE_SHIFT) { >> case IMX6_BMODE_SD: >> case IMX6_BMODE_ESD: >> case IMX6_BMODE_MMC: >> case IMX6_BMODE_EMMC: >> SETUP_IOMUX_PADS(usdhc2_pads); >> SETUP_IOMUX_PADS(usdhc3_pads); >> >> /* >> * Upon reading BOOT_CFG register the following map is done: >> * Bit 11 and 12 of BOOT_CFG register can determine the current >> * mmc port >> * 0x1 SD2 >> * 0x2 SD3 >> */ >> >> reg &= 0x3; /* Only care about bottom 2 bits */ >> switch (reg) { >> case 1: >> spl_boot_list[0] = BOOT_DEVICE_MMC1; >> spl_boot_list[1] = BOOT_DEVICE_MMC2; >> break; >> case 2: >> spl_boot_list[0] = BOOT_DEVICE_MMC2; >> spl_boot_list[1] = BOOT_DEVICE_MMC1; >> break; >> } >> break; >> >> What do you think? > This might cause surprising results when the U-Boot image on the SPL boot > device is damaged for some reason. This kind of fallback device (other than > USB boot) should not be enabled by default, in my opinion. Thanks for sharing your opinion. I agree with you, but I was still wondering what were your thoughts about this. Regards, Walter > baruch > >>> In the future, please keep i.MX maintainers (Stefano, Fabio) in Cc. >> >> Thanks for the advice. You are totally right. >> >> Regards, >> >> Walter >> >>> Thanks, >>> baruch >>> >>>> return 0; >>>> } >>>> @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name) >>>> return strcmp(name, tmp_name); >>>> } >>>> +void board_boot_order(u32 *spl_boot_list) >>>> +{ >>>> + struct src *psrc = (struct src *)SRC_BASE_ADDR; >>>> + unsigned int reg = readl(&psrc->sbmr1) >> 11; >>>> + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK; >>>> + unsigned int bmode = readl(&src_base->sbmr2); >>>> + >>>> + /* If bmode is serial or USB phy is active, return serial */ >>>> + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) { >>>> + spl_boot_list[0] = BOOT_DEVICE_BOARD; >>>> + return; >>>> + } >>>> + >>>> + switch (boot_mode >> IMX6_BMODE_SHIFT) { >>>> + case IMX6_BMODE_SD: >>>> + case IMX6_BMODE_ESD: >>>> + case IMX6_BMODE_MMC: >>>> + case IMX6_BMODE_EMMC: >>>> + /* >>>> + * Upon reading BOOT_CFG register the following map is done: >>>> + * Bit 11 and 12 of BOOT_CFG register can determine the current >>>> + * mmc port >>>> + * 0x1 SD2 >>>> + * 0x2 SD3 >>>> + */ >>>> + >>>> + reg &= 0x3; /* Only care about bottom 2 bits */ >>>> + switch (reg) { >>>> + case 1: >>>> + SETUP_IOMUX_PADS(usdhc2_pads); >>>> + spl_boot_list[0] = BOOT_DEVICE_MMC1; >>>> + break; >>>> + case 2: >>>> + SETUP_IOMUX_PADS(usdhc3_pads); >>>> + spl_boot_list[0] = BOOT_DEVICE_MMC2; >>>> + break; >>>> + } >>>> + break; >>>> + default: >>>> + /* By default use USB downloader */ >>>> + spl_boot_list[0] = BOOT_DEVICE_BOARD; >>>> + break; >>>> + } >>>> + >>>> + /* As a last resort, use serial downloader */ >>>> + spl_boot_list[1] = BOOT_DEVICE_BOARD; >>>> +} >>>> + >>>> #ifdef CONFIG_SPL_BUILD >>>> #include <asm/arch/mx6-ddr.h> >>>> static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = { ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-16 17:05 ` Walter Lozano @ 2020-03-16 17:25 ` Baruch Siach 2020-03-16 17:53 ` Walter Lozano 0 siblings, 1 reply; 15+ messages in thread From: Baruch Siach @ 2020-03-16 17:25 UTC (permalink / raw) To: u-boot Hi Walter 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.lozano@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. > > 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 <baruch@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 baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-16 17:25 ` Baruch Siach @ 2020-03-16 17:53 ` Walter Lozano 2020-03-16 18:11 ` Baruch Siach 0 siblings, 1 reply; 15+ messages in thread From: Walter Lozano @ 2020-03-16 17:53 UTC (permalink / raw) To: u-boot Hi Baruch, On 16/3/20 14:25, Baruch Siach wrote: > Hi Walter > > 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.lozano@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? >>> 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 <baruch@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? Regards, Walter > baruch > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-16 17:53 ` Walter Lozano @ 2020-03-16 18:11 ` Baruch Siach 2020-03-16 18:56 ` Walter Lozano 0 siblings, 1 reply; 15+ messages in thread From: Baruch Siach @ 2020-03-16 18:11 UTC (permalink / raw) To: u-boot 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.lozano@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. > > > > 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 <baruch@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. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-16 18:11 ` Baruch Siach @ 2020-03-16 18:56 ` Walter Lozano 2020-04-19 4:24 ` Walter Lozano 0 siblings, 1 reply; 15+ messages in thread From: Walter Lozano @ 2020-03-16 18:56 UTC (permalink / raw) To: u-boot 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.lozano@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 <baruch@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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-03-16 18:56 ` Walter Lozano @ 2020-04-19 4:24 ` Walter Lozano 2020-05-18 17:25 ` Walter Lozano 0 siblings, 1 reply; 15+ messages in thread From: Walter Lozano @ 2020-04-19 4:24 UTC (permalink / raw) To: u-boot Hi Stefano, I noticed that this series has state = Changes Requested, but not sure what are the changes need. Could you please clarify? There is a silly hunk but Baruch suggested that this no requires a v3. However if you prefer a v3, I can prepare it Please confirm. On 16/3/20 15:56, Walter Lozano wrote: > 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.lozano@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 <baruch@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC 2020-04-19 4:24 ` Walter Lozano @ 2020-05-18 17:25 ` Walter Lozano 0 siblings, 0 replies; 15+ messages in thread From: Walter Lozano @ 2020-05-18 17:25 UTC (permalink / raw) To: u-boot Hi Stefano, Could you please check the status of this patchset and confirm if a v3 is required? On 19/4/20 01:24, Walter Lozano wrote: > Hi Stefano, > > I noticed that this series has state = Changes Requested, but not sure > what are the changes need. > > Could you please clarify? There is a silly hunk but Baruch suggested > that this no requires a v3. However if you prefer a v3, I can prepare it > > Please confirm. > > On 16/3/20 15:56, Walter Lozano wrote: >> 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.lozano@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 <baruch@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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 3/4] mx6cuboxi: enable OF_CONTROL and DM in SPL 2020-03-11 14:30 [PATCH v2 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 1/4] mx6cuboxi: enable MMC and eMMC in DT for SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC Walter Lozano @ 2020-03-11 14:30 ` Walter Lozano 2020-03-11 14:30 ` [PATCH v2 4/4] mx6cuboxi: remove unused code Walter Lozano 3 siblings, 0 replies; 15+ messages in thread From: Walter Lozano @ 2020-03-11 14:30 UTC (permalink / raw) To: u-boot In order to take the beneficts of DT and DM in SPL, like reusing the code and avoid redundancy, enable SPL_OF_CONTROL, SPL_DM and SPL_DM_MMC. With this new configuration SPL image is 50 KB, higher than the 38 KB from the previous version, but it still under the 68 KB limit. Signed-off-by: Walter Lozano <walter.lozano@collabora.com> --- configs/mx6cuboxi_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig index bee7d280f0..7ea79b9064 100644 --- a/configs/mx6cuboxi_defconfig +++ b/configs/mx6cuboxi_defconfig @@ -25,6 +25,7 @@ CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vga; setenv stderr serial,vga; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi;" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y @@ -37,6 +38,7 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y # CONFIG_SPL_PARTITION_UUIDS is not set CONFIG_OF_CONTROL=y +CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx6dl-hummingboard2-emmc-som-v15" CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15 imx6q-hummingboard2-emmc-som-v15" CONFIG_MULTI_DTB_FIT=y @@ -45,6 +47,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y +CONFIG_SPL_DM=y CONFIG_DWC_AHSATA=y CONFIG_DM_MMC=y CONFIG_FSL_USDHC=y -- 2.20.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v2 4/4] mx6cuboxi: remove unused code 2020-03-11 14:30 [PATCH v2 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL Walter Lozano ` (2 preceding siblings ...) 2020-03-11 14:30 ` [PATCH v2 3/4] mx6cuboxi: enable OF_CONTROL and DM in SPL Walter Lozano @ 2020-03-11 14:30 ` Walter Lozano 3 siblings, 0 replies; 15+ messages in thread From: Walter Lozano @ 2020-03-11 14:30 UTC (permalink / raw) To: u-boot After enabling SPL_OF_CONTROL, SPL_DM and SPL_DM_MMC the MMC initialization code is not longer needed. This patch removes the unused code. Signed-off-by: Walter Lozano <walter.lozano@collabora.com> --- board/solidrun/mx6cuboxi/mx6cuboxi.c | 65 ---------------------------- 1 file changed, 65 deletions(-) diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index 9bf3645f72..6e8d4e5666 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -162,76 +162,11 @@ static void setup_iomux_uart(void) SETUP_IOMUX_PADS(uart1_pads); } -static struct fsl_esdhc_cfg usdhc_cfg = { - .esdhc_base = USDHC2_BASE_ADDR, - .max_bus_width = 4, -}; - -static struct fsl_esdhc_cfg emmc_cfg = { - .esdhc_base = USDHC3_BASE_ADDR, - .max_bus_width = 8, -}; - int board_mmc_get_env_dev(int devno) { return devno; } -#define USDHC2_CD_GPIO IMX_GPIO_NR(1, 4) - -int board_mmc_getcd(struct mmc *mmc) -{ - struct fsl_esdhc_cfg *cfg = mmc->priv; - int ret = 0; - - switch (cfg->esdhc_base) { - case USDHC2_BASE_ADDR: - ret = !gpio_get_value(USDHC2_CD_GPIO); - break; - case USDHC3_BASE_ADDR: - ret = (mmc_get_op_cond(mmc) < 0) ? 0 : 1; /* eMMC/uSDHC3 has no CD GPIO */ - break; - } - - return ret; -} - -static int mmc_init_spl(bd_t *bis) -{ - struct src *psrc = (struct src *)SRC_BASE_ADDR; - unsigned reg = readl(&psrc->sbmr1) >> 11; - - /* - * Upon reading BOOT_CFG register the following map is done: - * Bit 11 and 12 of BOOT_CFG register can determine the current - * mmc port - * 0x1 SD2 - * 0x2 SD3 - */ - switch (reg & 0x3) { - case 0x1: - SETUP_IOMUX_PADS(usdhc2_pads); - usdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK); - gd->arch.sdhc_clk = usdhc_cfg.sdhc_clk; - return fsl_esdhc_initialize(bis, &usdhc_cfg); - case 0x2: - SETUP_IOMUX_PADS(usdhc3_pads); - emmc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK); - gd->arch.sdhc_clk = emmc_cfg.sdhc_clk; - return fsl_esdhc_initialize(bis, &emmc_cfg); - } - - return -ENODEV; -} - -int board_mmc_init(bd_t *bis) -{ - if (IS_ENABLED(CONFIG_SPL_BUILD)) - return mmc_init_spl(bis); - - return 0; -} - static iomux_v3_cfg_t const enet_pads[] = { IOMUX_PADS(PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL)), IOMUX_PADS(PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL)), -- 2.20.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-05-18 17:25 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-11 14:30 [PATCH v2 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 1/4] mx6cuboxi: enable MMC and eMMC in DT for SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC Walter Lozano 2020-03-12 5:02 ` Baruch Siach 2020-03-12 16:52 ` Walter Lozano 2020-03-16 16:28 ` Baruch Siach 2020-03-16 17:05 ` Walter Lozano 2020-03-16 17:25 ` Baruch Siach 2020-03-16 17:53 ` Walter Lozano 2020-03-16 18:11 ` Baruch Siach 2020-03-16 18:56 ` Walter Lozano 2020-04-19 4:24 ` Walter Lozano 2020-05-18 17:25 ` Walter Lozano 2020-03-11 14:30 ` [PATCH v2 3/4] mx6cuboxi: enable OF_CONTROL and DM in SPL Walter Lozano 2020-03-11 14:30 ` [PATCH v2 4/4] mx6cuboxi: remove unused code Walter Lozano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.