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

[Ulf Samuelsson <ulf@atmel.com>]

> In message <01f401c79e40$5e938450$0302a8c0@atmel.com> you wrote:
>>
>> Any interface to dataflash would need the following operations:
> 
> Good. We're back on a technical level and can discuss potential
> implementations.
> 
> Let me try to reformulate yur suggestions a bit, trying  tomap  these
> into  my  idea  of  a  possible  interface  (just  as base for future
> discussion):
> 
>> * move from sdram to dataflash (with optional checksum write & byte
>> granularity)
> 
> * Copy from memory to dataflash
> 
>  I see no reason why we should restrict the source of  the  copy  to
>  RAM.  Also,  we should use the term "copy" as "move" to me includes
>  the operation of removing/erasing the source of the data.
> 
>  What exactly do you mean by "checksum write"?  The  currently  used
>  "cp.b" interface doesn't do anything like this either, or does it?
> 

No but a way to common error is that the kernel is too large to fit into
its allocated area and when the file system is written it overwwrites the end
of the kernel.
In my branch, I can set an environment variable crccheck=1
and if set, any cp.b to dataflash will add a checksum at the end.
Any cp.b from dataflash will again compute the checksum
and compare vs the checksum at the end.

Saves me a lot of confusing linux boot errors.

>> * move from dataflash to sdram (with optional checksum check & byte
>> granularity)
> 
> * Copy from dataflash to memory.
> 
>  Same remars as above.
> 
>> * compare dataflash to sdram
> 
> * That would be a two step procedure, like currently used for other
>  storage devices:
> 
>  - Copy from dataflash to memory
>  - compare two memory areas

If I wanted to wear down my fingers by typing a lot of things,
I would have choosen a career as a COBOL programmer.

Your suggestion has the unwanted side effect that you destroy the SDRAM
in the process, and you have to keep in mind where you put intermediate copies.

Since dataflash sectors are 256 kB, and you should avoid putting linux/rootfs
in the same sector as u-boot, code size is of much less importance than
ease of use.

It is very important to reduce typing to a minimum.

Having to do 2-3 commands to do what can be done by one command
and complicating the user experience in the process, is simply not acceptable.

>  No new command needed.
> 
>> * list dataflash contents
> 
>  What exactly do you mean here? Do you have any such function
>  currently?
> 

yes

>> * fill dataflash
> 
> * That would be a two step procedure:
>  - fill memory area (RAM)
>  - copy from memory to dataflash
> 

>  No new command needed.

See above, ease of use, is much more important than code size.

>> * modify dataflash (with byte granularity)
> 
> * That would be a three step procedure:
> 
>  - Copy from dataflash to memory
>  - modify memory
>  - copy from memory to dataflash
> 
>  No new command needed.
> 
>> * erase dataflash (byte and partition)
> 
>  OK.
> 
>> * enable/disable write protection of dataflash partition
> 
>  OK.
> 
>> * print dataflash chip info
> 
>  OK.
> 
>> I see no reason to compare two dataflash areas and to compare two
>> dataflash areas.
> 
> Neither do I, as it boild down to the elementary functions listed
> above: copy to memory and compare in memory.
> 
>> It should be possible to stored the environment in dataflash
> 
> Agreed.
> 
>> It would be good to be able to change the partition information
>> dynamically
>> so you can grow/shrink the linux-kernel size.
> 
> The mtdparts command should support dataflash devices, too.
> 
>> Possibly the pagesize should be migrated into the environment
> 
> What do you mean by that?
> 

The pagesize of the dataflash varies between 264,528,1056 bytes depending on chip.
It might be of interest to know this in a script.

> Best regards,
> 

It should be possible to remove any code accessing parallel flash,
so the memory commands only access SDRAM.
Many boards do not have any parallel flash, and this code will just bloat the binary.

> Wolfgang Denk
> 
> -- 


Best Regards
Ulf Samuelsson