From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Fri, 05 Oct 2012 12:35:28 +0200 Subject: [U-Boot] [PATCH v3 3/7] gpt:doc: GPT (GUID Partition Table) documentation In-Reply-To: <505764B0.4020503@wwwdotorg.org> References: <1345795995-24656-1-git-send-email-l.majewski@samsung.com> <1347523805-17825-1-git-send-email-l.majewski@samsung.com> <1347523805-17825-4-git-send-email-l.majewski@samsung.com> <505764B0.4020503@wwwdotorg.org> Message-ID: <20121005123528.73196e27@amdc308.digital.local> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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