[U-Boot-Users] Atmel DataFlash hooks.

[Haavard Skinnemoen]

On 1/29/07, Ulf Samuelsson <ulf at atmel.com> wrote:
>
> >
> > I'm not sure if I understand. U-boot pretends mmc and DataFlash are
> > memory mapped? That sounds completely insane, especially for MMC. What
> > happens if you insert an 8GB SD card on a 32-bit host?
> >
> >
> There is nothing to stop U-Boot memory commands from implementing a 64
> bit virtual address space.

Except that for most (all?) CPUs supported by u-boot, the virtual
address space _isn't_ 64 bit.

> (The day that you have an 8GB Dataflash, Champagne corks will
> fly.Largest one today is 8 MB)

Yeah, that's why I said it makes slightly more sense to do this with
DataFlash than with MMC. But I'm guessing that whoever implemented the
memory mapped MMC thing didn't expect MMC cards to reach 8 GB  any
time soon either.

> > I haven't actually used DataFlash on any avr32 boards yet, but I have
> > written an MMC driver for it and I didn't even know it could be
> > accessed as a memory-mapped device. In fact, I can't even understand
> > why anyone would want that --
>
> The reason to memory map is that then it is easy to do memory commands
> like copy, compare etc, which you do want to do on dataflash, even
> though it is not fully implemented in the current mainstream.
> I have implemented additional functions, because they are really needed.
> I wrote them because it is such a pain to copy to RAM before you can
> compare,
> and I definitely do not like to have to start doing that again.

I agree that the functionality is needed. I just disagree with the interface.

> It is perfectly possible to memory map the dataflash without having a lot
> of ifdefs, by letting the memory commands call a driver.
> I believe this is the way forward.
>
> It is easier for a user to learn a single command set to handle flash
> regardless of type.

How do you teach the user that the DataFlash is mapped at some obscure
address that has absolutely nothing to do with reality? What address
is it mapped at anyway? I can't find any information about this in the
README...

Extending the memory commands to take a prefix specifying which
address space you're talking about would make a lot more sense,
though. Then it might make sense to use 64-bit offsets too since we're
not really talking about the CPU's address space anymore, although it
could be difficult to support offsets of different size with a single
command.

Maybe it would be better to create a different set of commands for
manipulating any kind of raw storage (including flash) and let the
memory commands deal with memory.

> MMC/SD/USB Memories have the advantage of beeing able to be read/written
> by the host, and this advantage makes it more natural to use a real file
> system.

Exactly. It's just absurd to pretend removable storage devices reside
in physical memory.

Haavard