Parallella Community

does it work on legacy.ldf? I mean try the other way around, start from legacy.ldf and move the needed lib into internal.
as mentioned in this post

Thanks yes that partly works, I am using the legacy.ldf at the moment.
I have two problems :
1) I am using a buffer as a buffer for std out replacement, and that is overlapping the working program, I do not know how to separate them using the .ldf.
2) when I try and move functions they 'are not found' I think my syntax is wrong

- is there a .ldf guide anywhere ? Is it particular to the parallella ? I have seen some for the Blackfin, but that looks different.

When using the legacy or fast profiles, some code is placed at the external memory. Normally, it will occupy a 1MB-pre-core region, starting at 0x8e000000. This means that the code will occupy up to 16MB of the external space.

The upper 16MB are allocated for the program heap, again, 1MB per core. When using malloc(), *printf() and other stdio functions that use malloc internally, they will use this heap space for their operation. If you look carefully you'll notice that the heap segments are locates in the "shared_dram" section. This means that what you see is most probably the heap running over your mailbox, or vice-versa.

If this is indeed the case, you can solve it by doing one of these:

1. Using a custom LDF, shrink down the heap and locate it in the upper part of "shared_dram";

2. Assuming that the program operation does not require too much heap space, and that the heap grows linearly, you can place your mailbox in the upper area of the section. In order to do this, you can:

2.1. Change your outbuf from a string to a pointer and assign it a specific address (say 0x8fffff00), discarding the SECTION() attribute. Remember to change the mailbox address in the host program accordingly;

2.2. In a custom LDF, define a new section in a specific address (say 0x8fffff00) and change the outpuf attribute to that section name. See the matmul example for an how-to reference.

The GNU website has a reference manual for linker scripts, if you want to go deeper in the LDF mechanics:



and here's another one:

From a glance, before really verifying your LDF code, I think that the host buffer address should be 0x01fff000, and not 0x00fff000 (I assume that the buffer is above the heap, and the heaps start at 0x01000000).

Also, there is a problem with e_alloc() when the offset is not a multiple of page size (4KB on this system), which is why you get the mmap() failure when allocating the 128 bytes buffer. I am actually right now working on a fix for this problem, which I found a couple of days ago, so it should be OK in the next release.