[kaffe] kaffe on xscale - how to do it
Gérard Basler
gerard.basler@starticket.ch
Wed Jan 21 13:23:03 2004
Hi!
After spending hours of recompiling and testing I figured out how to
build kaffe for PXA based iPaqs:
JThreads
--------
I needed Christophe's patch to use jthreads.
http://www.mail-archive.com/kaffe@kaffe.org/msg04197.html
XScale has no fpu therefore you have to change SP_OFFSET:
config/arm/linux/md.h:
#define SP_OFFSET 20
//#define FP_OFFSET 7
glibc-2.3.2/sysdeps/arm/fpu/bits/setjmp.h -> SP_OFFSET = 20
glibc-2.3.2/sysdeps/arm/bits/setjmp.h -> SP_OFFSET = 8
It's vice versa? Why?
Interpreter
-----------
The Interpreter runs with the changes mentioned above.
JIT
---
I'm using the gcc 3.3.2 toolchain from handhelds.org
This gcc breaks the code if you compile it with "-O2"
I've built gcc twice: once with --with-cpu=strongarm1100 and once with
--with-arch=armv4t --with-cpu=xscale. Same result.
Therefore use:
CFLAGS="-=O0"
Furthermore the caches aren't properly flushed.
XScale's cache is 32kb. Strongarm SA 1100 only has 16kb. It's
recommended that you go through an array that's twice as big as your
cache ( http://www.v3space.com/a/a3/75/arm/arm_linux_boot-1.html ), if
you clean it that way:
config/arm/linux/md.c:
#define CACHE_SIZE (32 * 1024)
#define LINE_SIZE sizeof(int)
#define CACHE_LINES (CACHE_SIZE / LINE_SIZE)
static volatile int flusher[CACHE_LINES];
void
flush_dcache(void)
{
int i;
for (i = 0; i < CACHE_LINES; i++) {
flusher[i]++;
}
sched_yield();
}
So change set:
#define CACHE_SIZE (2 * 32 * 1024)
The following code-fragment from glibc didn't work. It looks like the
2.4.19-rmk6-pxa1-hh36 kernel I'm currently using doesn't implement cache
flushing well. Maybe it needs alignment? The kernel code already seems
to perform that step.
http://lists.arm.linux.org.uk/pipermail/linux-arm/2000-November/000251.html
#define CLEAR_CACHE(BEG,END)
\
{
\
register unsigned long _beg __asm ("a1") = (unsigned long)(BEG);
\
register unsigned long _end __asm ("a2") = (unsigned long)(END);
\
register unsigned long _flg __asm ("a3") = 0;
\
__asm __volatile ("swi 0x9f0002 @ sys_cacheflush"
\
: /* no outputs */
\
: /* no inputs */
\
: "a1");
\
}
Starting
--------
I get stackoverflows if I run bigger programs. Starting with "-ss 256k"
or so should solve the problem.
Next Steps
----------
- gcc 3.4
- kernel 2.6 (kernel bug in 2.4?)
- get a real cpu ;-)
Alright.
I could start a massive beast of a java program with that steps.
I'd be very interested if someone figures out how to flush the cache the
way it sould be done...
~Gérard