From: Ulf Samuelsson <ulfs@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Atmel DataFlash hooks.
Date: Wed, 31 Jan 2007 18:37:15 +0100 [thread overview]
Message-ID: <007201c7455f$aebb2b20$01c4af0a@atmel.com> (raw)
In-Reply-To: 528646bc0701310911m76603e4fv672659ec28393ae4@mail.gmail.com
Grant Likely wrote:
> On 1/29/07, Wolfgang Denk <wd@denx.de> wrote:
>> In message <45BD6755.3000100@comcast.net> you wrote:
>>> On the other hand, I do not think it less logical to require a
>>> write to flash to consist of a command different from cp, since in
>>> order for it to actually work, the user must have done all the
>>> right preparation.
>>
>> Call it historical reasons, then ;-)
>>
>>> takes no code at all. The only issue arises with cp/loadX. If we all
>>> agree there is no desire to interface anything that requires a
>>> routine to read data from it to the memory commands, then I have no
>>> desire to go there either. Presently, we have loadX commands that
>>> will work with
But we dont all agree,
I only see a bunch of non-data flash users that agree
that dataflash users do not need to do memory commands.
Memory commands are used to handle flash and DRAM.
The user today see no difference between dataflash and flash,
and use both kinds in the same way.
It is completely illogical then to claim that the memory
commands are useful for parallel flash and not for serial flash.
Please explain to me why the users should care about
that you do not like the internal implementation?
The idea that dataflash / mmc / sd could be used with a prefix,
also shows a total unwillingness.
A perfectly good implementation would let the memory commands
(after translation of environment variables)
send the parameters to a validation routine for each supported memory.
The validation routine would return an accept or reject.
If accepted, then for you would call a probe routine
for any memorty read, which would return a pointer to a valid block
of memory containint minimum n valid bytes.
The SDRAM/Flash would just return the passed parameters
while a serial flash memory /memor card/NAND flash etc
would first read a block into a buffer and then return
a pointer to the buffer.
With such a structure, it is up to the driver to select how to
handle memory addresses.
An MMC driver could validate "mmc:10000FFFF" (note > 4 GB address)
and a dataflash driver could check for addresses between
C0000000..DFFFFFFF like it does today.
At the intialization of u-boot, each flash driver registers
its access routines in a table.
Then no ifdefs would be needed and any memory can
be used as memory.
>> I do agree. Grant?
>
> Yes, I agree.
>
>>
>> [I really have to stop myself from writing "You can take this for
>> Granted" :-) ]
>
> :-P
Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM: +46 (706) 22 44 57
Tel: +46 (8) 441 54 22
Fax: +46 (8) 441 54 29
Mail: Box 2033 174 02 Sundbyberg
Visit: Kavalleriv?gen 24
174 58 Sundbyberg'
Sweden
next prev parent reply other threads:[~2007-01-31 17:37 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 [this message]
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
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='007201c7455f$aebb2b20$01c4af0a@atmel.com' \
--to=ulfs@atmel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox