Do you plan to produce the 2GB pyra?

[ible]

thankfully we haven't gotten the thread too derailed for ED to step in and make the second post.

 

[zmatt]

he was asking whether hypotherical 2GB units with half the memory bandwidth would be slower than 4GB ones with full bandwidth.

That's somewhat complicated, and will depend will very much depend on how the system is being used. The available memory bandwidth is shared between all subsystems that need to handle more data than fits in their local cache/sram. This means the two A15 cores, the display controller, and any video/graphics related subsystems used (SGX544, GC320, IVA-HD, maybe ISS).

For video streams it's easy to calculate bandwidth required, e.g. 720p60 ARGB8888 is 211 MB/s, 1080p60 is 475 MB/s, YUYV is half the bandwidth of ARGB8888. The display subsystem can be compositing up to four layers total (across LCD and HDMI combined), but typically only one would be fullscreen (or two if LCD and HDMI are used simultaneously), and it can have a writeback stream e.g. for screencast.

For other subsystems I don't immediately have concrete numbers for use cases. Max theoretical bandwidth for a 128-bit port on the L3MAIN is 3.5 GB/s per direction, max 6.7 GB/s total since reads also consume some write-bandwidth (for the requests), although in practice it may be limited by how many requests in progress the initiator can have simultaneously. DSS, IVA-HD, and ISS all have a 128-bit port, SGX544 and GC320 even have two 128-bit ports each. The memory controller has two 128-bit target ports.

Some random memory microbenchmark on a single cortex-A15 core @ 1.5 GHz showed it could do 5.4 GB/s write, 4.0 GB/s read.

Max theoretical ddr3 bandwidth (read+write combined) is just under 4 GB/s per channel, 8 GB/s total.

The 2GB units built with four (4) 512MB chips should have the same memory performance of the 4GB units built with four (4) 1GB chips.

More or less. It's possible the 4GB version is slightly faster for some workloads due to the ability to keep twice as many rows open simultaneously.

For actively 'running' tasks, the processor runs low on resources prior to the application load reaching 2GB.

The maximum virtual memory usable by a process is 2GB or 3GB depending on user/kernel split. Of course an "application" can consist of multiple processes (see e.g. chrome), and an application can use ram that's not part of its address space (disk cache).

This benefit may be marginal when compared to utilizing a /swap to either the eMMC or a fast memory card.

lol... no. really, no.

linux kernels (not all that recent - I think I started noticing this around kernel 3.2-ish) will use available quite agressively for filesystem optimisation and other stuff.

Correct. It seems perfectly reasonable to me to include frequently accessed files (e.g. databases) as part of the working set of a process, in which case it can easily exceed the virtual memory limit.

The MMU should be able to map 4GB of memory into whatever configuration the chip wants I'd have thought, assuming it can use large enough pages. An ARM chip using 32-bit program counter should be able to address 8GB of contiguous memory per process I'd have thought.

Eh, there's a lot of confusion here. Yes the MMU can map the 4GB of virtual memory to physical memory any way you like, with 4KB granularity. Using larger pages is somewhat supported by linux (see hugetblfs and transparent hugepages) and may result in memory savings and better performance, it does not affect how much memory can be mapped. The program counter is only relevant for code execution, and 2^32 bytes is still 4GB.

Note that linux reserves the top 1-2GB (configurable at compilation time) of virtual memory for the kernel's memory and memory-mapped I/O.

 

[FIQ]

What if some RAM chips fail on production? Could remove the faulty chips and produce some 2GB boards from that.

 

[slaeshjag]

Considering how horribly bandwidth starved the pandora is (I mean really, A handful of layers of 2D with the CPU idle is enough to saturate the memory bus, and _aegis_ software opengl renderer have no problems saturating the memory bus either with just CPU code), it'd be foolish to risk having the same problem, regarding 2 or 4 chips.

 

[levi]

What if some RAM chips fail on production? Could remove the faulty chips and produce some 2GB boards from that.

Theoretically yes, although depending on which chip failed you'd have to have different boot parameters to avoid using one or other of the chips I think. However, this would result in a unit with half the memory bandwidth, so it'd be a worse kind of 2GB unit than the ones actually planned using the same number of chips but each with half of the capacity.

Although I think this means 2GB units will require different boot parameters to 4GB units, which would be a maintenance burden if uboot ever gets updated. So that might be a reason not to actually produce any 2GB units at all.

 

[Grench]

lol... no. really, no.

I know what you're thinking, but I don't think you're giving the Linux /swap management enough credit. No, it will never be as fast as real RAM. It does not need to be. It just has to be someplace to shuffle off extraneous bloat crap that programs called into RAM and are not using. Like the contents of 30 of the 40 Web pages that you might keep open but never flip to. It isn't suckling down energy to refresh sitting there either. Modern kernels will also RAM cache to max out the system RAM usage and will push lower use things to /swap to make more room for the RAM to cache the HDD.

 

[Drezrek]

