Hi Sam,
[Relaying the same message to your gmail address] [Cc-ing Peng, as U-Boot MMC maintainer] [Cc-ing Faiz, as the one who already reviewed the patch]
On Thu, Jan 09, 2020 at 08:47:15PM +0200, Sam Protsenko wrote:
Fastboot specification [1] requires MMC to be filled with 0xFF's on "fastboot erase" command:
erase:%s Erase the indicated partition (clear to 0xFFs)Current "fastboot erase" implementation uses actual MMC erase operation blk_derase(), which can fill MMC either with 0x00 or 0xFF, depending on used MMC controller; from [2]:
The content of an explicitly erased memory range shall be '0' or '1' depending on different memory technology.For example, on BeagleBoard X15 it fills memory with '0'.
Furthermore, the minimal amount of memory blk_derase() can erase is "erase group size", and it's usually 512 KiB or more. So if we try to erase some partition which is smaller than 512 KiB, "fastboot erase" won't work at all, due to alignment. It's good practice to align all partitions to "erase group size" boundary, but it's not a strict requirement, so we just can't use blk_derase() due to this restriction.
In order to provide the consistent way to erase partitions, adhere to the fastboot spec, and fix erasing of small partitions, let's use regular MMC write operation and fill the partition with 0xFF.
[1] https://android.googlesource.com/platform/system/core/+/refs/tags/android-10... [2] https://www.jedec.org/system/files/docs/JESD84-A441.pdf
Signed-off-by: Sam Protsenko semen.protsenko@linaro.org
drivers/fastboot/fb_mmc.c | 90 +++++++++++++++++++++++++-------------- 1 file changed, 59 insertions(+), 31 deletions(-)
Roman (CC-ed) reported below [0-1] measurements results with and w/o the patch when erasing the eMMC 'system' partition on R-Car H3ULCB.
As can be seen, 'fastboot erase' now needs roughly one order of magnitude more time to perform its job. That's a big performance hit and it is not easy to live with.
I tried to track down the original commit adding the "0xff" mention to fastboot docs, but couldn't find any discussion attached to it:
erase:%s Erase the indicated partition (clear to 0xFFs)
I think that interpreting the above statement as a requirement is a matter of perspective. The statement could have also been written as a pure empirical observation on specific HW. It could also have been a reflection of author's experience, who might only have dealt with 0xFF-filled-on-erase MMC technologies.
In any case and regardless of the above, filling memory with 0xFF on erase for ALL platforms seems rather expensive. Any ideas/thoughts?
Could userspace stay agnostic whether memory is 0x0 or 0xFF on erase and just concentrate on the useful contents/payload?
[0] Before applying the patch: $ time fastboot erase system ******** Did you mean to fastboot format this ext4 partition? erasing 'system_a'... OKAY [ 6.521s] finished. total time: 6.521s
real 0m6,588s user 0m0,005s sys 0m0,000s
[1] After applying the patch: $ time fastboot erase system ******** Did you mean to fastboot format this ext4 partition? erasing 'system_a'... OKAY [ 51.256s] finished. total time: 51.256s
real 0m51,478s user 0m0,004s sys 0m0,000s