[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Ulf Samuelsson <ulfs at dof.se> wrote:

First, a clarification.  I'm coming at this from the point of view of
establishing some architectural clarity.  Currently, the primary way
to access non-memory-mapped memories is via the block device
infrastructure (include/part.h, disk/part.c).  DataFlash is currently
a major exception and I see no reason to treat it as such.

My goal is to attack the current #ifdef hell in u-boot.  DataFlash
just happens to be the first thing I want to clean up.  I'm pretty
sure I'm going to trod on all kinds of toes as I go through stuff.

> Are you prepared to make the fixes so that all Atmel development kits
> are supported by your patches.
> This means taking the atmnel patches from the Atmel ftp site and
> test them thoroughly on the appropriate boards.

No.  If the board port is not in mainline, then it is the
responsibility of the port maintainer to keep it synced.

For the stuff that *is* in mainline, I will of course make sure that
the patches compile, but I cannot test them.  I do not have the
hardware to do so, nor will I spend the time to test boards that I
have absolutely no involvement with.

Once again, this is about establishing some level of architectural
clarity; in this case about how to access non memory mapped memories.
That *requires* discussion and involvement of the board port
maintainers.

>
> AT91SAM9260EK
> AT91SAM9261EK
> AT91SAM9263EK
> AT91RM9200DK
> AT91RM9200EK
> ATR0663EK
> AT91SAM9XE
> and probably several AVR32 boards currently in design.
>
> I assume there are multiple customer boards that rely on this as well.

Even if the owner of the non-mainline boards is not able/willing to
migrate to internal u-boot changes, older u-boot releases will of
course continue to work as is.  However, I refuse to be handcuffed to
old design and code if in hindsight it was poorly done.  I reference
"linux-2.6/Documentation/stable_api_nonsense.txt" here as support.

>
> Will you patches support byte writes?

I don't see any reason why not.  Need to settle on a design first.

> > 3. Create an abstraction layer for accessing both bus addressable and
> > non bus addressable memories.  Add a naming convention for commands to
> > specify non-bus-addressable devices.  ie. "cp.b 00004000 DF:0000 100"
> > would copy 0x100 bytes from bus address 0x4000 to dataflash 0x0000.
> > (but I really don't think this is the route to go; far to complex.  I
> > don't think it is unreasonable to require a separate command to copy
> > to/from off-bus memories before comparing, booting, etc.)
> >
>
> I think it is unreasonable to require that users of dataflash
> has a more complex way of handling that memory.
> Computers are good at handling these things, humans are not.

Changes to the load sequence can easily be handled in environmental
boot scripts.  Regardless of how it is changed, the command format
should not stay as-is (as I think it is a bad precedence to pretend it
has a bus address).  Hence it does require changes to how boards are
booted (like your example solution below).

>
> Woudl you accept a patch that required bus addressable devices
> to have a prefix?
> "cp.b BAD:00004000 0000 100"

As I said; I don't particularly like this from an architectural
standpoint.  However, if it was done in a way that was *generic* (ie.
any memory device could register to use it) then I would be cool with
it.  If it's just another mess of device specific #ifdefs in the
memory access routines then I violently disagree.

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