#milkymist IRC log for Monday, 2011-08-29

--- Mon Aug 29 201100:00
kristianpaulhi00:19
wolfspraulaw: good morning!02:03
wolfspraulwpwrak and lekernel found a bug related to audio-in signal loss. We need to short L3 on all boards.02:03
wolfspraulor maybe remove L3?02:03
awwolfspraul, good morning02:03
wolfspraulaw: maybe we need to remove & short it, not leave & short02:03
wolfsprauldid we remove L19 ?02:04
awokay...I started to count 100 times on 0x7c board02:04
awof course 'removed & shorted' L19 in rc302:04
wolfspraulmaybe we also need to remove & short L3 then02:05
awactually no mount on L19, manually direct shorted L1902:05
wolfspraulyes I know02:05
wolfspraulI am not sure what's better - leave L3 on and just short around it, or remove L3 and short the pads02:05
wolfspraulmaybe removing is better?02:05
awsince two pads of L3 on top layer are adjacent routes, directly short on L3 0402 is suitable for personal use not good for outgoing purpose.02:12
wolfspraulso you think remove & short L3 is better?02:12
awthere's no close components surrounding L3 though. so yes, I'd remove L3 and short it by soldering.02:13
wolfspraulshould be ok02:14
aw0x7c: 9. reflashed with 'lockflash' version: http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/log/urjtag_lock_7C.log 10. rendering by powered-cycle 100 times and CRC tested pass: http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/7C-lock-results04:51
Action: xiangfu move the snapshots to 'http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/' and finished setup dailybuild, include milkymist-firmware and milkymist-openwrt04:54
xiangfunow try to finish 'reflash_m1.sh' for all those URL. updates. snapshot. rc3, lockflash etc.04:55
wolfspraulaw: ok great04:58
wolfspraulnext step: L3 fix on all avail-fix2b boards04:58
wolfspraulwpwrak: can you confirm that the idea is to remove & short L3? not solder around L3, right?04:58
awwpwrak, for short L3, will the loss of audio line-in show up while removing / reinserting stereo line-in cable? since i am going to rework few boards about L3 fix. After that fix, I need to test audio functions through test program. so what I need to watch out the err about L3?04:58
awBesides I need to confirm all audio functions are still good after L3 fix, i meant what else i have to be carefully watch while using test program? or I need to verify using GUI normally?05:01
awi'll go back to see backlog after lunch. ;-)05:03
xiangfuthe URL will be: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/05:03
wpwrakwolfspraul: i just soldered a 0R on top of L3 :) but how you short it shouldn't really matter05:04
wpwrakaw: the only audio function i used so far is input, to modulate visual effects05:05
wpwrakaw: what L3 does: if your external equipment has a mismatched ground potential, connecting audio (in and probably also out) can "crash" the audio codec or freeze the entire M105:07
wpwrakaw: with L3 shorted, this doesn't happen. if you don't see this kind of problem with the original L3, then the rework will have no observable effect for you05:08
wolfspraulwpwrak: but is it ok to _remove_ L3 and short the pads?05:15
wpwraksure. whatever shorts the pads :)05:16
wolfspraulok, that's what I thought but just confirming...05:17
awwpwrak, alright, seems that may not show up 'crash' in my test environment even I short L3.06:44
awwolfspraul, I'll directly go for those second round boards with fix2b patch, and test audio function again after short L3.06:46
wolfspraulwait06:46
wolfspraulaw: I don't think you need to try to reproduce the bug. the L3 bug is clearly understood and clearly fixed. there should be little risk in the shorting not working, so I don't think it's a big problem that you cannot test whether the bug is fixed.06:47
wolfspraulfor testing audio function again - sure if you like you can do it.06:48
wolfspraulmaybe better :-)06:48
wolfspraulthe important thing I want to do now is to take 30 boards, and apply L3 fix, test audio function, and then go through 10 render cycles on each one06:48
wolfsprauloh wait06:49
wolfspraulalso run the flash locking06:49
wolfspraulso it's like this:06:49
wolfspraul1. pick 30 boards from avail-fix2b group06:49
awwolfspraul, No, I don't try to reproduce that issue, I was trying to say/know what else I have to pay more attention after 'short' L3, now it's clear06:49
wolfspraul2. for each board:06:49
wolfspraul2.1. remove and short L306:49
wolfspraul2.2. run lock_only script to lock some flash partitions06:49
wolfspraul2.3. test audio function06:49
wolfspraul2.4. test 10 render cycles06:50
wolfspraul2.5. one final CRC test at the end06:50
wolfspraul3. done06:50
wolfspraul:-)06:50
wolfspraulwhat do you think?06:50
awokay06:52
wolfspraulbut I want to make sure that this lock_only.sh script really locks the flash06:53
awwolfspraul, i just created a 'Avail-fix2b with short L3: ' under http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Test_Results06:53
wolfspraulmaybe it's safer to run the entire reflash_m1.sh again?06:53
wolfspraulit just takes about 1 minute I think06:53
wolfspraulmaybe safer?06:53
awyou don't worry this, since the log will be auto recorded under my folder then i'll upload them. ;-)06:53
wolfspraulok06:54
wolfspraulso if we do this plan above, that's a total of 30*10 = 300 render cycles06:54
wolfspraultogether with the 200 before (100 on 4C, 100 on 7C), that's a total of 500 cycles on boards with locked flash06:54
wolfspraulif those 500 all pass without crc corruption, we know for sure that the locking fixed the crc problem06:54
awyes, so I'll pick them from 0x30 to accumulate a total 30 pcs boards.06:54
wolfspraulif there is a crc problem somewhere, even though locking, oh well :-)06:55
wolfspraulthen we think about it then :-) not now..06:55
wolfspraulnow we just hope to BE LUCKY! :-)06:55
awand also recorded in the note as well as wiki that catagory, so that we know how they are moving.06:55
wolfspraulsure record everything06:55
awyup;-)06:55
wolfspraulaw: is the plan clear?06:55
awalright...time to do now. surely clear . ;-)06:56
wolfspraulwait06:56
wolfspraulone more thing06:56
wolfspraulwe have pretty nice packing instructions already06:56
awoah...great.06:56
wolfspraulhttp://en.qi-hardware.com/wiki/Milkymist_One_accessories#packing_instructions06:56
wolfspraulsome things about case assembly still missing, and some other details. but it's a great start.06:56
awsure. it was great! must be done by Yi. ;-)06:57
awI'll surely see them after our first 30pcs coming. ;-)06:57
awcool though. ;-)06:58
lekernelwolfspraul, nice package! good job :)08:21
xiangfuyes. nice package.08:41
GitHub78[scripts] xiangfu pushed 1 new commit to master: http://git.io/X0QGxA08:54
GitHub78[scripts/master] reflash_m1.sh: add --release --snapshot - Xiangfu Liu08:54
wolfspraulthanks! [package comments] a lot of work indeed...09:11
wolfspraulhope we are smart and lucky on marketing too :-)09:11
wolfspraulwe can think ahead a little for Adam. if his 30*10 render cycles all pass, we are definitely ready.09:11
wolfspraulassembly -> packing -> sales09:11
wolfspraulbut waht if not? what if one board shows another crc problem even after locking the partitions?09:11
wolfspraulwe are slowly moving to the point that Sebastien already mentioned where we will just handle those cases one-by-one via support09:12
wolfspraulso probably we will look at that board a little, try to find a reason for the crc problem. but then there's a good chance we will just start sales.09:12
wolfspraulunless we are lucky and find an easy to fix root cause... which we will give a shot but not an overly excessive study time.09:13
wolfspraulthat's roughly my thinking09:13
GitHub76[scripts] xiangfu pushed 1 new commit to master: http://git.io/RghGdA09:16
GitHub76[scripts/master] reflash_m1.sh merge lockflash - Xiangfu Liu09:16
wolfspraulxiangfu: ah nice - all move into one script - great!09:21
GitHub198[scripts] xiangfu pushed 1 new commit to master: http://git.io/M1k_wg09:33
GitHub198[scripts/master] reflash_m1.sh merge read_flash - Xiangfu Liu09:33
xiangfuwolfspraul, yes. still two needs merged.09:33
wpwrakwolfspraul: yeah, i'd keep all the boards that had a history of NOR problems - except the single-word corruption - or "pulses" back for now, but go ahead with those that look healthy for now.12:17
wpwrakwolfspraul: it could still be that NOR corruption cannot be fixed by locking or a later field upgrade, but then that would mean major rework anyway. and i'm not sure you want to go into this with rc3. so worst case - i.e., if my down ramp theory is correct AND the address affected can be anywhwere - would be that rc3 is just unreliable when powering down.12:19
wpwrakwolfspraul: i consider it good news that no previously "available" boards joined the "cluster" of unreliable booting in the fix2b testing12:20
wpwrakwolfspraul: (NOR corruption) of course, if you want to be sure no such unreliability exists, then you have to delay until more testing is done. i.e., we don't know yet when exactly the thing happens, what causes it, what the pattern of affected addresses is, and how we can make it stop for good.12:22
wpwrak(packaging instructions) that's basically a checklist for adam ? (with or without someone else assisting him)12:24
wpwrak(packaging) the U-shaped divider that goes on top of the power supplies and various other accessories is probably a little messy to place, with so many things floating around underneath. maybe make it a full roll (i.e., O-shaped from the side, doesn't need to be a box with side walls, though) in the future12:27
wpwrak(packaging) the aesthetics of the package look nice (interior and exterior)12:28
lekernelwolfspraul, btw, do you want to ship the JTAG pod attached to the M1 PCB, or separately?13:56
lekernelimo it's better to separate it, because it may otherwise fall because of shocks etc.13:56
lekernelif there is some space remaining among the cables ... :)13:57
GitHub37[scripts] xiangfu pushed 2 new commits to master: http://git.io/7fo0xg14:14
GitHub37[scripts/master] reflash_m1.sh merge reflash_m1_rc3.sh - Xiangfu Liu14:14
GitHub37[scripts/master] reflash_m1.sh meger reflash_mac_bios.sh - Xiangfu Liu14:14
wpwraklekernel: yeah, i think shipping it attached would just ask for trouble14:17
wolfspraulI definitely think the jtag-serial should be seated on the pcb. I cannot see at all how it can become loose, those 2 connectors are super strong.14:55
wpwraknaw, why take the risk ? if someone wants to use jtag, they have to open the M1 anyway. that's already few enough people who will be eager to do this15:14
wpwrakwolfspraul: and regarding connectors not coming loose, didn't people have their wlan module come off in freerunners ? that's even more impossible ;-))15:17
wolfsprauldo you know how tough that little thing sits there?15:21
wolfspraulI seriously cannot imagine any better place than right there. Come off? It sounds like a total phantasy to me, really.15:22
wolfspraulyou would need vibrations and shock far harder than the acrylic case could ever withstand :-)15:22
wolfspraulyes, to use them people need to open the case, of course15:22
wolfspraulbut ship separately? risk is 0%, so the additional hassle of a separate pod is not worth it, imho15:23
wolfspraulI will shake my m1 a little tomorrow to test this :-)15:23
wolfspraulbut this idea sounds really really far fetched to me...15:23
wolfspraulthe 2 connectors are crazy strong15:23
wolfspraulalas, I heard the argument clearly, so I shall test a little tomorrow :-)15:26
wpwrakyou do't need strong vibrations :) they just have to be continuous. add a slight pulling force, e.g., the M1 laying upside down and mother nature has she needs to give her son murphy a helping hand :)15:28
kristianpaulI had seen those vibration cases with CFs..15:34
wolfspraulkristianpaul: hey there! :-)15:34
kristianpaulhey :)15:34
wolfsprauldo you know there is another hardware fix you can apply to your m1?15:34
wolfspraulyou can remove & short L315:35
kristianpaulL3 ?15:35
wolfspraulyes15:35
wolfspraulsimilar to L1915:35
wolfspraulL19 fixed the problem of camera signal loss15:35
wolfspraulbut on the first day of receiving his m1, Werner found a similar problem, even more severe, with signal loss on line-in15:35
wolfspraulwhen unplugging and replugging cables. even hang the m1.15:35
kristianpaulbut i dont have wolfson chip15:35
wolfspraulremoving and shorting L3 fixes this bug15:35
kristianpaulor is this know from rc2 as well?15:35
wolfspraulah, good point15:35
wolfspraulI don't know :-)15:36
wolfspraulI don't think we changed much from National to Wolfson, but you are right I'm not sure whether the L3 effect and fix is the same on rc215:36
kristianpauli havent time to check all logs just bacj from mountain yday, but as i need to solder some broken wires for my laptop PSU i:l do L19 and verify L3 on my board15:37
wpwrakkristianpaul: if you have an L3, then it will probably be susceptible to such problems, too, no matter what the codec is. no codec in its right mind can being whacked on its head by ground :)15:37
kristianpaulokay15:37
kristianpaulare you going to short all the L** too ?;-)15:37
wolfsprauloh sure it's up to you15:37
wolfspraulbut you can probably safely remove and short L19 and L3, and improve your m1 :-)15:38
kristianpaulsure i like the idea15:38
wolfspraulany namuru news?15:38
kristianpaulno, i havent coded the logging for the tracking loop wich i need to move forward15:39
kristianpaullogging for gnuplot15:43
wolfspraulah ok, good15:43
wpwrak(short and remove) or just short, without removing22:22
wpwrakin fact, a tiny bit of resistance may be beneficial, so that the thing can act as a fuse in case there's a LOT of current rushing through it :) (not that it should, but ...)22:29
kristianpaulsure wpwrak i'm not planing to remove22:38
--- Tue Aug 30 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!