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