[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/28/07, Wolfgang Denk <wd at denx.de> wrote:
> In message <528646bc0701271419l8069e56nb06bb328cf85b8b7 at 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