News for hackers. Stuff that matters.
Re:Progress update from the Librem 5 hardware department by codedokode on Tuesday September 04, 2018 @11:46PM (#17914895)
Can it be that they just allow modem to use the same RAM and ROM that CPU uses, so that they don't have to install another RAM chip?
Re:Progress update from the Librem 5 hardware department by subway on Wednesday September 05, 2018 @12:11AM (#17914974)
Yes/No/It's Complicated.

If when you say "ROM" you're talking about the persistent storage holding the modem's firmware, then absolutely -- that firmware lives in a "vendor" partition on the same emmc as the OS.

When talking about "RAM", things get a bit more complex. Most usb and even pcie modems are going to ship with enough built-in (that is, on the same die) RAM to get the job done. They have absolutely no need for the quantities or qualities of external DDR (where your OS is running from most of the time).

That said, when the modem is embedded in the SoC, all bets are off -- it's really convenient to share as much as possible, and is entirely possible for the modem cores to depend on the same DDR memory as your ARM cores.

Re:Progress update from the Librem 5 hardware department by biktor_gj on Wednesday September 05, 2018 @02:15AM (#17915433)
On Qualcomm SoCs, a chunk of the memory area is reserved for the baseband, and another section is reserved for TrustZone kernel, but it does the same as an integrated GPU in a PC. Then it connects via a pseudo tty with a kernel driver, but as the baseband has more privilleges than the main cpu, it really could do whatever it wants, just like TrustZone.
Re:Progress update from the Librem 5 hardware department by cjbprime on Wednesday September 05, 2018 @10:09AM (#17918089)
It can share the CPU's RAM chip without being able to read from (the rest of) it, because of the IOMMU.
Re:Progress update from the Librem 5 hardware department by subway on Thursday September 06, 2018 @10:01AM (#17926319)
And Qualcomm would never improperly configure their SMMU:

https://nvd.nist.gov/vuln/detail/CVE-2016-10444

They only sat on this one for two years before fixing it.