[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Hi Mr. Denk,
    You are up late this Sunday night. Probably you will not see this 
until Monday morning!

Wolfgang Denk wrote:

>In message <45BD21D7.20203 at comcast.net> you wrote:
>  
>
>>>I can't see how you would get the standard  configuration  (just  RAM
>>>and NOR flash support) smaller with such a change?
>>>
>>>      
>>>
>>There are presently quite a few #ifdefs involved in cmd_mem.c and 
>>cmd_load.c to take different memory types into consideration. These 
>>would mostly go away. That is why I think a ram + flash configuration 
>>    
>>
>
>OK, so the *source* code may become smaller indeed.  But  I'd  expect
>the  memory  footprint  on  the target system to grow instead, or you
>lose functionality.
>  
>
You lose functionality as outlined below. The memory footprint is 
smaller though. Not that that is a big advantage anyway, I just wanted 
to assert it didn't get larger.

>  
>
>>configuration. Naturally, you loose the ability to dump flash data with 
>>md, compare to flash data with cmp, copy flash data with cp.b, load data 
>>directly to flash with loadb, etc. so it is not free, just a bit smaller.
>>    
>>
>
>Arghhh... Indeed, that's not free. I guess for such a price there are
>other, more efficient ways to reduce the code size.
>  
>
Probably. However the fact it gets no larger could be important.

>  
>
>>>>current system, it is just a formalization of what
>>>>has always been desired.
>>>>        
>>>>
>>>Umm... "always been desired" - by whom? :-)
>>>
>>>      
>>>
>>Well, as I understood it, at least partially by you. :-) The ability to 
>>use memory oriented commands on memory other than simple ram seems to be 
>>    
>>
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
>
>>considered a plus by many u-boot community members. However, this does 
>>    
>>
>
>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.

> 
>
>  
>
>>add some complexity and size to the associated memory manipulation 
>>commands. As the object being addressed differs more and more from 
>>    
>>
>
>Not really. Normally only writing may need special handling.
>  
>
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. 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.

>  
>
>>simple ram, more and more people seem to accept "new" commands to read 
>>and write these objects, and to forgo the advantages/features of the 
>>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 
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.

>  
>
>>What my goal in this proposed design is to allow users to choose at 
>>compile time what features are desired for the u-boot memory commands  
>>a) without an ifdef maze and b) without needing to inject new code into 
>>cmd_mem.c and cmd_load.c for every different memory technology that will 
>>use memory access type commands. If somebody wants to use the memory 
>>commands on a serial EEPROM, this can be made to work if desired, or 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.
>  
>
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.

>  
>
>>made to work if not considered necessary, without changing cmd_mem.c.  
>>How possible/good this goal is remains to be seen, I agree. The current 
>>    
>>
>
>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 
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 
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.

>  
>
>>I completely  agree with small and simple, and making feature choices at 
>>compile time. I think these attributes can be preserved, or perhaps 
>>    
>>
>
>Ther eis another thing that is important to me: U-Boot  on  different
>systems,  boards  and architectures shall always behave as similar as
>possible. Having the "cmp" command (if configured into  U-Boot)  work
>on  flash  memory  on  one system and failing to do so on another one
>seems unacceptable to me.
>  
>
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, 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, 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
>
>  
>