[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

>> 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=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

Best Regards,
Ulf Samuelsson
ulf at 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