[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson <ulf@atmel.com>]

>
> 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.
(The day that you have an 8GB Dataflash, Champagne corks will
fly.Largest one today is 8 MB)

> 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.

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.

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.


> the main usage of an MMC or SD card is
> to put a filesystem (usually FAT, but you can use pretty much
> anything) on it and use it for storage.
>
> I guess DataFlash makes slightly more sense to access this way, but I
> still think the interface is totally unintuitive.
>
> So, even though I'm technically more of a developer than a user,
> consider this a vote in favour of ripping the stuff out. Unless of
> course lots of users depend on stuff working this way. I highly doubt
> it since it doesn't even work properly (yes, the MMC stuff too; the
> mmc2info function on pxa is a total hack which only works for 32MB
> cards.)
>
> H?vard
>
> -------------------------------------------------------------------------
> 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: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070129/050570ee/attachment.vcf