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