[U-Boot-Users] Atmel DataFlash hooks.
Ulf Samuelsson
ulf at atmel.com
Tue Jan 30 07:55:25 CET 2007
J. William Campbell skrev:
> Ulf Samuelsson wrote:
>
>
>>> If it can be decided that the only devices that will be supported by the
>>> memory commands in cmd_mem.c are those devices that can be read directly
>>> as ram without a read routine, I think that would help clarify the
>>> intent of the commands.
>>>
>>>
>>>
>>>
>> Why limit to "read".
>> Why not say that any memory which can be read or *written* without a driver
>> will be supported by the cmd_mem.c ?
>>
>>
>>
>>
>>
> There are at least two very good reasons why adding the "written"
> constraint is not practical: First, as he has stated several times in
> this thread, Mr. Denk believes that users regard NOR flash as just like
> ram and therefore expect ram commands to work on it. This point of view
> certainly has merit, and while we may not all totally agree with it, it
> is, and must be, Mr. Denk's u-boot. He is the final determining person
> on what will be accepted.
>
Dataflash users regard dataflash as just like RAM
even though all commands are not implemented.
> The second, and perhaps even better reason to not remove NOR flash from
> the memory commands is that it will break just about 100% of all
> existing u-boot configurations. Ok, maybe it's 95%, but its real large.
> This doesn't even take into account how many README files out there
> describe copying things into flash with the cp command. This type of
> support is not going away for these reasons.
>
So you are happy with only breaking 100% of all dataflash based
configurations?
> My main goal in this thread is to create/keep the "read" constraint
> intact so that we don't have constant additions of #ifdefs to the
> cmd_mem.c to support any arbitrary non-memory bus devices that people
> decide they want to use like memory, or that if we were going to do that
> we would create a way to do it that didn't result in an #ifdef maze.
> Mr. Denk has solved this concern on my part. We aren't going to add
> devices that require read routines.
>
> Best Regards,
> Bill Campbell
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
--
Best Regards,
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
links: www.avrfreaks.net; www.at91.com; avr32linux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070130/5d145a48/attachment.vcf
More information about the U-Boot
mailing list