[U-Boot-Users] Atmel DataFlash hooks.
wd at denx.de
Mon Jan 29 14:29:10 CET 2007
In message <45BD6755.3000100 at comcast.net> you wrote:
> You are up late this Sunday night. Probably you will not see this
> until Monday morning!
> >Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash
> 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
> 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
> >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.
> 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
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...
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The algorithm to do that is extremely nasty. You might want to mug
someone with it." - M. Devine, Computer Science 340
More information about the U-Boot