[U-Boot-Users] Atmel DataFlash hooks.

J. William Campbell
2007-01-29T03:17:41Z

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