| Message ID | 20220421180523.1328390-2-festevam@gmail.com |
|---|---|
| State | Accepted |
| Commit | d175982c207bb2ace592d7985cd3f05ab99759d9 |
| Delegated to: | Stefano Babic |
| Headers | show |
| Series | [v3,1/2] imx8mn_ddr4_evk: Add USB Mass Storage support | expand |
On Thu, Apr 21, 2022 at 11:06 AM Fabio Estevam <festevam@gmail.com> wrote: > > From: Fabio Estevam <festevam@denx.de> > > When trying to boot via USB on i.MX8MN it is necessary to specify > the U-Boot environment location, otherwise the boot process simply > hangs. > > Specify the environment location when booting from USB. > > Tested on a imx8mn-evk. > > Suggested-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> > Signed-off-by: Fabio Estevam <festevam@denx.de> > --- > Changes since v2: > - Handle explicitly the CONFIG_ENV_IS_NOWHERE case and return > ENVL_UNKNOWN as fallback (Marek). > > arch/arm/mach-imx/imx8m/soc.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c > index 7059d87e336b..34a07b53e57a 100644 > --- a/arch/arm/mach-imx/imx8m/soc.c > +++ b/arch/arm/mach-imx/imx8m/soc.c > @@ -1536,6 +1536,16 @@ enum env_location arch_env_get_location(enum env_operation op, int prio) > return ENVL_UNKNOWN; > > switch (dev) { > + case USB_BOOT: > + if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)) > + return ENVL_SPI_FLASH; > + if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND)) > + return ENVL_NAND; > + if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC)) > + return ENVL_MMC; > + if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE)) > + return ENVL_NOWHERE; > + return ENVL_UNKNOWN; > case QSPI_BOOT: > case SPI_NOR_BOOT: > if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)) > -- > 2.25.1 > Fabio, Thanks - this at least allows me to boot on imx8mp-venice-gw74xx without needing to enable CONFIG_ENV_IS_NOWHERE. I do however notice when I do so env is attempted to load from MMC dev 0 (CONFIG_ENV_IS_IN_MMC=y) - what controls the device number in this case as for this board, the emmc is dev 2. U-Boot SPL 2022.04-00073-g9d2b56e8338a (Apr 25 2022 - 12:35:37 -0700) DRAM : LPDDR4 4 GiB WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from BOOTROM Find img info 0x48025c00, size 1396 Need continue download 1024 DTB : imx8mp-venice-gw74xx Download 873624, Total size 875672 NOTICE: BL31: v2.4(release):f884ad7b0ba2 NOTICE: BL31: Built : 14:00:19, Mar 17 2022 U-Boot 2022.04-00073-g9d2b56e8338a (Apr 25 2022 - 12:35:37 -0700) CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz) CPU: Industrial temperature grade (-40C to 105C) at 46C Reset cause: POR Model: Gateworks Venice GW74xx i.MX8MP board DRAM: 4 GiB clk_register: failed to get osc_32k device (parent of usb_root_clk) Core: 211 devices, 24 uclasses, devicetree: separate WDT: Started watchdog@30280000 with servicing (60s timeout) MMC: FSL_SDHC: 2 Loading Environment from MMC... MMC Device 0 not found *** Warning - No MMC card found, using default environment In: serial@30890000 Out: serial@30890000 Err: serial@30890000 Net: KSZ9897S: eth2: lan1, eth3: lan2, eth4: lan3, eth5: lan4, eth6: lan5, eth1: ethernet@30be0000, eth0: ethernet@30bf0000 Best Regards, Tim
Hi Tim, On 25/04/2022 16:41, Tim Harvey wrote: > Fabio, > > Thanks - this at least allows me to boot on imx8mp-venice-gw74xx > without needing to enable CONFIG_ENV_IS_NOWHERE. Care to reply with your Tested-by? > > I do however notice when I do so env is attempted to load from MMC dev > 0 (CONFIG_ENV_IS_IN_MMC=y) - what controls the device number in this > case as for this board, the emmc is dev 2. That's a separate issue. I see that you replied to Peng's patch: "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause for your env numbering problem.
On Mon, Apr 25, 2022 at 3:47 PM Fabio Estevam <festevam@denx.de> wrote: > > Hi Tim, > > On 25/04/2022 16:41, Tim Harvey wrote: > > > Fabio, > > > > Thanks - this at least allows me to boot on imx8mp-venice-gw74xx > > without needing to enable CONFIG_ENV_IS_NOWHERE. > > Care to reply with your Tested-by? Sure, Tested-By: Tim Harvey <tharvey@gateworks.com> > > > > > I do however notice when I do so env is attempted to load from MMC dev > > 0 (CONFIG_ENV_IS_IN_MMC=y) - what controls the device number in this > > case as for this board, the emmc is dev 2. > > That's a separate issue. agreed it would be a separate issue... just curious if you knew where that was coming from. It certainly isn't a common behavior to boot via USB then expect 'saveenv' to save to a specific eMMC device. > > I see that you replied to Peng's patch: > "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause > for your env numbering problem. That has nothing to do with the mmc device used for U-Boot env. Commit f342c9e381c0 ("imx: dynamic setting mmcdev and mmcroot") adds setting 'mmcroot=' if mmcautodetect=yes which seems to me like a completely inappropriate hack that assumes U-Boot's mmc device numbering matches the kernels device numbering (which has changed over time and is not a stable ABI). I believe you have been involved in discussions about that in the past as well regarding how to best tell the kernel what the root device is. Every discussion I have seen (and there have been many over the years) end up with the recommendation of using UUID. Best regards, Tim
Hi Tim, On Mon, Apr 25, 2022 at 8:15 PM Tim Harvey <tharvey@gateworks.com> wrote: > Tested-By: Tim Harvey <tharvey@gateworks.com> Thanks. > agreed it would be a separate issue... just curious if you knew where > that was coming from. It certainly isn't a common behavior to boot via > USB then expect 'saveenv' to save to a specific eMMC device. > > > > > I see that you replied to Peng's patch: > > "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause > > for your env numbering problem. > > That has nothing to do with the mmc device used for U-Boot env. Commit > f342c9e381c0 ("imx: dynamic setting mmcdev and mmcroot") adds setting > 'mmcroot=' if mmcautodetect=yes which seems to me like a completely > inappropriate hack that assumes U-Boot's mmc device numbering matches Agreed. > the kernels device numbering (which has changed over time and is not a > stable ABI). I believe you have been involved in discussions about > that in the past as well regarding how to best tell the kernel what > the root device is. Every discussion I have seen (and there have been > many over the years) end up with the recommendation of using UUID. Yes, using UUID is good solution for that. mmc alias also works in kernels > 5.10 too.
Hi Fabio On Tue, Apr 26, 2022 at 3:57 AM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Tim, > > On Mon, Apr 25, 2022 at 8:15 PM Tim Harvey <tharvey@gateworks.com> wrote: > > > Tested-By: Tim Harvey <tharvey@gateworks.com> > > Thanks. > > > agreed it would be a separate issue... just curious if you knew where > > that was coming from. It certainly isn't a common behavior to boot via > > USB then expect 'saveenv' to save to a specific eMMC device. > > > > > > > > I see that you replied to Peng's patch: > > > "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause > > > for your env numbering problem. > > > > That has nothing to do with the mmc device used for U-Boot env. Commit > > f342c9e381c0 ("imx: dynamic setting mmcdev and mmcroot") adds setting > > 'mmcroot=' if mmcautodetect=yes which seems to me like a completely > > inappropriate hack that assumes U-Boot's mmc device numbering matches > > Agreed. > > > the kernels device numbering (which has changed over time and is not a > > stable ABI). I believe you have been involved in discussions about > > that in the past as well regarding how to best tell the kernel what > > the root device is. Every discussion I have seen (and there have been > > many over the years) end up with the recommendation of using UUID. > > Yes, using UUID is good solution for that. > > mmc alias also works in kernels > 5.10 too. What changes if we drop? Does the board boot anyway? Michael
> From: Fabio Estevam <festevam@denx.de> > When trying to boot via USB on i.MX8MN it is necessary to specify > the U-Boot environment location, otherwise the boot process simply > hangs. > Specify the environment location when booting from USB. > Tested on a imx8mn-evk. > Suggested-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> > Signed-off-by: Fabio Estevam <festevam@denx.de> > Tested-By: Tim Harvey <tharvey@gateworks.com> Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 7059d87e336b..34a07b53e57a 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -1536,6 +1536,16 @@ enum env_location arch_env_get_location(enum env_operation op, int prio) return ENVL_UNKNOWN; switch (dev) { + case USB_BOOT: + if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)) + return ENVL_SPI_FLASH; + if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND)) + return ENVL_NAND; + if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC)) + return ENVL_MMC; + if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE)) + return ENVL_NOWHERE; + return ENVL_UNKNOWN; case QSPI_BOOT: case SPI_NOR_BOOT: if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))