There's yet to be any answer to this, seems like ED is more focused on the production at the moment. Makes sense, though.
Also; Since there still is a massive split between the 2GB vs 4GB version, wouldn't be surprised if the first one was dropped but I'm very curious to see how things turn out.

 

[EvilDragon]

No real answer yet, that will probably be a last minute decision based on tests .)

 

[ible]

no news is no news!

 

[Mr_Loon]

No real answer yet, that will probably be a last minute decision based on tests .)

Thanks ED, keep us posted. Why wait until the last minute though? Could the tests not be done now as there are working prototypes with 2GB & 4GB?

 

[Askarus]

Thanks ED, keep us posted. Why wait until the last minute though? Could the tests not be done now as there are working prototypes with 2GB & 4GB?

May depend on the price and whether it makes sense or not to produce the 2GB version.
And how well production runs and how hard it is to maintain multiple RAM sizes on the OS side.

 

[Bernd]

What's the Problem?

The main difference between 2Gig and 4Gig is that there are less soldered ram chips.

And what is the problem in maintaining the os?
Isn't the ram size only one value in a setting file?

 

[TrashyMG]

What's the Problem?
And what is the problem in maintaining the os?
Isn't the ram size only one value in a setting file?

Hardware configurations including memory setup and timings are done in a device tree binary and typically require different device tree. However I don't think this is as big of a deal as Askarus makes it out to be, I think the gurus already figured out how to load a different DTB configuration based on hardware revision of the CPU board at boot time via some set jumper bits. the LPAE linux kernel can be used in both configurations with out issues so the actual OS isn't an issue really.

 

[Grench]

Hardware configurations including memory setup and timings are done in a device tree binary and typically require different device tree. However I don't think this is as big of a deal as Askarus makes it out to be, I think the gurus already figured out how to load a different DTB configuration based on hardware revision of the CPU board at boot time via some set jumper bits. the LPAE linux kernel can be used in both configurations with out issues so the actual OS isn't an issue really.

I suspect that part of the issue with the previous posts is understanding the differences between a PC where you throw a few sticks of RAM in and the BIOS sees it and you simply click OK and move on Vs an ARM SoC that has no BIOS and doesn't really know where to look for it's RAM until it's told where to go at a register level.

What's the Problem?

The main difference between 2Gig and 4Gig is that there are less soldered ram chips.

And what is the problem in maintaining the os?
Isn't the ram size only one value in a setting file?

Actually, they can have the SAME chip count (4) but use different capacity chips (512MB Vs 1GB) and if I recall correctly the chips themselves are completely different pin arrangements.

There are two ways to do a 2GB unit though. Using the four 512MB chips OR using two 1GB chips. The issue there is that the two 1GB chips would only have half the data path and would have hypothetically lowered performance.

Within these three types of units (2GB on four 512MB, 2GB on two 1GB, 4GB on four 1GB) the actual address space of the RAM is going to be considerably different from one configuration to the next. The RAM configuration for the dev boards was based around the 2GB on four 512MB chips and was/is known/working.

Where the development work starts is to figure out the address assignments for the 1GB chips in both potential 2GB and 4GB examples.

Then there is the OS - which in this case would include everything from uboot on up. That has to auto-detect which of the three configurations the individual device conforms to then map the RAM to the OS for that version so that the OS writes to actual existing memory.

I suspect that the decisioning on which configuration the device is and where to map the RAM for the OS to happens in the uboot. I'm not sure on this though. It may be that the uboot might need to match the device RAM/hardware - which could mean 3 different uboot versions.

So, yes, there are real OS level tasks and serious hardware level coding that need to be worked out as a result of the whole 4GB addition. I sure hope we find uses for the 4GB of RAM. (Testing with the 2GB dev board showed there wasn't much left to gain as the OMAP was tasked out at 2GB.)

Now, I have no actual insights to the actual work involved in actually making it work. Other more qualified people are doing that. What I have stated above is from piecing together snippets of information from multiple messages over a broad time frame. My conclusions -feel logical to me-, that does not make them accurate. If one of the development team sees something here that is incorrect, it will not hurt my feelings a bit to have it corrected.

 

[Mr_Loon]

@EvilDragon : Thought I'd give the question 'Do you plan to produce the 2GB pyra?' a little bump in lieu of the announcement that the 4GB boards are working & there have been so few pre orders for 2GB Pyras.

I can see arguments on both sides but the decision should be made soon IMHO.....

 

[levi]

Does he need to discuss it here before he does it though? I guess there's no actual price difference in the preorder amounts just yet, so it's not as if shifting those who'd pledged for a 2GB unit free money if you shifted them to 4GB, but on the other hand it would commit them to slightly more when it comes to upgrading their pledge to the unit price.

That said, I would be willing to commit to that slight increase since I'm one of the few preorderers who preordered a 2GB unit in the EU cellular spec (although the cellular spec is irrelevant since it's only the RAM that affects the CPU board).