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