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;...
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;...
> +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".
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;...
> +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".
> +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.
> + puts("Using default GPT UUID\n");
> +
> + return set_gpt_info(&mmc->block_dev);
> +}
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
