[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson <ulf@atmel.com>]

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