From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Tue, 30 Jan 2007 07:52:04 +0100 Subject: [U-Boot-Users] Atmel DataFlash hooks. In-Reply-To: <1defaf580701291628s572e1092re30ea906140e2a30@mail.gmail.com> References: <528646bc0701281850n4b4fa2b1x7022b4daf9bfe89a@mail.gmail.com> <20070129130700.362D1353CEE@atlas.denx.de> <1defaf580701291306h3a13f937k31bf792cd7ae2835@mail.gmail.com> <45BE7BC7.8030704@atmel.com> <1defaf580701291628s572e1092re30ea906140e2a30@mail.gmail.com> Message-ID: <45BEEB14.9080302@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 Haavard Skinnemoen skrev: > On 1/29/07, Ulf Samuelsson wrote: > >>> I'm not sure if I understand. U-boot pretends mmc and DataFlash are >>> memory mapped? That sounds completely insane, especially for MMC. What >>> happens if you insert an 8GB SD card on a 32-bit host? >>> >>> >>> >> There is nothing to stop U-Boot memory commands from implementing a 64 >> bit virtual address space. >> > > Except that for most (all?) CPUs supported by u-boot, the virtual > address space _isn't_ 64 bit. > > >> (The day that you have an 8GB Dataflash, Champagne corks will >> fly.Largest one today is 8 MB) >> > > Yeah, that's why I said it makes slightly more sense to do this with > DataFlash than with MMC. But I'm guessing that whoever implemented the > memory mapped MMC thing didn't expect MMC cards to reach 8 GB any > time soon either. > > >>> I haven't actually used DataFlash on any avr32 boards yet, but I have >>> written an MMC driver for it and I didn't even know it could be >>> accessed as a memory-mapped device. In fact, I can't even understand >>> why anyone would want that -- >>> >> The reason to memory map is that then it is easy to do memory commands >> like copy, compare etc, which you do want to do on dataflash, even >> though it is not fully implemented in the current mainstream. >> I have implemented additional functions, because they are really needed. >> I wrote them because it is such a pain to copy to RAM before you can >> compare, >> and I definitely do not like to have to start doing that again. >> > > I agree that the functionality is needed. I just disagree with the interface. > > >> It is perfectly possible to memory map the dataflash without having a lot >> of ifdefs, by letting the memory commands call a driver. >> I believe this is the way forward. >> >> It is easier for a user to learn a single command set to handle flash >> regardless of type. >> > > How do you teach the user that the DataFlash is mapped at some obscure > address that has absolutely nothing to do with reality? What address > is it mapped at anyway? I can't find any information about this in the > README... > I have not seen a single customer complain about the fact that a serial flash is memory mapped. The customers are informed about the memory map of the board in the board documentation. If the interface is changed, then this board documentation will have to change. Alternatively the board documentation will have to document two different command sets for handling dataflash, depending on which version of u-boot is on the board. I am convinced that this is going to cause all sorts of confusion at the customers. This simple point is key to why I think that the interface to the dataflash should remain as it is. If the internal implementation changes to something more maintainable I do not have a problem with that, as long as it is tested. I do have a problem with the approach: "let's change the interface, and leave the debugging to someone who cares about whether it works or not". I know that Atmel's AT91 department does not want to spend any time on U-Boot right now so who will test the fixes for dataflash? > Extending the memory commands to take a prefix specifying which > address space you're talking about would make a lot more sense, > though. If you only see dataflash as an extra storage device then you might have a point, in my world it is quite often the only device and I do not see any need to have any prefix. Computers are good at computation and humans does not like typing. I am sure that noone wants to have a prefix for accessing their normal parallell flash memory and I think anyone that do not want to have such a prefix, should have respect for those that do not want to have a prefix for accessing their only (serial) flash. On the memory map: I think this is up to the implementor. In AT91 U-Boot AT45/dataflash drivers you have the following mapping : * chip select 0 maps to 0xC000_0000 * chip select 1 maps to 0xD000_0000 > Then it might make sense to use 64-bit offsets too since we're > not really talking about the CPU's address space anymore, although it > could be difficult to support offsets of different size with a single > command. > > Maybe it would be better to create a different set of commands for > manipulating any kind of raw storage (including flash) and let the > memory commands deal with memory. > > >> MMC/SD/USB Memories have the advantage of beeing able to be read/written >> by the host, and this advantage makes it more natural to use a real file >> system. >> > > Exactly. It's just absurd to pretend removable storage devices reside > in physical memory. > > Haavard > > ------------------------------------------------------------------------- > 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/f6048a93/attachment.vcf