00:01 <GitHub130> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/_ujjeQ

00:01 <GitHub130> [flickernoise/master] ptest: default to relative path for MMDIR - Sebastien Bourdeauducq

00:02 <wpwrak> massively parallel patching :)

00:12 <lekernel> and thanks for the patches. did you find something?

00:14 <wpwrak> no, nothing new. everything works here :)

00:15 <wpwrak> when you do a "make test" under src/compiler/, or even "make valgrind", does it pass ? there should be a total of 125 tests

00:16 <lekernel> patch: Unchained - A Matter Of Taste (Remix).fnp: FAILED (patches)

00:16 <lekernel> failed to add equation to per-vertex footer: FPVM, line 57: Failed to allocate renamed register for variable

00:17 <wpwrak> excellent ! so it's not just lm32 :)

00:20 <wpwrak> is this the same fpvm.c you have ? http://downloads.qi-hardware.com/people/werner/tmp/fpvm.c

00:21 <wpwrak> and was that "make test" or "make valgrind" ?

00:21 <lekernel> and make valgrind shows something too

00:22 <lekernel> http://pastebin.com/r979kxzC

00:22 <lekernel> that bug should soon be dead :)

00:28 <wpwrak> does your infra-fnp.h look like this ? http://downloads.qi-hardware.com/people/werner/tmp/infra-fnp.h

00:30 <lekernel> yes, exact same

00:31 <wpwrak> what does lemon -x say ? mine is Lemon version 1.0

00:32 <wpwrak> and re2c -v -> re2c 0.13.5

00:33 <lekernel> same

00:35 <wpwrak> hmm. the error is at the last line. this may try to tell us something ...

00:41 <wpwrak> FPVM_MAXERRLEN is to small for the entire error message. that's why it gets truncated. doesn't necessarily mean the variable name is bad

04:05 <cladamw> ( M1rc3 yield = 88 / 90)

05:42 <GitHub65> [scripts] xiangfu pushed 1 new commit to master: http://git.io/MVuDmg

05:42 <GitHub65> [scripts/master] remove the .git folder extension - Xiangfu Liu

06:13 <GitHub58> [scripts] xiangfu pushed 2 new commits to master: http://git.io/OHb1Eg

06:13 <GitHub58> [scripts/master] compile-milkymist-firmware.sh: cleanup the .git exitention - Xiangfu Liu

06:13 <GitHub58> [scripts/master] compile-flickernoise: using relative paths, 80 rule cleanup - Xiangfu Liu

06:21 <GitHub122> [scripts] xiangfu pushed 1 new commit to master: http://git.io/NsDVQw

06:21 <GitHub122> [scripts/master] compile-lm32-rtems: 80 rule cleanup - Xiangfu Liu

06:33 <wpwrak> xiangfu: i was quicker ;-)

06:38 <xiangfu> wpwrak, yes. :D

06:47 <xiangfu> wpwrak, ok. then I try to work on rtems-yaffs2. :D

06:51 <GitHub1> [rtems-yaffs2] xiangfu pushed 3 new commits to master: https://github.com/milkymist/rtems-yaffs2/compare/07a447d...9f52f45

06:51 <GitHub1> [rtems-yaffs2/master] Merge branch 'upstream' - Xiangfu Liu

06:51 <GitHub1> [rtems-yaffs2/master] fix the redefined warning - Xiangfu Liu

06:51 <GitHub1> [rtems-yaffs2/master] remove hardcode app name for nor-mkyaffs2image - Xiangfu Liu

08:11 <cladamw> ( ultrasonic cleaner) yesterday went to Victory Source Industrial Corp. SMT manufacturer to discuss with their experience.

08:14 <cladamw> 1. they also rarely use ultrasonic cleaner, since they don't like to rework the parts (switches, quartz) after ultrasonic.

08:17 <cladamw> 2. i brought 0x67/0x6d and discuss firstly their histories, and they thought it's original temperature settings on pcb pads didn't meet profile while smt reflowing at the beginning. I told that it could be that. Since I survived few boards after I used heat air.

08:19 <cladamw> 3. so they didn't suggest me to do ultrasonic clean, but i still did one (0x6d). And still can't be bootup though

