1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Dismiss Notice

Do you plan to produce the 2GB pyra?

Discussion in 'Ask EvilDragon Questions' started by Mr_Loon, Mar 7, 2017.

  1. rygD

    rygD Nihilistic Mystic

    Joined:
    Feb 28, 2014
    Messages:
    6,062
    Location:
    Everywhere
    Oh, sorry. I meant a hypothetical "you" that would actually care. What I was getting at is that a unit with lower specs that is one of only a small handful will probably not sell for more money based on rarity alone, based on prices of other palmtops I know of. Unless you care about rarity, it probably wouldn't have any additional value. Still not sure if I am being clear. (It is fun to know that you have one of only 5 of a thing, though.)
     
  2. ible

    ible Advanced Guard Tower

    Joined:
    Mar 24, 2014
    Messages:
    1,562
    Location:
    Once in California, previously in the Netherlands
    thankfully we haven't gotten the thread too derailed for ED to step in and make the second post.
     
    levi likes this.
  3. zmatt

    zmatt Member

    Joined:
    Oct 31, 2015
    Messages:
    67
    Location:
    Netherlands
    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.

    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.

    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).

    lol... no. really, no.

    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.

    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.
     
    _jr_ and levi like this.
  4. FIQ

    FIQ Member

    Joined:
    Apr 1, 2014
    Messages:
    93
    What if some RAM chips fail on production? Could remove the faulty chips and produce some 2GB boards from that.
     
  5. slaeshjag

    slaeshjag ¯\_(ツ)_/¯

    Joined:
    Apr 8, 2010
    Messages:
    2,651
    Location:
    ~Stockholm, Sweden
    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.
     
  6. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    7,529
    Location:
    Somewhere off the coast of the EU
    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.
     
  7. Grench

    Grench Forum Addict!

    Joined:
    Oct 3, 2008
    Messages:
    4,976
    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.
     
  8. Drezrek

    Drezrek Dumb Dragon Dude

    Joined:
    Jun 19, 2016
    Messages:
    28
    Location:
    Dreamland
    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.
     
  9. EvilDragon

    EvilDragon Administrator Staff Member

    Joined:
    Mar 4, 2003
    Messages:
    18,896
    Location:
    Ingolstadt
    No real answer yet, that will probably be a last minute decision based on tests .)
     
    ible likes this.
  10. ible

    ible Advanced Guard Tower

    Joined:
    Mar 24, 2014
    Messages:
    1,562
    Location:
    Once in California, previously in the Netherlands
    no news is no news! :)
     
  11. Mr_Loon

    Mr_Loon Can't Remember

    Joined:
    Aug 30, 2010
    Messages:
    2,284
    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?
     
  12. Askarus

    Askarus Advanced Member

    Joined:
    Sep 28, 2011
    Messages:
    3,953
    Location:
    Germany
    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.
     
  13. Bernd

    Bernd Member

    Joined:
    May 4, 2016
    Messages:
    111
    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?
     
  14. TrashyMG

    TrashyMG Moderator Staff Member

    Joined:
    Jan 18, 2010
    Messages:
    9,951
    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.
     
  15. Grench

    Grench Forum Addict!

    Joined:
    Oct 3, 2008
    Messages:
    4,976
    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.

    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.
     

Share This Page

Loading...