From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Tue, 30 Jan 2007 07:55:25 +0100 Subject: [U-Boot-Users] Atmel DataFlash hooks. In-Reply-To: <45BE95C6.8090809@comcast.net> References: <20070129132910.020C2353AC5@atlas.denx.de> <45BE7E71.5010703@atmel.com> <45BE95C6.8090809@comcast.net> Message-ID: <45BEEBDD.9060705@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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