From: Tolunay Orkun <listmember@orkun.us>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Atmel DataFlash hooks.
Date: Wed, 31 Jan 2007 01:44:45 -0600 [thread overview]
Message-ID: <45C048ED.7060202@orkun.us> (raw)
In-Reply-To: <1defaf580701291306h3a13f937k31bf792cd7ae2835@mail.gmail.com>
So far I have been staying out of this thread. But I felt maybe my $0.02
could be useful in this discussion.
I personally feel like existing commands should work on future devices.
However, assuming not every memory can be mapped to processor memory
space directly I propose prefixing the addresses with an a"ddress space
tag" or simply tag (expanding from original similar suggestion).
For example,
cp.b 0xfff00000 tag:0x00002000 2000
The tag would be defined by board designer as appropriate for the
particular board. For example, it could be "sd1", "sd2", "eeprom",
"hdd". In this case, "sd1", "sd2" could be referring different instances
of the same type of device (say sd/mmc memory).
I am envisioning associated with the "tag" the board designer maps a
technology driver "dataflash", "mmc", "ide", etc. This approach could
even give us the opportunity to use window mapped flash devices (i.e.
flash is mapped into memory smaller than total device size) etc. This
approach would also not modify the user experience significantly. U-Boot
commands could be developed cleanly and the commands would uniformly use
a limited number of accessors provided by the technology drivers. This
could help eliminate the #ifdef maze and remove inconsistencies between
commands which have been mentioned in the previous posts of this thread.
I think in addition to ram, we can support regular nor flash that is
directly mapped to address space as before (grandfathered).If a command
could not be supported on a device (like protect on/off) the command
would issue an error if issued for incompatible device/memory space.
What do you think?
Tolunay
next prev parent reply other threads:[~2007-01-31 7:44 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 [this message]
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
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=45C048ED.7060202@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