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. 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
