[U-Boot-Users] Atmel DataFlash hooks.

Tolunay Orkun listmember at orkun.us
Wed Jan 31 08:44:45 CET 2007

So far I have been staying out of this thread. But I felt maybe my $0.02 
could be useful in this discussion.

I personally feel like existing commands should work on future devices. 
However, assuming not every memory can be mapped to processor memory 
space directly I propose prefixing the addresses with an a"ddress space 
tag" or simply tag (expanding from original similar suggestion).

For example,

cp.b 0xfff00000 tag:0x00002000 2000

The tag would be defined by board designer as appropriate for the 
particular board. For example, it could be "sd1", "sd2", "eeprom", 
"hdd". In this case, "sd1", "sd2" could be referring different instances 
of the same type of device (say sd/mmc memory).

I am envisioning associated with the "tag" the board designer maps a 
technology driver "dataflash", "mmc", "ide", etc. This approach could 
even give us the opportunity to use window mapped flash devices (i.e. 
flash is mapped into memory smaller than total device size) etc. This 
approach would also not modify the user experience significantly. U-Boot 
commands could be developed cleanly and the commands would uniformly use 
a limited number of accessors provided by the technology drivers. This 
could help eliminate the #ifdef maze and remove inconsistencies between 
commands which have been mentioned in the previous posts of this thread. 
I think in addition to ram, we can  support regular nor flash that is 
directly mapped to address space as before (grandfathered).If a command 
could not be supported on a device (like protect on/off) the command 
would issue an error if issued for incompatible device/memory space.

What do you think?


More information about the U-Boot mailing list