<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?
<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
<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