[U-Boot] [PATCH] Add support for offset of a filesystem within a block-device

[Hannes Petermaier]

On 2014-03-12 20:00, Tom Rini wrote:
> On Wed, Mar 12, 2014 at 06:19:00PM +0100, Hannes Petermaier wrote:
>> On 2014-03-12 17:08, Tom Rini wrote:
>>> On Thu, Mar 06, 2014 at 02:30:35PM +0100, Hannes Petermaier wrote:
>>>
>>>> For clear separation of user's (OS) filesystem to U-Boot and other's
>>>> stuff it is now possible to give the filesystem a specific offset and a
>>>> specific size.
>>>> For full consistency OS storage driver also has to support this and
>>>> has to use same offset and size.
>>>>
>>>> Following new parameters has been added to the block_dev_desc_t
>>>> structure:
>>>> - lba_offset : offset in blocks from which fs is reading/writing
>>>> - lba_fs     : size in blocks of fs
>>>>
>>>> This two parameters are filled from the underlaying device-driver.
>>>> As default they are initialized for giving whole size of block-device
>>>> to the filesystem.
>>>>
>>>> In case of mmc-driver a function for modifiying drive geometry is
>>>> called 'board_mmc_geometry', this function is implemented as
>>>> '__weak', so it can be replaced by a board-specific function, which
>>>> can setup suitable offset and size for the filesystem.
>>>> This function is responsible for giving reasonable values, e.g.
>>>> lba_offset+lba_fs must not exceed available blocks of the device.
>>>>
>>>> Only MMC Driver and FATFS are modified to support this.
>>>>
>>>> Signed-off-by: Hannes Petermaier <oe5hpm at oevsv.at>
>>> Sorry if I'm being dense here, but what is the usecase exactly?  When we
>>> don't have a partition table of some sort?
>>>
>> Hi Tom,
>>
>> I try to explain the use case with my application as example:
>>
>> I have an eMMC flash with 4GB space. On my target OS vxWorks is
>> running, which has as filesystem a simple DOS-FAT.
>>
>> I would like to give an offset to the filesystem due to two reasons:
>> a) U-Boot with its environment should / can not remain within the
>> DOSFS (it should not be accessible by the user/OS). Also U-Boot must
>> be at least with the MLO "in front" of the flash since i am booting
>> from the eMMC flash.
>> b) i want limit the user-accessible space to the flash to about 512MB.
>>
>> There are, for my unterstanding, two ways to achieve this:
>>
>> a) give no offset for the "blockdevice" at all and have a partition
>> table at the bottom of flash (ROM code searches in my case (am3352)
>> at several places for a bootable code, so this method would be
>> suitable for booting) - i don't know how it is on other processors,
>> the rest would be magic of the following partioning software (OS) -
>> but many os (vxworks for example) cannot have specific
>> start-cylinder for the first partition, we would have to rewrite the
>> partitioner. Making a change within the partitioning section at the
>> OS is therefore a bit critical, not at least because changes there
>> affects all other block devices too.
>>
>> So plan b) looked best for my opinion:
>> Give a specific offset/size to the 'blockdevice' within raw-flash.
>> We have to adapt only the specific blockdevice driver to detect/have
>> a specific offset/size and rest of OS don't need to know about this
>> special situation. We don't use the space laying before the offset
>> within the OS at all (clear separation). Within U-Boot we can use
>> the whole flash in "raw-mode" and use "FAT" with the beginning of
>> specified offset.
>> With the offset i also can control how much space is left for the OS
>> and its filesystem.
>>
>> Is my explanation clear ? please feel free to ask me more.
>> Whats your opinion about this ?
> Thanks for explaining.  But you should be able to have this work without
> changing U-Boot or VxWorks code by doing:
> 1) Create a partition table at the start of eMMC
> 2) Write SPL to offset 128KB
> 2b) If you like, put a backup copy at 256KB
> 3) Write U-Boot to offset 384KB as usual
>
> Now here's where I'm hindered a bit by my (lack of) knowledge of
> VxWorks.  If you cannot say that the first partition in the table is
> wherever you like (which seems odd, this is fine elsewhere), just create
> a dummy partition that covers from the start until end-512MB, and then
> make the next partiton, where you want the user to see next and make it
> be 512MB.
>
Thanks for reply.

Good idea, i've also thougt about this way ....
but what happens in case of OS is going to re-partitioning the drive 
(flash), delete all partitions (dummy-part also) an puts the first (new) 
partition behind the part-table (vxWorks can handle up to four 
partitions and we give end-user the possibility to create/delete 
partitions) ? First partition becomes laying over U-Boot @ 384k (and 
some other stuff which may be stored there).
To prevent this case we would have to modify "fdisk" of vxWorks, which i 
would like to prevent because this is a common part of OS and would 
affect all mass-storage.
With my solution, OS never can see/delete any other (dummy) partitiion - 
it has always "a normal drive" accessible.

best regards,
Hannes