Okay, here we go: full disclosure, I'm an embedded software engineer that works at Google. My views are my own, and don't represent Google's opinions or views, yada yada.

I have been working with the i.MX8MQ SOC for over two years now, fighting with various bits of how it behaves with different vendors of RAM and dealing with exactly the same problems Purism is running into. While I haven't managed to get things upstreamed into mainline yet, our source trees are open and up at http://coral.googlesource.com.

I'm also a backer of the Librem 5, and while I didn't ask for an Aspen, I do want the project to succeed. I just have concerns that nobody's been able to answer.

> I can see a lot of mistakes or misconceptions here.

Yeah, that's probably because I'm typing on my phone and fighting both HN and iOS's Safari. Apologies.

> Wait, so are they sending them out or did nothing leave their hands? I'm confused.

Well, my statements are that a) they are trying to ship something but don't have certifications in place, and b) they claim they've shipped Aspen, but there's no evidence of it.

So... They have "shipped" and still haven't?

> No one is shipping SOMs, the phone is a board with the SoC integrated.

That's news to me -- the dev units were shipped with SOMs. If they are flattening the SOM into the baseboard, that's new, and is not what I found in my research. If that's the case, awesome, glad to hear it! :D

Where are the flattened schematics with the i.MX8MQ SOC and RAM onboard? So far, I haven't been able to find them.

Also, where's the FCC certification? Flattening the SOM into the baseboard or just integrating the SOC now makes certification a much bigger problem.

> What do you call Kicad schematics then? https://source.puri.sm/Librem5/dvk-mx8m-bsb/blob/master/dvk-....

That's for the baseboard of the dev unit, according to https://source.puri.sm/Librem5/dvk-mx8m-bsb/blob/master/READ... and the first page of the schematic. Pulling down the source and opening it in KiCad, I can't find the i.MX8MQ anywhere in the schematic or the PCB board art -- only the EmCraft SOM symbol.

> \Emcraft

Yep. Guessing that was a typo from my phone. Apologies!

> Apart from the phone having nothing to do with Elcom, it's also not* using anything made by Emcraft, so no one has any say about schematics but Purism.

Typically when you lay out a board schematic and board art, you use prior proven designs or have the upstream vendor design that part of the board for you. I'd be surprised if Emcraft isn't involved -- and more concerned if they aren't, given that the dev board does use the Emcraft SOM as a starting point.

> I wonder if other i.MX8 kernel contributors agree https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin....

Given that these commits typically come from either Purism, NXP, or Google in this regard, I can say that analysis is about correct -- the only contributors I've ever seen are the ones who are developing commercially using SOMs or the SOC directly. Obviously these corps are part of the community, but this commit is only tantamount to my point: it was authored by someone from Purism -- not someone with a dev board who doesn't work at Purism.

I'm glad to see commits to the mainline kernel, though. Go Purism! (no snark intended here -- this is one of the things I like about Purism) I'll likely be attempting to get our commits (if any) submitted to mainline at some point as well.

> You've clearly not read the report in the first link. RAM running at full speed was the problem causing heat generation.

Ahh, my apologies then. My memory must have failed me. Glad to be corrected!

> Source: work at Purism.

See above. :D