In message 45BD6755.3000100@comcast.net you wrote:
You are up late this Sunday night. Probably you will not see thisuntil Monday morning!
;-)
Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash contents?
You should. However, in the current u-boot, if you try these commands with Dataflash addresses, crc takes the crc of some random data, you get an error message saying it is not supported for cmp, and it works correctly for md (because there is explicit code to support it compiled in if Dataflash is present). There is also a device MMC which is included in some builds. As near as I can tell, it does not work in any of the read operations, there is no code built-in for it as a special case.
OK, so the implementation(s) is/are broken.
I was not aware of this - no system with Dataflash or MMC had to ever pass our regression testing.
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.
It does not, and probably is an example of why this is an issue to some of us. Dataflash requires a routine to read the data as well as to write it. Most of the memory read routines work fine on any memory technology that has a one-to-one bus address to data technology. Dataflash does not fit this model and therefore doesn't work in many read operations. In some cases you get an error, because it is explicitly handled in the code, in some cases you get a bogus result and no error. As near as I can determine, the MMC also requires a routine to read data. When copying from MMC to ram, the mmc_read routine is used. In no other cases is it used. Since I think the MMC is a read-write interface through a fifo buffer, based on looking at mmc.c, I assume it does not work in any cases except cp from ram to mmc and from ram to mmc. mmc to flash for instance would write trash to flash as near as I can tell. Also you can't cmp it or md it correctly.
I start to understand your concerns. So far I assumed that Dataflash and MMC support was just working fine.
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.
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.
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.
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.
Sorry if my argumentation was cofusing, but - as mentioned before - I never used Dataflash myself. My understanding was that it does provide such a direct read interface, but this was probably a misunderstanding then.
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.
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.
expect cp and loadX to work on NOR flash. In fact, I think it is expected to work on any bus-addressed flash type. I can see why removing that support would not work well for existing boards.
OK.
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 ;-)
takes no code at all. The only issue arises with cp/loadX. If we all agree there is no desire to interface anything that requires a routine to read data from it to the memory commands, then I have no desire to go there either. Presently, we have loadX commands that will work with
I do agree. Grant?
[I really have to stop myself from writing "You can take this for Granted" :-) ]
"flash" by calling flash_write. cp also explicity contains code to work with flash by calling flash_write. Dataflash and MMC devices work in cp by calling mmc_write, mmc_read, write_dataflash, and read_dataflash. These two devices work poorly/not at all in most other memory command cases, but if nobody sees this as a problem, then I don't either.
As I just learned today, there are serious problems with the implementation of the Dataflash support. So at least the most blatant bugs should get fixed, even in the old implementation.
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.
don't use them), I see no reason to change the current code. I would suggest removing support for MMC and Dataflash devices from the cmd_mem.c file, since these devices seem more like serial FLASH/USB device etc., and moving support to a new file, but I am sure current users wouldn't like that, so they probably must stay where they are. It
That's an important issue: what are *users* thinking about all that?
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...
Best regards,
Wolfgang Denk