2GB and 4GB

[TrashyMG]

Wouldn't worry too much about it, it's not like going from 2GB to 4GB is equivalent to double the power consumption. It's likely somewhere slightly more than 2GB. I remember seeing a chart somewhere, need to find it.

 

[Grench]

I still don't think that the move from 2GB to 4GB was worth the delay to the project that it caused (arguably between 6 months and 1 year). There are still learning moments around how to deal with the 4GB and where the graphics system stores things. But, on the flip side, there is now a lot better understanding of the ins and outs of the OMAP 5432 and how it deals with memory. We still don't have any actual need for more than the original 2GB of RAM specification - might some day.

IF the Pyra in current 4GB form sells enough units to be a success, then I have a prediction for what the first upgrade CPU board might be. It would still have the same OMAP 5432, but would have 8GB RAM (maximum that the OMAP 5432 can address) and the highest capacity eMMC that is directly compatible (physical pin-out, electrical, etc) and available in the right packaging to just be a drop in replacement on the pick and place machine. To me that is the logical, 'next step' instead of going after a whole new SoC with all of the inherent design pains so quickly.

 

[daveshah]

Not really sure what the point of that would be. I am not sure if anyone has ever successfully used an OMAP5 with 8GB of RAM, and indeed I saw some code in the TILER driver that I know would break going above 4GB RAM. The other question is what use case would actually benefit from this.

Hopefully, future SoCs will be a lot less painful as the kernel development would be shared with more boards and use cases; unlike the OMAP5 (personally I think we should wait for the iMX9/10 but maybe something else will crop up sooner than that).

 

[Grench]

Agreed. There is no practical point to going to 8GB RAM. But, beyond marketing specs, there wasn't much practical point to going to 4GB RAM either. I don't think I have even crossed 1GB RAM in use on my prototype.

There is always a clamoring for new/better/more though. People have been suggesting other SoC options fairly consistently - whether the suggestions are even remotely practical for this type of device is another conversation entirely. Just making a first pass at SoCs for finding something that fits in our heat envelope, physically fits on the board, has the needed peripheral support, isn't too expensive, is available to the project, has long term product availability, and at least doubles the 3D graphics performance - that weeds things out pretty quick.

Sharing the same SoC as other devices would indeed be handy too. The few options I've seen that meet all that were actually Mediatek based. Unfortunately many in the GNU/Linux community would burn me at the stake for even suggesting such a thing due to Mediatek having done some sin or another years ago. So, that adds another wrinkle - Linux community acceptance.

 

[Phlyra]

Agreed. There is no practical point to going to 8GB RAM. But, beyond marketing specs, there wasn't much practical point to going to 4GB RAM either. I don't think I have even crossed 1GB RAM in use on my prototype.

There is always a clamoring for new/better/more though. People have been suggesting other SoC options fairly consistently - whether the suggestions are even remotely practical for this type of device is another conversation entirely. Just making a first pass at SoCs for finding something that fits in our heat envelope, physically fits on the board, has the needed peripheral support, isn't too expensive, is available to the project, has long term product availability, and at least doubles the 3D graphics performance - that weeds things out pretty quick.

Sharing the same SoC as other devices would indeed be handy too. The few options I've seen that meet all that were actually Mediatek based. Unfortunately many in the GNU/Linux community would burn me at the stake for even suggesting such a thing due to Mediatek having done some sin or another years ago. So, that adds another wrinkle - Linux community acceptance.

Would we not benefit from 8Gb RAM in the same way that RPi has, or is that too simplistic a view, particularly given we’re highly unlikely to use the Pyra as a server...?

 

[daveshah]

The RPi 4 has more CPU power, and less in the way of thermal constraints. It is also 64-bit, which means that one process could easily access all 8GB if needed, whereas on the 32-bit OMAP5 in general each process is limited to 3GB each.

 

[Phlyra]

The RPi 4 has more CPU power, and less in the way of thermal constraints. It is also 64-bit, which means that one process could easily access all 8GB if needed, whereas on the 32-bit OMAP5 in general each process is limited to 3GB each.

Ok so the only way 8Gb would ever be useful to us is with a 64-bit capable CPU with lower thermal constraints?

 

[Letalis Sonus]

whereas on the 32-bit OMAP5 in general each process is limited to 3GB each.

Actually, the amount of address space dedicated to the kernel is adjustable. As each process has its own set of virtual memory configuration, the remaining reserved memory space is only limited by the amount of shared memory you actually need to interact with other processes or the kernel itself. The only reason why such a huge chunk of address space is being allocated to the kernel itself is performance: if everything the kernel needs uses the same virtual memory address mappings you do not need to reprogram their entries within the MMU configuration when switching to other tasks, which also affects other related things like the TLB.

