From: Hannes Petermaier <hannes@petermaier.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Add support for offset of a filesystem within a block-device
Date: Wed, 12 Mar 2014 18:19:00 +0100 [thread overview]
Message-ID: <53209704.303@petermaier.org> (raw)
In-Reply-To: <20140312160823.GS16805@bill-the-cat>
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@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
next prev parent reply other threads:[~2014-03-12 17:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 13:30 [U-Boot] [PATCH] Add support for offset of a filesystem within a block-device Hannes Petermaier
2014-03-12 16:08 ` Tom Rini
2014-03-12 17:19 ` Hannes Petermaier [this message]
2014-03-12 19:00 ` Tom Rini
2014-03-12 19:17 ` Hannes Petermaier
2014-03-12 19:33 ` Tom Rini
2014-03-12 20:14 ` Hannes Petermaier
2014-03-12 20:27 ` Tom Rini
2014-03-12 20:51 ` Hannes Petermaier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53209704.303@petermaier.org \
--to=hannes@petermaier.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox