Hi Sam,
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.0.0_r25/fastboot/README.md#command-reference
> [2] https://www.jedec.org/system/files/docs/JESD84-A441.pdf
>
> Signed-off-by: Sam Protsenko <semen.protse...@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 erased memory 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
--
Best Regards,
Eugeniu
