Hello, i'm working on a porting of the Wonka jvm on an ARM cpu running
eCos. To be more clear, i link wonka against some eCos libraries; then
i load the executable into the memory of a PXA255 board and run it.

Wonka uses its own Virtual File System, and to let things work you
have to:
1) create an image of the filesystem (i'm using ext2)
2) convert the filesystem image into an ELF32 object with the
'arm-elf-objcopy' tool
3) link together the libraries and the filesystem object to a binary
executable.

When you download the executable to the PXA board, all goes right and
wonka runs well. However, the executable is big (about 2.5 Mb) and it
takes about 6 minutes to download it, so testing applications is not
so easy.
To resolve this problem i (my teacher...) want(s) Wonka *not* to be
linked against the filesystem image; i would load the standalone
filesystem image into memory, load the wonka executable and run it.
Obviously, Wonka must know where the filesystem is located in memory.

PROBLEM: i can't let it work :(. When i launch wonka, it freezes when
trying to do something with the filesystem (perhaps mounting? i have
to do better debug).

Now i explain in more detail how i have tried to "hack" wonka.

I used 'arm-elf-nm' to dump symbols from image.o (the filesystem image
converted to an ELF32 object) and i saw this:

 001b2000 D _binary_image_end
 001b2000 A _binary_image_size
 00000000 D _binary_image_start

these are probably symbols introduced by the arm-elf-objcopy tool when
it sees that the input file is a fs image.
These symbols are also declared as extern in a source file in the
wonka tree, wonka/src/driver/ecos/disk-image.c :

 extern void _binary_image_end;
 extern void _binary_image_start;

these symbols are late used in a structure:

 image->disk = (w_ubyte *)&_binary_image_start;
 image->size = (w_long)((w_ubyte *)&_binary_image_end - image->disk);

it is evident that these symbols refer to the beginning of the
filesystem image.
So, the first thing i tried was to :

 1) modify the source of the driver, giving a fixed value to these
variables:
 
   unsigned int _binary_image_end = 0x006b2000;
   unsigned int _binary_image_start = 0x00500000;

 and, of course, modify the other piece of code, to let pointers work
properly:

   image->disk = (w_ubyte *)_binary_image_start;
   image->size = (w_long)((w_ubyte *)_binary_image_end -
image->disk);

 2) link the filesystem image object, relocating the .data section to
the new value of _binary_image_start. I did this because i see that,
when linking, the value of the __data_start symbol is always equal to
the value of the _binary_image_start symbol. So i deduced that the fs
image is located at the beginning of the .data segment of the module,
and i could find it here.
 So i did:

   $ arm-elf-ld -Tdata 0x500000 -o image image.o
 
 now 'arm-elf-nm' gives:
   
   006b2000 D _binary_image_end
   001b2000 A _binary_image_size
   00500000 D _binary_image_start
   006b2000 A __bss_end__
   006b2000 A _bss_end__
   006b2000 A __bss_start
   006b2000 A __bss_start__
   00500000 D __data_start
   006b2000 A _edata
   006b2000 A _end
   006b2000 A __end__
   00080000 ? _stack

 it seems to be ok for me.

 3) load the image to the PXA board memory using xscale-elf-gdb

 4) load wonka and run it

 As I said before, this doesn't work. Wonka freezes while mounting
the filesystem (or something similar). I'm sure the pointers point to
the right locations, so the problem is in the data.

Does anybody have any idea?

Thanks, Marco