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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
