[OE-core] [RFC PATCH 1/2] android-tools: import android-tools from meta-smartphone into oe-core

[Nicolas Dechesne]

On Sat, Aug 29, 2015 at 2:36 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
>>
>> Assuming that make_ext4fs is a tool to create an ext4 file system,
>> what's the difference between that and our mke2fs which is used to
>> create ext4 file systems?
>>
> We've worked quite hard to land the ext4 rootfs creation code into
> upstream e2fsprogs. I'd like to understand if we're missing anything for
> that to work with fastboot. If we are, I suspect it wouldn't be hard to
> add and should save maintenance of a separate tool (support in e2fsprogs
> means we get any other ext* improvements for free).

thanks for the feedback.

I sent this as RFC , because I wanted to initiate a discussion... I
decided to simply move existing recipes from meta-smartphone/android
for that purpose.

compared to 'regular' ext4 images , fastboot added the (convenient)
ability to support sparse images, to reduce the size of what is
transmitted over the USB, when flashing (and reduce the size of
writting to eMMC). For devices with 8GB+ eMMC that is a big deal
whether we flash a raw ext4 image, or its sparse'd version. More info
about fastboot sparse format at [1].

Unfortunately I haven't found any tool to 'sparse' an existing image,
make_ext4fs is doing the FS as well, so as you noticed it duplicates
what mke2fs does. make_ext4fs generates sparse image optionally (with
-s flag), but I don't know precisely what's the difference between the
generated image vs what mke2fs would do. The non sparse image from
make_ext4fs doesn't have the sparse header, and as far as I can tell
it is a valid 'ext4' image, which I can mount with mount -o loop, for
example (or inspect with dumpe2fs).

I've looked further into that today, and :

* when transferring an image to be flashed over USB, the target uses a
RAM buffer. if the image file size is smaller than the RAM buffer,
then our standard ext4 image can be flashed just fine.

* when transferring an image larger than the internal target RAM
buffer, then the host side fastboot program will split the images into
chunks that can be individually transferred and flashed. In that case
I am able to load a standard OE ext4 image *only* if I round/pad the
image to 4096 bytes, otherwise fastboot fails (with cryptic assertion
which I don't quite understand for now). If anyone has experience with
that, please let us know.

* Of course images from make_ext4fs whether they are sparse, non
sparse, large or not, always work.

* the size if this intermediate buffer is platform specific, the host
side fastboot queries the target to know the size of this buffer.

so in short.. OE ext4 image seems to be working fine (with the file
size limitation), but we are missing the specific sparse support.
Maybe that's good enough for OE core, and we can keep the
customization/optimizations in BSP layers..


[1] http://www.2net.co.uk/tutorial/android-sparse-image-format