<kristianpaul> hi
<wolfspraul> aw: good morning!
<wolfspraul> wpwrak and lekernel found a bug related to audio-in signal loss. We need to short L3 on all boards.
<wolfspraul> or maybe remove L3?
<aw> wolfspraul, good morning
<wolfspraul> aw: maybe we need to remove & short it, not leave & short
<wolfspraul> did we remove L19 ?
<aw> okay...I started to count 100 times on 0x7c board
<aw> of course 'removed & shorted' L19 in rc3
<wolfspraul> maybe we also need to remove & short L3 then
<aw> actually no mount on L19, manually direct shorted L19
<wolfspraul> yes I know
<wolfspraul> I am not sure what's better - leave L3 on and just short around it, or remove L3 and short the pads
<wolfspraul> maybe removing is better?
<aw> since 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.
<wolfspraul> so you think remove & short L3 is better?
<aw> there's no close components surrounding L3 though. so yes, I'd remove L3 and short it by soldering.
<wolfspraul> should be ok
<xiangfu> move the snapshots to 'http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/' and finished setup dailybuild, include milkymist-firmware and milkymist-openwrt
<xiangfu> now try to finish 'reflash_m1.sh' for all those URL. updates. snapshot. rc3, lockflash etc.
<wolfspraul> aw: ok great
<wolfspraul> next step: L3 fix on all avail-fix2b boards
<wolfspraul> wpwrak: can you confirm that the idea is to remove & short L3? not solder around L3, right?
<aw> wpwrak, 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?
<aw> Besides 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?
<aw> i'll go back to see backlog after lunch. ;-)
<wpwrak> wolfspraul: i just soldered a 0R on top of L3 :) but how you short it shouldn't really matter
<wpwrak> aw: the only audio function i used so far is input, to modulate visual effects
<wpwrak> aw: 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 M1
<wpwrak> aw: 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 you
<wolfspraul> wpwrak: but is it ok to _remove_ L3 and short the pads?
<wpwrak> sure. whatever shorts the pads :)
<wolfspraul> ok, that's what I thought but just confirming...
<aw> wpwrak, alright, seems that may not show up 'crash' in my test environment even I short L3.
<aw> wolfspraul, I'll directly go for those second round boards with fix2b patch, and test audio function again after short L3.
<wolfspraul> wait
<wolfspraul> aw: 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.
<wolfspraul> for testing audio function again - sure if you like you can do it.
<wolfspraul> maybe better :-)
<wolfspraul> the 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 one
<wolfspraul> oh wait
<wolfspraul> also run the flash locking
<wolfspraul> so it's like this:
<wolfspraul> 1. pick 30 boards from avail-fix2b group
<aw> wolfspraul, 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 clear
<wolfspraul> 2. for each board:
<wolfspraul> 2.1. remove and short L3
<wolfspraul> 2.2. run lock_only script to lock some flash partitions
<wolfspraul> 2.3. test audio function
<wolfspraul> 2.4. test 10 render cycles
<wolfspraul> 2.5. one final CRC test at the end
<wolfspraul> 3. done
<wolfspraul> :-)
<wolfspraul> what do you think?
<aw> okay
<wolfspraul> but I want to make sure that this lock_only.sh script really locks the flash
<aw> wolfspraul, i just created a 'Avail-fix2b with short L3: ' under http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Test_Results
<wolfspraul> maybe it's safer to run the entire reflash_m1.sh again?
<wolfspraul> it just takes about 1 minute I think
<wolfspraul> maybe safer?
<aw> you don't worry this, since the log will be auto recorded under my folder then i'll upload them. ;-)
<wolfspraul> ok
<wolfspraul> so if we do this plan above, that's a total of 30*10 = 300 render cycles
<wolfspraul> together with the 200 before (100 on 4C, 100 on 7C), that's a total of 500 cycles on boards with locked flash
<wolfspraul> if those 500 all pass without crc corruption, we know for sure that the locking fixed the crc problem
<aw> yes, so I'll pick them from 0x30 to accumulate a total 30 pcs boards.
<wolfspraul> if there is a crc problem somewhere, even though locking, oh well :-)
<wolfspraul> then we think about it then :-) not now..
<wolfspraul> now we just hope to BE LUCKY! :-)
<aw> and also recorded in the note as well as wiki that catagory, so that we know how they are moving.
<wolfspraul> sure record everything
<aw> yup;-)
<wolfspraul> aw: is the plan clear?
<aw> alright...time to do now. surely clear . ;-)
<wolfspraul> wait
<wolfspraul> one more thing
<wolfspraul> we have pretty nice packing instructions already
<aw> oah...great.
<wolfspraul> some things about case assembly still missing, and some other details. but it's a great start.
<aw> sure. it was great! must be done by Yi. ;-)
<aw> I'll surely see them after our first 30pcs coming. ;-)
<aw> cool though. ;-)
<lekernel> wolfspraul, nice package! good job :)
<xiangfu> yes. nice package.
<GitHub78> [scripts] xiangfu pushed 1 new commit to master: http://git.io/X0QGxA
<GitHub78> [scripts/master] reflash_m1.sh: add --release --snapshot - Xiangfu Liu
<wolfspraul> thanks! [package comments] a lot of work indeed...
<wolfspraul> hope we are smart and lucky on marketing too :-)
<wolfspraul> we can think ahead a little for Adam. if his 30*10 render cycles all pass, we are definitely ready.
<wolfspraul> assembly -> packing -> sales
<wolfspraul> but waht if not? what if one board shows another crc problem even after locking the partitions?
<wolfspraul> we are slowly moving to the point that Sebastien already mentioned where we will just handle those cases one-by-one via support
<wolfspraul> so 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.
<wolfspraul> unless we are lucky and find an easy to fix root cause... which we will give a shot but not an overly excessive study time.
<wolfspraul> that's roughly my thinking
<GitHub76> [scripts] xiangfu pushed 1 new commit to master: http://git.io/RghGdA
<GitHub76> [scripts/master] reflash_m1.sh merge lockflash - Xiangfu Liu
<wolfspraul> xiangfu: ah nice - all move into one script - great!
<GitHub198> [scripts] xiangfu pushed 1 new commit to master: http://git.io/M1k_wg
<GitHub198> [scripts/master] reflash_m1.sh merge read_flash - Xiangfu Liu
<xiangfu> wolfspraul, yes. still two needs merged.
<wpwrak> wolfspraul: 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.
<wpwrak> wolfspraul: 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.
<wpwrak> wolfspraul: i consider it good news that no previously "available" boards joined the "cluster" of unreliable booting in the fix2b testing
<wpwrak> wolfspraul: (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.
<wpwrak> (packaging instructions) that's basically a checklist for adam ? (with or without someone else assisting him)
<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 future
<wpwrak> (packaging) the aesthetics of the package look nice (interior and exterior)
<lekernel> wolfspraul, btw, do you want to ship the JTAG pod attached to the M1 PCB, or separately?
<lekernel> imo it's better to separate it, because it may otherwise fall because of shocks etc.
<lekernel> if there is some space remaining among the cables ... :)
<GitHub37> [scripts] xiangfu pushed 2 new commits to master: http://git.io/7fo0xg
<GitHub37> [scripts/master] reflash_m1.sh merge reflash_m1_rc3.sh - Xiangfu Liu
<GitHub37> [scripts/master] reflash_m1.sh meger reflash_mac_bios.sh - Xiangfu Liu
<wpwrak> lekernel: yeah, i think shipping it attached would just ask for trouble
<wolfspraul> I 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.
<wpwrak> naw, 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 this
<wpwrak> wolfspraul: and regarding connectors not coming loose, didn't people have their wlan module come off in freerunners ? that's even more impossible ;-))
<wolfspraul> do you know how tough that little thing sits there?
<wolfspraul> I seriously cannot imagine any better place than right there. Come off? It sounds like a total phantasy to me, really.
<wolfspraul> you would need vibrations and shock far harder than the acrylic case could ever withstand :-)
<wolfspraul> yes, to use them people need to open the case, of course
<wolfspraul> but ship separately? risk is 0%, so the additional hassle of a separate pod is not worth it, imho
<wolfspraul> I will shake my m1 a little tomorrow to test this :-)
<wolfspraul> but this idea sounds really really far fetched to me...
<wolfspraul> the 2 connectors are crazy strong
<wolfspraul> alas, I heard the argument clearly, so I shall test a little tomorrow :-)
<wpwrak> you 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 :)
<kristianpaul> I had seen those vibration cases with CFs..
<wolfspraul> kristianpaul: hey there! :-)
<kristianpaul> hey :)
<wolfspraul> do you know there is another hardware fix you can apply to your m1?
<wolfspraul> you can remove & short L3
<kristianpaul> L3 ?
<wolfspraul> yes
<wolfspraul> similar to L19
<wolfspraul> L19 fixed the problem of camera signal loss
<wolfspraul> but on the first day of receiving his m1, Werner found a similar problem, even more severe, with signal loss on line-in
<wolfspraul> when unplugging and replugging cables. even hang the m1.
<kristianpaul> but i dont have wolfson chip
<wolfspraul> removing and shorting L3 fixes this bug
<kristianpaul> or is this know from rc2 as well?
<wolfspraul> ah, good point
<wolfspraul> I don't know :-)
<wolfspraul> I 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 rc2
<kristianpaul> i 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 board
<wpwrak> kristianpaul: 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 :)
<kristianpaul> okay
<kristianpaul> are you going to short all the L** too ?;-)
<wolfspraul> oh sure it's up to you
<wolfspraul> but you can probably safely remove and short L19 and L3, and improve your m1 :-)
<kristianpaul> sure i like the idea
<wolfspraul> any namuru news?
<kristianpaul> no, i havent coded the logging for the tracking loop wich i need to move forward
<kristianpaul> logging for gnuplot
<wolfspraul> ah ok, good
<wpwrak> (short and remove) or just short, without removing
<wpwrak> in 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 ...)
<kristianpaul> sure wpwrak i'm not planing to remove