[U-Boot-Users] Atmel DataFlash hooks.

Grant Likely
2007-01-29T02:33:15Z

On 1/28/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc0701271419l8069e56nb06bb328cf85b8b7@mail.gmail.com> you wrote:

> > - large number of
>
> of ???

heh; brain fart... please ignore. :)

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

yes.

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

May bootloaders use this type of interface. OpenFirmware is a good
example. RedBoot is another. CFE does too. I think it is a good and
well established abstraction regardless of whether it is an OS or a
bootloader.

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

Mostly to keep the use cases simple; but maybe I'm optimizing too
early. I was thinking in terms of not needing to dynamically allocate
temporary buffers.

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

Neither am I.

I'm not trying to design a one size fits all interface for all extra
device features. The specific problem I want to tackle is to provide
a single hook point for attaching read/write commands to non-memmapped
devices. I'm comfortable with keeping the existing device specific
commands for protect/erase/etc, (at least for now).

I'm going to do a trial implementation of that stuff discussed so far
so I can post patches for review. At that point I'll be looking for
feedback to decide if this is a direction worth pursuing further. If
so, then I'll take a look at the protect/erase/etc features

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

I don't think it will be; but I'll should just stop arguing here and
implement it. It's the only way to actually know.

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

I'm not looking at rewriting all the device back end drivers. I'm
only looking at the attachment to common commands. I have no
intention to rip and replace the existing code for early access.

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

:-P

Cheers,
g.

--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195