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.
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.
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}