On 03/14/2017 07:07 AM, Tim Harvey wrote:
On Mon, Mar 13, 2017 at 6:08 PM, Sergey Kubushyn <k...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
