[U-Boot] [PATCH] Add support for offset of a filesystem within a block-device

[Tom Rini]

On Wed, Mar 12, 2014 at 09:14:31PM +0100, Hannes Petermaier wrote:
> 
> On 2014-03-12 20:33, Tom Rini wrote:
> >On Wed, Mar 12, 2014 at 08:17:47PM +0100, Hannes Petermaier wrote:
> >
> >>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.
> >Since this is really eMMC, mark SPL/U-Boot as protected?  I'd swear such
> >a thing is allowed, but I've just been looking at QSPI things recently
> >not eMMC so I might have some mental mismatch.
> >
> Hi Tom,
> You're right. SPL could be marked as protected.
> But how to deal here with u-boot itself ? its address is within a
> possible area of a partition.
> Fdisk doesn't know about that :-(
> We also cannot protect #0 where partition-table is stored, because
> user should able to create/delete partitions.

Block size then wouldn't let 0->128K be writable, 128->whatever
read-only, whatever->end writable ?

> So - maybe be a solution, but unfortunately not for me :-(
> Today we give to our end-users up to 4 partitiions, exact that what
> VxWorks can support - so i will be hard to have a 5th one ...

Well, I guess there's two ways to look at this, either just
documentation or seeing how hard it would be to make VxWorks behave like
other OSes and let partition 1 be wherever it says it is, or some
combination of both.

I do appreciate you posting the code as it may be useful to others but
at least right now, barring an outcry of "oh wait, I need this too!" I'm
inclined to mark this as RFC in patchwork.  Thanks again!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/29d1d40d/attachment.pgp>