[U-Boot] [PATCH 1/1]: environment in eMMC boot partition
This allows to place U-Boot environment into eMMC boot partition thus saving space on user partition for the OS (or whatever.) When booting off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions to boot so U-Boot (or SPL) is written to one (or both) such partitions. When such boot configuration is used it makes sense to place environment in the same partition where the U-Boot itself is so the entire user partition is available for the OS.
It might be not well polished yet but it is a simple patch that can be reworked later.
It uses 4 Kconfig variables right now which probably belong to the board Kconfig. Those are:
CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot partition if defined
CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be stored in (either 1 or 2)
CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be different from the environment partition
CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if defined
Here is an excerpt from actual board Kconfig:
=== Cut === config ENV_IN_EMMC_BOOT bool "Environment is in eMMC boot partition" default y
config EMMC_ENV_PART hex "eMMC boot partition used for environment (1 or 2)" default 1
config EMMC_BOOT_PART hex "eMMC boot partition the board boots off of (1 or 2)" default 1
config EMMC_BOOT_ACK bool "Enable ACKs from eMMC when booting off of boot partition" default n === Cut ===
Signed-off-by: Sergey Kubushyn ksi@koi8.net --- --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -68,6 +68,45 @@ int env_init(void) return 0; }
+#ifdef CONFIG_ENV_IN_EMMC_BOOT +__weak u8 mmc_get_env_part(struct mmc *mmc) +{ + return CONFIG_EMMC_ENV_PART; +} + +__weak u8 mmc_get_boot_part(struct mmc *mmc) +{ + return CONFIG_EMMC_BOOT_PART; +} + +__weak u8 mmc_get_boot_ack(struct mmc *mmc) +{ +#ifdef CONFIG_EMMC_BOOT_ACK + return 1; +#else + return 0; +#endif +} + +static int mmc_set_env_part(struct mmc *mmc) +{ + int ret = 0; + u8 boot_part = 0; + u8 boot_ack = 0; + u8 env_part = 0; + + boot_part = mmc_get_boot_part(mmc); + boot_ack = mmc_get_boot_ack(mmc); + env_part = mmc_get_env_part(mmc); + + ret = mmc_set_part_conf(mmc, boot_ack, boot_part, env_part); + + if (ret) + puts("MMC switch to boot partition failed\n"); + + return ret; +} +#else #ifdef CONFIG_SYS_MMC_ENV_PART __weak uint mmc_get_env_part(struct mmc *mmc) { @@ -96,6 +135,7 @@ static int mmc_set_env_part(struct mmc *mmc) #else static inline int mmc_set_env_part(struct mmc *mmc) {return 0; }; #endif +#endif
static const char *init_mmc_for_env(struct mmc *mmc) { @@ -113,6 +153,15 @@ static const char *init_mmc_for_env(struct mmc *mmc)
static void fini_mmc_for_env(struct mmc *mmc) { +#ifdef CONFIG_ENV_IN_EMMC_BOOT + u8 boot_part = 0; + u8 boot_ack = 0; + + boot_part = mmc_get_boot_part(mmc); + boot_ack = mmc_get_boot_ack(mmc); + + mmc_set_part_conf(mmc, boot_ack, boot_part, 0); +#else #ifdef CONFIG_SYS_MMC_ENV_PART int dev = mmc_get_env_dev();
@@ -121,6 +170,7 @@ static void fini_mmc_for_env(struct mmc *mmc) #endif blk_select_hwpart_devnum(IF_TYPE_MMC, dev, env_mmc_orig_hwpart); #endif +#endif }
#ifdef CONFIG_CMD_SAVEENV
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
On Wed, Oct 05, 2016 at 01:28:07PM -0700, Sergey Kubushyn wrote:
This allows to place U-Boot environment into eMMC boot partition thus saving space on user partition for the OS (or whatever.) When booting off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions to boot so U-Boot (or SPL) is written to one (or both) such partitions. When such boot configuration is used it makes sense to place environment in the same partition where the U-Boot itself is so the entire user partition is available for the OS.
It might be not well polished yet but it is a simple patch that can be reworked later.
It uses 4 Kconfig variables right now which probably belong to the board Kconfig. Those are:
CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot partition if defined
CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be stored in (either 1 or 2)
CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be different from the environment partition
CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if defined
Here is an excerpt from actual board Kconfig:
I think what's missing is that in the other cases where we do environment in the eMMC boot partitions we don't need the boot ack part. Can you see if the existing hooks work, when you add in something for boot ack?
On Sat, 8 Oct 2016, Tom Rini wrote:
On Wed, Oct 05, 2016 at 01:28:07PM -0700, Sergey Kubushyn wrote:
This allows to place U-Boot environment into eMMC boot partition thus saving space on user partition for the OS (or whatever.) When booting off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions to boot so U-Boot (or SPL) is written to one (or both) such partitions. When such boot configuration is used it makes sense to place environment in the same partition where the U-Boot itself is so the entire user partition is available for the OS.
It might be not well polished yet but it is a simple patch that can be reworked later.
It uses 4 Kconfig variables right now which probably belong to the board Kconfig. Those are:
CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot partition if defined
CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be stored in (either 1 or 2)
CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be different from the environment partition
CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if defined
Here is an excerpt from actual board Kconfig:
I think what's missing is that in the other cases where we do environment in the eMMC boot partitions we don't need the boot ack part. Can you see if the existing hooks work, when you add in something for boot ack?
Eh, I _DO_ use existing hook. And one of the parameters passed to that hook is boot ack (drivers/mmc/mmc_boot.c, line 101):
=== Cut === int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access) === Cut ===
I could've just set it to 0 unconditionally but there might be some board configs that might require it to be enabled so I made it configurable.
And I don't think we have any boards with environment in boot partition because there is simply no support for this in common/enc_mmc.c. Remember, eMMC boot partition and a partition on eMMC you boot off of are totally orthogonal :) Boot partitions (there are 2 of those and one user partition on eMMC) are special. You have to explicitely switch to a boot partition to access it. When U-Boot is started eMMC boot partition it had been read off (if the system boots off of boot partition using special boot protocol) is long gone and what U-Boot sees is _USER_ partition. One can create up to 4 GP partitions on eMMC but those are _DIFFERENT_ partitions and they all reside in _USER_ partition i.e. GP partitions just subdivide the single _USER_ partition into up to 4 parts.
When you boot off of an eMMC boot partition U-Boot binary is written into boot partition so no part of visible _USER_ partition is taken, not a single byte. That means that only one 512-byte block of the user partition is reserved (MBR/partition table) so one can start a primary DOS partition on eMMC at block 1 and use the entire space up to the last block for that partition. However there is still U-Boot environment that one has to put somewhere. Although it is possible to put it into user partition starting first DOS (or GP) partition at e.g. block 160 or so and using that gap between MBR and start of the first partition for environment it is not a right thing to do. This way we are wasting some otherwise useable eMMC storage space while still have plenty of unused space in 2 boot partitions.
If we put U-Boot in a boot partition it is logical to put its environment in the same partition, isn't it? This is even more logical knowing the fact it would save us some storage space for the OS filesystem...
But anyway, please hold off -- that patch won't apply because the alpine email client "beautifies" text-only emails for some moronic reasons by adding trailing whitespace to _SOME_ lines on mail _SEND_ thus screwing up the patch. I will re-send that patch using git send-email that seems to work correctly in a couple of hours. I will format it to follow official rules and add proper CCs before re-sending.
Did you get that nand-bootupdate patch I re-sent yesterday with git send-email? Did it work if you got it? It's been done against u-boot-imx.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
On Sat, Oct 08, 2016 at 03:41:50PM -0700, Sergey Kubushyn wrote:
On Sat, 8 Oct 2016, Tom Rini wrote:
On Wed, Oct 05, 2016 at 01:28:07PM -0700, Sergey Kubushyn wrote:
This allows to place U-Boot environment into eMMC boot partition thus saving space on user partition for the OS (or whatever.) When booting off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions to boot so U-Boot (or SPL) is written to one (or both) such partitions. When such boot configuration is used it makes sense to place environment in the same partition where the U-Boot itself is so the entire user partition is available for the OS.
It might be not well polished yet but it is a simple patch that can be reworked later.
It uses 4 Kconfig variables right now which probably belong to the board Kconfig. Those are:
CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot partition if defined
CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be stored in (either 1 or 2)
CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be different from the environment partition
CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if defined
Here is an excerpt from actual board Kconfig:
I think what's missing is that in the other cases where we do environment in the eMMC boot partitions we don't need the boot ack part. Can you see if the existing hooks work, when you add in something for boot ack?
Eh, I _DO_ use existing hook. And one of the parameters passed to that hook is boot ack (drivers/mmc/mmc_boot.c, line 101):
=== Cut === int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access) === Cut ===
I could've just set it to 0 unconditionally but there might be some board configs that might require it to be enabled so I made it configurable.
And I don't think we have any boards with environment in boot partition because there is simply no support for this in common/enc_mmc.c. Remember,
I've put environment on the boot partitions on the eMMC on Beaglebone black for a number of years. See include/configs/am335x_evm.h: #elif defined(CONFIG_EMMC_BOOT) #define CONFIG_ENV_IS_IN_MMC #define CONFIG_SYS_MMC_ENV_DEV 1 #define CONFIG_SYS_MMC_ENV_PART 2 #define CONFIG_ENV_OFFSET 0x0 #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
Now, I fully accept that it's not working in your case and there must be something further needed.
On Sat, 8 Oct 2016, Tom Rini wrote:
On Sat, Oct 08, 2016 at 03:41:50PM -0700, Sergey Kubushyn wrote:
On Sat, 8 Oct 2016, Tom Rini wrote:
On Wed, Oct 05, 2016 at 01:28:07PM -0700, Sergey Kubushyn wrote:
This allows to place U-Boot environment into eMMC boot partition thus saving space on user partition for the OS (or whatever.) When booting off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions to boot so U-Boot (or SPL) is written to one (or both) such partitions. When such boot configuration is used it makes sense to place environment in the same partition where the U-Boot itself is so the entire user partition is available for the OS.
It might be not well polished yet but it is a simple patch that can be reworked later.
It uses 4 Kconfig variables right now which probably belong to the board Kconfig. Those are:
CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot partition if defined
CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be stored in (either 1 or 2)
CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be different from the environment partition
CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if defined
Here is an excerpt from actual board Kconfig:
I think what's missing is that in the other cases where we do environment in the eMMC boot partitions we don't need the boot ack part. Can you see if the existing hooks work, when you add in something for boot ack?
Eh, I _DO_ use existing hook. And one of the parameters passed to that hook is boot ack (drivers/mmc/mmc_boot.c, line 101):
=== Cut === int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access) === Cut ===
I could've just set it to 0 unconditionally but there might be some board configs that might require it to be enabled so I made it configurable.
And I don't think we have any boards with environment in boot partition because there is simply no support for this in common/enc_mmc.c. Remember,
I've put environment on the boot partitions on the eMMC on Beaglebone black for a number of years. See include/configs/am335x_evm.h: #elif defined(CONFIG_EMMC_BOOT) #define CONFIG_ENV_IS_IN_MMC #define CONFIG_SYS_MMC_ENV_DEV 1 #define CONFIG_SYS_MMC_ENV_PART 2 #define CONFIG_ENV_OFFSET 0x0 #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
Now, I fully accept that it's not working in your case and there must be something further needed.
That's all nice but it is not like it boots off of eMMC special boot partition and environment is actually NOT in eMMC boot partition...
eMMC is special -- it has 2 additional boot partitions that are HIDDEN on normal use and only used for special boot protocol that is only implemented in SOME SoCs. Regular MMC card has only one hardware part that is same as eMMC user partition. Actually there is yet another one in eMMC called RPMB but that one is totally special and not a storage partition at all. Linux shows up at least 3 partitions on eMMC that are usually named /dev/block/mmcblkXboot[0,1] and /dev/block/mmcblkXpY so boot partitions can be accessed as regular block devices. They are made read-only by default so one has to set a partition R/W before it can be written to.
Older SoCs can not take advantage of those boot partitions -- they treat eMMC as a regular MMC device with only one partition and it works just fine, just advanced eMMC features are wasted. i.MX6 boots off of eMMC boot partition if available and there are special boot configuration switches for this -- you can select the boot proto bus width, boot ACK, and some other parameters. It is OK to waste those resources if SoC does not support those -- there is no other choice anyway -- but if they ARE supported why wouldn't we use those?
eMMC boot partitions are _NOT_ in eMMC address space by default -- all address space corresponds to USER partition. In order to access a boot (or RPMB) partition one has to issue a special mmc command writing to extended command register, EXT_CSD[179] that allows to switch to a boot partition. When you switched to a boot partition user partition becomes unavailable i.e. the entire address space corresponds to that boot partition you switched to and is looks like the only one available on that eMMC device.
There are special compile-time config variables in U-Boot for including boot and RPMB partition access (CONFIG_SUPPORT_EMMC_BOOT and CONFIG_SUPPORT_EMMC_RPMB respectively) that add corresponding commands and access methods to regular "mmc" command (cmd/mmc.c line 742 and other places.) It is eMMC-specific, regular MMC devices do _NOT_ have those features.
BTW, U-Boot list server ran out of space so it won't show up in regular list posts until the space issue is fixed...
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
On Sat, Oct 08, 2016 at 03:41:50PM -0700, Sergey Kubushyn wrote:
Did you get that nand-bootupdate patch I re-sent yesterday with git send-email? Did it work if you got it? It's been done against u-boot-imx.
Yes, but I've not had a chance to look at it (and none of my imx boards have NAND, just SD/MMC and SATA).
participants (2)
-
Sergey Kubushyn -
Tom Rini