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 21:14:31 +0100 [thread overview]
Message-ID: <5320C027.5080109@petermaier.org> (raw)
In-Reply-To: <20140312193318.GW16805@bill-the-cat>
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.
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 ...
best regards,
Hannes
next prev parent reply other threads:[~2014-03-12 20:14 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
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 [this message]
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=5320C027.5080109@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.