From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Thu, 19 Jul 2018 23:41:10 +0530 Subject: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device In-Reply-To: <20180719132602.z42x6r4fhzaa7ody@flea> References: <20180716081956.32434-1-jagan@amarulasolutions.com> <20180716081956.32434-22-jagan@amarulasolutions.com> <20180716094621.amirpk6kpus5ow4z@flea.home> <20180717115754.py2xm6ozcetdxqht@flea.home> <20180719132602.z42x6r4fhzaa7ody@flea> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Jul 19, 2018 at 6:56 PM, Maxime Ripard wrote: > On Wed, Jul 18, 2018 at 08:15:23PM +0100, Alex Kiernan wrote: >> On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard >> wrote: >> > >> > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote: >> > > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki wrote: >> > > > >> > > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard >> > > > wrote: >> > > > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: >> > > > >> Usually eMMC is default env fat device for environment, >> > > > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc >> > > > >> device as 1. but with DM_MMC it can be more possible to >> > > > >> probe eMMC as device 2 since for most of the sunxi platforms >> > > > >> eMMC is configured mmc2. >> > > > >> >> > > > >> So update the fastboot mmc default device as 2 if DM_MMC and >> > > > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards >> > > > >> may not use all possible mmc devices or partly disabled in DT, >> > > > >> for those update the device in board specific defconfig. >> > > > >> >> > > > >> Cc: Olliver Schinagl >> > > > >> Cc: Chen-Yu Tsai >> > > > >> Signed-off-by: Jagan Teki >> > > > >> --- >> > > > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + >> > > > >> configs/Sinlinx_SinA33_defconfig | 1 + >> > > > >> configs/amarula_a64_relic_defconfig | 1 + >> > > > >> drivers/fastboot/Kconfig | 3 ++- >> > > > >> 4 files changed, 5 insertions(+), 1 deletion(-) >> > > > >> >> > > > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig b/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> index 5657fc2594..20ea254191 100644 >> > > > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 >> > > > >> CONFIG_SCSI=y >> > > > >> CONFIG_USB_EHCI_HCD=y >> > > > >> CONFIG_USB_MUSB_GADGET=y >> > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 >> > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y >> > > > >> diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig >> > > > >> index 394534b8b5..7841219a65 100644 >> > > > >> --- a/configs/Sinlinx_SinA33_defconfig >> > > > >> +++ b/configs/Sinlinx_SinA33_defconfig >> > > > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y >> > > > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y >> > > > >> CONFIG_USB_EHCI_HCD=y >> > > > >> CONFIG_USB_MUSB_GADGET=y >> > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 >> > > > > >> > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both >> > > > > have the eMMC on MMC2, and you claim you want to update the default to >> > > > > point to MMC2, but you're changing both these boards to point to MMC1 >> > > > > instead? >> > > > >> > > > If DM_MMC and SLOT != 1 => default device 2 which is updated by >> > > > kconfig, this is with all relevant mmc nodes are enabled >> > > > but these two boards mmc1 is not enabled so emmc will detected in device 1 >> > > > >> > > > > >> > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y >> > > > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y >> > > > >> diff --git a/configs/amarula_a64_relic_defconfig b/configs/amarula_a64_relic_defconfig >> > > > >> index b72cbfabc6..caeb3f6008 100644 >> > > > >> --- a/configs/amarula_a64_relic_defconfig >> > > > >> +++ b/configs/amarula_a64_relic_defconfig >> > > > >> @@ -12,4 +12,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" >> > > > >> # CONFIG_SPL_DOS_PARTITION is not set >> > > > >> # CONFIG_SPL_EFI_PARTITION is not set >> > > > >> CONFIG_USB_MUSB_GADGET=y >> > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 >> > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y >> > > > >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig >> > > > >> index bc25ea1d9c..4a1bfd119c 100644 >> > > > >> --- a/drivers/fastboot/Kconfig >> > > > >> +++ b/drivers/fastboot/Kconfig >> > > > >> @@ -88,7 +88,8 @@ config FASTBOOT_FLASH_MMC_DEV >> > > > >> int "Define FASTBOOT MMC FLASH default device" >> > > > >> depends on FASTBOOT_FLASH_MMC >> > > > >> default 0 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1 >> > > > >> - default 1 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1 >> > > > >> + default 1 if ARCH_SUNXI && !DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1 >> > > > >> + default 2 if ARCH_SUNXI && DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1 >> > > > > >> > > > > It'd be better to be fixed properly, instead of just relying on a >> > > > > broken index. >> > > > >> > > > I don't think we can't do anything with this now, since this INDEX >> > > > more rely on SPL for pinctrl enablement. if you have any suggestion >> > > > please share. >> > > >> > > Would another answer (at least for this specific case) to change the >> > > fastboot code so it doesn't need the device number in advance? Given >> > > we get device names along the lines of 'mmcsda1', we could parse out >> > > the 'a' to figure out the device number (and then use the alias code >> > > so your board can expose a portable name). >> > >> > That sounds like a pretty good solution. I guess we would have some >> > corner cases when we have a NAND and an MMC card for example that can >> > be flashed using fastboot, but I'm not sure we have boards in that >> > setup at the moment (for Allwinner SoCs at least). >> > >> >> It's not something I need right now, but having spent so much time >> refactoring the fastboot code I'd like to get to this! Support for >> `getvar all` is also on my todo list. >> >> The NAND stuff is a good call, I'm not sure how that fits in (not >> least not having a board which has a NAND part). > > Maybe we can hack something at the partition level though: instead of > having the partition name itself, what about prefixing it by the > device name? ie having something like mmc1:rootfs and nand0:rootfs, as > partition name. How about giving an input during command 'fastboot [dev_type] ' it can be fastboot 0 mmc 1 similar like ums did 'ums 0 mmc 1'