public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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