[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161008/4d81b33d/attachment.sig>

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161008/e02f10cf/attachment.sig>

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Tom Rini]

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).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161008/4c8e0a1a/attachment.sig>

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************