DMA memory while using the GBA ROM space as RAM

Amadeus amadeus at
Tue Aug 22 13:22:20 CEST 2006


I want to share some thoughts about this problem.

Linux known 3 types of zones: DMA, NORMAL and HIGHMEM.

Up to now, all memory is by default in zone 0 == DMA. This is true for 
all ARM architectures.

I have added the GBA ROM space to zone 0 == DMA, because this was the 
only working way. I have tried using DISCONTIGMEM, but it appears to be 
broken on ARM/uCLinux. And even under DISCONTIGMEM, all memory gets 
allocated in zone 0 == DMA. Nobody has ever used the other zones for 
ARM cpus.

HIGHMEM is special because there is no direct mapping for HIGHMEN, and 
this is not what we want for GBA ROM space.

If we use the NORMAL zone for GBA ROM space, we get a preference for 
NORMAL == GBA ROM space. The DMA space (main memory) will only be used 
by DMA buffers and when no GBA ROM space is available. This is not what 
I want.

So I make the following suggestion:

We will use only zone 0 == DMA. This has only one drawback: if we 
allocate a DMA buffer, we might get a buffer in GBA ROM space.

But this limitation is not severe: we use DMA buffers (for DMA or ARM7 
communication) only in very few device drivers. And as we can always 
count on the fact that the static kernel data structures are in main 
memory (==DMA-capable), we can simply allocate a static DMA buffer 
inside the driver. We can also align this buffer on an ARM9 cache line.

The firmware reading process does this, and it's working fine.
The sound driver was converted, and it's running fine also.
The wifi driver should be OK in a few hours.

What do you think?

We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

More information about the dslinux-devel mailing list