From: Pierre AUBERT <p.aubert@staubli.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command
Date: Fri, 18 Apr 2014 08:39:56 +0200 [thread overview]
Message-ID: <5350C8BC.9000607@staubli.com> (raw)
In-Reply-To: <20140417195619.09D8538040B@gemini.denx.de>
Hello Wolfgang,
Le 17/04/2014 21:56, Wolfgang Denk a ?crit :
> Dear Pierre Aubert,
>
> In message <1397747435-24042-3-git-send-email-p.aubert@staubli.com> you wrote:
>> This sub-command adds support for the RPMB partition of an eMMC:
>> * mmc rpmb key <address of the authentication key>
>> Programs the authentication key in the eMMC This key can not
>> be overwritten.
>> * mmc rpmb read <address> <block> <#count> [address of key]
>> Reads <#count> blocks of 256 bytes in the RPMB partition
>> beginning at block number <block>. If the optionnal
>> address of the authentication key is provided, the
>> Message Authentication Code (MAC) is verified on each
>> block.
>> * mmc rpmb write <address> <block> <#count> <address of key>
>> Writes <#count> blocks of 256 bytes in the RPMB partition
>> beginning at block number <block>. The datas are signed
>> with the key provided.
>> * mmc rpmb counter
>> Returns the 'Write counter' of the RPMB partition.
>>
>> The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB
> Such new options must be documented in the README.
I will add it in a V3
>
>> Signed-off-by: Pierre Aubert <p.aubert@staubli.com>
>> CC: Pantelis Antoniou <panto@antoniou-consulting.com>
>> ---
>> common/cmd_mmc.c | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 127 insertions(+), 1 deletions(-)
>>
>> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
>> index c1916c9..3cf11e7 100644
>> --- a/common/cmd_mmc.c
>> +++ b/common/cmd_mmc.c
>> @@ -130,7 +130,123 @@ U_BOOT_CMD(
>> "display MMC info",
>> "- display info of the current MMC device"
>> );
>> +#ifdef CONFIG_SUPPORT_EMMC_RPMB
>> +static int confirm_key_prog(void)
>> +{
>> + puts("Warning: Programming authentication key can be done only once !\n"
>> + " Use this command only if you are sure of what you are doing,\n"
>> + "Really perform the key programming ? ");
>> + if (getc() == 'y') {
> Would it not makes sense to flush the input before reading the char,
> so that you don;t react on any type-ahead that might already be
> buffered?
>
>> + int c;
>> +
>> + putc('y');
>> + c = getc();
>> + putc('\n');
>> + if (c == '\r')
>> + return 1;
>> + }
> Should we allow for 'Y"? And for "yes" / "Yes"?
>
> We have getenv_yesno() - maybe we should provide a similar function
> that can be used in other places where such interactive confirmation
> is needed?
I have found such a confirmation in cmd_fuse, cmd_otp and cmd_mmc. It
makes sense to provide
a global function. I will try to submit a patch for that.
>> + if (state != RPMB_INVALID) {
> Change this into
>
> if (state == RPMB_INVALID)
> return CMD_RET_USAGE;
>
> and avoid one level of indentation; this will make the code much
> easier to read.
>
>> + if (IS_SD(mmc)) {
> Is IS_SD() a reliable test for eMMC devics, or would that also return
> true in other cases?
You're right, the test must be more restrictive. The RPMB partition is
available only since the release 4.41 of the Jedec
standard. I will fix it in a V3.
>
>> + if (confirm_key_prog()) {
>> + if (mmc_rpmb_set_key(mmc, key_addr)) {
>> + printf("ERROR - Key already programmed ?\n");
>> + ret = CMD_RET_FAILURE;
>> + }
>> + } else {
>> + ret = CMD_RET_FAILURE;
>> + }
> You should really avoid deep nesting and take early exits.
> You can write this as:
>
> if (!confirm_key_prog())
> return CMD_RET_FAILURE;
>
> if (mmc_rpmb_set_key(mmc, key_addr)) {
> printf("ERROR - Key already programmed ?\n");
> ret = CMD_RET_FAILURE;
> }
>
> Please fix globally.
No problem, it will be fixed globally in V3
>
>> + } else if (state == RPMB_COUNTER) {
>> + unsigned long counter;
>> + if (mmc_rpmb_get_counter(mmc, &counter))
> Please insert a blank line between declarations and code.
Ok
>
>> + printf("%d RPMB blocks %s: %s\n",
>> + n, argv[2], (n == cnt) ? "OK" : "ERROR");
> As the input is in hex, it is usually also a good idea to (also) print
> the count in hex.
For coherency with the mmc read and mmc write, I kept the same output.
But it can be changed, of course.
>
>> #endif /* CONFIG_SUPPORT_EMMC_BOOT */
>> +#ifdef CONFIG_SUPPORT_EMMC_RPMB
>> + } else if (strcmp(argv[1], "rpmb") == 0) {
>> + return do_mmcrpmb(argc, argv);
>> +#endif /* CONFIG_SUPPORT_EMMC_RPMB */
> I think that now, with more subcommands being added, we should
> convert the mmc code to proper subcommand handling. [It might even
> make sense to do so for "mmc rpmb", too.]
Do you think about the use of the macro U_BOOT_CMD_MKENT ?
>
> Best regards,
>
> Wolfgang Denk
>
Best regards
Pierre Aubert
next prev parent reply other threads:[~2014-04-18 6:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 12:12 [U-Boot] [PATCH 0/2] eMMC: support for Read Protected Memory Block (RPMB) Pierre Aubert
2014-04-11 12:12 ` [U-Boot] [PATCH 1/2] eMMC: add support for operations in RPMB partition Pierre Aubert
2014-12-23 5:13 ` Roman Peniaev
2014-04-11 12:12 ` [U-Boot] [PATCH 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command Pierre Aubert
2014-04-17 15:10 ` [U-Boot] [PATCH V2 0/2] eMMC: support for Read Protected Memory Block (RPMB) Pierre Aubert
2014-04-17 15:10 ` [U-Boot] [PATCH V2 1/2] eMMC: add support for operations in RPMB partition Pierre Aubert
2014-04-17 15:10 ` [U-Boot] [PATCH V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command Pierre Aubert
2014-04-17 19:56 ` Wolfgang Denk
2014-04-18 6:39 ` Pierre AUBERT [this message]
2014-04-22 17:41 ` Wolfgang Denk
2014-04-22 15:54 ` [U-Boot] [PATCH V3 0/3] eMMC: support for Read Protected Memory Block (RPMB) Pierre Aubert
2014-04-22 15:54 ` [U-Boot] [PATCH V3 1/3] eMMC: add support for operations in RPMB partition Pierre Aubert
2014-04-22 15:54 ` [U-Boot] [PATCH V3 2/3] Add the function 'confirm_yesno' for interactive confirmation Pierre Aubert
2014-04-22 15:54 ` [U-Boot] [PATCH V3 3/3] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command Pierre Aubert
2014-04-22 17:48 ` Wolfgang Denk
2014-04-24 6:40 ` [U-Boot] [PATCH V4 0/3] eMMC: support for Read Protected Memory Block (RPMB) Pierre Aubert
2014-04-24 6:40 ` [U-Boot] [PATCH V4 1/3] eMMC: add support for operations in RPMB partition Pierre Aubert
2014-04-24 6:55 ` Wolfgang Denk
2014-04-24 7:16 ` Pierre AUBERT
2014-04-24 7:33 ` Wolfgang Denk
2014-04-24 7:41 ` Pierre AUBERT
2014-04-24 6:59 ` Wolfgang Denk
2014-04-24 7:56 ` Pierre AUBERT
2014-04-24 6:40 ` [U-Boot] [PATCH V4 2/3] Add the function 'confirm_yesno' for interactive Pierre Aubert
2014-04-24 6:40 ` [U-Boot] [PATCH V4 3/3] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command Pierre Aubert
2014-04-24 8:30 ` [U-Boot] [PATCH V5 0/3] eMMC: support for Read Protected Memory Block (RPMB) Pierre Aubert
2014-04-24 8:30 ` [U-Boot] [PATCH V5 1/3] eMMC: add support for operations in RPMB partition Pierre Aubert
2014-05-23 8:50 ` Pantelis Antoniou
2014-04-24 8:30 ` [U-Boot] [PATCH V5 2/3] Add the function 'confirm_yesno' for interactive Pierre Aubert
2014-05-23 8:52 ` Pantelis Antoniou
2014-04-24 8:30 ` [U-Boot] [PATCH V5 3/3] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command Pierre Aubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5350C8BC.9000607@staubli.com \
--to=p.aubert@staubli.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox