Hello all,
i'm using the PrizmSDK 0.3 (the gcc tool chain) for some Prizm development. AFAIK, the other tools (mini SDK) requires the old Casio compiler. I have had problems with the casio compiler so i prefer not to use it again.
I need to adjust link settings to make more ram available for my app. i tried changing prizm.ld MEMORY like this:
MEMORY
{
/* Loads code at 300000, skips g3a header */
rom (rx) : o = 0x00300000, l = 512k
ram (rwx) : o = 0x08100004, l = 500k
}
This works (so far), i can have a bit more ram for BSS. However the heap is still limited to 128k. Does anyone know the memory map for the device.
So far, i have this info from another document but i don't know whether the numbers are valid for PrizmSDK (because they don't tally with the above).
Flash 32 MB
Flash: 0xA0000000..0xA1FFFFFF (0x80000000..0x81FFFFFF: physically identical, but cacheable)
RAM 2 MB
0xA8000000..0xA81FFFFF (0x88000000..0x881FFFFF: physically identical, but cacheable)
0xA8000000..0xA80287FF: VRAM
0xA80D35D0 : start of main memory
0xA80E3000 : end of main memory
0xA80F0000..0xA815FFFF: system stack (512 kB).
0xA8160000..0xA81DFFFF: add-in stack (512 kB).
0xA81E0000..0xA81FFFFF: heap.
I know that sometimes address areas are duplicated, so some places can have different address for the same region. maybe we have that here.
I know that the heap i likely to be limited to 128k in which case, i might have to code my own heap management of a chunk of ram, once i know the actual layout and arrangement.
thanks for any help,
-- hugh.
As the one who wrote that linker script, I can hopefully offer some help.
hugh9860 wrote:
This works (so far), i can have a bit more ram for BSS. However the heap is still limited to 128k. Does anyone know the memory map for the device.
So far, i have this info from another document but i don't know whether the numbers are valid for PrizmSDK (because they don't tally with the above).
These numbers look reasonable, but I have no idea what sort of address mirroring happens (or what exactly the MMU is configured to do). I suspect that the ROM region in the linker script is actually a virtual memory mapping to wherever the current addin happens to be in Flash, though.
As for .bss, I don't think anybody's determined what's actually there, nor how much memory is available. If we assume that the memory map you present is correct (albeit missing some mappings), my best guess is that we're pointing the section at the middle of the system stack, which doesn't cause problems because that memory region is grossly oversized for that it's needed for.
hugh9860 wrote:
I know that the heap i likely to be limited to 128k in which case, i might have to code my own heap management of a chunk of ram, once i know the actual layout and arrangement.
The ability to claim extra heap space from the addin stack is something that's been on my list to add to libfxcg for a while, such that you can specify a maximum addition at link-time.
Since libfxcg provides its own malloc function (which currently just calls the malloc syscall), that implementation can be refined to use the additional claimed space as necessary.
Until I (or somebody) put together such a thing, though, I'd suggest grabbing a chunk of stack at startup and managing that as desired.Code: #include <fxcg/heap.h>
void *alloca(size_t n);
static heap_t *extra_heap;
void *my_malloc(size_t n) {
// Do stuff with extra_heap
}
int main() {
extra_heap = alloca(0x40000);
do_stuff();
return 0;
}
i like the idea of using alloca, because the stack is above the add-in ram.
however, where is heap.h, im using PrizmSDK 0.3?
-- hugh.
Oh, my fault there. fxcg/heap.h is new-style header providing the prototype for sys_malloc (the malloc syscall), but then I didn't do anything with it. You can just ignore that line.
_alloca undefined at link.
poo.
Firstly, the adjustment that you did changes the stack, not the heap. Malloc uses the heap. alloca may be what you want, don't know what it does.
Remember that PrizmSDK is old. These functions are located in libfxcg on github.
ok, i put my own malloc in and, because alloca is missing, i initialise the heap from the stack by delcaring a large automatic array!
eg
main()
{
char heap[256*1024];
initialiseHeap(&heap, sizeof(heap));
...
}
nasty but works. currently i now have 256k for heap. not tried any bigger yet.
AHelper wrote:
Firstly, the adjustment that you did changes the stack, not the heap. Malloc uses the heap. alloca may be what you want, don't know what it does.
Remember that PrizmSDK is old. These functions are located in libfxcg on github.
It does exactly what I wanted. Should be implemented as a builtin, but we can work around that in a hideous fashion.
Pre-post ninja response:
hugh9860 wrote:
ok, i put my own malloc in and, because alloca is missing, i initialise the heap from the stack by delcaring a large automatic array!
That works too. Actually a little bit cleaner than alloca, or the solution I was going to propose (inline assembly to adjust the stack pointer).
I'd expect alloca to be provided as a builtin (since it needs to be inlined), so either I mucked up the prototype or our GCC build is wonky. I'll have to investigate further.
alloca does the same as my hack, but cleaner.
what i really need to do is set the start of my heap to the end of my add-in. then it can use all the headroom of the add-in ram and *then* roll over the old heap space and get anothr 128k.
is there source for crt0.s. also how do i get the latest PrizmSDK from github
thanks,
-- hugh.
Um, note that the addin is located in ROM (just saying due to the wording). Also, the stack can't be completely used. The addin's stack grows downwards. Running the heap into that will be very painful.
Also, crt0.s is the source. crt0.o is the compiled version. .s usually means assembly (in this case, SH4a asm)
Yes, you're right about the stack being in the way.
the idea would be to adjust crt0 to put the stack at the end of the old heap space and the start of the heap at the end of add-in RAM area.
eventually they will still collide though
I just added alloca to the libfxcg headers, so it appears to work now.
Silly example:
Code: #include <alloca.h>
int main() {
int *l[16];
int i;
for (i = 0; i < 16; i++) {
l[i] = alloca(sizeof(int));
l[i] = i;
}
return 0;
}
AHelper wrote:
Remember that PrizmSDK is old. These functions are located in libfxcg on github.
That reminds me once more that we need to pack up a new PrizmSDK including all the libfxcg updates into a v0.4 version, perhaps. Can you guys coordinate on when the current set of libraries is sufficiently complete and functional?
