All of lore.kernel.org
 help / color / mirror / Atom feed
From: Walter Lozano <walter.lozano@collabora.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC
Date: Thu, 12 Mar 2020 13:52:13 -0300	[thread overview]
Message-ID: <f4b1c412-b1f2-4e29-42bb-2d658e37f6fb@collabora.com> (raw)
In-Reply-To: <87d09i413t.fsf@tarshish>

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 = {
>

  reply	other threads:[~2020-03-12 16:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f4b1c412-b1f2-4e29-42bb-2d658e37f6fb@collabora.com \
    --to=walter.lozano@collabora.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.