<wpwrak_> (in german, sorry)
<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 !
<aw_> wpwrak, man! like your this introduction as the beginning of day. ;-) Preparation of Fedex gift to you this morning though. :)
<wpwrak> (parcel) very good :-))
<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.
<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
<wpwrak> xiangfu: but once the rc3 tests are done, then yes, the more you can lock, the better :)
<wolfspraul> yes I agree
<wolfspraul> xiangfu: first you make it work, add the command to the script, but disabled
<wolfspraul> then we can decide later when is the best time to start using it
<wolfspraul> but those 2 things are separate
<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.
<wolfspraul> same for adding a check nor / crc check button in the Flickernoise GUI
<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.
<xiangfu> I am test that with 'erase' under flickernoise now.
<xiangfu> wpwrak, wolfspraul it works fine. there is no 'unlock' in 'erase' command :)
<xiangfu> when I run 'erase /dev/flash4' nothing happen. so it works just fine.
<wolfspraul> don't understand
<xiangfu> wpwrak, also I already add the check code in 'lockflash' under urJtag,  for 'erase' just for double check.
<wolfspraul> what are you trying to do now?
<xiangfu> test 'lockflash' if it working.
<wolfspraul> huh? don't understand either :-)
<wolfspraul> sorry you lost me somewhere...
<xiangfu> for double check.
<xiangfu> 1. I lock all partiton except the data partition.
<wolfspraul> how?
<wolfspraul> with urjtag?
<xiangfu> 2. then run 'erase /dev/flash5' 'erase /dev/flash4' 'erase /dev/flash3'
<xiangfu> yes. [1] is using urjtag
<xiangfu> [2] is under flickernoise
<wolfspraul> ahh :-)
<xiangfu> flash5 is data partition. flash4 is flickernoise, flash3 is splashscreen.
<xiangfu> after run those three command only data partition become empty. other still there.
<wpwrak> heh, good :) seems to work then
<xiangfu> wolfspraul, yes. I will add them as comment in script file
<wpwrak> instead of erasing, you could also try writing some zero bytes
<wolfspraul> where do you run the erase commands?
<wolfspraul> rtems shell?
<xiangfu> flickernosie serial console
<wolfspraul> ok
<xiangfu> yes. rtems shell.
<wolfspraul> are there commands for unlocking and locking a partition?
<xiangfu> no.
<wolfspraul> should we add them?
<xiangfu> no unlocking.
<xiangfu> no locking
<xiangfu> I don't think so.
<wolfspraul> how can the web update work then?
<xiangfu> wep update is only update regular images. not rescue, we only lock rescue images for now.
<xiangfu> wolfspraul, oh one thing is
<wolfspraul> sounds like at some point a lock/unlock command in the rtems shell is a nice feature
<xiangfu> if we boot to rescue mode, then if the 'web update' will working on 'rescue' partitions? needs check source code
<wolfspraul> maybe not now, so much stuff...
<wolfspraul> no I think the web update should always just update the non-rescue stuff
<wolfspraul> the rescue stuff remains unchanged
<wolfspraul> another nice feature would be a "check nor crc" button in the Flickernoise GUI (but hidden somewhere in a dialog)
<wolfspraul> it could help with customer support later
<xiangfu> sorry for confuse. yes webupdate is always working on non-resuce stuff no matter what mode.
<wolfspraul> another thing - why is the jtag verify so slow?
<wolfspraul> also - why is the reading so slow?
<wolfspraul> writing is fast, reading is slow? why?
<xiangfu> sorry, don't know the detail. never look into those stuff.
<wolfspraul> sure, just saying
<wolfspraul> probably a software inefficiency somewhere, never got optimized...
<wolfspraul> I cannot imagine a hardware limitation
<wolfspraul> is it easy to make faster? don't know
<wolfspraul> could also be nice in some cases
<wolfspraul> 4 hour read time for 32 megabytes nor is bad, in a lot of error/debugging/analysis cases
<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...
<wolfspraul> so let's see
<wolfspraul> 1. locking in urjtag works now, patch not upstream yet
<wolfspraul> 2. there is no lock/unlock command in the rtems shell now, nice-to-have feature
<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.
<wolfspraul> argh
<wolfspraul> sorry
<wolfspraul> 3. there is no 'check nor' button in the flickernoise gui now, another nice-to-have feature
<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.
<wolfspraul> is this correct?
<wolfspraul> speading ;-) -> speeding
<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.
<wolfspraul> maybe faster today, and sure that should also work
<wolfspraul> but any urjtag optimization would be independent of that
<wolfspraul> ideally everything works, and everything is fast, right? :-)
<wpwrak> for using locking, the update process in FN would also have to set the lock bits
<wpwrak> (everything fast) yes :)
<wolfspraul> I think update only updates unlocked parts
<wolfspraul> locking is only for rescue path now
<wolfspraul> that's how I understood xiangfu above
<wpwrak> you can probably lock more. the more you can lock, the better
<wolfspraul> let's start with the rescue path
<wolfspraul> if you lock more, the web update process needs to add unlock/lock. it's all work. doesn't work today.
<wpwrak> yeah, rescue is top priority :)
<wpwrak> (web update) yup. my concern would be that the M1 would suddenly fail
<wolfspraul> I don't disagree with you
<wpwrak> not nice for the usage scenario. it's reassuring that you can recover without undue pain, but still bad
<wolfspraul> I'm just trying to be clear about what can realistically work when
<wpwrak> but that can of course be fixed in the fields
<wolfspraul> not what I wish to work today (which is: everything)
<wpwrak> field, even
<GitHub169> [scripts] xiangfu pushed 2 new commits to master: http://bit.ly/nxyw8T
<GitHub169> [scripts/master] add lockflash command as comment - Xiangfu Liu
<GitHub169> [scripts/master] compile-lm32-rtems clean gdb build folder - Xiangfu Liu
<wpwrak> how's the battle going so far ?
<xiangfu> 1 vs 80 :)
<wpwrak> yeah, poor adam. surrounded by all the boards !
<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
<aw_> iled (expected 978f860c, got 33d3152a)' while using test program 10. keep performing CRC test again, then pass without power-cycle.
<aw_> wpwrak, hi i just met a CRC failed while using test program, then keep performing test CRC again, and passed.
<aw_> i continue testing the rest... stay tuned. ;-)
<aw_> item 9: flickernoise.fbi(rescue)(CRC)CRC failed (expected aa12a56a, got b0c6b06d)
<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
<aw_> 0x77 and 0x85 will be interesting. I'll go check them tomorrow
<wpwrak> 0x85 sounds a little scary. maybe a cousin of 0x3a.
<wpwrak> the rest of the results sounds nice, though. two more mini-clusters two kill, "pulse" and what looks like a NOR/CRC cluster