[U-Boot-Users] Atmel DataFlash hooks.

Tue Jan 30 07:52:04 CET 2007

Haavard Skinnemoen skrev:
> On 1/29/07, Ulf Samuelsson <ulf at atmel.com> 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 