#milkymist IRC log for Friday, 2011-08-19

wpwrak_btw, even big guys like intel have flash problems: http://www.heise.de/newsticker/meldung/Firmware-Update-behebt-8-MByte-Bug-bei-Intel-SSD-320-1325177.html00:10
wpwrak_(in german, sorry)00:10
wpwrak_and, live at the arena, the battle continues ! good vs. evil, who will win ? yesterday, the lesser minions of evil were no match for adam, the champion of good. today, evil will send its greater demons, 0x32 and 0x3c. will good prevail ? watch the battle unfold, live only on #milkymist !01:20
aw_wpwrak, man! like your this introduction as the beginning of day. ;-) Preparation of Fedex gift to you this morning though. :)01:53
wpwrak(parcel) very good :-))02:05
xiangfuaw_, wpwrak, should we enable the 'loclflash' command now? no one reply my email on urjtag.(maybe later) maybe we just apply the patch manually, and start to use that now.03:12
wpwrakxiangfu: have you tested the locking yet ? i wouldn't enable it just yet, because we may still find NOR corruptions that locking would hide03:14
wpwrakxiangfu: but once the rc3 tests are done, then yes, the more you can lock, the better :)03:14
wolfspraulyes I agree03:16
wolfspraulxiangfu: first you make it work, add the command to the script, but disabled03:16
wolfspraulthen we can decide later when is the best time to start using it03:17
wolfspraulbut those 2 things are separate03:17
wolfspraulyou work on making it work, upstreaming the patch, etc. but please keep it disabled by default! so you don't disrupt the work of others right now.03:17
wolfspraulsame for adding a check nor / crc check button in the Flickernoise GUI03:18
wolfspraulthat's a nice thing to have, we should get it there. but no need to quickly deploy it, we can do that later at a convenient time. but it needs to be implemented first.03:18
xiangfuI am test that with 'erase' under flickernoise now.03:25
xiangfuwpwrak, wolfspraul it works fine. there is no 'unlock' in 'erase' command :)03:26
xiangfuwhen I run 'erase /dev/flash4' nothing happen. so it works just fine.03:26
wolfsprauldon't understand03:26
xiangfuwpwrak, also I already add the check code in 'lockflash' under urJtag,  for 'erase' just for double check.03:26
wolfspraulwhat are you trying to do now?03:26
xiangfutest 'lockflash' if it working.03:27
wolfspraulhuh? don't understand either :-)03:27
wolfspraulsorry you lost me somewhere...03:27
xiangfufor double check.03:27
xiangfu1. I lock all partiton except the data partition.03:28
wolfspraulhow?03:28
wolfspraulwith urjtag?03:28
xiangfu2. then run 'erase /dev/flash5' 'erase /dev/flash4' 'erase /dev/flash3'03:28
xiangfuyes. [1] is using urjtag03:28
xiangfu[2] is under flickernoise03:28
wolfspraulahh :-)03:28
xiangfuflash5 is data partition. flash4 is flickernoise, flash3 is splashscreen.03:29
xiangfuafter run those three command only data partition become empty. other still there.03:29
wpwrakheh, good :) seems to work then03:29
xiangfuwolfspraul, yes. I will add them as comment in script file03:29
wpwrakinstead of erasing, you could also try writing some zero bytes03:30
wolfspraulwhere do you run the erase commands?03:30
wolfspraulrtems shell?03:30
xiangfuflickernosie serial console03:30
wolfspraulok03:30
xiangfuyes. rtems shell.03:30
wolfspraulare there commands for unlocking and locking a partition?03:30
xiangfuno.03:30
wolfspraulshould we add them?03:31
xiangfuno unlocking.03:31
xiangfuno locking03:31
xiangfuI don't think so.03:31
wolfspraulhow can the web update work then?03:31
xiangfuwep update is only update regular images. not rescue, we only lock rescue images for now.03:32
xiangfuwolfspraul, oh one thing is03:32
wolfspraulsounds like at some point a lock/unlock command in the rtems shell is a nice feature03:33
xiangfuif we boot to rescue mode, then if the 'web update' will working on 'rescue' partitions? needs check source code03:33
wolfspraulmaybe not now, so much stuff...03:33
wolfspraulno I think the web update should always just update the non-rescue stuff03:33
wolfspraulthe rescue stuff remains unchanged03:33
wolfspraulanother nice feature would be a "check nor crc" button in the Flickernoise GUI (but hidden somewhere in a dialog)03:34
wolfspraulit could help with customer support later03:34
xiangfusorry for confuse. yes webupdate is always working on non-resuce stuff no matter what mode.03:34
wolfspraulanother thing - why is the jtag verify so slow?03:35
wolfspraulalso - why is the reading so slow?03:35
wolfspraulwriting is fast, reading is slow? why?03:35
xiangfusorry, don't know the detail. never look into those stuff.03:35
wolfspraulsure, just saying03:35
wolfspraulprobably a software inefficiency somewhere, never got optimized...03:36
wolfspraulI cannot imagine a hardware limitation03:36
wolfspraulis it easy to make faster? don't know03:36
wolfspraulcould also be nice in some cases03:36
wolfspraul4 hour read time for 32 megabytes nor is bad, in a lot of error/debugging/analysis cases03:37
wolfspraulalso 'verify skipped' doesn't sound right in our production process, of course it shoudl be verified. but impossible to enable while it's so slow...03:37
wolfspraulso let's see03:38
wolfspraul1. locking in urjtag works now, patch not upstream yet03:38
wolfspraul2. there is no lock/unlock command in the rtems shell now, nice-to-have feature03:38
wolfspraul3. there is no 'check nor' button in the flickernoise 03:34 < xiangfu> sorry for confuse. yes webupdate is always working on non-resuce stuff no matter what mode.03:38
wolfspraulargh03:38
wolfspraulsorry03:38
wolfspraul3. there is no 'check nor' button in the flickernoise gui now, another nice-to-have feature03:38
wolfspraul4. we don't know why urjtag read (and verify) are so slow. speading this up to the same speed as writing is already now is another nice-to-have feature.03:39
wolfspraulis this correct?03:39
wolfspraulspeading ;-) -> speeding03:40
wpwrakfor 4., according to mwalle, gdb may be a faster alternative. not sure if it needs BIOS support, though. i think he said it did but maybe i misunderstood.03:40
wolfspraulmaybe faster today, and sure that should also work03:41
wolfspraulbut any urjtag optimization would be independent of that03:41
wolfspraulideally everything works, and everything is fast, right? :-)03:41
wpwrakfor using locking, the update process in FN would also have to set the lock bits03:41
wpwrak(everything fast) yes :)03:41
wolfspraulI think update only updates unlocked parts03:42
wolfspraullocking is only for rescue path now03:42
wolfspraulthat's how I understood xiangfu above03:42
wpwrakyou can probably lock more. the more you can lock, the better03:42
wolfspraullet's start with the rescue path03:42
wolfspraulif you lock more, the web update process needs to add unlock/lock. it's all work. doesn't work today.03:43
wpwrakyeah, rescue is top priority :)03:43
wpwrak(web update) yup. my concern would be that the M1 would suddenly fail03:43
wolfspraulI don't disagree with you03:44
wpwraknot nice for the usage scenario. it's reassuring that you can recover without undue pain, but still bad03:44
wolfspraulI'm just trying to be clear about what can realistically work when03:44
wpwrakbut that can of course be fixed in the fields03:44
wolfspraulnot what I wish to work today (which is: everything)03:44
wpwrakfield, even03:45
GitHub169[scripts] xiangfu pushed 2 new commits to master: http://bit.ly/nxyw8T03:45
GitHub169[scripts/master] add lockflash command as comment - Xiangfu Liu03:45
GitHub169[scripts/master] compile-lm32-rtems clean gdb build folder - Xiangfu Liu03:45
wpwrakhow's the battle going so far ?09:54
xiangfu1 vs 80 :)09:56
wpwrakyeah, poor adam. surrounded by all the boards !10:00
aw_0x85: 1. finish 1st boot to rendering test then power cycle again, then can't reconfiguration(d2/d3 dimly lit); then can reconfiguration after maybe 3 minutes 2. U7U19U20-C17F 3. replaced new u7/u19/u20 4. applied fix2b 5. D16(in-circuit): For.V.=154mV, Rev.V = 1547mV 6. d2/d3 is fully off after powered on 7. tp36/tp37 is 3.3V 8. reflashed successfully 9. got 'CRC failed (expected aa12a56a, got b0c6b06d)' and 'splash.rawCRC fa12:18
aw_iled (expected 978f860c, got 33d3152a)' while using test program 10. keep performing CRC test again, then pass without power-cycle.12:18
aw_wpwrak, hi i just met a CRC failed while using test program, then keep performing test CRC again, and passed.12:19
aw_i continue testing the rest... stay tuned. ;-)12:20
aw_item 9: flickernoise.fbi(rescue)(CRC)CRC failed (expected aa12a56a, got b0c6b06d)12:21
aw_fix2b so far: 0x32 pulse / 0x34 good / 0x39 good / 0x3A nor / 0x3C pulse / 0x40 good / 0x48 render fail / 0x54 good / 0x55 nor / 0x5C good / 0x61 good / 0x63 good / 0x6b good / 0x6c good / 0x77 pulse / 0x7a good / 0x7d good, midi to be fixed / 0x7f good / 0x85 good, but CRC failed then pass14:46
aw_0x77 and 0x85 will be interesting. I'll go check them tomorrow14:50
wpwrak0x85 sounds a little scary. maybe a cousin of 0x3a.16:03
wpwrakthe rest of the results sounds nice, though. two more mini-clusters two kill, "pulse" and what looks like a NOR/CRC cluster16:04
--- Sat Aug 20 201100:00

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