07:33 <Joerg-Neo900> jale42: thanks a lot! anyway this confirms what I said: issues only happen when we have both outer and center BGA balls, which isn't the case between CPU and RAM PoP. Nikolaus says the problem is on lower interface (to PCB) which is not *exactly* related to the chip being a PoP stack. The reasons may be multiple, incl too steep chill temperature profiles, too low preheating, but also too much solderpaste or flux, as well as population of PCB on

07:33 <Joerg-Neo900> opposite PCB side

07:34 <Joerg-Neo900> I *suspect* it's more like the PCB that warps here

11:17 <enyc> Joerg-Neo900: fixable?

11:26 <Joerg-Neo900> enyc: I don't know what exactly is the cause of the problems Nikolaus encountered. I think they *must* be fixable since a few dozen millions of devices with OMAP3 had been built successfully. I still fail to see how the RAM PoP chip (Micron or non-Micron) *on top* of the OMAP makes a difference for soldering the *bottom* of OMAP to the PCB

11:28 <Joerg-Neo900> I suspect the issues are with PCB material and with component population on opposite PCB side of the OMAP

11:29 <Joerg-Neo900> or simply with such trivial things like amount of applied solder paste etc

11:31 <enyc> nods

11:32 <enyc> Joerg-Neo900: hows the PCB layout issues for v2 // enough info on this to make a new newspost?

11:32 <enyc> need to make enough connections to gent the right input somewhere

11:32 <Joerg-Neo900> I just a few minutes ago discussed with ceene about having a "hackaton" this weekend

11:33 <Joerg-Neo900> please rephrase your last post!

11:33 <enyc> we need to make enough people-connections to get the right help // input on theese issues, somehow!

11:33 <Joerg-Neo900> yes

11:34 <enyc> Joerg-Neo900: i've not seen akycha or whovere-it-was in this channel etc...

11:34 <enyc> Joerg-Neo900: r.e. PCB layout etc.... aiui lots of tool development was needed!

11:34 <Joerg-Neo900> she's here, but not posting

11:35 <Joerg-Neo900> (tool development) we're switching from eagle to kicad plus tools wpwrak (and me) developed

11:36 <enyc> whats' eagle still doing? any specific blockers to not needing it at all?

11:37 <Joerg-Neo900> we have the exact position of some mechanical components like card holders and switches defined in eagle. We need to port this to the layout now and make sure it's correct to the <0.1mm while we use a new refined PCB shape

11:38 <Joerg-Neo900> http://neo900.linenoise.info/spread_out.png http://wstaw.org/m/2017/02/23/plasma-desktopD17764.png http://wstaw.org/m/2017/02/23/plasma-desktopC17764.png http://wstaw.org/m/2017/02/23/plasma-desktopV17764.png http://neo900.linenoise.info/outlines.png

11:39 <enyc> I understand the fiddlyness, had lots of fun hacking things together myself, not in cad, just physical layouts/protos

11:39 <enyc> complex 3d tetris type thing ;p

11:40 <Joerg-Neo900> here we need to make sure e.g. pushbutton switches are exactly right distance from opposite side of case (which is where the PCB is held by case) so pushing down the button actually operates the switch

11:41 <enyc> is anybody lese using these new tools // made any protos with them?

11:41 <Joerg-Neo900> it's a matter of 0.1mm or less, between always-pressed and doesn't-work-at-all

11:41 <Joerg-Neo900> ~eeshow

11:41 <infobot> extra, extra, read all about it, eeshow is https://neo900.org/stuff/eeshow/ and https://neo900.org/git?p=eeshow;a=summary

11:41 <Joerg-Neo900> and google for fped

11:42 <Joerg-Neo900> fped is even 'in debian'

11:44 <enyc> I may be able to get the help of a dd to put eeshow in debian if this is of any use....

11:44 <enyc> ooh already in 'experimental'

11:44 <Joerg-Neo900> not for us, but other kicad-using EE will probably like it

11:45 <Joerg-Neo900> oh, didn't know

11:45 <enyc> -- W. Martin Borgert <debacle@debian.org> Sun, 06 Nov 2016 21:48:00 +0000

11:45 <Joerg-Neo900> anyway the kicad folks liked eeshow very much

11:46 <enyc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842211

11:47 <enyc> if you have reached something of a 'stable' point in eeshow (at least, not much changing at the moment), but fixed real issues since 20161102 version, may be worth contacting that maintainer and suggestiing it be updated for now...

11:49 <enyc> and ask if it can go into 'unstable' and then 'squeeze-backports' ...

11:50 <enyc> err stretch

11:50 <Joerg-Neo900> I don't know which changes since 20161102

11:51 <Joerg-Neo900> anyway it feels rather stable to me

11:51 <Joerg-Neo900> an extremely convenient tool

11:52 <Joerg-Neo900> I joked that we should sell it under brand name "Neo900 eeshow" ;-)

11:53 <Joerg-Neo900> in the domain it's made for (showing schematics and differences between schematics versions) it beats everything else I've seen so far, hands down

11:53 <enyc> gin suggestios werner commited many fixes in december

11:53 <Joerg-Neo900> possible, yes

11:54 <enyc> so ask the package maintainer to update, and ask about getting from experimental to unstable?

11:54 <Joerg-Neo900> http://paste.opensuse.org/22593094

11:55 <enyc> yes. are you using that updated version successfully?

11:57 <Joerg-Neo900> yes

11:57 <Joerg-Neo900> actually I guess all the updates were due to my bitching ;-)

11:57 <enyc> ok fine

11:58 <enyc> so thats enough to say in good faith to the DD W. Martin Borgert <debacle@debian.org> that this is now working, thank them for sponsoring eeshow into debian, can they update to latest fixed version, and let us know what will help to get it from 'experimental' into 'unstable' ?

11:58 <Joerg-Neo900> just one nasty caveat: -N n limit history to n revisions (unlimited if omitted or 0)

11:59 <Joerg-Neo900> yes

11:59 <Joerg-Neo900> (caveat) I'd really prefer that default to be maybe 50 instead of 'unlimited'

11:59 <enyc> Joerg-Neo900: so commit that change, then write to DD ?

12:00 <Joerg-Neo900> 'unlimited' causes my system to freeze from RAM starvation, on neo900 git

12:00 <Joerg-Neo900> please go ahead

12:02 <Joerg-Neo900> (caveat) IOW make sure you never run eeshow without explicit limit set by providing -N paramter

12:03 <Joerg-Neo900> in Neo900 DE we deal with that via make

12:04 <Joerg-Neo900> REVCOUNT ?= 30

12:04 <Joerg-Neo900> eeshow -N $(REVCOUNT) -d docdb.out neo900.pro

12:05 <Joerg-Neo900> werner didn't like the idea to change the default to e.g. 30 in eeshow, don't know why

13:21 <enyc> Joerg-Neo900: i'm not in the neo900 fit or otheriwse, i could later set this up, but might be better if somebody already in-the-system just put in the change and emailed the DD ?

14:50 <Joerg-Neo900> I have no clue about that stuff

14:56 <Joerg-Neo900> all I can say is http://paste.opensuse.org/69014659 just works

22:47 <ravelo> Joerg-Neo900, it looks like you are not worried about the problems Nikolaus had with gta04