From: Michal Simek <michal.simek@xilinx.com>
To: u-boot@lists.denx.de
Subject: [PATCH 6/6] cmd: Add a memory-search command
Date: Thu, 4 Jun 2020 15:10:18 +0200 [thread overview]
Message-ID: <cb4bec42-801f-a992-ee06-32a214b7e889@xilinx.com> (raw)
In-Reply-To: <CAPnjgZ24b-v+N3CuO+psEAsMt1HMTuN1+WVa6NWgmmTscWFPvQ@mail.gmail.com>
On 04. 06. 20 15:09, Simon Glass wrote:
> Hi Michal,
>
> On Thu, 4 Jun 2020 at 07:05, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> On 04. 06. 20 15:00, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Thu, 4 Jun 2020 at 02:33, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>
>>>> On 04. 06. 20 4:59, Simon Glass wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Wed, 3 Jun 2020 at 01:08, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>
>>>>>> On 03. 06. 20 3:26, Simon Glass wrote:
>>>>>>> It is useful to be able to find hex values and strings in a memory range.
>>>>>>> Add a command to support this.
>>>>>>>
>>>>>>> cmd: Fix 'md' and add a memory-search command
>>>>>>> At present 'md.q' is broken. This series provides a fix for this. It also
>>>>>>> implements a new memory-search command called 'ms'. It allows searching
>>>>>>> memory for hex and string data.
>>>>>>> END
>>>>>>
>>>>>> END likely shouldn't be here.
>>>>>
>>>>> Oops
>>>>>
>>>>>> Recently I have met with the case that I have strings in i2c eeprom and
>>>>>> need to move them to variable. And I didn't find any way how to do it.
>>>>>> That's why I am curious if you are introducing this new command to also
>>>>>> in case of string search to fill any variable which will contain this
>>>>>> string.
>>>>>
>>>>> Sorry it is just for memory-mapped things at present. But like we have
>>>>> 'i2c md' I suppose we could have 'i2c ms'.
>>>>
>>>> It wouldn't matter. I can do i2c read to memory and then ms to do it.
>>>> But question remains. When you find the string in memory how you want to
>>>> work with it? You need to have a way to move it to variable and use it
>>>> as the part of your script.
>>>
>>> Ah OK I didn't think of that.
>>>
>>> I suppose you could use $mempos to find it, if we had a way to move a
>>> string from memory to an env var? Does that exist? If not, setexpr
>>> could be enhanced to do it quite easily.
>>
>> You will find it that what's your ms does. But I haven't seen that
>> setexpr part of that.
>> Also when I find that string I should be able to for example write my
>> variable to that location.
>>
>> What was the use case you had in your mind how you want to handle string
>> when you find it?
>
> My use case is just to interactively search memory for things - e.g.
> ACPI tables, pointers to addresses and the like. Useful for debugging.
ok. Got it.
M
next prev parent reply other threads:[~2020-06-04 13:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 1:26 [PATCH 1/6] Update MEM_SUPPORT_64BIT_DATA to be always defined Simon Glass
2020-06-03 1:26 ` [PATCH 2/6] cmd: mem: Use a macro to avoid #ifdef in help Simon Glass
2020-06-03 5:56 ` Stefan Roese
2020-07-09 0:22 ` Tom Rini
2020-06-03 1:26 ` [PATCH 3/6] cmd: mem: Drop #ifdef for MEM_SUPPORT_64BIT_DATA Simon Glass
2020-06-03 5:57 ` Stefan Roese
2020-07-09 0:22 ` Tom Rini
2020-06-03 1:26 ` [PATCH 4/6] display_options: " Simon Glass
2020-07-09 0:23 ` Tom Rini
2020-06-03 1:26 ` [PATCH 5/6] command: " Simon Glass
2020-07-09 0:23 ` Tom Rini
2020-06-03 1:26 ` [PATCH 6/6] cmd: Add a memory-search command Simon Glass
2020-06-03 6:05 ` Stefan Roese
2020-06-08 2:43 ` Simon Glass
2020-06-03 7:07 ` Michal Simek
2020-06-04 2:59 ` Simon Glass
2020-06-04 8:33 ` Michal Simek
2020-06-04 13:00 ` Simon Glass
2020-06-04 13:05 ` Michal Simek
2020-06-04 13:09 ` Simon Glass
2020-06-04 13:10 ` Michal Simek [this message]
2020-07-09 0:23 ` Tom Rini
2020-06-03 5:56 ` [PATCH 1/6] Update MEM_SUPPORT_64BIT_DATA to be always defined Stefan Roese
2020-07-09 0:22 ` Tom Rini
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=cb4bec42-801f-a992-ee06-32a214b7e889@xilinx.com \
--to=michal.simek@xilinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.