public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox