[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

>> >
>> > Memory is always memory. Serially attached devices are NOT memory.
>>
>> That is _your_ definition of memory, others like "Webster Dictionary"
>> say:
>> 
>> "Memory: a device (as a chip) or a component of a device in which
>> information especially for a computer can be inserted and stored and
>> from which it may be extracted when wanted; especially : RAM"
>> 
>> You add an extra requirement that memory must be randomly addressable
>> over a parallel bus.  This view is uncompatible with Websters
>> dictionary which does not pose such restrictions.  Furthermore,
>> everyone designing flash memories, believe that serial flash memories
>> are memories.
> 
> That belive has nothing to do with software interface design. While you
> pretend serial flash memory is somehow mapped into procesor address
> space, others have different ideas. "Webster Dictionary" uses largest
> common denominator so its definition applies to hard discs as well.
> Do we pretend hard disc content is mapped over IDE or SCSI bus into
> CPU address space?

Not in U-boot but in very efficient databases, the virtual memory is used to directly map
to hard disks since this is much more efficient than file access.
This is one of the main reasons to move to 64 bit virtual addressing

my primary concern is ease of use, and I am pretty sure that 
any new interface will result in more typing than the old interface.

Just the thought of having to type 
"spi write" or 
"dataflash write" 

instead of 

"cp.b"

sends shudder down my spine...

If people agreed that we change the memory interface from "cp.b" to

"memory write"

then I would have more sympathy for the change.

Any interface to dataflash would need the following operations:

* move from sdram to dataflash (with optional checksum write & byte granularity)
* move from dataflash to sdram (with optional checksum check & byte granularity)
* compare dataflash to sdram
* list dataflash contents
* fill dataflash
* modify dataflash (with byte granularity)
* erase dataflash (byte and partition)
* enable/disable write protection of dataflash partition
* print dataflash chip info

I see no reason to compare two dataflash areas and to compare two dataflash areas.

It should be possible to stored the environment in dataflash

The partitioning of the flash needs to take into account that 
the dataflash pages are not 2^n, they are 2^n + some small amount.
The 256 page sectors should also be taken into account.
The current partitioning is totally screwed for a linux-2.6 kernel.
It would be good to be able to change the partition information dynamically
so you can grow/shrink the linux-kernel size.

Possibly the pagesize should be migrated into the environment




[snip]


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
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib@81.80.104.162/