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

Tim Harvey tharvey at gateworks.com
Tue Mar 14 13:07:06 UTC 2017


On Mon, Mar 13, 2017 at 6:08 PM, Sergey Kubushyn <ksi at 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.

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?

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.

Regards,

Tim


More information about the U-Boot mailing list