<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
<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: 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
<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>
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
<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?
<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>
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>
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. :)
<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 :)
<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