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 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.