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