> 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.
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
That's also clarified in the blog post. Sorry, I haven't posted the link before: https://puri.sm/posts/supplying-the-demand/
> 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.
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."
This can create ambiguity in which bit of the 2 or 8 or whatever is on the bus, and temperature, board design, bus length, humidity etc change the phase where the best sampling place is for the data signal. So there is 'training' to test which fine delay between the receiver pll clock and the data gives the lowest error rate when used to sample the incoming data. Periodically some buses must pause and do retraining to account for, eg, temperature changes.
Often this is done by setting registers. The trick is that its hundreds of thousands of registers to alter the way the PHY behaves with regard to impedance and other parameters, and the vast majority are undocumented. So its done with a two stage thing: the first is a generative program that analyses the eye diagrams using feedback from the PHY over a long period of time to get the majority of the settings.
The second half is actually getting the PHY PLLs to sync with the clocks and the RAM, which is done by the PHY at runtime, every boot.
Basically it's the memory chip bring up procedure of the memory controller. It figures out what kind of ram is on the bus, configures and even tests it so it's ready for use.
Maybe Purism has a way to do this?
I am not an expert!
PCs have codified it mostly to a set of well known and understood timings that are interchangable, so in that domain its easy. But raw DDR chips used with SOCs is much much harder because you're not beholden to Intel's standards for the PHY or the RAM.
What else is concerning is that they are shipping the SOM without schematics or documentation -- even the dev units have no details on their construction. For reference, Purism only made the baseboard and mechanicals -- the actual SOC and RAM are on a module made by Elecom. I asked about this in their matrix channels and the best answer I could get was "it will be made open" -- a tall order, given the past history of Elecom keeping their designs close to their chest. This is most likely the core reason why their thermal and RAM performance sucks -- the community can't get in there to help.
Note that they aren't even running the RAM at full speed -- that's not something you can easily change without re-generating the training programs, and locking that in without proper burn-in or huge amounts of QA to validate is going to likely be the biggest hurdle they will face. Especially given the requirement that the program not be updated.
Source: built and shipped SOMs using the i.MX8MQ in the past and still supporting them now: RAM training is a huge problem.