[U-Boot] [U-Boot, 1/3] sysboot: Add support for ubifs to the sysboot command

[Hans de Goede]

Hi,

On 20-08-15 21:53, Stephen Warren wrote:


 > On 20-08-15 18:04, Hans de Goede wrote:
>> ubifs does not go though the generic block layer because mtd devices
>> are special, so the "any" filesystem option to sysboot does not work,
>> this adds support for a "ubifs" filesystem to the sysboot command which
>> makes it possible to boot from ubifs using an extlinux.conf file.
 >
 > Why are they special? Surely ubifs support can be integrated into the
 > filesystem layer, thus removing the need for patches 1 and 3 in this series?

I looked into that before going that root, the problem is that the
filesystem layer assumes that files sit on top of block devices,
and all the filesystem layer code operates on block_dev_desc_t devices.

But ubifs operates on ubi volumes which in turn operate on raw nand,
this has vastly different characteristics then regular block devices.

ubifs deals with erase-blocks, finding or creating a free
erase block when it needs to write stuff, then erasing an entire
block and writing part of it a page-size at a time where
erase-block-size != page-size, and both are typically of values
much larger then disk sector-sizes. There is no notion of erase
blocks in the fs / block layer.

Working with raw flash just is vastly different from working with
block devices, so ubifs can not be shoe-horned to fit into the
filesystem layer. I agree this would have been the logical thing
to do, and I've looked into doing this, but the 2 simply do not fit.

 > The problem here is that in patch 3,BOOTENV_DEV_UBIFS and
 > BOOTENV_SHARED_UBIFS duplicate the file looping logic that already exist
 > in other block device scanning macros. Naively it looks like it should
 > be possible to avoid that completely. One change I vaguely had in mind
 > for the distro boot scripts was to add a user-configurable environment
 > variable to specify which of extlinux, script (and later perhaps
 > Android, ...) support each partition was scanned for. Any time a change
 > like that is made, with this patch applied first, that change would have
 > to be replicated twice (and potentially n times if we continue down this
 > path).

As I said in my commit msg: "mtd devices are special", so I'm afraid we
will just have to live with a little duplication here.

Regards,

Hans