All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.