All of lore.kernel.org
 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 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.