They still use RAM, but the SIGSTOP and SIGCONT signals do exactly this for programs on Linux, completelly freezing the program to be re-started later in exactly the same state. I have used it to pause renders before, at least until I found the undocumented button in BlendLuxCore to pause renders natively.
Also, these stopped programs would probably move to swap memory very quickly if it was needed, given that while they are stopped they are not doing anything.
Simply correct (comes from Tina Turner: “Simply the Best”)! From now on NXP offers i.MX 8M Plus: Quad Cortex-A53 @ 1.8 GHz based on 14 nm LPC FinFET, 15 x 15 FC-BGA 0.5 mm pitch (instead of 17 x 17 FC-BGA).
Document Number: IMX8LAYERCMPR REV 1
1 Like
The problem of the 14nm i.MX 8 seems to be the smaller GPU. iMX8 Nano and Plus only have a GC7000UltraLite 3D GPU (2 shaders). This looks like half the size ~performance then the 8M in the Librem5. Nano doesn’t have PCIe and the Plus only 1x PCIe.
Beside Vivante GC7000UltraLite 3D GPU there is added separate GC520L 2D GPU (8 x Single Pass Composition Blending). In my non-expert opinion, NXP i.MX8M Quad is great when performing on a steady (condition) external power supply. For example we have devices (like SolidRun Ltd CuBox Pulse) that are capable of using dual display on i.MX8 including 4k decoding. New to i.MX8M Plus is Tensilica HiFi 4 DSP with 448 KB OCRAM and 64 KB TCM, is this disadvantage as well? Also, is there something that I missed when this Forum talked about “some kind” of heat (thermal) problems with the current processor option?
Not being in batch Dogwood I might say that I’m patient. I just think this is great news from NXP (even if not related to Librem 5).
i.MX8M Plus belongs to NXP Semiconductors’ EdgeVerse platform brand:
EDIT to add this Fact sheet:
The i.MX 8M Plus is a whole different chip than the i.MX 8M Quad. It depends on what you want to do with Librem 5 whether you think that Fir will be better or worse than Evergreen.
Improvements:
- Shrinks from 28nm HPC to 14nm LPC FinFET process node, so more energy efficient
- Shrinks from a 17x17 mm package to a 15x15 mm package, so saves space
- Increases max CPU clock from 1.5 to 1.8 GHz
- Adds a neural processing unit (2.3 TOPS)
- Adds a dual camera image signal processor (2x HC/1x 12 MP) with HDR and dewarp
- Improves the Cortex-M7 subprocessor from 266 to 800 MHz and increased its tightly coupled SRAM from 256 to 512 KB.
- Adds video hardware encoding (H.264 and H.265 at 1080p60), whereas the i.MX 8M Quad has to do software encoding
- Adds a HiFi 4 DSP for audio and natural language processing
- Adds Immersiv3D audio with Dolby Atmos® and DTS:X®
- Increases promise to produce the chip from 10 years to 15 years
- Improves things that aren’t used by the Librem 5 (increases number of USB interfaces from 2 to 3, increases number of Ethernet interfaces from 1 to 2, increases PCIe from version 2.0 to 3.0, etc.)
- Improves the PMIC (hopefully for better power efficiency)
- I think that it increases the number of video interfaces from 2 to 3 (so potentially could have dual screen video out if Purism decides to implement it, but I haven’t read the docs to know how this works)
Disadvantages:
- Decreases the L2 cache from 1MB to 512KB.
- Reduces the GPU from GC7000Lite (4 shaders) to GC7000UltraLite (2 shaders)
- Decreases the max video out from 60 to 30 frames per second and gets rid of HDR (4Kp60 HDR -> 4Kp30)
- Decreases max video hardware decoding from 4Kp60 HDR to 1080p60 (no HDR)
The i.MX 8M Plus looks a lot better, until you dig into the details. Its image signal processor only supports a max resolution of 12 MP, which isn’t enough to support the 13 MP back camera in the Librem 5, so it probably won’t be used by the back camera, but the front camera might use it. We probably won’t have any software that will take advantage of the neural processing unit and the audio digital signal processor for quite a while. I doubt that the 3D audio in the i.MX 8M Plus will be used, since the Librem 5 already has an advanced audio chip. The Cortex-M core might be great as a processor in low-power mode, but I doubt that will be supported any time soon.
The real advantages I see are that the CPU in Fir will be 20% faster and it will consume less energy than in Evergreen. Also video hardware encoding will make Fir a lot more energy efficient and cooler when shooting video (but it will only be 1080p max resolution video).
However, the tradeoff is that the GPU in fir will be less powerful and the smaller L2 cache probably will hurt performance to some degree. If you play 3D games or want to use the Librem 5 as a PC, you probably are going to prefer Evergreen over Fir. In theory the hardware in Evergreen will support 4Kp video out so it can take advantage of the 4K video decoding whereas Fir is limited to 1080p hardware video decoding. Of course, we don’t know the thermal limits or what will be supported in Evergreen, so its better GPU and better video out might be meaningless in the real world.
Over the long term, we might get the software to take advantage of the NPU and DSP and the better Cortex-M core in fir and it is awesome that NXP is guaranteeing 15 years of production, because that means 15 years of Linux driver updates from NXP. Fir will probably be supported for longer than any phone in the world, but I do have to wonder if anyone will want to carry around the clunky thing 15 years from now.
8 Likes
Thank you very much for this easy to understand overview! IMO, it is definitively to early to have any expectations concerning the i.MX 8M Plus as Librem 5v2 main processor. It might be that Purism (if and when able to get first samples) decide to go with the MIMX8ML6xVNxZAA variant without NPU, but not necessary (I’ve no clue). 1080p60 H.265/4 HW video decode and encode is just fine for my next smartphone, as I’m accustomed “in the real world” usage. As you already determined and compared all necessary, here is just quick view into several product derivatives of this brand new NXP processor:
It would great to have a programmable button …
2 Likes
In a sense, you can already do that, as everything is under your control.
You could probably do something like “if the microphone kill switch is off, then use the volume buttons to do x and y instead of volume control”
I’d also be interested to see how hard it is to use the gyro-sensor to detect gestures like “double tap on the back” or so.
1 Like
providing that you aren’t interested in using the volume control to control the output volume.
Sure. That’s why I linked it with the state of a killswitch, so you could switch how the volume control behaves. You could also link it with other states (home screen, screen is tapped) or activities (zoom in camera apps is common).
Admittedly, an additional button has more freedom.
That’s why gryo senser patterns are also interesting.
Or hey, the proximity sensor 
Double tap it to take a picture or something like that.
1 Like
On Pinephone, SXMo operating system uses “volume up/down” and “power” buttons for navigating the menu (up/down and enter). It works amazingly well and is quite convenient.
2 Likes
“I would like to accept an incoming call via enabling microphone kill switch” - that was what I thought some month ago. Owning the phone seams to make a huge difference in how we mind about device functionality.
But “double tap on the back” sounds really nice. You tell your friends you phone PIN to unlock screen and let them try to unlock. Nothing happens. You take the phone, enter same numbers, double tap the back and your friends don’t even realize, that this double tap is an “enter” command. 
I can imagine that gryo sensor patterns could be really nice for some better use cases. But how difficult is it to design different pattern to avoid using wrong commands or using commands when you didn’t want to do anything?
or rather the ‘double-tap’ would be customized to only respond to a SPECIFIC tap pattern that only YOU know 
Like a music rhythm pattern? Just hope that you don’t miss one single tap while this 30s sequence. 
1 Like
We actually have that! It’s implemented in the lock screen. Sensitive to 10 different tap positions.
7 Likes
wow you guys thought about everything didn’t you ?
1 Like
doesn’t seem to work on mine. Is that implemented in byzantium?
Irony is hard to get in the WWW, I guess @dcz just meant you can (un)lock your phone with a PIN - hence the 10 different tap positions: 0 - 9
3 Likes
I see. Just hoped I could wake up the device with a double tap (as in Sailfish OS). No need for unlocking