On Sat, Aug 29, 2015 at 2:36 PM, Richard Purdie <richard.pur...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
