From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] imx: imximage: add new CHECK/CLR BIT command
Date: Wed, 08 Jul 2015 15:16:15 +0200 [thread overview]
Message-ID: <559D229F.4050905@denx.de> (raw)
In-Reply-To: <20150630080223.GA5884@shlinux2>
Hi Peng,
On 30/06/2015 10:02, Peng Fan wrote:
> The reason to add different commands but not one CHECK_DATA_COMMAND is that
> compatible with current implementation.
> Current DCD supports "DATA 4 addr value". If want to use one CHECK_DATA_COMMAND
> to cover CHECK_BITS_SET/CLR, we need another entry, then commands like this:
> "CHECK_DATA 4 addr mask [SET or CLR]", which will make code more complex. So,
> I choose to make CHECK_BITS_SET/CLR different commands, but not one CHECK_DATA
> command.
>
> Since "4" is not used for V2, how about "CHECK_DATA SET addr mask" and
> "CHECK_DATA CLR addr mask"?
>
>>
>>>
>>> dcd_v2_t is redefined, because there may not be only one write data command,
>>> there may be many different commands like CHECK_BITS_SET, CHECK_BITS_CLR and
>>> CLR_BIT.
>>
>> I disagree or maybe this is related to i.MX7, where I could not check
>> the documentation. Please explain here: I see only one command
>> (CHECK_DATA_COMMAND, Chapter 8.7.2.2 in i.MX6Q).
>
> i.MX7 needs CHECK_DATA_COMMAND to wait some bits set, because CHECK_BITS_SET
> is implemented, so I call it a command:)
> Yeah, there is only one CHECK_DATA_COMMAND. I'll refine this piece commit msg.
>
>>
>>>
>>> dcd_len is still leaved there, since changing it needs changes for dcd v1.
>>> For v2, we check whether dcd size is larger than MAX_DCD_SIZE_V2, but not
>>> dcd_len.
>>
>> It is just a bit confusing, and these are details in implementation -
>> they are not related to the commit where you explain the new feature.
>> Move these comments inside the code where they belong to.
>
> Ok. Will do.
>
>>
>>>
>>> Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
>>> ---
>>> tools/imximage.c | 129 ++++++++++++++++++++++++++++++++++++++++++-------------
>>> tools/imximage.h | 24 +++++++++--
>>> 2 files changed, 119 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/tools/imximage.c b/tools/imximage.c
>>> index 6f469ae..1c0225d 100644
>>> --- a/tools/imximage.c
>>> +++ b/tools/imximage.c
>>> @@ -22,6 +22,9 @@ static table_entry_t imximage_cmds[] = {
>>> {CMD_BOOT_FROM, "BOOT_FROM", "boot command", },
>>> {CMD_BOOT_OFFSET, "BOOT_OFFSET", "Boot offset", },
>>> {CMD_DATA, "DATA", "Reg Write Data", },
>>> + {CMD_CLR_BIT, "CLR_BIT", "Reg clear bit", },
>>> + {CMD_CHECK_BITS_SET, "CHECK_BITS_SET", "Reg Check bits set", },
>>> + {CMD_CHECK_BITS_CLR, "CHECK_BITS_CLR", "Reg Check bits clr", },
>>
>> The table reflects Freescale's documentation. This has the big advantage
>> because there is no need to explain which command is supposed to do
>> because this is really well done by Freescale in the manuals. Here we
>> should have only an additional entry due to CHECK_DATA_COMMAND, exactly
>> what the SOC is able to do.
>
> Back to the question, why I implemented CHECK_BITS_SET/CLR, but not
> CHECK_DATA_COMMAND. I do not want to introduce more entry in one DCD entry
> such as "CHECK_DATA 4 addr mask [CLR/SET]", so I use two software commands
> to cover CHECK_DATA_COMMAND.
Yes, I understand, but if we check the current implementation you'll
agree that it follows the schema to have an entry in the command table
for each ROM command.
>>
>
> Ok. more work need to be done to use this way, seems need to refactor
> the current patch.
>
> The main point about your comments is my way implementation should
> follow Reference mannual, but not different commands implemented in imximage.c
> for only one command in reference mannual.
Yes, this is my biggest concern in your implementation. This makes IMHO
also more confusing the code later when it must be detected if it was a
CMD_DATA or CMD_CLR_BIT or...
This is automatically solved by switching to function pointers.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
prev parent reply other threads:[~2015-07-08 13:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 9:38 [U-Boot] [PATCH] imx: imximage: add new CHECK/CLR BIT command Peng Fan
2015-06-15 15:17 ` Fabio Estevam
2015-06-15 15:20 ` Otavio Salvador
2015-06-15 15:26 ` Fabio Estevam
2015-06-15 17:55 ` Chris Kuethe
2015-06-15 17:58 ` Fabio Estevam
2015-06-15 15:53 ` Stefano Babic
2015-06-16 1:48 ` Peng Fan
2015-06-16 11:30 ` Stefano Babic
2015-06-28 11:00 ` Stefano Babic
2015-06-30 8:02 ` Peng Fan
2015-07-07 20:02 ` Nitin Garg
2015-07-08 13:16 ` Stefano Babic [this message]
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=559D229F.4050905@denx.de \
--to=sbabic@denx.de \
--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