From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Petermaier Date: Wed, 12 Mar 2014 20:17:47 +0100 Subject: [U-Boot] [PATCH] Add support for offset of a filesystem within a block-device In-Reply-To: <20140312190021.GV16805@bill-the-cat> References: <1394112635-21016-1-git-send-email-oe5hpm@oevsv.at> <20140312160823.GS16805@bill-the-cat> <53209704.303@petermaier.org> <20140312190021.GV16805@bill-the-cat> Message-ID: <5320B2DB.1030203@petermaier.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> 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