[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Wolfgang Denk wrote:

>In message <45BD6755.3000100 at comcast.net> you wrote:
>  
>
><snip>
>  
>
>>True enough. Yet the only memory write command that explicitly works on 
>>flash memory is cp.  mw does not check for a flash address, so what it 
>>does depends on the protect state of the chip and how the flash works. 
>>    
>>
>
>Note that this is intentionally. This is what you use to  test  flash
>access  commands on the low level. I would consider it broken it this
>were different.
>  
>
I understand your point. Similar conditions apply to memory-mapped 
control and status registers. However, there is still an asymmetry 
between mw and cp. mw feeds the data directly to the chip, no matter 
what kind of chip/address is used (which is useful). cp "cooks" the data 
sent to flash chips so that it will actually write into the chips. 
(Granted it is cooked very rare, but still it is cooked)  This is also 
desired behavior, but not the same behavior.

<snip>

>  
>
>>>>memory commands. This becomes especially true when the size of the 
>>>>object to be read/written exceeds the size of the CPU address space. 
>>>>        
>>>>
>>>Do you have an example where this happens in U-Boot context?
>>>
>>>      
>>>
>>Yes, some of them you give later, like an IDE disk. It would be 
>>    
>>
>
>That's not what we discussed. You wrote: "size of the  object  to  be
>read/written"  -  the size of such objects is probably always smaller
>than the storage capacity of the external devices. And I  doubt  that
>you  will ever be able to write (as an atomical operation) any object
>that is bigger than the CPU's address space.
>  
>
We agree here, I just was not very precise. The trick  is that if you 
allow mapping an IDE disk as memory, you could copy from one part of the 
disk to another part of the disk an an object that is LARGER than the 
CPU memory space. (There would be nothing requiring the first or second 
operand of the cp command must be on the CPU memory bus) We also both 
agree we don't want to do this as part of the cmd_mem.c interface!

>  
>
>>>I feel that would be not natural. And EEPROM (like on a I2C bus) does
>>>not have any natural adresses in the CPU's address  space.  Same  for
>>>IDE  or  USB  devices.  These are storage devices on some form of I/O
>>>bus, but certainly NOT memory.
>>>      
>>>
>>Agreed. But these same arguments apply to Dataflash. Also, there are 
>>eeproms that are not serial and can reside on the CPU memory bus. The 
>>    
>>
>
>If they do, it is natural to be able to access these  using  standard
>commands like "md". That must be a supported option.
>  
>
All read commands would work fine. Write operations could be another 
story. If we define (as I think you do) mw to be a "raw" write to the 
address space, it would also work, subject to any timing requirements of 
the device, which is the users problem anyway. cp is another story.

>  
>
>>read-type memory commands would work fine on them, but there would be no 
>>way to write to them. I imagine it could be done by hacking into the 
>>    
>>
>
>I'm not sure I understand. What sort of devices do you have  in  mind
>specifically?  We've  had  FRAM  on some boards which was just read /
>write without problems.
>  
>
You undoubtedly had FRAM like the FM20L08 that has "NoDelay" writes. 
However, even these chips do have a software protect/unprotect sequence 
that  requires some "flash-like" commands to use. Some EEPROM chips  
(for instance the M28LV16) have a (3 ms) page/byte maximum write cycle, 
which requires a write routine to poll the chip for done on a write when 
a page boundary is crossed or at the end of any write operation.

>  
>
>>If it can be decided that the only devices that will be supported by the 
>>memory commands in cmd_mem.c are those devices that can be read directly 
>>as ram without a read routine, I think that would help clarify the 
>>intent of the commands.
>>    
>>
>
>Yes, that's what I have in mind.
>  
>
Good. I think this position greatly clarifies things, at least from my 
point of view.


<snip>

>>>IMHO we should provide a user inteface which is powerful, yet easy to
>>>use - this requires it must be intuitive to the end user. For most  f
>>>them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
>>>EEPROM is not.
>>> 
>>>      
>>>
>>I am not sure I concur with the idea users consider NOR flash as 
>>"memory" . NOR flash has always required the user to be aware of the 
>>protect on/protect off requirements, as well as erase requirements. In 
>>    
>>
>
>But it's still memory - "flash memory" is a very commnonly used term,
>so for me there is not the slightest doubt about this.
>  
>
I understand you point of view. However, the very common use of "flash 
memory" is also often directed at flash memory that has an spi or other 
type of interface, which is not the type of flash memory you have in 
mind! It is also worthy of mention that PPCBUG does have a PFLASH 
command, so it is not a universal idea that NOR flash is simply memory. 
It is however a perfectly good point of view, and the one that u-boot 
follows!

>  
>
>>fact, the user even needs to know what sectors to protect/unprotect in 
>>some cases. The only "memory" write commands that actually do work on 
>>NOR flash are cp and loadX. However, I do agree that u-boot users by now 
>>    
>>
>
>No. Also mw works fine - exactly as it should.
>  
>
Ack.

<snip>

>  
>
>>On the other hand, I do not think it less logical to require a write to 
>>flash to consist of a command different from cp, since in order for it 
>>to actually work, the user must have done all the right preparation.
>>    
>>
>
>Call it historical reasons, then ;-)
>  
>
I like this better :-)

>>Presently, if there is more than one type of  parallel flash in the 
>>system, it must be dealt with inside the flash_write routine. Maybe this 
>>has never been a problem. It is also true that you can't write across 
>>flash memory type boundaries, you get an error, so this is probably 
>>fine/expected.
>>    
>>
>
>No - if flash regions are mapped contiguously, a "cp" should be  able
>to cross device boundaries transparently.
>  
>
Actually, what I said above is wrong. The flash_write code DOES allow 
crossing  flash type boundaries. What is not allowed in the flash_write 
routine is starting in flash and ending in non-flash. This throws an 
error. Starting in flash,  intervening ram, ending in flash would not 
work properly. Holes in the memory map between flash regions also would 
not work properly. This  may be defined as an error, but  you don't get 
an error  message in these cases as near as I can tell. Rather, the code 
seems to do something untoward in the next flash bank. It would be 
trivial to detect and throw an error for these cases, but the current 
code does not.  Also, there are several places in the current code where 
it is assumed that if the initial destination address is in ram, the 
entire operation is in ram. This can be false if ram and flash are 
contiguously mapped. IMNSHO this condition should either work or be an 
error that is detected.

There is also a semantic question regarding the meaning of the size part 
of the cp.X command when the destination operand is flash. If the 
destination operand is in flash, the size of the operand for both the 
source and destination addresses is not enforced. The size of access is 
enforced if the destination is ram. This may be a bit of a nit, but I 
bring it up for completeness. cp.l commands that look like they for sure 
should generate an alignment exception will not do so if the destination 
is flash.

<snip>

>>change. I had thought that there was interest in interfacing non-bus 
>>devices to the memory commands, along the lines of the Dataflash 
>>    
>>
>
>Not on my side...
>
>  
>
Ack. Not mine either!

Best Regards,
Bill Campbell

>Best regards,
>
>Wolfgang Denk
>
>  
>