Hi Stephen,
>
> > On 09/13/2012 02:10 AM, Lukasz Majewski wrote:
> > > Documentation of the GPT format.
> >
> > > diff --git a/doc/README.gpt b/doc/README.gpt
> >
> > > +Example usage:
> > > +==============
> > > +
> > > +To restore GUID partition table one needs to:
> > > +1. at ./include/configs/{board}.h
> > > + - define "partitions=" environment variable with format:
> > > +
> > > "name=u-boot,size=60M;name=kernel,size=60M;name=platform,size=1G;"
> > > + - define GPT_PARTS_NUM with actual number of partitions (as
> > > defined above)
> >
> > That seems unfortunate; the partitions variable and GPT_PARTS_NUM
> > define could easily become out-of-sync (what if the user edited the
> > variable in order to create an alternative disk layout, or what if a
> > developer simply forgot to update GPT_PARTS_NUM when editing the
> > hard-coded value?).
> >
> > Instead, can't GPT_PARTS_NUM be removed, and the code simply count
> > the number of entries in the partitions variable?
>
> Yes, the GPT_PARTS_NUM can (and shall be replaced) with a runtime
> detection of the number of available partitions. This can be done in a
> similar way as it is done at DFU code.
>
> >
> > > + - #define CONFIG_EFI_PARTITION and #define CONFIG_CMD_GPT
> > > +
> > > +2. From u-boot prompt type:
> > > + gpt mmc 0 uuid_disk=ec2cddf2-fbf5-11e1-af3a-001fd09285c0, \
> > > + uuid1=ed09c4b0-fbf5-11e1-9a95-001fd09285c0, \
> > > + uuid2=edd6d93c-fbf5-11e1-875a-001fd09285c0, \
> > > + uuid3=f0485114-fbf5-11e1-a3ae-001fd09285c0 ...
> > > +
> > > + UUIDs shall be defined up to GPT_PARTS_NUM. Smaller number is
> > > acceptable.
> > > + When UUIDs are NOT provided, internal (rather weak) GUID
> > > generator will be
> > > + used instead
> >
> > Hmmm. It's a little unfortunate to provide the partitions list
> > through one mechanism (environment variable with a hard-coded
> > name), and the UUIDs through a different mechanism (command-line).
> > Surely these two mechanisms can be combined; rather than the
> > command reading an environment variable, you could at least require
> > the user to pass the appropriate data on the command-line, and
> > optionally have them pass the environment variable if they want to
> > use the pre-defined layout, e.g.:
> >
> > pre-defined:
> > gpt mmc 0 ${partitions}
> >
> > manual/custom layout:
> > gpt mmc 0 name=u-boot,size=60M;name=kernel,size=60M;...
> >
> > Then, I wonder if you couldn't define the partitions environment
> > variable as:
> >
> > partitions=\
> > name=u-boot,size=60M,uuid=${uuid_gpt_u_boot};\
> > name=kernel,size=60M,uuid=${uuid_gpt_kernel};...
> >
> > and have the environment variables expanded as in:
> >
> > setenv uuid_gpt_u_boot=ed09c4b0-fbf5-11e1-9a95-001fd09285c0
> > setenv uuid_gpt_kernel=...
>
> This is a good idea to allow uuid_gpt_u_boot= to be set via setenv.
> Moreover I think, that "editing" of "partitions" names, uuid and other
> parameters shall be done via setenv (as you proposed).
>
> > gpt mmc 0 ${partitions}
>
> Moreover I think, that parsing ${partitions} as a list of argv[n] is
> not the best option to proceed.
>
> I think that it would be easier to:
> 1. Prepare predefined "partitions=" variable
> at ./include/configs/trats.h (when no one is available on the
> platform) 2. Edit relevant env variables (uuid_gpt_u_boot=, etc) via
> setenv and saveenv.
> 3. restore it with gpt mmc 0 partitions (- the name of the stored and
> prepared env variable)
>
> I'd like to emphasis, that I strive to avoid parsing possibly (very)
> long list of GPT partition definition via gpt command's argv[n].
>
> If user wants to edit something, then one can use setenv to do that.
>
I must correct myself here.
After some research I will give a shoot to the
gpt mmc 0 ${partitions} approach.
As you pointed out, the depth of u-boot's shell variable expanding is
one.
Due to this the string passed to gpt command needs to be parsed and
expanded in the gpt command:
name=csa-mmc,size=8MiB,uuid=${uuid_gpt_csa-mmc}
the ${uuid_gpt_csa-mmc} needs to be expanded during runtime.
> >
> > That way, the gpt command would read everything from the
> > command-line, yet the partition layout and UUID names could be
> > specified separately, so as to allow the user to define them at
> > different times or places.
You are right, this approach (even when taking into account the extra
complexity of gpt command's run-time variables expanding) is most
universal.
I will prepare patches with this approach.
> >
> > The implementation of "gpt" would have to scan all the variables it
> > extracted from the command-line, and expand any environment variable
> > references in them for this to work, since I assume the shell
> > doesn't do recursive variable expansions like make does.
> >
> > Oh, and don't you want the "gpt" command to take a sub-command like
> > "create", so that "gpt" could do different things in the future,
> > e.g. take an existing GPT layout, and edit, say, one partition's
> > name:
> >
>
> This is a nice idea to divide the gpt commands to subcommands. However
> I now focus on gpt restoration (done in a correct and agreed
> way :-) ). I will prepare the gpt command to be easily dividable to
> sub-commands.
>
> > gpt create mmc 0 ${partitions}
> > gpt set-name mmc 0 ${partition-id} ${new-name}
>
>
>
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
