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