[U-Boot-Users] Atmel DataFlash hooks.

J. William Campbell
2007-01-29T20:45:08Z

Wolfgang Denk wrote:

>In message <45BD6755.3000100@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
>
>
>