Using More Memory

[eoghanoh]

Hello,

by default, there is 32MB of shared DRAM available to a program on a Parallella board, even though there's a total of 1GB on the board and there's lots free.

I'd like to use more, e.g. 512MB.

How do I do this?

I presume I need to edit the bsp and / or hdf file or something like that but not really sure where to start. Is there a simple set of instructions anywhere? It seems like something that people will want to do. From everything I've read it seems that Parallella reserves a block of memory when I load the ehal, so I suppose really what I'm trying to do is increase this block of memory so I can access it with e_alloc.

Am I right about this? Can it use more? If it can, a further question is then: why does it ship with only 32MB configured?

Thanks,
Eoghan.

[ysapir]

There's two parts for this issue. Theoretically, there is no prevention for the Epiphany to access ALL of the DRAM on the board. Technically, this is really a shared, flat memory space. However, due to the nature of Linux, we had to guarantee that no system memory is being overwritten by the Epiphany programs. Thus, we excluded a part of the DRAM from the system's memory map. In effect, whatever the Virtual Memory Manager decides to use, it will not be on that excluded space, and it is safe for the Epiphany to fully use this area.

It was decided quite arbitrarily (well, not really arbitrary - as it was inherited from our previous prototype boards) to allocate 32MB of the DRAM for that purpose.

To change this amount, you first need to change the Linux configuration files (unfortunately, at this time I cannot help with that, but IIRC, it was already discussed in the forums). Then, you need to make the eHAL and eLIB aware of these changes. This is done using the *.hdf configuration file used by e_init().

[greytery]

[timpart]

@greytrey I think you may have misread the postings. The original question was about the 32Mb of the 1 Gb external DRAM that is excluded from Linux general use and available as a shared resource for the ARM and Epiphany cores to use. It is possible to change this allocation so the Epiphany can have more RAM to work with.

However the local RAM on the Epiphany is still fixed at 32Kb per core. The external RAM in the previous paragraph is off chip, and although it transparently forms part of the Epiphany memory map, it is slower to access. (The rest of the 1 Gb is also accessible but since Linux might do anything to it at any time, doing so is dangerous.)

Tim

[notzed]

[greytery]

@timpart - that's a very polite RTFM. Thankyou.
Got a bit carried away there.
Ho Hum, back to the manual until I get the real thing to play with.
tery

[shodruk]

I think there are some limitations in external memory access.
With the default configuration of Parallella,
the Core-ID of Epiphany is set to (32-35, 8-11),
so the Epiphany can only access its east address (0-63, 12-63).

e.g.
0x00c00000 - 0x03ffffff
0x04c00000 - 0x07ffffff
0x08c00000 - 0x0bffffff
...
0xfcc00000 - 0xffffffff

So we can get up to 52MB contiguous memory space. (with E16 Parallella)

Note: This is only my understanding...

[aolofsson]

Shodruky, That is correct.

Question for all: How big of an issue is it to not support large contiguous areas of physical memory for software developers? Our assumption was that that this could be hidden from most users.

Andreas

[shodruk]

I think that is not a serious limitation.
It is even possible to implement virtual memory in software.
In any case, with Epiphany, we have to manage data segmented into 8KB or so.

[greytery]

{OK, I've calmed down, doubled my medication...}

It's a truism that if an application dataset is larger or differently organised than the limits/constraints of the Parallella architecure then that application will need to work around/within the constraints, such as the 8KB segmentation mentioned.
It's probably a only small subset of applications/developers that really need to access large contiguous datasets in the current Parallella's global memory - so not a big issue.
For those who do need it, perhaps it would be best to just document how to adjust the size and location of the global memory more flexibly/easilly - especially for a E64 build, say, -rather than have it fixed at 32MB. { ... like one of shodruck's Ubunu tips maybe?}

But having access to a large global memory and then actually using it is not straightforward.
The performance hit of accessing the off-chip memory is itself a major constraint - and many developers will have to take this into account even for basic applications.
There's a good analysis/advice by @tnt on the performance impact of reading data/running code from the external global memory on one of the early boards.

.

Basically - don't. Unless you must.

tery