[U-Boot] [PATCH 5/6] gpt: Support for new "gpt" command

[Lukasz Majewski <l.majewski@samsung.com>]

Hi Stephen,

> On 08/24/2012 02:13 AM, Lukasz Majewski wrote:
> > New command - "gpt" is now supported. It shows and restores the GPT
> > partition table.
> > It looks into the "partitions" environment variable for partitions
> > definition. It can be enabled at target configuration file with
> > CONFIG_CMD_GPT.
> 
> > diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
> 
> > +int set_gpt_info(block_dev_desc_t *dev_desc)
> > +{
> > +	char *ps[GPT_PARTS_NUM], *name[GPT_PARTS_NUM];
> > +	unsigned int size[GPT_PARTS_NUM];
> > +	char *tok, *t, *p, *s, *ss;
> > +	int i, ret;
> > +
> > +	s = getenv("partitions");
> > +	if (s == NULL) {
> > +		printf("%s: \"partitions\" env variable not
> > defined!\n",
> > +		       __func__);
> > +		return -1;
> > +	}
> 
> It'd be nice to be able to pass the partition definition on the
> command-line instead of (or perhaps as an alternative to) reading an
> environment variable.
> 
> Some documentation of the expected format of the partitions variable
> would be useful. From the following patch, the format appears to be:
> 
> 8M(csa-mmc),60M(u-boot),60M(kernel),...
> 
> That's not particularly extensible (think about allowing partition
> type UUID to or attributes to be specified), and the brackets are a
> bit painful. Can we use key/value for defining the values, and have a
> simple separate separator between fields and partitions, e.g.
> something like:
> 
> size=8M,name=csa-mmc;size=60M,name=u-boot;size=60M,name=kernel;...
This approach looks reasonable, but...

> 
> That would allow us to very easily allow new fields to be specified
> per partition in the future, e.g.:
> 
> uuid=XXXXX,size=512M,name=boot,type=21686148-6449-6E6F-744E-656564454649,attrs=2;uuid=YYYYY,size=7000M,name=root,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4,attrs=0;...

it would be a pain to paste so long string to u-boot command line.
Suppose we have 8 partitions to define. Then the definition string grows
considerable.

For default restoration, it would be good to define the environment
variable (like "partitions") to perform quick default restoration.

However there is a problem with passing UUID - size, name and
attributes can be defined at ./include/config/{board}.h
(partitions=size=8M,name=csa-mmc;size=60M,name=u-boot;size=60M,name=kernel)
, but UUID shall be passed by user via command line or generated
internally at u-boot (as it is proposed in this patch).

When passing from user it would look like:

gpt default uuid1 uuid2 .... uuid8

But we shall also think about using guid_gen() function (reimplemented)
for handy and quick gpt restoration.


> 
> > +U_BOOT_CMD(
> > +	gpt,	CONFIG_SYS_MAXARGS,	1, do_gpt,
> > +	"GUID Partition Table",
> ...
> > +	"gpt restore - reset GPT partition to defaults\n"
> > +	"gpt dev #num - set device number\n"
> ...
> > +static void set_gpt_dev(int dev)
> > +{
> > +	gpt_dev = dev;
> > +}
> > +
> 
> Hmmm. I think it'd be better to specify the device each time the gpt
> command was invoked. That would be simpler to use, more flexible, and
> more consistent with how other commands such as "ext2load" operate.
> 
> In other words, I would get rid of "gpt dev" completely, and instead
> of implementing "gpt restore", implement "gpt restore mmc 0".

Agree - the same approach is in dfu.

> 
> I'm not sure "restore" is the correct name, given that the command can
> write arbitrary new partition layouts, rather than just restoring some
> specific hard-coded table from e.g. a backup image.
> 
> I'm not sure that "gpt" is even the best command name; it'd be nice if
> this were generic and could be extended to work with e.g. FAT in the
> future - something like:
> 
> part write usb 1 gpt uuid=XXXXX,size=512M,name=boot,...
> part write mmc 0 fat size=512M,attrs=0x80;...

I'm open for discussion. Since part command is not yet finished, I will
use the gpt command for version 2 of this patch series. When we agree
with rest of GPT implementation we can decide if gpt or part command
will be used. OK?
> 
> > +U_BOOT_CMD(
> > +	gpt,	CONFIG_SYS_MAXARGS,	1, do_gpt,
> > +	"GUID Partition Table",
> > +	"show - show GPT\n"
> 
> s/show/gpt show/
> 
> > +static void gpt_show(void)
> > +{
> > +	struct mmc *mmc = find_mmc_device(gpt_dev);
> > +
> > +	print_part_efi(&mmc->block_dev);
> > +}
> 
> Do we really need another way of showing partition tables; "mmc part",
> "usb part", ... already exist. I think if we want another way, it'd be
> better to add this functionality to my proposed "part" command, i.e.
> "part show mmc 0".

I agree that "gpt show" is not needed. Instead "mmc part" can be used.
> 
> > +static int gpt_default(void)
> > +{
> > +	struct mmc *mmc = find_mmc_device(gpt_dev);
> > +
> > +	if (mmc == NULL) {
> > +		printf("%s: mmc dev %d NOT available\n", __func__,
> > gpt_dev);
> > +		return CMD_RET_FAILURE;
> > +	}
> 
> Why only allow mmc devices; what about USB for example? Other commands
> such as ext2load allow arbitrary device types to be used. Rob Herring
> recently posted some patches to unify how commands such as ext2load,
> ext2ls, fatload, fatls, ... all obtain a device/partition handle from
> their command-line - this patch should probably build on top of those
> patches.

Yes, but Rob's patches are not yet accepted to mainline. I'd prefer to
not use patches which aren't accepted as a base for development. 

> 
> > +	puts("Using default GPT UUID\n");
> > +
> > +	return set_gpt_info(&mmc->block_dev);
> > +}
> 


I think, that most important change is to pass table with pointers to
partition entries to set_gpt_table. Second thing is to fix guid_gen()
function and change the format of "partitions" to be key=value pairs.


-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group