<Joerg-Neo900>
pondering how to tackle that problem, of course this needs a solution in one way or another
<Joerg-Neo900>
discussion solicited
<Joerg-Neo900>
two ideas to solve on a technical basis: *) use ultra-low melting point solder paste to solder the RAM-PoP on top of the mounted OMAP *) use a distance ring PCB of maybe 0.2mm thickness between OMAP and RAM
<Joerg-Neo900>
alternatives: use another make but compatible in specs SoC. Find expertise from those who built devices with that chip combo, particularly N9 fab engineers. Find a sponsor who either finances or does the needed test runs. Scale up the project by a factor 10 or 20 to a batch volume target of 5000 or more, so we can afford test runs - needs funding, or a bigger company to take over
<jonwil>
Replacing the SoC with something that isn't an OMAP might make it harder to achieve the goal of being able to run the N900 stack on the thing. Then again I dont know if that is still a goal or not (FPTF has basically died off as far as I can see)
<Joerg-Neo900>
FPTF is a means to _not_ be bound to OMAP in the long tun
<Joerg-Neo900>
run*
<Joerg-Neo900>
for now N900 compatibility is the key project goal
<enyc>
=)
<jonwil>
Thinking about it some more, as long as the instruction set and stuff (i.e. the bits that a userspace app not related to the hardware in the device such as rtcom-call-ui or would actually
<Joerg-Neo900>
OTOH it seems FPTF makes some progress recently since freemangordon is porting maemo to a tablet and enyc and Wizzup and others are involved in 'rebasing maemo on devuan'
<Joerg-Neo900>
jonwil: yep
<jonwil>
There are 2 different goals here
<Joerg-Neo900>
I think we could deal with a few slightly different interfaces, as long as they are still of needed functionality and the IS is same
<jonwil>
Goal 1 is being able to run all the open source bits (that aren't somehow hardware specific to the N900) on some random device (and doing more work to clone the closed source bits that are needed to make that happen e.g. the work on the bookmark code)
<Joerg-Neo900>
actually a chip supporting same Instruction Set and same DSP but a different more friendly graphics engine would possibly be a win
<jonwil>
The DSP is a TI architecture so only a TI chip would have that
<bencoh>
assuming there is such a thing ... which I highly doubt
<bencoh>
all omap chips use powervr
<bencoh>
(unless they don't have any gpu at all)
<jonwil>
But that said, the DSP doesn't really matter since its only used for media decoding and if the new chip had either its own media decoding DSP or an alternative way to decode media we could slot that in place of the things that currently talk to the TI DSP
<Joerg-Neo900>
jonwil: yep, prolly. So we lose the acceleration from it, can't tell for sure what that would be in particular, prolly something audio related for sure
<bencoh>
jonwil: if you're really going that way you could already throw the whole "compability" stuff away
<Joerg-Neo900>
and ack to your last post
<bencoh>
which basically means half of the time of this project
<Joerg-Neo900>
bencoh: hmm, nope, not really. it's pretty well defined limited battlefield. MOMPLS
<Joerg-Neo900>
I *think* it's worth pondering if either of my above listed ideas (low-temp solderpaste, distance ring) could help fix that problem
ecloud has quit [Ping timeout: 260 seconds]
<Joerg-Neo900>
instead of low-temp solderpaste, even glue or sticky tape *might* be an alternative
<jonwil>
IMO any replacement CPU (if we need one) needs to be 100% ABI and instruction set compatible with the OMAP 3430 in the N900, it needs to be fully documented and open, it needs to not be running any code that the user can't control (e.g. no WiFi or BT radio with closed-source firmware as part of the SoC) and it needs full X11 linux drivers for its GPU that can work with the software versions...
<jonwil>
...we need it to work with (either 100% complete FOSS drivers or closed-source blobs)
<jonwil>
The ultimate goal (or one of them anyway) for the Neo900 project is to be able to run a full Fremantle software stack with only those pieces that need changing or porting because of different hardware in the new phone being changed/ported (and cloned first if need be)
<Joerg-Neo900>
yes
<Joerg-Neo900>
absolutely
<Joerg-Neo900>
none of the other OS alternatives for a linux phone so far seem to satisfy the reliability and quality requirements
ecloud has joined #neo900
<bencoh>
15:01 <+Joerg-Neo900> seems it's all inside gstreamer
<bencoh>
Joerg-Neo900: nope, gstdsp does not use openmax
<Joerg-Neo900>
e.g Nikoluas on GTA04 still uses suspend2ram and nevertheless has >30mA idle consumption, which is waaay too much. Not even to start with response times to events and audio etc
<bencoh>
and I didn't say switching SoC wouldn't be doable for this project
<Joerg-Neo900>
bencoh: yes, sure. Sorry didn't imply that
<bencoh>
I'm only saying that you've spent so much time on things that were needed only because you didn't want to switch SoC, that it would just sound crazy as of now
<Joerg-Neo900>
yes, absolutely
<bencoh>
and actually the only fact that you're now considering it when it was completely out of the question for legacy reasons back then sounds ... :/
<Joerg-Neo900>
I'm *very* reluctant to go that route (not even starting to think about mere feasibility regarding the project plans)
<bencoh>
30mA with s2ram sounds huge to me, btw
<Joerg-Neo900>
I'm not pondering it, I just listed it
<Joerg-Neo900>
yes, it is
<bencoh>
n900 can go below 30mW in idle, so ...
<Joerg-Neo900>
also what I listed regarding SoC change was a compatible SoC
jake42_ has joined #neo900
ravelo_ has joined #neo900
<jake42_>
suspend current for the gta04a4 is below 30mA (usually 17 to 20mA)
<bencoh>
jake42_: lurking when not even online is the worst kind of lurking ever :D
<bencoh>
but, err ... is that mW or mA
<jake42_>
mA
<bencoh>
because in n900's case I'm really talking about 30mW
<jonwil>
That goal includes running unmodified versions of closed source packages like telepathy-ring, libconnui, osso-wlan-security, rtcom-call-ui and tablet-browser-ui
<bencoh>
30mA is *really* huge
<jake42_>
joerg was talking mA
<bencoh>
well then there's another factor
ravelo has quit [Ping timeout: 255 seconds]
<jake42_>
but there are fixes in the recent revision a5, which should (!) solve it
<bencoh>
I wonder if you don't have a pad configuration issue there then
<bencoh>
pullup that are forced to ground when chip is suspended for instance
chomwitt has joined #neo900
<bencoh>
or just no real suspend support for the soc
<Joerg-Neo900>
> The GTA04A5 seems to be able to reach <30mA in suspend to RAM which is
<Joerg-Neo900>
> ca. 100mW. This gives only 40 hours of standby time which is still
<Joerg-Neo900>
> less than other devices (which have up to 100 or 400 hours).
<bencoh>
arm core should be in dormant mode in suspend, so arm current should be pretty insignificant, which means that either soc (or internal soc controllers/peripherals) or external devices are still powered
<jake42_>
Joerg-Neo900: do you have a source for that?
<bencoh>
(this is actually not that uncommon, and occured to us here)
<jake42_>
thx
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.46/20161213183751]]
<jake42_>
IIRC there have been changes to be able to turn of the clock/xo while in suspend from a4->a5
<Joerg-Neo900>
actually I think http://www.ti.com/lit/an/swpa182c/swpa182c.pdf#19 incl applying glue to fix the RAM PoP to OMAP die is the process with the least variables with potential to introduce failure due to warping
<Joerg-Neo900>
jake42_: that would be mandatory for decent idle consumption
<jake42_>
right, thats orthogonal to any possible production problems causing leak current
<jake42_>
Joerg-Neo900: but apart from any production problems, the suspend current should be better in a5
<Joerg-Neo900>
indeed orthogonal
<Joerg-Neo900>
it's actually also orthogonal to the OS quality I started with
<bencoh>
when I said something was possibly shorted to ground, I didn't necessarily mean during production process
<bencoh>
it could be a badly configured pullup
<bencoh>
that will just draw current when powering down part of the soc
<bencoh>
(again, this occured to us, not just once)
<bencoh>
(us == $job)
<Joerg-Neo900>
bencoh: yep, we had a few of those in OpenMoko
<Joerg-Neo900>
(OM = GTA01/2)
<bencoh>
and turning clocks off would definitely be a good start if they're not turned off already
<Joerg-Neo900>
you need a XO that allows control, and you need a line doing that control, from SoC to XO
<bencoh>
I wonder how much current those gta04 draws in idle
<bencoh>
Joerg-Neo900: actually XO current might not be the most significant one here
<bencoh>
some chips can reduce overall power consumption just by gating clock from XO
<jake42_>
bencoh: this a4 here draws some 300mA with display on ~80% (mesaured with the columbcounter in battery)
<jake42_>
(on qtmoko v56)
<Joerg-Neo900>
alas that's not very informative since display backlight is hugest consumer
<jake42_>
yes, also current frequency would be needed
<jake42_>
gtg
<jake42_>
cya
jake42_ has quit [Quit: Page closed]
<Joerg-Neo900>
and iirc even video bus eats quite a lot, interestingly depending on whether you have all black or all white display content, since the levels on data lines and thus the power consumption vary by that
<Joerg-Neo900>
(a big) IIRC the difference between black and white was ~20mA, with no backlight at all. Unclear if it's consumed by video bus or by LCD itself driving the cells black
<Joerg-Neo900>
anyway back when (8 years ago?) I calculated that it's in line with the video bus lines getting pulled low against a pullup of known size
<bencoh>
well, idling n900 with backlight on (and backlight level at 4/5) actually eats roughly 130mA so ...
<Joerg-Neo900>
we might try other approaches as well (special ultra-low temperature solder paste or cold joints; distance ring)
* Joerg-Neo900
idly mentions that Vapor Phase as used in GTA04 doesn't inherently provide any sane preheat phase in thermal profile. The heatup is pretty harsh and instant
<Joerg-Neo900>
which easily can acerbate warping since the die is heating up slower than the thin PCB ring
<Joerg-Neo900>
s/acerbate/aggravate/
<Joerg-Neo900>
anyway, again: I *think* presoldering OMAP to (rigid) RAM PoP and then applying underfill between the BGA balls so the SoC PCB is glued to RAM PoP will create a non-warping compound
<Joerg-Neo900>
maybe presoldering is sufficient even without underfill
<timclassic>
Ah thanks. I also found the first message on the thread which cleared things up a bit too.
<Joerg-Neo900>
but underfill would fix the distance between OMAP PCB and PoP, so when the OMAP die is glued to PoP then no way the OMAP PCB could warp upward during mounting / reflowing of the stack to main PCB
<Joerg-Neo900>
duh, this gave me headache
<Joerg-Neo900>
literally
<Joerg-Neo900>
bbl
arcean has quit [Ping timeout: 246 seconds]
galiven__ has joined #neo900
galiven_ has quit [Ping timeout: 264 seconds]
xmn has quit [Quit: Leaving.]
<Joerg-Neo900>
one thing we'll definitely want to do: have special cheap evaluation PCB (possibly only 2-layer) with only several OMAP footprints on them, to test POP soldering with different solder profiles and techniques (like above mentioned pre-assembly with glue and underfill), to minimize expense on dead final products from soldering failures on PoP stack
<Joerg-Neo900>
still costs us a OMAP chup and a PoP RAM chip per test, plus a few bucks for the PCB, but way more affordable than a two thirds of failed NeoN boards
<Joerg-Neo900>
chip even
paulk-blaze has joined #neo900
<enyc>
Joerg-Neo900: what routes do you have to find enigneers who had exprienc ewith the issue / solutions ?
<Joerg-Neo900>
nothing specific yet, probably contacting a few friends from Maemo/Nokia and asking them if they know somebody
<enyc>
i know revk/aaisp used to work in nokia ages ago iirc
<enyc>
but may not be ehlpfulc for 'now'
<enyc>
if i have a clear question summarized (or link to page with spec of issue) i can try to ask
<Joerg-Neo900>
the question is: "do you recall any details of the reflow procedure used to solder the OMAP3630+TAM PoP stack in N9?"
<enyc>
because... yeild issues etc etc now
<Joerg-Neo900>
s/TAM/RAM/
<Joerg-Neo900>
if you need because then that's "because we need to avoid warp issue"
<ravelo>
>> I just wonder if it is possible to use a foil with micro gold pearls an
<ravelo>
>> glue the chip only in stat soldering.
frf has joined #neo900
frf has quit [Quit: Page closed]
louisdk has joined #neo900
<ravelo>
I just contacted a former Nokia Hardware manager about the soldering issue
<ravelo>
let's see if he can help us
chomwitt has joined #neo900
illwieckz has quit [Ping timeout: 260 seconds]
illwieckz has joined #neo900
illwieckz has joined #neo900
illwieckz has quit [Changing host]
chomwitt has quit [Quit: WeeChat 1.0.1]
illwieckz has quit [Quit: Ça va couper chérie…]
illwieckz has joined #neo900
illwieckz has quit [Changing host]
illwieckz has joined #neo900
illwieckz has quit [Ping timeout: 240 seconds]
illwieckz has joined #neo900
<Joerg-Neo900>
((foil with micro gold pearls)) haven't seen that, but it sounds pretty much exactly like the anisotropic conductive sticky tape I mentioned before. Did I?
<Joerg-Neo900>
then there's also conductive viscose glue liquid
<Joerg-Neo900>
which might be even better than the sticky tape since the latter needs a constant pressure by a clamp or whatever
<Joerg-Neo900>
but again, I think pre-assembling the PoP stack is the key
<Joerg-Neo900>
it is absolutely plausible and obvious
<Joerg-Neo900>
and when even TI mentions it in their application note, despite the added workload fromn doing such pre-assembly, it must have some advantages that make it worthwhile doing it nevertheless
<Joerg-Neo900>
for me it seems obvious that the flimsy thin PCB of OMAP gets supported by the rigid RAM PoP so it can't warp anymore
xmn has joined #neo900
<Joerg-Neo900>
particularly when you use cyanoacrylate underfill after pre-assembly so the OMAP<->PoP joints are immutable and enforced
<Joerg-Neo900>
I'm pretty eager to give it a try
<Joerg-Neo900>
one of the challenges with this approach is: you basically need a OMAP ZIF socket to test the soldered stack before you apply the underfill, since after you applied that you could only 'fix' anything with a sledgehammer
<Joerg-Neo900>
no biggie, those sockets exist and are available for a few 100 bucks
* enyc
thinks... superglue
<Joerg-Neo900>
both the underfill and the conductive glue are "superglue" cyanoacrylate variants
<Joerg-Neo900>
underfill is particularly low viscosity, while the cinductive stuff is high viscosity with a high percentage of silver pearls
<ravelo>
I don't quite have a clue about this but it sounds nice
<Joerg-Neo900>
:-)
<Joerg-Neo900>
for underfill the question is how to apply it without spilling on the bottom BGA. I suspect wick (thin cotton whatever string) or razorblade application might be a thing
<Joerg-Neo900>
for conductive glue keep in mind that we can't glue to solderballs that get reflowed afterwords - glue doesn't stick to liquid solder