On 1/26/07, Ulf Samuelsson ulfs@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.