[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

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
> >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

-- 
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