[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.   *
******************************************************************