[U-Boot-Users] Atmel DataFlash hooks.

Wolfgang Denk
2007-01-28T15:01:36Z

In message <528646bc0701271419l8069e56nb06bb328cf85b8b7@mail.gmail.com> you wrote:
>
> Just for the moment; forget the term 'block device' and forget about
> the current implementation of u-boot. How significant are the

OK.

> difference between the following devices? mmc, CF, IDE HD, SCSI HD,
> DataFlash, memmapped flash, NAND flash, i2c eeprom, USB storage.
> Here's my short list:
> - different block sizes; DataFlash can be written byte at a time;
> while other devices have minimum write sizes. Some devices need
> blocks to be specifically erased before rewriting.

- some devices can also only be read in blocks of a certain size

- some device can have sectors / blocks write protected, both logi-
cally (in U-Boot), or in hardware; some of these devices come up
write protected out of reset i. e. you have to unprotect these to
make them writable.

- some devices may require (re-) write operations evey now and then
to avoid data loss.

- some devices must never be wrtitten to when the board resets / loses
power.

- some devices may be "banked"; right now, for example, we have no
way to access flash devices on systems that need bank switching.

> - memmapped flash can be be read directly on the memory bus; but
> writing requires a special routine
> - Large variation of size, from a few kbytes up to thousands of gigabytes.
> - Some devices are typically partitioned for convenience
> - speed differences
> - large number of

of ???

> The technology varies wildly, but they are all storage devices which
> store of an ordered sequence of bytes. In every device, the address
> of a single item of data can be boiled down to a single integer.

...assuming your "integer" type has enough bits to address any byte.

> Take a look at the following interface. For *most* commands; how well
> does this is this api encapsulate those differences for common
> commands? Assume that device specific commands still exist for things
> that don't fit well into the model. ie. block erase and protect
> commands.

I don't doubt that you can come up with aninterface that fits more or
less nicely on oll possible tyes of storage media. After all, a file
is a file is a file, as we all have learnt - haven't we?

IN addition to your own fun inh designing nice interfaces, please
also keep in minde the mental welfare of the normal end user, who
thinks of "flash memory" as some simple thing where you can just read
data from.

> open(device) # Prepare for read/write operation
> seek(distance, abs_flag) # Relative or absolute seek
> read(buffer, count)
> write(buffer, count)
> close() # Operation finished; sync any pending buffers back to disk.

Please keep in mind that this is a boot loader, not an OS. One im-
portant point is, and always has been, to keep the memory footprint
small. I often sacrificed beautiful code for an uglier, but much
smaller implementation. And I guess I will (have to) do this again.

> Notes:
> - assume device can only be opened once. ie. it's a bug to call open() twice

Why?

> - this could be used by commands like mm, md, bootm, etc. I'm not
> trying to design a full control interface (protect, erase, etc).

Why not? I'm not willing to see such functions dropped.

> - common commands would typically call open(), seek(),
> read/write(), read/write(), ..., close() before returning to user.
> ie. device would *not* be left open after command completes.

Sounds like a lot of code to implement (code size) and run (execution
times).

> - should be suitable for partition access too
> - read/write commands are expected to transparently handle block
> boundaries. ie. if one byte is written to the middle of a block; the
> write hook should read the block, modify the byte, and keep it
> buffered until it either a read/write/seek() moves to another sector,
> or close() is called.
> - and yes, I'm just using the each device as a file perspective.

> It's a well established abstraction, so why not here too?

Well, just to name one of the potential issues: U-Boot is designed to
make porting to new hardware as eassy as possible. So we want to have
serial console output as soon as possible. That means that very, very
early in the boot process you will have to read the environment to
read environment variables like "baudrate" and some others. In this
stage, we usually don't have a regular stack, we have no BSS, and we
have no writable data segment. In other words, we don't have a
regular C environment, only a very primitve subset. But *all* your
new code would have to be able to run in this environment. Or we
would need duplicate implementations which is even worse than what we
have today. If you want, you can even go one step further and think
about NAND booting, where you have even more severe size restrictions
(for which we don't have a good solution yet).

I don't want to say it's impossible what you usggest, but I have to
admit that I cannot see a way to implement this without redefining
the basics of the project.

> Thoughts? Feel free to tell me if I'm flying too high in the
> stratosphere on this one.

I can't read your altimeter from here, but it seems you did take off
(i. e. lose ground ;-)

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
God made machine language; all the rest is the work of man.