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


Malcolm,

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.

regards
Amadeus
-- 
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