dslinux/linux-2.6.x/drivers/mmc scsd_c.c scsd_s.S

Amadeus amadeus at iksw-muees.de
Mon Aug 28 13:56:05 CEST 2006


On Monday 28 August 2006 12:45, Malcolm wrote:
> > I want to set up a common build for all RAM-capable cards now, and
> > for this goal, code sharing makes sense to me.
> I doubt it matters as much as you think.

Hmmm.. the C part is 2.5 KBytes. The assembler part is 1.5 KBytes.
Maybe not so important, you are right.

> The kernel has a fast memcpy implementation.

I see in the CF drivers (IDE), you have made use of the kernel copy 
implementations. The supercard SD interface is not suitable for memcpy 
and friends..

> Ideally the stack would be in DTCM, but as there is a stack per
> process, this is not possible.
> I don't know how to force the stack to be in RAM with the current
> memory regions.

DTCM is a good idea. But you are right, unlike standard linux, there is 
no "kernel stack" in uCLinux. I have found 3 stacks for special things 
like interrupts and data abort, but no stack for the kernel.

The DTCM is 16K. This is not enough for a user stack for each process.
The size of the user stack is variable in uCLinux... 

So, with stack in GBA ROM space, I think assembler is mandatory for each 
driver accessing GBA ROM space as IO. Or we find another way of 
blocking stack usage in C programs.

> Chishm's lib is being developed in cvs:
> http://devkitpro.cvs.sourceforge.net/devkitpro/libfat/
> He has much improved M3SD code over the original from the M3
> manufacturers.

Oh, thank you. Seems to be the same code as in the dragon lib for M3SD.

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