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