[U-Boot] accessing eMMC boot partitions from U-Boot

[Stephen Warren <swarren@wwwdotorg.org>]

On 03/14/2017 07:07 AM, Tim Harvey wrote:
> On Mon, Mar 13, 2017 at 6:08 PM, Sergey Kubushyn <ksi@koi8.net> wrote:
>> On Mon, 13 Mar 2017, Stephen Warren wrote:
>>
>>> On 03/13/2017 03:34 PM, Tim Harvey wrote:
>>>>
>>>>  Greetings,
>>>>
>>>>  I'm working with some boards with eMMC FLASH and understand that I can
>>>>  set the fields of the PARTITION_CONFIG with the 'mmc partconf' command
>>>>  to specify what partition is used for boot. Once I do that to set the
>>>>  boot0 partition for example, how can I access that  partition from
>>>>  within u-boot via mmc read/write? In Linux the kernel provides access
>>>>  to user/boot0/boot1/rpmb via different devices, but I don't see u-boot
>>>>  doing that.
>>>
>>>
>>> The "mmc dev" command can be used to select which MMC device to operate
>>> on. The "typical" command "mmc dev 0" selects the main partition on MMC
>>> device 0 for later MMC-specific commands such as "mmc read". You can add an
>>> extra parameter to that command to request a specific HW partition, e.g.
>>> "mmc dev 0 1" selects boo0 of MMC device 0 and "mmc dev 0 2" selects boot1.
>>>
>>> A similar naming scheme exists for commands that take a complete device
>>> specification each time. For example, "part list mmc 0" to list partitions
>>> in the main partition on MMC device 0, or "part list mmc 0.1" to list
>>> partitions on boot0 of MMC device 0.
>>
>>
>> Unfortunately this has absolutely nothing to do with eMMC _BOOT_
>> partitions... There 2 of those on eMMC and they are _NOT_ accessible in
>> this fashion. Neither they bear any FS on them. eMMC is _SPECIAL_ in that
>> respect -- although it does look like e.g. SD Card it has 2 additional
>> _HARDWARE_ boot partitions that none of other MMC devices have. Those are
>> invisible and they are _NOT_ a part of user partition.
>>
>> I did try to push a patch that would've allowed to put U-Boot environment
>> into boot partitions so entire _USER_ partition would be free but
>> unfortunately it had been met with fierce resistance, as usual, as well as
>> my patch for writing a bootable U-Boot into boot NAND on iMX6. I will
>> probably make another attempt tomorrow or later this week as time permitted
>> against 2017-03 but will give up if this one also failed...
>>
>> We do use U-Boot with those patches in production devices which we
>> manufacture many thousands of with no problems at all.
>>
>
> Sergey,
>
> While Stephen's usage does appear to be correct and works for me to
> allow access to user/boot0/boot1 I would be interested in seeing your
> patches that allow env to be stored in boot0/boot1 and see value in
> those.

You don't need a patch for this. Here's how the Jetson TK1 board places 
the environment:

/* Environment in eMMC, at the end of 2nd "boot sector" */
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_ENV_OFFSET               (-CONFIG_ENV_SIZE)
#define CONFIG_SYS_MMC_ENV_DEV          0
#define CONFIG_SYS_MMC_ENV_PART         2

ENV_PART has been in place since mid-late 2012, and negative ENV_OFFSET 
since mid 2013.

> I'm also interested in what use cases everyone has for boot0/boot1 and
> rpmb (rpmb appears to be accessed via 'mmc rpmb'). From my
> understanding boot0/boot1 are both ideal places for SPL/U-boot. Is
> there any reason why U-Boot env shouldn't go here as well?

For example, NVIDIA Tegra stores the BCT ("Boot Configuration Table") 
there, which contains a "pointer" (eMMC boot partition offset) to the 
bootloader SW to load, which in some cases is U-Boot (a combined 
SPL+main binary) and in others is various proprietary bootloaders. 
Tegra's boot redundancy scheme doesn't make use of the separate boot HW 
partitions, in fact, I believe the boot ROM and/or some early boot SW, 
treats boot0+boot1 as effectively a concatenated RAID-0 device!. Rather, 
redundancy relies on replicating the data multiple times back-to-back in 
the boot partitions.

If you're interested, there are a few more details at:
http://http.download.nvidia.com/tegra-public-appnotes/index.html

> It also seems to me that the point of two boot partitions would be to
> allow a safe upgrade to ping-pong between the two, however I don't see
> how this would work without support from SoC boot rom (and in my case
> I don't see evidence that the IMX6 would try one, then the other).
> Obviously a user could boot from boot0, then choose to flash a new
> bootloader to boot1 and change the bootpart to boot1 but that wouldn't
> allow recovery via boot0 if boot1 was invalid/corrupt as the hardware
> would always select boot1 on powerup.

Yes, this seems like it would be a great application for the two 
partititons, and yes I agree it'd require boot ROM support or similar in 
all likelihood.