wpwrak | xiangfu: by the way, did you read my mail on the milkymist list "NOR corruption analysis 3/4, a subtle gotcha" ? | 00:56 |
---|---|---|
wpwrak | and if yes, do you think the M1rc3 adam is shipping have their NOR locked ? | 00:56 |
xiangfu | wpwrak, on todo list. I will read now. | 01:01 |
wpwrak | heh. yeah, i wrote a lot there :) | 01:02 |
xiangfu | wpwrak, wow. the lockflash command is in the middle of 'flashmem' :( | 01:50 |
xiangfu | wpwrak, so if yes. the M1rc3 is not locked. :( | 01:50 |
xiangfu | wpwrak, I am in the 'urjtag' mailing list. | 01:51 |
xiangfu | aw, Hi | 01:55 |
xiangfu | can you post your reflash_m1.sh somewhere? are you using the latest reflash_m1.sh? | 01:55 |
wolfspraul | xiangfu: yeah well, that's ok and we just improve and move forward. | 01:58 |
wolfspraul | so change the script to put the lockflash command last? | 01:58 |
wolfspraul | and get it to Adam asap (now) | 01:58 |
wolfspraul | but I don't fully understand yet - we say that every flashmem command unlocks the entire nor? | 01:59 |
GitHub6 | [scripts] xiangfu pushed 1 new commit to master: http://git.io/Uly1qQ | 02:00 |
GitHub6 | [scripts/master] reflash_m1.sh mv the lockflash to the end of command series - Xiangfu Liu | 02:00 |
xiangfu | wolfspraul, ( every flashmem command unlocks the entire nor?) yes. | 02:00 |
xiangfu | wolfspraul, yes. get it to Adam asap | 02:01 |
wolfspraul | xiangfu: aw : can you make sure Adam uses the new, hopefully working, script from now on | 02:01 |
wolfspraul | and also, can we make a little "just lock" script that Adam can use to lock the units he still has in stock? | 02:01 |
wolfspraul | I think it's not too difficult | 02:02 |
xiangfu | wpwrak, there is no 'unlock' command in flickernoise. so if we correct lock rescue partition. the flickernosie will never change all rescue partition. | 02:02 |
wolfspraul | hmm | 02:02 |
wolfspraul | well | 02:02 |
wolfspraul | Adam would need to open the top acrylic | 02:02 |
wolfspraul | well, I think it's needed | 02:02 |
xiangfu | wolfspraul, (just lock) yes. already implemented. | 02:02 |
wolfspraul | aw: you there? | 02:03 |
wolfspraul | it seems Werner found a little problem with the reflash script you are using :-) | 02:03 |
xiangfu | yes. have to use jtag. | 02:03 |
aw | xiangfu, wolfspraul http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/tool/reflash_m1_rc3.sh | 02:04 |
wolfspraul | aw: yes sorry about this | 02:05 |
wolfspraul | I read Werner's mail a few days ago but didn't understand the significance right away | 02:05 |
wolfspraul | xiangfu: which command does adam need to run to just lock a unit that is otherwise ready for shipping? | 02:05 |
xiangfu | reflash_m1.sh --lockflash | 02:06 |
xiangfu | aw, please use this latest reflash_m1.sh : https://raw.github.com/milkymist/scripts/master/scripts/reflash_m1.sh | 02:07 |
aw | are you guys meaning that I HAVE TO open all packed m1 to reflash them again? ;-) | 02:08 |
xiangfu | aw, sorry. it is "reflash_m1.sh --lock-flash" | 02:08 |
xiangfu | aw, seems yes. ;-) | 02:09 |
aw | xiangfu, so the new command in terminal to keyin "reflash_m1.sh --lock-flash"? | 02:09 |
aw | xiangfu, i actually used http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/tool/reflash.sh to call "reflash_m1.sh" | 02:10 |
xiangfu | aw, if the m1 is already reflashed.(by old reflash_m1.sh) we have to use 'reflash_m1.sh --lock-flash' for real lock flash. | 02:10 |
aw | so my previous command is "./reflash.sh 00 70" like this | 02:10 |
wolfspraul | aw: yes, need to open the box, take m1 out, open top acrylic, connect jtag-usb cable, run reflash_m1.sh --lock-flash, reboot once to test rendering, pack again | 02:11 |
aw | xiangfu, help me to modify MY OWN "reflash.sh" script to include your latest "reflash_m1.sh" | 02:12 |
aw | xiangfu, be noticed that since that my own "reflash,sh" was trying to save all logs to my 'log' folder. | 02:16 |
wolfspraul | xiangfu: didn't you run some test to verify that blocks were locked? | 02:16 |
aw | i.e.: ./reflash_m1_rc3.sh $1 $2 2>&1 | tee -a log/urjtag_lock_$2.log | 02:16 |
wolfspraul | or you only verified the lockflash command itself, but not the locking after the entire script ran? | 02:16 |
aw | so this will be changed to what? "./reflash_m1.sh $1 $2 2>&1 | tee -a log/urjtag_lock_$2.log ????" | 02:17 |
wolfspraul | aw: should be, but let's wait for xiangfu's feedback. I think he is testing right now :-) | 02:19 |
wolfspraul | xiangfu knows those scripts best | 02:19 |
xiangfu | there is no verified like werner used: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1rc3/norruption/2/upset | 02:21 |
xiangfu | there are two command for aw: | 02:22 |
xiangfu | 1. ./reflash_m1.sh --rc3 00 07 : is just like before but fixed the lock flash | 02:22 |
xiangfu | 2. ./reflash_m1.sh --lock-flash: is for only lock rescue partition. | 02:23 |
wolfspraul | xiangfu: so that's: ./reflash_m1.sh --rc3 $1 $2 2>&1 | tee -a log/urjtag_lock_$2.log | 02:23 |
wolfspraul | right? | 02:23 |
xiangfu | yes. | 02:23 |
xiangfu | aw, http://pastebin.com/V2dHHKWr | 02:26 |
xiangfu | the new reflash.sh | 02:26 |
aw | okay...got it, thanks you both. :-) | 02:28 |
wolfspraul | xiangfu: again - didn't you test the locking somehow? | 02:28 |
wolfspraul | I remember you ran some command in the rtems shell to verify that things were locked | 02:29 |
aw | another rework starts. :) | 02:29 |
wolfspraul | how did you test that exactly? | 02:29 |
wolfspraul | you didn't test locking after running the full script? | 02:29 |
wolfspraul | so you didn't notice that the flashmem after lockflash unlocked the entire nor? | 02:29 |
wolfspraul | I just try to make sure Adam doesn't waste his time in case the right blocks are still in fact locked... | 02:29 |
xiangfu | wolfspraul, yes. I test before. under flickernoise. I lock the whole flash. and try to 'rm' some files under rtems. | 02:30 |
wolfspraul | but you didn't test after running the script? | 02:30 |
xiangfu | there is no such test in script. | 02:30 |
wolfspraul | can you test that now? | 02:30 |
wolfspraul | sure | 02:30 |
xiangfu | yes. since werner already finish one. | 02:30 |
xiangfu | I will add it now. | 02:31 |
wolfspraul | you can try this: | 02:31 |
wolfspraul | take the old script | 02:31 |
wolfspraul | ah well, no | 02:31 |
wolfspraul | the good news is that we still work with low volumes :-) | 02:31 |
wolfspraul | so we didn't test the lockflash right actually | 02:31 |
wolfspraul | about 25 units shipped out unlocked | 02:32 |
wolfspraul | adam was planning to ship out another 8 today, at least for those the realization comes in time... | 02:33 |
xiangfu | I will test(make sure) a little anyway for more understanding, will report later. | 02:33 |
xiangfu | sorry needs reboot. back online in several minutes | 02:33 |
aw | xiangfu, hi you just posted the same link about reflash_m1.sh in list, is it the same version of here(irc) you gave to me couples minutes before? | 03:10 |
xiangfu | yes. same | 03:10 |
xiangfu | aw, without any parameters just 'reflash_m1.sh' will print the VERSION | 03:11 |
xiangfu | it should be: Version of me: 2011-10-14 | 03:11 |
aw | xiangfu, okay. got it. thanks. | 03:12 |
aw | xiangfu, the msg "jtag batch file is /tmp/tmp.MYrv734ed1" I don't need to care, right? | 03:23 |
xiangfu | just double checked. we HAVE TO put the lockflash to the end of jtag command series. | 03:24 |
xiangfu | wpwrak, thanks. :) | 03:24 |
xiangfu | aw, no. | 03:24 |
aw | xiangfu, ? don't need to care or need to care? | 03:26 |
xiangfu | don't need to care. | 03:27 |
aw | and i have bad result that d2/d3 is dimly lit after reflash. | 03:27 |
aw | what i supposedly to do? relfash it again? I still don't power off now. need to probe some TPs...man! | 03:29 |
wolfspraul | he :-) | 03:30 |
wolfspraul | rule #1: relax | 03:30 |
wolfspraul | the shipments that were planned to go out today can go out later | 03:31 |
wolfspraul | did you power cycle after the --lock-flash script? | 03:32 |
xiangfu | wolfspraul, no. I am not point aw to using --lock-flash. just use new reflash_m1.sh and reflash again. | 03:32 |
wolfspraul | ah OK | 03:32 |
aw | yes. i use whole reflash function | 03:33 |
wolfspraul | well, then figure out why it's not booting now... | 03:33 |
wolfspraul | :-) | 03:33 |
aw | now TP35/TP36/TP37 is all 3.3V high well. | 03:33 |
wolfspraul | aw: you please don't worry and no stress. shipments go out when we have everything under control. | 03:33 |
aw | and now its status(d2/d3 dimly it disppears) after I use probers. | 03:34 |
xiangfu | 1. read the standby. 2. do CRC check.see if there is NOR corruption | 03:34 |
aw | yup...i still keep not to power off. | 03:35 |
aw | next to read back | 03:35 |
xiangfu | sorry. it's 1. read the standby see if there is NOR corruption | 03:35 |
aw | fyi http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/tool/read_flash_m1.sh | 03:38 |
xiangfu | aw, please delete that one. | 03:39 |
aw | need to use a new one? I don't have. | 03:40 |
xiangfu | aw, use the one you have download. like './reflash_m1.sh --read-flash' will read standby.bin and print out the path | 03:40 |
aw | oh..okay | 03:40 |
xiangfu | now 'reflash_m1.sh' do everything :-) | 03:41 |
aw | reading... | 03:44 |
aw | xiangfu, http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/bitstream/0x75-standby-1/standby.fpg | 03:57 |
aw | xiangfu teach me how to run diff? thanks. | 03:58 |
tuxbrain | hi, there is any Flicker Noise starting guide? Programing manual? language reference? tutorial? anything for a totally newbie to start to write patches from scratch? | 05:18 |
aw | xiangfu, http://pastebin.com/iGqtYtNf | 05:19 |
wolfspraul | tuxbrain: probably not | 05:19 |
wolfspraul | that's one of our top todo items though | 05:19 |
wolfspraul | you can read & learn from the current 54 patches, that's one approach | 05:19 |
aw | xiangfu, does it mean there's difference existed? | 05:19 |
wolfspraul | there are 2 old milkdrop manuals that have some partial value | 05:20 |
tuxbrain | I have loan my board to one guy specialiced in video shows hardware (DMX lightning, interactive music and so) , and his feeling is that there is no clear info on how to use it, and after some search I had to agree with him | 05:23 |
wolfspraul | I agree as well | 05:23 |
aw | xiangfu, it booted up to rendering though. | 05:26 |
aw | i'm trying to count 10 times. | 05:27 |
tuxbrain | An how patches are created now? how to know the intrucction set right now? the only option is the also created patches? | 05:28 |
wolfspraul | I guess so, I never wrote or modified one. | 05:31 |
wolfspraul | trial & error | 05:31 |
wolfspraul | :-) | 05:31 |
tuxbrain | no a good answer to a posible costumer :P | 05:32 |
wolfspraul | yes and no. we are working on making this product ready for the dummies. | 05:32 |
wolfspraul | at the same time, where it is now, someone who has a little passion and enthousiasm and spends a weekend on it can get a lot done. | 05:33 |
wolfspraul | I'm not just saying this to talk to myself, but we have proof in customers like Don (www.no-carrier.com) | 05:33 |
wolfspraul | but yes, the box right now does require some activity still | 05:33 |
wolfspraul | although with every update we make it a bit easier to start, explore, enhance, etc. | 05:34 |
tuxbrain | where the patches are hosted? I want to at least do a command list (also to figure out my self) and maybe starting for that to do a language reference? there is something started in that way yet? | 05:35 |
wolfspraul | must be somewhere in github.com/milkymist, one sec | 05:35 |
wolfspraul | one plan was to have a sharing site where people can easily upload and download patches from | 05:35 |
wolfspraul | and m1 users can just press "download all" to get the latest stuff from the sharing site | 05:35 |
wolfspraul | but that's just a plan today | 05:35 |
wolfspraul | maybe here? https://github.com/milkymist/flickernoise/tree/master/patches | 05:36 |
tuxbrain | not a bad plan :) , but first you need the users to know how to write those patches :P | 05:36 |
tuxbrain | patch sintax also doesn't allow comments , isn't it? | 05:43 |
xiangfu | aw, yes. from the diff there is no NOR corruption | 05:46 |
xiangfu | aw, the m1 should boot fine. | 05:46 |
xiangfu | tuxbrain, http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-05092011-0000/doc/handbook.pdf | 05:47 |
xiangfu | tuxbrain, here is the patch language guide. | 05:47 |
aw | xiangfu, good, but from my previous reflash experiences, the d2/d3 led must be fully off immediately after finished reflash. | 05:47 |
aw | xiangfu, and although i just finished 10 times rendering test by power-cycle | 05:48 |
aw | xiangfu, now to test CRC.. | 05:48 |
aw | xiangfu, good. pass on CRC image test. | 05:49 |
tuxbrain | xiangfu: Great! that is exactly what I'm looking for!!! | 05:50 |
xiangfu | tuxbrain, here is a user manual: http://www.milkymist.org/wiki/index.php?title=Flickernoise_user_manual | 05:52 |
tuxbrain | This should be really more accesible, also maybe do a wiki pages to enrich it and create the commented examples | 05:52 |
xiangfu | tuxbrain, it's a start anyway :) | 05:52 |
xiangfu | tuxbrain, the patch language use '//' as comment | 05:55 |
tuxbrain | xiangfu: (comments) :) then is not used very much | 05:55 |
xiangfu | tuxbrain, http://www.milkymist.org/wiki/index.php?title=Flickernoise_Patching_Language | 05:56 |
xiangfu | also a start. | 05:56 |
aw | I'm thinking if used a long usb cable to cause that since I didn't open video-in side acrylic case so that i use a 90 degree usb long cable. I'm going to open side case and use a short usb cable to reflash it again. | 05:56 |
xiangfu | aw, ok. | 05:57 |
aw | xiangfu, btw, which usb cable you are using now? | 05:57 |
xiangfu | aw, you can use 'reflash_m1.sh --lock-flash' for ONLY lock the rescue flash, without reflash all the images. | 05:57 |
xiangfu | aw, that will save a lot of time. | 05:58 |
xiangfu | aw, I have double check 'reflash_m1.sh --lock-flash' works just fine. | 05:58 |
aw | xiangfu, hmm...i want to see what real reason that it shows d2/d3 dimly lit after reflash. so I'll still use all.but this time to use short usb cable. | 05:59 |
xiangfu | aw, ok. | 05:59 |
xiangfu | aw, the only different of the reflash script file is 'we put lockflash to the end of flash command series', just FYI. | 06:00 |
tuxbrain | xiangfu: yes I agree the info you pass me are a start but at least is a better start than a new user percives when he arrives at MM ( I include myselft in this group) | 06:00 |
xiangfu | tuxbrain, (comments) yes. | 06:01 |
xiangfu | tuxbrain, we should slowly add more comments. | 06:01 |
aw | xiangfu, btw, so my question is that did you see your d2/d3 dimly lit _immediately_ after reflash with new script? | 06:02 |
tuxbrain | I dissagre in the "slowly" but I can understand there are limited working hands an a lot of things to do :P | 06:02 |
xiangfu | aw, I have to reflash again for find out the d2/d3 . | 06:03 |
aw | xiangfu, i meant _don't_ power cycle after reflash, just see if d2/d3 dimly lit _immediately_ after reflash. | 06:03 |
xiangfu | aw, ok. | 06:04 |
aw | xiangfu, yup. tks we confirm together. | 06:04 |
tuxbrain | Do you agree in create a wikified Flicker noise handbook in addition to the pdf? | 06:04 |
xiangfu | tuxbrain, yes. that is what 'http://www.milkymist.org/wiki/index.php?title=Flickernoise_Patching_Language' this page for. | 06:06 |
xiangfu | aw, reflashing... | 06:08 |
xiangfu | aw, yes. they are dim. not totally off. | 06:09 |
aw | xiangfu, yes. hmm...this shows the new script file will _definitely_ let d2/d3 dimly lit with putting lockflash to the end of flash command | 06:10 |
xiangfu | aw, yes. | 06:11 |
xiangfu | aw, I tried another flash end with 'flashmem' that make those two led totally off. | 06:11 |
aw | xiangfu, mine here the symptom is the same no matter what short or long usb cable. | 06:11 |
xiangfu | so basically: | 06:11 |
xiangfu | 1. end with 'flashmem' two leds will totally OFF | 06:12 |
xiangfu | 2. end with 'lockflash' two leds will DIM | 06:12 |
aw | xiangfu, yup...so this means that we MUST power cycle again to let it boot up, this is different symptom from before. | 06:12 |
tuxbrain | xiangfu: ok I will use this one to wikify the pdf, what you consider better, to create different pages per chapter or one big wikipage with all content in? | 06:13 |
aw | xiangfu, right. | 06:13 |
xiangfu | aw, (must power cycle) yes. that is true. | 06:14 |
aw | wolfspraul, you there. so this newest script with 'lockflash' at the end comes up a symptom which is surely not the same as previous rc3 M1s we sent out. | 06:15 |
xiangfu | tuxbrain, I think one big wikipage with menu | 06:15 |
aw | xiangfu, wolfspraul MUST to power cycle to boot up after reflash. so from now on. i continue to reflash others. how do you think? or any considerations that we didn't think about? | 06:17 |
xiangfu | aw, (since this issue can easy re-produce) I think continue | 06:18 |
xiangfu | aw, but for the m1 already flashed. you can just use 'reflash_m1.sh --lock-flash' no needs to reflash all images. | 06:18 |
aw | with this way. i found that it's still good that i can keep using long 90 degree usb cable for sure. And surely no need to take apart video-in side acrylic case. | 06:19 |
xiangfu | aw, yes. | 06:20 |
wolfspraul | aw: xiangfu : I have lost overview right now. I think you two are working on this. | 06:20 |
aw | xiangfu, okay...but if i still want to do some records, so the script of my 'reflash.sh' need to do change? | 06:20 |
wolfspraul | obviously we can only send out units that are 100% perfect and 100% understood | 06:20 |
wolfspraul | xiangfu: what happened on that 1 unit that Adam could not boot anymore? | 06:20 |
xiangfu | wolfspraul, <xiangfu> so basically: | 06:20 |
xiangfu | <xiangfu> 1. end with 'flashmem' two leds will totally OFF | 06:20 |
xiangfu | <xiangfu> 2. end with 'lockflash' two leds will DIM | 06:20 |
wolfspraul | ok. but if Adam power cycles, does the board boot to render? | 06:21 |
aw | wolfspraul, yes after power cycle | 06:21 |
xiangfu | wolfspraul, after power cycles. works just fine. | 06:21 |
wolfspraul | ah ok | 06:21 |
wolfspraul | then it's probably nothing :-) | 06:21 |
wolfspraul | in fact, if you see the two leds DIM, it means you are using the new, fixed, script :-) | 06:22 |
wolfspraul | right? | 06:22 |
xiangfu | yes. | 06:22 |
aw | yup....but we did a care this time | 06:22 |
aw | right | 06:22 |
wolfspraul | yes yes sure, very good | 06:22 |
wolfspraul | I totally appreciate that you watch for small unexpected things | 06:22 |
wolfspraul | many times the big issues are hiding behind them | 06:22 |
wolfspraul | so... now we proceed with the 8 units? | 06:23 |
aw | wolfspraul, yes | 06:23 |
aw | i may still catch up 3 M1s this afternoon firstly | 06:24 |
xiangfu | aw, you can use a script like this: http://pastebin.com/ZjfgvL0X | 06:24 |
xiangfu | save it as 'lock_flash_only.sh' maybe :) | 06:24 |
aw | xiangfu wolfspraul cu..keep working though. thanks for clarification. | 06:24 |
aw | xiangfu, great, thanks. | 06:25 |
xiangfu | aw, see you later. | 06:26 |
xiangfu | tuxbrain, do you have account in milkymist.org/wiki? | 06:26 |
xiangfu | milkymist.org/wiki is not for public register. have to accept by admin. | 06:27 |
wpwrak | good morning :) busy night, i see ... checking the backlog ... | 07:49 |
wolfspraul | wpwrak: we finally realized what you wrote in your mail the day before :-) | 07:49 |
wpwrak | (locking process) it could also be done by software. but i don't know if this would be really easier than using jtag with what's presently installed | 07:52 |
wpwrak | (d2/d3 dim after lockflash) hmm. that's a little strange. according to https://raw.github.com/milkymist/scripts/master/scripts/reflash_m1.sh there is a "pld reconfigure" after it, so that should work. | 08:11 |
wpwrak | aw: oh, and the flashmem for --bios-mac would have to be before the lockflash, too | 08:11 |
aw | wpwrak, mmm | 08:12 |
wpwrak | wolfspraul: (realize) i was a bit surprised about how calmly you took the news ;-) | 08:12 |
xiangfu | wpwrak, --bios-mac yes. | 08:13 |
wpwrak | maybe we should dump all the lock bits, just to be sure | 08:14 |
wolfspraul | wpwrak: it simply didn't register, the meaning | 08:14 |
wpwrak | yeah, i didn't want to sound overly alarmist :) maybe it was a bit too subdued as a result. sorry about that. | 08:15 |
wolfspraul | no problem, all fine | 08:16 |
wolfspraul | I will not write long and complicated mails to the people who already got units | 08:16 |
wolfspraul | instead we just wait, and if there's a support case we take it from there | 08:16 |
wolfspraul | we are talking about 'relatively' rare things already | 08:16 |
aw | wpwrak, you know what? i actually don't want to see symptom (d2/d3 dim after lockflash), since there might be haven a failure board by manufacture caused that to indicate a DIM lit. so _IF_ there's any s/w can let d2/d3 don't dimly lit then I can quickly know what possible factory side effect reasons caused it. | 08:16 |
wolfspraul | and in the meantime, another bug fixed... | 08:17 |
wolfspraul | one step closer to world domination | 08:17 |
aw | wpwrak, but if the newest script it indicates likely in that way. I have no choice you know. :-) | 08:17 |
aw | wolfspraul, just packed the 3 sets to tuxbrain, today will go out. and now working on others. | 08:19 |
wpwrak | aw: my main concern would be that the dim d2/d3 means that something didn't finish before the script tried to restart. the dim d2/d3 itself doesn't worry me too much. | 08:19 |
wpwrak | s/means/could mean/ | 08:20 |
wolfspraul | aw: great | 08:21 |
aw | wpwrak, yes, that's also my thinking. so _if_ there's any way can let them not dimly lit immediately after reflash, i would prefer to use. | 08:21 |
aw | wpwrak, since I need to tell if the reconfiguration is done or not. :-) | 08:22 |
wpwrak | i would first look at whether those lock bits are really set. one could use my "upset" script that simply tries to write and sees what happens - brutal but efficient. but there is also a way to verify them without attempting a write. | 08:26 |
wpwrak | oh, and are we using the ID in factory-programmed OTP register of the NOR ? that should be a way to identify units, even across reflashing | 08:34 |
wpwrak | reading the lock bits should work as follows: (with fjmem) first, poke 0 0x90 | 08:39 |
wpwrak | then peek 2, peek 0x20002, peek 0x40002, etc. | 08:39 |
xiangfu | (we using the ID in factory-programmed OTP register of the NOR ? that should be a way to identify units, even across reflashing) sorry. what you mean? | 08:40 |
wpwrak | the lowest bit read back by the peeks would indicate whether the block is locked (D0 = 1) or not (D0 = 0) | 08:40 |
wpwrak | to verify that the read operation as such works, a read of 0, 0x20000, 0x40000, etc., should produce 0x0089 | 08:41 |
wpwrak | (ID) i mean that, if you get an M1 where the entire flash has been erased, can you still find out its serial number ? | 08:42 |
wolfspraul | the only serial number is the MAC address label on the bottom acrylic | 08:42 |
wolfspraul | there may be more serial numbers in the fpga somewhere, or other chips | 08:42 |
wpwrak | there's one in the NOR | 08:42 |
tuxbrain | I have just registered in Milkymist wiki, can any admin allow me to edit? | 08:43 |
wpwrak | (64 bits) | 08:43 |
sb0 | tuxbrain, you can't register on the milkymist wiki, otherwise it gets filled with spam | 08:44 |
sb0 | unfortunately the ssh key for the milkymist.org website is on my other computer in Berlin ... but xiangfu has another working one | 08:44 |
tuxbrain | mmm I'm registered.... or at least this is what the wiki says I'm logged in | 08:45 |
tuxbrain | but I can't edit | 08:45 |
sb0 | xiangfu, you need to edit wiki/.../specialuserlogin.php, uncomment the 'return' after the comment that says 'spam', create the account normally, and comment it again | 08:45 |
sb0 | huh, really? | 08:46 |
tuxbrain | aaah right I'm not registered | 08:46 |
tuxbrain | ok | 08:46 |
xiangfu | sb0, ok. got it. | 08:46 |
xiangfu | tuxbrain, wait one moment. | 08:47 |
sb0 | s/comment/uncomment and the other way around | 08:48 |
tuxbrain | xiangfu: no , I want it now :P (just kidding take your time) I have tons of items in my todo list to be attended | 08:48 |
xiangfu | tuxbrain, please try again :) finished comment. | 08:51 |
tuxbrain | ok great I'm logged in (this time not just in my imagination) | 08:53 |
xiangfu | ok disabled register again. :) | 08:53 |
tuxbrain | email confirmed , edit enabled, I will try to contribute as much as I can :) thanks | 08:58 |
wpwrak | hmm, the WE# test is a little annoying. i'm clearly still getting NOR corruption. but is seems as if it's a bit less than it used to be. need more samples to be sure, through :-( | 09:04 |
xiangfu | (ID in factory-programmed ... a way to identify units,) I got it. :) | 09:05 |
wpwrak | xiangfu: this script should dump all the lock bits http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1rc3/norruption/2/dumplock | 09:10 |
xiangfu | try it now in my m1. | 09:11 |
wpwrak | i couldn't test it yet, though, because my M1 is still hammering its NOR :) | 09:11 |
wpwrak | if you change the offset=2 at the beginning to offset=0, it should output lots of 0x89 instead | 09:11 |
xiangfu | all is 0x001D after lock flash | 09:15 |
wpwrak | everything, even the last value ? | 09:15 |
xiangfu | everything. | 09:16 |
xiangfu | all is 0x001D. | 09:16 |
xiangfu | here is my step: | 09:17 |
xiangfu | 1. reflash_m1 --lock-flash | 09:17 |
xiangfu | 2. ./dumplock | 09:17 |
wpwrak | hmm. the last one should be different. 0x001C or such. because the block at 0x6E0000 isn't locked | 09:18 |
xiangfu | 3. it give all 0x001D : http://pastebin.com/n0bGGZ5r | 09:18 |
xiangfu | 4. then I flashmem bios image to m1. without lockflash at the end | 09:18 |
xiangfu | 5. run ./dumplock again | 09:19 |
xiangfu | 6 get same as STEP_3. | 09:19 |
xiangfu | but ./upset give correct result. | 09:19 |
wpwrak | can you please try changing the offset to 0 ? that'll check if we're actually reading the right group of data | 09:19 |
xiangfu | after change to 0. all is 0x0089 | 09:21 |
wpwrak | excellent. now let's try offset=4 | 09:22 |
xiangfu | URJ_BUS_READ(0x006a0004) = 0x0001 (1) | 09:23 |
xiangfu | URJ_BUS_READ(0x006c0004) = 0x0001 (1) | 09:23 |
xiangfu | URJ_BUS_READ(0x006e0004) = 0x0000 (0) | 09:23 |
xiangfu | the last three lines. | 09:23 |
wpwrak | yes !! | 09:23 |
xiangfu | yes. we get correct result. | 09:24 |
wpwrak | aw: a new sword for you to slay the dragon: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1rc3/norruption/2/dumplock | 09:25 |
wpwrak | aw: this will check the lock bits without trying to change anything. the output should be 55 lines of the type URJ_BUS_READ(0x006a0004) = 0x0001 (1) and then one line URJ_BUS_READ(0x006e0004) = 0x0000 (0) | 09:26 |
aw | wpwrak, oh? this file is for 'jtag' cmd. | 09:31 |
wpwrak | it runs "jtag" for you :) as usual, fjmem has to be in the current directory | 09:35 |
wpwrak | mwalle: does urjtag actually have a preferred location / a search path for fjmem ? might be useful | 09:36 |
aw | wpwrak, okay..i need to run it. :-) | 09:36 |
xiangfu | wpwrak, why the offset is 4? should be 2! | 09:37 |
xiangfu | from the document | 09:37 |
wpwrak | xiangfu: heh, that's why i thought, too, at the beginning ;-) | 09:38 |
wpwrak | see note 3, though :) | 09:38 |
wpwrak | it also makes sense, because all quantities are 16 bits. but yes, they did a good job at making it confusing | 09:39 |
xiangfu | got it. thanks | 09:41 |
xiangfu | (confusing) yes. "This address is latched during a x8 program cycle. Not used in x16 mode" | 09:43 |
xiangfu | first time I read it like "This address is latched during a x8 mode. Not used in x16 mode" :( | 09:44 |
aw | hi, so BOTH (0x6a0004) = 0x0001 & (0x6e0004) = 0x0000, then "locked" or "not locked"? | 09:44 |
aw | i saw 55 lines. :) | 09:45 |
xiangfu | 0x6a0004) = 0x0001 is locked. | 09:47 |
wpwrak | aw: yes, the first 55 lines should all be 0x0001 = locked. then there's one more line (for the regular bitstream) of 0x0000 = not locked | 09:47 |
wpwrak | aw: if you have an M1 that you haven't locked yet, you could run the script on it. it should show you everything 0x0000 | 09:49 |
aw | wpwrak, aha...so (0x6e0004) is a start address of regular bitstream which doesn't need to be locked, and surely before that address is for rescue/standby bitstream, does I realize correctly? | 09:51 |
wpwrak | yes, exactly | 09:51 |
aw | okay, thanks. :-) | 09:51 |
wpwrak | 0x6e0004 is a control, to make sure we would actually see incorrect values :) | 09:52 |
aw | great, i should have seen this again: http://milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#Flash_Memory_Distribution | 09:53 |
aw | wpwrak, okay..thanks for this new sword. ;-) | 09:53 |
wpwrak | happy dragon-slaying ! ;-) | 09:56 |
aw | yupp...great tool. | 09:58 |
sb0 | new dates in London (Jon and friends) and Bergen at Piksel (me): http://www.milkymist.org/wiki/index.php?title=Main_Page | 11:15 |
sb0 | bbl | 11:15 |
wpwrak | kewl. with the lizards :) | 13:13 |
Fallenou | if someone want to come and show Milkymist : http://oshug.org/event/oshcamp | 13:34 |
Fallenou | I will be there I will bring a few stickers to give to people interested | 13:34 |
sb0 | lizards? | 14:12 |
wpwrak | mozilla | 14:15 |
wpwrak | anyone care to try this ? http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1rc3/norruption/2/dumpotp | 14:48 |
wpwrak | my OTP is 0x0A96 0x0324 0x0E00 0x2CCD followed by 4 x 0xFFFF | 14:48 |
wpwrak | the 0xFFFF are user-defined, so it's normal for it to be all ones. the rest is the unique ID from the factory | 14:49 |
sb0 | what do you want to do with it? | 15:00 |
wpwrak | it could be useful for identifying boards | 15:00 |
wpwrak | since the only ID they seem to have is a sticker (?) | 15:01 |
wpwrak | e.g., when a board is returned or such, find its production and repair history | 15:01 |
sb0 | hmm... let's not overdo it | 15:07 |
sb0 | sticker should be enough imo | 15:08 |
kristianpaul | stickers do not respond to scripts !! :) | 16:42 |
kristianpaul | and mac saved on flash can be lost easilly.. | 16:42 |
Action: kristianpaul install werner utils | 16:43 | |
kristianpaul | wpwrak: what are those poke for? | 16:45 |
kristianpaul | ahh | 16:46 |
kristianpaul | he ;) | 16:46 |
kristianpaul | wpwrak: http://pastebin.com/F1EqCUti | 16:46 |
wpwrak | thanks ! | 16:55 |
wpwrak | quite a lot of randomness. so they're not just serial numbers. good. | 16:55 |
kristianpaul | and what they are? | 16:56 |
wpwrak | the pokes send commands to NOR. NOR reads are like RAM reads, but NOR writes are special. | 16:56 |
wpwrak | the first poke switched the NOR into a mode where subsequent reads will read device information (instead of memory content) | 16:56 |
wpwrak | and the poke at the end switches the NOR back to normal operation | 16:57 |
mobileT | so | 18:11 |
mwalle | wpwrak: some time ago i tried to implement a command in urjatg to read the otp key, but my spartan 6 is an ES and the OTP is just 0xff... for me | 18:11 |
mobileT | aha | 18:12 |
mobileT | hi there | 18:12 |
wpwrak | well, with the nor it was easy :) | 18:16 |
mwalle | ah that was the nor flash | 18:19 |
mwalle | the spartan6 has some read only unique id, too | 18:19 |
mwalle | wpwrak: (search path) no | 18:24 |
wpwrak | (spartan id) that may be useful, too. in case the nor dies or gets swapped | 18:26 |
mwalle | wpwrak: the s6 may be swapped too ;) | 18:26 |
wpwrak | yeah, but it's usually swap-to-trash. not swap-to-other board :) | 18:27 |
wpwrak | and if both get swapped ... oh dear :) | 18:28 |
kristianpaul | hi mobileT | 18:30 |
mobileT | hiho | 18:51 |
mobileT | worst.. live.. cd.. ever! | 18:51 |
mobileT | :D | 18:51 |
kristianpaul | ah, i forgot to ask, bu i guess this OTP then programed by ramdon as you confirmed before | 20:17 |
wpwrak | random or pseudo-random, yes | 20:24 |
kristianpaul | how big is it? no more that few bytes i guess? | 20:28 |
wpwrak | the part you can program is 64 bits or 8 bytes :) | 20:30 |
kristianpaul | boring :) | 20:31 |
kristianpaul | so may be been _very_ carefull with urjtag erase flah commands, the locking feature could minic a rom? | 20:34 |
wpwrak | hmm ? | 20:34 |
kristianpaul | i mean several time had been mentioned the lack of a rom bistreaming/firmware to start a rescue mode | 20:37 |
wpwrak | well, yes. but what does urjtag have to do with it ? | 20:40 |
kristianpaul | oh yes sorry, the erase flash command is from flickernoise :) | 20:41 |
wpwrak | yeah. eraseflash from FN would be a problem :) | 20:42 |
GitHub188 | [clang-lm32] jpbonn pushed 58 new commits to master: http://git.io/bEYuPg | 20:51 |
GitHub188 | [clang-lm32/master] [driver] The -v option doesn't quoted the command line arguments for historical - Chad Rosier | 20:51 |
GitHub188 | [clang-lm32/master] [driver] For consistency, handle all shell special characters handled by the - Chad Rosier | 20:51 |
GitHub188 | [clang-lm32/master] Use APFloat::toString to print APFloats more precisely in the AST printer. Patch by Olaf Krzikalla. - Eli Friedman | 20:51 |
GitHub175 | [llvm-lm32] jpbonn pushed 10 new commits to master: http://git.io/e5QSFA | 20:51 |
GitHub175 | [llvm-lm32/master] Some fixes. - JP Bonn | 20:51 |
GitHub175 | [llvm-lm32/master] Corrected calling conventions to not put variadic arguments on stack by default. - JP Bonn | 20:51 |
GitHub175 | [llvm-lm32/master] Corrected i64 to be 32bit aligned by default. - JP Bonn | 20:51 |
sb0 | http://www.youtube.com/watch?v=tCRPUv8V22o | 23:43 |
--- Sat Oct 15 2011 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!