From: Tolunay Orkun <listmember@orkun.us>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Atmel DataFlash hooks.
Date: Wed, 31 Jan 2007 20:46:21 -0600 [thread overview]
Message-ID: <45C1547D.4060009@orkun.us> (raw)
In-Reply-To: <20070201000604.AF6C0353A8A@atlas.denx.de>
Wolfgang Denk wrote:
>> Then please continue to explain why, when you are doing exactly
>> the same manouvers, but use a serial flash, you do not need the
>> commands.
>>
>
> Because these devices are not directly addressable in the processors
> address space, i. e. they are not memory.
>
> Everything is fine as long as the "md" command in U-Boot and the "md"
> command at my BDI2000's telnet prompt show the same results for the
> same address ranges. When this is NOT the case, something is broken.
> Here, it is the U-Boot implementation.
>
I guess I am OK with either implementation.
I think just because BDI is not capable of handling any address space
besides the processor address space should not mean we should so
restrictive of command line of U-Boot. I think address space tags that I
proposed yesterday could remove the confusion of what address the
command is referring to and it is easy to explain that a BDI could only
access untagged address space directly and everything else are
indirectly accessible memory. This would also enable us to use paged
memory mapped to a small window in processor address space seamlessly.
Anyway, I think either approach is valid and usable. There are pros and
cons with either scheme.
I think it might be easier to educate the user with one set of commands
as opposed to user having to decide which one of several <dev>
read/write commands should be applicable.
>> The concept to map an address is not at all hard to explain.
>> Even so, I have never had the question in over 100 projects.
>>
>
> For me this is a very important issue: when U-Boto and a hardware
> debugger start behaving differently, I consider this a serious
> problem. U-Boot is a boot loader, and as such mostly a hardware debug
> tool.
>
I see your point. However, with a hardware debugger you are not
currently able to mmc data directly and so you could not be able to
access mmc:0x00112233 either because "mmc:0x00112233" is not an address
that would be valid for BDI. So, I see no difference. It is really
mostly a matter of style rather than function.
Having the capability of u-boot memory commands to access different
address spaces is a convenience feature. When such feature is not
available the read/write commands will bring a chunk to ram and it will
be processed using memory commands again so first one would allow the
two operations combined but not a huge gain or loss either way.
Having said all that, I will concluded that either way is OK for me as
long as we maintain consistent architecture.
Tolunay
next prev parent reply other threads:[~2007-02-01 2:46 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-26 16:45 [U-Boot-Users] Atmel DataFlash hooks Peter.Pearse
2007-01-26 19:11 ` Grant Likely
2007-01-26 21:25 ` Wolfgang Denk
2007-01-26 22:34 ` Grant Likely
2007-01-27 0:42 ` Wolfgang Denk
2007-01-27 1:52 ` Grant Likely
2007-01-27 4:11 ` [U-Boot-Users] Arm-linux-gcc malloc get failure while arm-elf-gcc ok Rui.Zhou at nokia.com
2007-01-27 11:46 ` Rui.Zhou at nokia.com
2007-01-27 13:34 ` [U-Boot-Users] Atmel DataFlash hooks Andreas Schweigstill
2007-01-27 16:36 ` Wolfgang Denk
2007-01-27 17:04 ` Andreas Schweigstill
2007-01-27 17:17 ` Ulf Samuelsson
2007-01-28 14:39 ` Wolfgang Denk
2007-01-29 1:32 ` Andreas Schweigstill
2007-01-29 12:52 ` Wolfgang Denk
2007-01-27 22:19 ` Grant Likely
2007-01-28 1:47 ` J. William Campbell
2007-01-28 15:17 ` Wolfgang Denk
2007-01-28 22:21 ` J. William Campbell
2007-01-28 22:50 ` Wolfgang Denk
2007-01-29 2:50 ` Grant Likely
2007-01-29 13:07 ` Wolfgang Denk
2007-01-29 21:06 ` Haavard Skinnemoen
2007-01-29 22:57 ` Ulf Samuelsson
2007-01-29 23:55 ` Wolfgang Denk
2007-01-30 0:28 ` Haavard Skinnemoen
2007-01-30 1:03 ` Wolfgang Denk
2007-01-30 1:16 ` Haavard Skinnemoen
2007-01-30 22:23 ` Wolfgang Denk
2007-01-30 6:52 ` Ulf Samuelsson
2007-01-31 7:44 ` Tolunay Orkun
2007-01-29 3:17 ` J. William Campbell
2007-01-29 7:35 ` Ulf Samuelsson
2007-01-29 13:36 ` Wolfgang Denk
2007-01-29 13:29 ` Wolfgang Denk
2007-01-29 20:45 ` J. William Campbell
2007-01-29 21:48 ` Wolfgang Denk
2007-01-29 23:03 ` J. William Campbell
2007-01-30 0:01 ` Wolfgang Denk
2007-01-29 23:08 ` Ulf Samuelsson
2007-01-30 0:48 ` J. William Campbell
2007-01-30 1:06 ` Wolfgang Denk
2007-01-30 6:55 ` Ulf Samuelsson
2007-01-31 17:11 ` Grant Likely
2007-01-31 17:37 ` Ulf Samuelsson
2007-01-31 21:55 ` Wolfgang Denk
2007-01-31 23:13 ` Ulf Samuelsson
2007-01-31 23:50 ` Grant Likely
2007-02-01 0:06 ` Wolfgang Denk
2007-02-01 2:46 ` Tolunay Orkun [this message]
2007-01-29 11:10 ` Stefan Roese
2007-01-29 2:27 ` Grant Likely
2007-01-28 15:01 ` Wolfgang Denk
2007-01-29 2:33 ` Grant Likely
2007-01-29 7:49 ` Ulf Samuelsson
2007-01-29 13:38 ` Wolfgang Denk
[not found] ` <528646bc0701310848x4c63cf53gd228f860c0fd0444@mail.gmail.com>
2007-01-31 16:50 ` Grant Likely
2007-02-01 12:40 ` Andreas Schweigstill
2007-01-29 12:56 ` Wolfgang Denk
2007-01-29 10:43 ` Stefan Roese
-- strict thread matches above, loose matches on Subject: below --
2007-01-26 8:44 Grant Likely
2007-01-26 9:42 ` Peter.Pearse
2007-01-26 13:53 ` Wolfgang Denk
2007-01-26 19:24 ` Grant Likely
2007-01-26 21:27 ` Wolfgang Denk
2007-01-26 22:35 ` Grant Likely
[not found] ` <000001c7416f$fa61fed0$01c4af0a@atmel.com>
2007-01-26 19:02 ` Grant Likely
[not found] ` <02eb01c74180$c4911410$01c4af0a@atmel.com>
2007-01-26 20:27 ` Grant Likely
2007-01-26 21:21 ` Ulf Samuelsson
2007-01-26 22:40 ` Grant Likely
2007-01-26 23:01 ` Ulf Samuelsson
2007-01-26 23:46 ` Grant Likely
2007-01-27 9:44 ` Ulf Samuelsson
2007-01-29 10:49 ` Stefan Roese
2007-01-29 13:44 ` Peter.Pearse
2007-01-29 14:47 ` Stefan Roese
2007-01-29 16:03 ` Wolfgang Denk
2007-01-29 10:33 ` Stefan Roese
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=45C1547D.4060009@orkun.us \
--to=listmember@orkun.us \
--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