| 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.html | 00: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 |
| xiangfu | aw_, 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 |
| wpwrak | xiangfu: have you tested the locking yet ? i wouldn't enable it just yet, because we may still find NOR corruptions that locking would hide | 03:14 |
| wpwrak | xiangfu: but once the rc3 tests are done, then yes, the more you can lock, the better :) | 03:14 |
| wolfspraul | yes I agree | 03:16 |
| wolfspraul | xiangfu: first you make it work, add the command to the script, but disabled | 03:16 |
| wolfspraul | then we can decide later when is the best time to start using it | 03:17 |
| wolfspraul | but those 2 things are separate | 03:17 |
| wolfspraul | you 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 |
| wolfspraul | same for adding a check nor / crc check button in the Flickernoise GUI | 03:18 |
| wolfspraul | that'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 |
| xiangfu | I am test that with 'erase' under flickernoise now. | 03:25 |
| xiangfu | wpwrak, wolfspraul it works fine. there is no 'unlock' in 'erase' command :) | 03:26 |
| xiangfu | when I run 'erase /dev/flash4' nothing happen. so it works just fine. | 03:26 |
| wolfspraul | don't understand | 03:26 |
| xiangfu | wpwrak, also I already add the check code in 'lockflash' under urJtag, for 'erase' just for double check. | 03:26 |
| wolfspraul | what are you trying to do now? | 03:26 |
| xiangfu | test 'lockflash' if it working. | 03:27 |
| wolfspraul | huh? don't understand either :-) | 03:27 |
| wolfspraul | sorry you lost me somewhere... | 03:27 |
| xiangfu | for double check. | 03:27 |
| xiangfu | 1. I lock all partiton except the data partition. | 03:28 |
| wolfspraul | how? | 03:28 |
| wolfspraul | with urjtag? | 03:28 |
| xiangfu | 2. then run 'erase /dev/flash5' 'erase /dev/flash4' 'erase /dev/flash3' | 03:28 |
| xiangfu | yes. [1] is using urjtag | 03:28 |
| xiangfu | [2] is under flickernoise | 03:28 |
| wolfspraul | ahh :-) | 03:28 |
| xiangfu | flash5 is data partition. flash4 is flickernoise, flash3 is splashscreen. | 03:29 |
| xiangfu | after run those three command only data partition become empty. other still there. | 03:29 |
| wpwrak | heh, good :) seems to work then | 03:29 |
| xiangfu | wolfspraul, yes. I will add them as comment in script file | 03:29 |
| wpwrak | instead of erasing, you could also try writing some zero bytes | 03:30 |
| wolfspraul | where do you run the erase commands? | 03:30 |
| wolfspraul | rtems shell? | 03:30 |
| xiangfu | flickernosie serial console | 03:30 |
| wolfspraul | ok | 03:30 |
| xiangfu | yes. rtems shell. | 03:30 |
| wolfspraul | are there commands for unlocking and locking a partition? | 03:30 |
| xiangfu | no. | 03:30 |
| wolfspraul | should we add them? | 03:31 |
| xiangfu | no unlocking. | 03:31 |
| xiangfu | no locking | 03:31 |
| xiangfu | I don't think so. | 03:31 |
| wolfspraul | how can the web update work then? | 03:31 |
| xiangfu | wep update is only update regular images. not rescue, we only lock rescue images for now. | 03:32 |
| xiangfu | wolfspraul, oh one thing is | 03:32 |
| wolfspraul | sounds like at some point a lock/unlock command in the rtems shell is a nice feature | 03:33 |
| xiangfu | if we boot to rescue mode, then if the 'web update' will working on 'rescue' partitions? needs check source code | 03:33 |
| wolfspraul | maybe not now, so much stuff... | 03:33 |
| wolfspraul | no I think the web update should always just update the non-rescue stuff | 03:33 |
| wolfspraul | the rescue stuff remains unchanged | 03:33 |
| wolfspraul | another nice feature would be a "check nor crc" button in the Flickernoise GUI (but hidden somewhere in a dialog) | 03:34 |
| wolfspraul | it could help with customer support later | 03:34 |
| xiangfu | sorry for confuse. yes webupdate is always working on non-resuce stuff no matter what mode. | 03:34 |
| wolfspraul | another thing - why is the jtag verify so slow? | 03:35 |
| wolfspraul | also - why is the reading so slow? | 03:35 |
| wolfspraul | writing is fast, reading is slow? why? | 03:35 |
| xiangfu | sorry, don't know the detail. never look into those stuff. | 03:35 |
| wolfspraul | sure, just saying | 03:35 |
| wolfspraul | probably a software inefficiency somewhere, never got optimized... | 03:36 |
| wolfspraul | I cannot imagine a hardware limitation | 03:36 |
| wolfspraul | is it easy to make faster? don't know | 03:36 |
| wolfspraul | could also be nice in some cases | 03:36 |
| wolfspraul | 4 hour read time for 32 megabytes nor is bad, in a lot of error/debugging/analysis cases | 03:37 |
| wolfspraul | also '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 |
| wolfspraul | so let's see | 03:38 |
| wolfspraul | 1. locking in urjtag works now, patch not upstream yet | 03:38 |
| wolfspraul | 2. there is no lock/unlock command in the rtems shell now, nice-to-have feature | 03:38 |
| wolfspraul | 3. 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 |
| wolfspraul | argh | 03:38 |
| wolfspraul | sorry | 03:38 |
| wolfspraul | 3. there is no 'check nor' button in the flickernoise gui now, another nice-to-have feature | 03:38 |
| wolfspraul | 4. 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 |
| wolfspraul | is this correct? | 03:39 |
| wolfspraul | speading ;-) -> speeding | 03:40 |
| wpwrak | for 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 |
| wolfspraul | maybe faster today, and sure that should also work | 03:41 |
| wolfspraul | but any urjtag optimization would be independent of that | 03:41 |
| wolfspraul | ideally everything works, and everything is fast, right? :-) | 03:41 |
| wpwrak | for using locking, the update process in FN would also have to set the lock bits | 03:41 |
| wpwrak | (everything fast) yes :) | 03:41 |
| wolfspraul | I think update only updates unlocked parts | 03:42 |
| wolfspraul | locking is only for rescue path now | 03:42 |
| wolfspraul | that's how I understood xiangfu above | 03:42 |
| wpwrak | you can probably lock more. the more you can lock, the better | 03:42 |
| wolfspraul | let's start with the rescue path | 03:42 |
| wolfspraul | if you lock more, the web update process needs to add unlock/lock. it's all work. doesn't work today. | 03:43 |
| wpwrak | yeah, rescue is top priority :) | 03:43 |
| wpwrak | (web update) yup. my concern would be that the M1 would suddenly fail | 03:43 |
| wolfspraul | I don't disagree with you | 03:44 |
| wpwrak | not nice for the usage scenario. it's reassuring that you can recover without undue pain, but still bad | 03:44 |
| wolfspraul | I'm just trying to be clear about what can realistically work when | 03:44 |
| wpwrak | but that can of course be fixed in the fields | 03:44 |
| wolfspraul | not what I wish to work today (which is: everything) | 03:44 |
| wpwrak | field, even | 03:45 |
| GitHub169 | [scripts] xiangfu pushed 2 new commits to master: http://bit.ly/nxyw8T | 03:45 |
| GitHub169 | [scripts/master] add lockflash command as comment - Xiangfu Liu | 03:45 |
| GitHub169 | [scripts/master] compile-lm32-rtems clean gdb build folder - Xiangfu Liu | 03:45 |
| wpwrak | how's the battle going so far ? | 09:54 |
| xiangfu | 1 vs 80 :) | 09:56 |
| wpwrak | yeah, 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 fa | 12: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 pass | 14:46 |
| aw_ | 0x77 and 0x85 will be interesting. I'll go check them tomorrow | 14:50 |
| wpwrak | 0x85 sounds a little scary. maybe a cousin of 0x3a. | 16:03 |
| wpwrak | the rest of the results sounds nice, though. two more mini-clusters two kill, "pulse" and what looks like a NOR/CRC cluster | 16:04 |
| --- Sat Aug 20 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!