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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/49b57dd2/attachment.pgp>