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