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 <oe5...@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 ?
best regards,
Hannes
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