08:22 <cladamw> 4. the picture and video about ultrasonic clean I requested them to take is still waiting them to send me, they don't want me to see more thought while i was waiting there. I hoped they will send me video & pic. not purely openness.

08:25 <cladamw> 5. so far I may request minbo to do remount fpga chip again with those two boards, but not now. So I'll send a report about rc3 firstly.

08:26 <cladamw> 6. current yield is 88/90. not 100%. :(

08:56 <wpwrak> cladamw: interesting. what else do they use to clean the boards then ?

09:01 <mumptai> water + iso + optionally a bit "soap" and that at raised temperatures and possibly ultrasonics

09:02 <cladamw> wpwrak, that Victory they said that usually tried to set parameters well while pre-process tasks doing. (i.e. 1. control the smt reflow machine temp. as good as possible, 2. to reduce reworks as possible, 3. to use high volatility cleaner as possible but few times to clean since such cleaner will erode the protection of flux from soldering. etc.)

09:03 <cladamw> wpwrak, from i saw their ultrasonic cleaner was took from like storehouse, and long time no use though.

09:05 <cladamw> so this fact from here factories (Minbo and Victory), they rarely not use ultrasonic but still can't imagine how they clean reworked boards.

09:07 <mumptai> some components don't take ultrasonics well

09:07 <cladamw> seems that they both don't want to face the other failures and to do extra-reworks caused by ultrasonic. But for diy, you can.

09:07 <cladamw> mumptai, yeah

09:08 <mumptai> without you more or less soak it in some cleaning liquid for a long time

09:09 <cladamw> so I doubted Victory and Minbo both now. Even they used high-volatility liquid to clean their boards.

09:10 <cladamw> I could only now seems that get like manufacturer official 'talking'. :(

09:11 <cladamw> there's one fact that 'few' boards from me I heated fpga then pass all function.

09:11 <mumptai> sounds like a bad ball

09:12 <cladamw> So I very doubted that temperature measuring was bad while smt reflow

09:12 <mumptai> could also be a crack in the pcb

09:13 <mumptai> or the bga-package

09:13 <cladamw> mumptai, there's one 0x74 I took back to let minbo to do remount fpga, then all functions still work even this board doesn't bad/worse histories like nor-corruption.

09:16 <mumptai> have you tried pressing on or flexing the bga/pcb of the "damaged" units?

09:16 <cladamw> mumptai, well...from 88 / 90 pass ratio, it seems could not be crack in pcb, I would be guessed that those two was the victims from varied/shifted temperature heating in reflow machine. even this is also rarely. so far I've not booted Minbo to remount. so don't know yet.

09:17 <cladamw> mumptai, i tried to press by hand. not in success. :-) Imagine that it's 488 balls. the force from balls are quite the same/balance I think.

09:18 <cladamw> so if there's one ball with cool soldering under fpga, pressing fpga chip probably don't have effect. :-)

09:19 <cladamw> sorry. it's 484 balls.

09:20 <mumptai> i once had such a board, re-reflowing helped, but we replaced it as soon as possible

09:25 <cladamw> regarding to if "flexing" bga chip while reworks? we guessed it could be. But from 88 / 90 ratio is pass, it seems not. Even we knew reworker used a small size heat blower (rework station) to blow the corner of fpga chip. (i.e. the area of 'reset' circuit), but they blew the whole batch of 89 pcs though. if the effect of flexing was happened, the yield ratio probably can't be 88/99.

09:27 <mumptai> dunno, actually its a mature technology, it takes some abuse to break it ;)

09:27 <mumptai> you might want to have a x-ray done

09:59 <wpwrak> (cleaning) interesting. i think the standard process for "water soluble" flux is some sort of "dishwasher". without ultrasound, but hot water under pressure.

10:00 <wpwrak> what's trickier is "no clean" flux. supposedly, it should just evaporate. alas, what's left behind can still cause trouble. i've had that with atusb, too. there, flux resistance made the reset signal rise very slowly and the whole system got out of sync.

10:12 <cladamw> that could explain the fact that "no clean" flux supposedly. If factory or EMS they really don't do that, would this be interesting that consumer product goes freakish after long time? I didn't pay more attentions on "water soluble" while stayed at factory.

10:36 <wpwrak> flux residues can cause all sorts of fun. if you have salts (= residues) lying around, a bit of humidity can turn them into conductors. what happens then, well ... :)