PAE-like aware software like the JVM in server mode may even allow you to use several virtual memory mapping configurations somewhat transparently in parallel to handle more than 4 GiB despite running in a 32-bit CPU mode.

 

[Swordfish II]

Yes, only 22 2GB orders.
We probably will NOT create them, instead, these will be updated for free to 4GB versions.
Unless you REALLY want a 2GB one, as we have some prototype PCBs lying around

Makes sense. You will spend more doing small batch orders and time. Just doesn't make sense.

 

[mrpalmtop]

Agreed. There is no practical point to going to 8GB RAM. But, beyond marketing specs, there wasn't much practical point to going to 4GB RAM either. I don't think I have even crossed 1GB RAM in use on my prototype.

There is always a clamoring for new/better/more though.

Strongly disagree here. Since Firefox began improving its process security, its memory usage has expanded massively. On 4GB, you basically have to use NoScript if you want to use other programs. It's a disaster now with less than that.

You can get by with a Chromium browser and less RAM but if you want the latest Firefox, it's currently a very bloated beast.

Having only 2GB as an option would not have been a good look for a device looking to target power users. Even mid- range phones have 4GB. High end ones have much higher.

 

[ToastBucket]

Ok so the only way 8Gb would ever be useful to us is with a 64-bit capable CPU with lower thermal constraints?

The OMAP5 is actually running LPAE which is an emulated 64bit mode. It provides extended address space for the extra RAM. This is what allows us to use 4GB. I don’t know if it can support up to 8GB though I haven’t looked into that.

https://elinux.org/images/6/6a/Elce11_marinas.pdf

 

[daveshah]

The theoretical limit of the OMAP5 is indeed 8GB, and the LC15 board is wired so it should be able to be built as 8GB with the right chips. But I think there may be kernel code that expects DRAM addresses to be 32 bits - and as discussed many programs would only be able to use 3-4GB each on their own right.

 

[levi]

It's just occurred to me, we don't have to worry about the price difference between 2GB and 4GB units. Given there'll be new product pages on the website which'll sell us real pyras and we can redeem our pyra vouchers against that, those product pages should just be for EU, US cellular and non-cellular versions at the 4GB prices. To date we've all paid the same 400EUR deposit and merely expressed a preference for 2GB or 4GB RAM. If ED doesn't offer 2GB RAM actual Pyra pages, we'll pay the same price as everyone else.

I'm not quite sure what he'll do if someone quibbles and demands a 2GB unit made using old prototype CPU boards, but with a bit of luck none of the 22 people will be so awkward, and won't want to actually buy a unit with 2GB of RAM in 2020.

 

[λ the β-Redex Reducer]

I was under the impression that he was going to give the 2GB pre-orderers a 4GB version for the 2GB price.

 

[levi]

I wasn't sure, but when I considered the way the shop works, I thought it through and the above is where I ended up.

 

[Phlyra]

Just wondering, would 8Gb RAM not serve useful for doing CAD work, video editing etc. on the Pyra?

 

[levi]

Not sure. One place I used to work the designers felt themselves comfortable running autoCAD on a machine with 4MB of RAM, but times change I guess. Video editing would probably benefit from more RAM, but 4GB is already more RAM than I have in any of my machines I'm currently running.

 

[λ the β-Redex Reducer]

I wasn't sure, but when I considered the way the shop works, I thought it through and the above is where I ended up.

Just because he has "Evil" in is name does not mean that he cannot be nice:

Yes, only 22 2GB orders.
We probably will NOT create them, instead, these will be updated for free to 4GB versions.

 

[mrpalmtop]

Just wondering, would 8Gb RAM not serve useful for doing CAD work, video editing etc. on the Pyra?

There are a thousand things I can use 8GB of memory for. My desktop has 64GB and hosts multiple virtual machines and containers, runs Firefox on dozens of bloated websites (thanks Bootstrap, React, etc.). It's helpful with video editing, software compiling, and allowing for remote user sessions.

If I were doing mobile app development still, the emulators would eat RAM for breakfast.

 

[Phlyra]

There are a thousand things I can use 8GB of memory for. My desktop has 64GB and hosts multiple virtual machines and containers, runs Firefox on dozens of bloated websites (thanks Bootstrap, React, etc.). It's helpful with video editing, software compiling, and allowing for remote user sessions.

If I were doing mobile app development still, the emulators would eat RAM for breakfast.

Ah yes, how could I forget the vm’s and containers!