Why 0x01000000 in e_alloc()?

[eliecer]

[notzed]

There are two reasons.

First, the value is an offset into the shared memory location, not an absolute physical address. So it will have to be within the range of the size of the shared memory. This is intentional because different hardware might use different addresses and the sdk is shielding you from it.

Second is due to where the linker script places the code and data of the executable. By default it reserves the first 16MB of the 32MB block for "shared" code, hence you use an offset of 16MB to avoid that (i.e. 0x1000000). But you can change the linker scripts to put this stuff elsewhere, or just define your executables in a way that they don't put any code or data there. Or use a completely different mechanism of just defining global variables and resolving their address properly.

[eliecer]

Thank you notzed.

My English is not good, but I think that I understan you: A core have 32MB (first 16MB to code, last 16MB to data). 0x01000000 means it points to the beginning of the 16MB to data.

Then, I have only 16MB for data, but I want share 300MB. How I do it? Is possible?

Thank you.

[greytery]

[notzed]

You can control the linker script, so you can give yourself more of the 32MB - all the way up to all 32MB if you can put all your code and working data on-core. At the very least you can inspect the code size generated and set a lower base.

For 300MB, currently you would have to do it in batches/slices/parts of some size that fits, and the host would need to set this data up each time.

If there is a new mechanism in a future sdk/fpga firmware that allows more memory to mapped on the arm side it will still not allow for any more than 32MB of contiguous (continuous) memory on the epiphany side due to the implementation of the hardware.

[greytery]

Yes, but not quite so, notzed,

On the E16 Parallella, the emesh addressing hardware could allow upto 52MB contiguous/continuous memory (i.e. addressing anything east of the last core's column address), if the FPGA e-link address logic was changed to allow it through.
But even 52MB is hardly worth the (significant) effort of rebuilding the FPGA, kernel, U-Boot, etc.

What is required is what shodruck called a "memory hole remapper" to circumvent the hardware feature. That includes Epiphany library routines for external memory access (read/write/DMA) that allow user code to 'see' a continuous external memory space, but perform the physical address translation for the emesh hardware. FPGA e-link logic would translate the addresses back to the real contiguous SDRAM memory.
I did some work on this (see topic ) while waiting for my boards to arrive. At that point, Andreas dangled that cryptic promise about something new in the pipeline, so I'm now (still) waiting to see what that could be .....

Cheers,