6 ms·

There have been some interesting technical developments with regard to the points Jay is making. For one, FCC certification should only be necessary for the bas

There have been some interesting technical developments with regard to the points Jay is making. For one, FCC certification should only be necessary for the baseboard -- the SOM and PCIe devices should carry their own certification. The fact that they are supposedly sending these out without certs for the baseboard is hugely concerning -- and illegal. If anything, this is the core reason why nothing has left their hands yet. 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.

awinter-py 7y ago
what is RAM training? I googled this but google thinks 'training' means 'documentation' apparently
- nsomaru 7y ago
  It seems that memory is “trained” on boot — the system does POST and checks that critical hardware is responding as expected. PC motherboards have some settings to adjust timing for enthusiasts, but I’m not sure that that’s a trend or even desirable in consumer electronics. So these expected values are probably “burnt in” to the design and difficult to change. Maybe Purism has a way to do this? I am not an expert!
  - mondoshawan 7y ago
    The memory isnt trained -- the PHY is. Its PLL and signal adjustment -- not too dissimilar to how a cable modem "trains" to get settings right for your specific line's characteristics. 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.
    - deleted 7y ago
      [deleted]
- mondoshawan 7y ago
  Modern DDR PHYs require PLL training and adjustment to communicate to the RAM chips because DDR is runs at such high speeds that it is mostly operating in the analog domain these days. 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.
- letstrynvm 7y ago
  Fast buses operate at some multiple of a reference clock wired up to both sides, it's often 1/2 or 1/8th of the actual data rate which each side arrives at by feeding the reference clock to an on-die pll. 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.
  - wiz21c 7y ago
    That seems so awfully analogue... :-/
    - letstrynvm 7y ago
      It is... underneath all that shiny logical digital it's analogue all the way down in any real implementation.
      - akimball 7y ago
        Pace Fredkin.
    - yjftsjthsd-h 7y ago
      It's hardware:) At that level, "digital" electronics... aren't.
- MisterTea 7y ago
  Good article: https://blog.asset-intertech.com/test_data_out/2014/11/memory-training-testing-and-margining.html https://blog.asset-intertech.com/test_data_out/2014/11/memor... 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.
V4ASt2 7y ago
I can see a lot of mistakes or misconceptions here. You say > 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-mx8m-bsb.kicad_pcb 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/linux.git/commit/?id=e464fd2ba4d4573445574388b0b5240ae37c1740 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.
- deleted 7y ago
  [deleted]
- mondoshawan 7y ago
  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 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-.. 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/README.md 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.. 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
deleted 7y ago
[deleted]

awinter-py 7y ago

what is RAM training? I googled this but google thinks 'training' means 'documentation' apparently

nsomaru 7y ago
It seems that memory is “trained” on boot — the system does POST and checks that critical hardware is responding as expected. PC motherboards have some settings to adjust timing for enthusiasts, but I’m not sure that that’s a trend or even desirable in consumer electronics. So these expected values are probably “burnt in” to the design and difficult to change. Maybe Purism has a way to do this? I am not an expert!
- mondoshawan 7y ago
  The memory isnt trained -- the PHY is. Its PLL and signal adjustment -- not too dissimilar to how a cable modem "trains" to get settings right for your specific line's characteristics. 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.
  - deleted 7y ago
    [deleted]
mondoshawan 7y ago
Modern DDR PHYs require PLL training and adjustment to communicate to the RAM chips because DDR is runs at such high speeds that it is mostly operating in the analog domain these days. 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.
letstrynvm 7y ago
Fast buses operate at some multiple of a reference clock wired up to both sides, it's often 1/2 or 1/8th of the actual data rate which each side arrives at by feeding the reference clock to an on-die pll. 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.
- wiz21c 7y ago
  That seems so awfully analogue... :-/
  - letstrynvm 7y ago
    It is... underneath all that shiny logical digital it's analogue all the way down in any real implementation.
    - akimball 7y ago
      Pace Fredkin.
  - yjftsjthsd-h 7y ago
    It's hardware:) At that level, "digital" electronics... aren't.
MisterTea 7y ago
Good article: https://blog.asset-intertech.com/test_data_out/2014/11/memory-training-testing-and-margining.html https://blog.asset-intertech.com/test_data_out/2014/11/memor... 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.

V4ASt2 7y ago

I can see a lot of mistakes or misconceptions here. You say > 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-mx8m-bsb.kicad_pcb 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/linux.git/commit/?id=e464fd2ba4d4573445574388b0b5240ae37c1740 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.

deleted 7y ago
[deleted]
mondoshawan 7y ago
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 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-.. 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/README.md 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.. 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

deleted 7y ago

[deleted]