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.
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.
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!
> Where are the flattened schematics with the i.MX8MQ SOC and RAM onboard? So far, I haven't been able to find them.
They are and will be available to anyone owning the phone, just like I said in the previous post.
You said:
> even the dev units have no details on their construction
so I showed you the full open sourced design.
You said
> the community can't get in there to help.
so I proved that anyone with the willpower can engage. Now you're complaining that people don't want to engage. By saying:
> the only contributors I've ever seen are [...] -- not someone with a dev board who doesn't work at Purism.
you're moving the goal posts and making me look wrong.
> Ahh, my apologies then. My memory must have failed me. Glad to be corrected!
See, that's the problem with your posts here. I'd much rather have you get corrected by asking questions at the community channels, which are frequently answered by engineers rather than post under-researched false things on unrelated forums. By posting wrong things, you're undermining the project, which you yourself claim to support.
The blog post says one thing. Nobody in the community has posted anything about actually having an Aspen in hand and working on it yet.
> They are and will be available to anyone owning the phone, just like I said in the previous post.
Technically I own one because I plonked down the ~$500 or whatever it was to preorder one. I'm in the later batches, but I have paid for one. It would be nice to get at those schematics, if they exist publicly. Sadly, I haven't been able to find them, and you haven't been forthcoming except to point me to a schematic and board art for the dev board.
> You said: even the dev units have no details on their construction
> so I showed you the full open sourced design.
Ah, sorry -- I should have been more clear in the first post. I was referring to the schematics for the EmCraft SOM, without which trying to manage thermals and manipulating device trees is going to be problematic.
Frankly, it's a bit disingenuous to call that a full open sourced design -- half the dev unit's board is missing and buried inside that EmCraft symbol.
> You said: the community can't get in there to help.
And they can't without schematics for the EmCraft SOM. I was prepping to actually help out at one point, but stopped because I couldn't find the EmCraft SOM schematic.
> you're moving the goal posts and making me look wrong.
No, you're reading too much into the original post. I said the community hasn't been able to help. Purism isn't the community, and your link points to a commit from a Purism account. I fail to see how I moved the goal posts here.
> See, that's the problem with your posts here. I'd much rather have you get corrected by asking questions at the community channels, which are frequently answered by engineers rather than post under-researched false things on unrelated forums. By posting wrong things, you're undermining the project, which you yourself claim to support.
I have asked in the community and dev board channels, on Matrix, and I have spoken with engineers involved. Some questions were answered, some weren't. Others were answered with handwavy "eventually" statements. I mentioned this in the first post I made about this.
>The blog post says one thing. Nobody in the community has posted anything about actually having an Aspen in hand and working on it yet.
I assume that's because none of the Aspen units went to non-staff members. From their blog post:
"We intended on the second revision of Aspen (black case) getting into the hands of backers, but due to the results of quality control tests against RAM clocking at full-speed (consuming power and generating heat), we made the decision to move those backers to Birch and deliver the rest of Aspen to developers and staff."
> The fact that they are supposedly sending these out without certs for the baseboard is hugely concerning -- and illegal.
and then
> this is the core reason why nothing has left their hands yet.
Wait, so are they sending them out or did nothing leave their hands? I'm confused.
> What else is concerning is that they are shipping the SOM without schematics or documentation
No one is shipping SOMs, the phone is a board with the SoC integrated.
> even the dev units have no details on their construction
What do you call Kicad schematics then? https://source.puri.sm/Librem5/dvk-mx8m-bsb/blob/master/dvk-...
> the actual SOC and RAM are on a module made by Elecom
Emcraft
> the best answer I could get was "it will be made open"
The phone schematics will be available to those with the phone in their hands. This is how GPL works as well, btw.
> a tall order, given the past history of Elecom keeping their designs close to their chest.
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.
> thermal and RAM performance sucks -- the community can't get in there to help.
I wonder if other i.MX8 kernel contributors agree https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> Note that they aren't even running the RAM at full speed
You've clearly not read the report in the first link. RAM running at full speed was the problem causing heat generation.
Source: work at Purism.