The L5 uses automotive-grade RAM (Micron MT53E768M32D4DT-053 WT:E), which has a unit price of $21.75, whereas standard RAM should be about half that price. I suspect Purism selected automotive-grade RAM because most of NXP customers are automakers, and it was one of the models of RAM that NXP says that it has tested and Purism didn’t want to test other RAM.
The schematics have a floating comment with various models of RAM and Flash memory that I suspect Purism was also considering. One of them was Micron MT53B1024M32D4NQ-062 WT:C TR 4GB RAM, whose unit price is $57.72, which is very expensive. You can get 4GB LPDDR4 SDRAM that costs $15, but Purism probably didn’t want to take the risk of using RAM that hadn’t been tested and recommended by NXP.
And automotive-grade components have much higher and stable quality than regular components.
They are also used for aeronautics and spatial application.
It you are talking about using RAM in space, you need radiation hardened components which are very expensive. The i.MX 8M Quad doesn’t support ECC RAM, which I assume would be required for use in aeronautics. The i.MX 8M Plus will support Inline ECC RAM, which isn’t as reliable as normal ECC RAM, so I assume that it still wouldn’t be used in aeronautics.
Still, it is nice that we are getting a better grade of RAM, and it is rated for higher clock speeds, so we are getting better than the normal stuff found in most phones.
No, it’s specific use case. Aero-spatial electronics engineering is not only about high altitude and orbiting devices. Most of the electronics is on the ground.
But, even on this domain, there is a new approach, developed by SpaceX I believe, which consists of no longer using hardened electronics but rather standard components (which may be automotive grade) and relying only on the redundancy of the ECUs that carry out the same operations in parallel (redundancy that has already existed for a long time).
Also, there are less sensible than RAM automotive-grade component that are used for high altitude / space devices.
The modern chipa are made with too small nm level methods which don’t like it when radiation adds voltage spikes. I can’t remember the exact size but a friend in the space tech field, who I asked about this directly, said that they’d prefer the the size around at least 40-60nm level so that they don’t get too much effects form particles - hence old CPUs, as they are made with such fefty methods. Shielding required is very expensive (not in money but weight - which translates to money when it is launched into orbit). L5 is too modern and sophisticated and not nearly heavy enough (shielding) for space travel, I’m afraid.
Back to original question: RAM, eMMC, memorycard, USB-stick. Is there a combo where system is in one and one or two of the others are used as RAM and it’s extension? Would USB-swap add anything to the table (regardless how little, inconvenient and how much effort it would take)?
I would like to say that it shouldn’t be much effort because that is standard Linux functionality but those could be famous last words.
The two problems that I would raise are:
is the solid state medium up to the rigors of the high write-load from swapping or even thrashing?
would the performance be even somewhat acceptable?
A partial workaround to the first item is only to swap out read-only pages i.e. hence they can be read back from the original executable file (if needed again) and don’t need to be written out when swapped out.
In respect of the first item an advantage of not using the eMMC is that the µSD card and USB flash drive can be thrown away and replaced if they die through excessive writes.
In terms of ease / ergonomics of use, the µSD card is clearly superior to a USB flash drive. You don’t really want to have to have a USB flash drive permanently attached at the bottom(?) of your phone (and it would also interfere with use of that port for charging and/or docking).
In respect of the second item, it has already been highlighted that the µSD card is on a relatively slow bus / interface. So I wouldn’t expect fantastic speeds but that is something that I will measure when I get my phone.
Honestly, swap is not something I would be advocating on a phone.
Depends on your goals. I’d suggest to not use swap to increase the memory of one (or each) process, but rather swap out unused processes only. Limiting each app to, say, 2GB RAM should help avoiding thrashing. Pausing every background / minimized app should help even more, and also increases battery life
This way, the wear of the swap medium shouldn’t be too high and the speed not too important.
For the record, enabling swap helped me push through the compilation of a Rust program I recently made on the Librem 5, so it does work. I mean, swap works, not the program
That was on eMMC, and I would be curious about the results of swap on the SD card, especially regarding speed and reliability.
Android uses something like swap, where it saves the state of applications that are evicted from memory. This is somewhat similar to what Linux normally does, which is swapping out unused pages: as a result, you get more operating memory, but you end up waiting on occasion.
I have bucketloads of applications open on my laptop at all times, and I added 30GiB of swap to help push that through. I can confirm that switching to a long unused instance of Firefox or QtCreator, I have to wait a little for the memory to swap in, so it sounds like it effectively swaps out unused programs.
I think enabling swap on the eMMC might be a good idea for the L5 for those who keep more than a handful of apps open.
Planning on upgrading my L5 once I get it to this module… I bought the tools to do it… And have an old Raspberry Pi that I will use to practice pulling chips, cleaning the pads, and purring them into place.
Sorry, but I do not think this is something you can do easily in your garage even if you have tools worth >5T€.
But maybe I am a bit to fearful.
Nevertheless, let us know if you could change the part on the RPi.
the trouble with large partitions is that if you use ALL the available space for files of different sizes from very small (couple bytes) to HUGE (tens of GBs) then you aren’t optimizing for speed.
ideally you wanna’ have partitions dedicated for small (what / uses by default) then you move up to larger inodes. the options are documented if you use the CLI to info mkfs or apropos fs
