Can Epiphany cores access unmapped memory?

[alexrp]

So, I'm wondering if Epiphany cores are able to access any memory outside the local memory bank. I'm guessing the answer is "no" for obvious security reasons, but is there some way to expose the rest of the Parallella's system memory to the eMesh so that they aren't limited to 32 kB of memory (even if it means slower memory access)? It doesn't have to be permanent; if a process on the ARM system can do it for the duration of its lifetime, that's fine.

[ysapir]

The Epiphany memory space is flat and global. On the Parallella, the eMesh shares the same space as the ARM CPU's.

[alexrp]

Me being a software person, I'm not completely clear on what that means. Does it mean that if I wanted to read some arbitrary memory location (not part of the eMesh's local memory space), I could? If yes, at that point I'm dealing in physical addressing, not virtual, correct?

[ysapir]

Your understanding is correct. At this time there's no OS available for the Epiphany that uses virtual memory. So, any address whose top 12 bits are != 0 will be routed outside of the core, and possibly outside of the chip. In effect, the ARM and the Epiphany share the same memory space (albeit, on the ARM you'll need to find your way to the physical address mapped to by the virtual address - which is done by the eHal driver).

[notzed]

[alexrp]

[notzed]

[alexrp]

[timpart]

[ysapir]

A few comments:

1. The "fixed" region is semi-fixed, as it is defined in the HDF file, which you process at the e_init() call. It can really be anywhere in the system, but on the Parallella we defined it to be excluded from the Linux' space, to serve as Epiphany's private DRAM.

2. There are two address ranges involved:

- 0x3e000000 - 0x3fffffff This space is the true, physical portion of the DRAM we assigned as EXT. MEM. This is the range you'd refer to from the ARM side

- 0x8e000000 - 0x8fffffff This is the same region, remapped to a different address range ("virtual", if you will) that you refer to from the Epiphany side.

The two regions are the same. You could actually used the "ARM" region from Epiphany and it will work, to some extent. Moreover, you could refer to any address in the physical space, even the Linux' memory, and it will work.

The reason for the distinction is that the current Epiphany chip on the Parallella has some limitation preventing it from accessing certain address ranges, some of which fall in the board's physical memory range. So, we implemented the remapping, to allow for a contiguous 32MB of addressable RAM. In future generations we anticipate this problem to be resolved, so 1:1 mapping would work just fine.

Accessing Linux' virtual space from the Epiphany is not possible directly (duh!), but you could possibly work around this by finding the physical address of the pointer allocated by malloc(). If you mmap() the Linux' memory, for example, you may have the base physical address for the virtual space, and from there the offset is easy to compute. You could then access this region from Epiphany, provided that it does not fall on one of those inaccessible "windows", and provided it was not relocated by the OS, like Tim mentions.