Read what you wrote: "use memory oriented commands on memory". That's exactly what I really expect to be able to do, indeed.
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.
I have CRC in my version of the dataflash drivers and can do cmp between SDRAM and flash, so if those patches get merged that is not an issue.
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. Some flash lets you change a single byte, others require various erase operations and so on. The rule here may be know what you are doing before you try to modify flash one byte at a time, but it is an asymmetry. I won't even hazard a guess at what loopw will do, but I am sure its not a good idea on flash. The MMC case is also not provided for at all.
I can't say if Dataflash really fits into this szenario; I never used this feature myself.
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.
If you want to update a byte in parallell flash, you have to read an entire (typically 64 kB) sector, erase that sector update the byte and write the complete secotr back.
If you want to update a dataflash (AT45) you read a 1056 byte area into a memory buffer internal to the device. This is a parallel operation so the complete page is read in a fe clock cycles.
You then send a short buffer write command which updates the specific byte, followed by a page write with autoerase.
Everything controlled by DMA at 30+ Mbps.
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.
I see the main reason to have MMC/SD is to be able to create a fs on a PC and then move it to the target. Same for USB memories.
Those little tings should contain a FAT file system...
Yes, some of them you give later, like an IDE disk. It would be impossible to memory map large IDE disks all at once, so nobody even considers it as an option. You could perhaps consider a serial Flash to be memory-mapped if that model was desired. I had thought that that might have been desired at one time, but I think that notion is obsolete.
No its not.
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.
If you want to store environment in EEPROM (which Wolfgang does not like) then I think you need to memory map it with the current U-Boot.
One way of using this is to have a microcontroller emulate the EEPROM.
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 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 flash interface, since it is after all similar. The chips read like ram
but write more like flash. However, this is somewhat confusing if the parallel eeprom interface would be in the flash module. I guess this can be worried about later if necessary. 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.
No it can't. Any modifications to the dataflash needs to allow for things that work today, and also what needs to be implemented, like memory compare, crc etc.
Me too, especially since, if we remove the Dataflash case and MMC case, support for commands like cmp crc, md etc. is absolutely transparent. It 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
That will never reach an agreement.
, then I have no desire to go there either. Presently, we have loadX commands that will work with "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
It is a problem. I have fixed some of it in my version of u-boot.
, then I don't either. 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.
So the summary of all this, from my point of view, is that if we do not expect to add a bunch of new devices to the cmd_mem.c and loadX interfaces, and if we are ok with the present performance of MMC devices and Dataflash devices in the current interface (I don't care since I 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 would be a shame if we intend to add a bunch of cases to the current stuff in cmd_mem.c to not generalize the interface to allow adding such devices without needing to modify cmd_mem.c in the common code, but if we don't expect to make such additions, then I see no need for such a change. I had thought that there was interest in interfacing non-bus devices to the memory commands, along the lines of the Dataflash interface, but with all cases working "properly". I personally have no such interest. If nobody else does, I see no reason for changes in how cmd_mem.c interfaces to "memory". The only change I have any interest in is adding a conditional compile allowing the removal of flash support from the cp/loadX commands without removing support for parallel flash from the board. I prefer FLASH WRITE x y z to cp x y z when dealing with flash, but that's just me. Naturally, all the other commands would still work the same, such as cmp, etc. This is probably because most of the systems I am now working with use serial flash which requires a different command anyway, so I just expect it.
Thanks for bearing with me on this, and I hope the research will be of some benefit!
Best Regards, Bill Campbell
Best regards,
Wolfgang Denk
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Best Regards, Ulf Samuelsson ulf@atmel.com GSM: +46 (706) 22 44 57 Tel: +46 (8) 441 54 22 Fax: +46 (8) 441 54 29 Mail: Box 2033 174 02 Sundbyberg Visit: Kavallerivägen 24 174 58 Sundbyberg' Sweden