<wpwrak> xiangfu: i've structured the description of that boot process a little bit: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/jtag-boot/README
<xiangfu> wpwrak, great. thanks.
<xiangfu> wpwrak, my m1 can not boot again. I am reading the standby.bin back now.
<wolfspraul> xiangfu: ha :-) you bricked it, broke it? tested to death?
<xiangfu> wolfspraul, no. just normal use. the last thing I do is test werner new 'boot.bit'.
<wolfspraul> ok
<xiangfu> read standby 3 times. http://pastebin.com/6khEnJZ8
<wolfspraul> xiangfu: your standby got modified? was it locked?
<xiangfu> wolfspraul, I can not make sure if it locked. since I test 'reflash_m1.sh' a lot.
<wolfspraul> ok
<wolfspraul> well you can also keep it unlocked, since if there is a write bug somewhere that is 'masked' by locking, it's better if you see it so we have a chance to track it down (the write bug)
<GitHub192> [scripts] xiangfu pushed 1 new commit to master: http://git.io/5h6rag
<GitHub192> [scripts/master] compile-flickernoise, use full path for MILKYMIST_GIT_DIR - Xiangfu Liu
<GitHub30> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/Numakw
<GitHub30> [flickernoise/master] flash.sh make parameters more flexible - Xiangfu Liu
<GitHub110> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/GlgyWQ
<GitHub110> [flickernoise/master] Makefile: add flash, it will flash both rescue and regular partitions - Xiangfu Liu
<GitHub98> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/ia35xQ
<GitHub98> [flickernoise/master] .gitignore: add TAGS - Xiangfu Liu
<wpwrak> xiangfu: (can't boot) hmm, with jtag-boot ? did it work before ?
<xiangfu> wpwrak, no. not relate to jtag-boot. it's just the (write bug) I think.
<wpwrak> xiangfu: can you run the CRC check ?
<xiangfu> wpwrak, I am not sure what command I have executed. I recently test a lot reflash.
<wpwrak> xiangfu: and can you please download your standby partition via JTAG ?
<xiangfu> wpwrak, too bad. I reflash my m1. :(
<xiangfu> wpwrak, standby.bin yes. I have download 3 times.
<xiangfu> wpwrak, they are all same.
<wpwrak> my M1 is now in its 669th power cycles and still seems to be healthy. so if you really were able to reproduce the NOR corruption, then i envy you :)
<wpwrak> (reflash) ah, so it's already gone. pity :-(
<xiangfu> the diff is here: http://pastebin.com/6khEnJZ8
<wpwrak> (download standby) did you download (= read) it before or after reflashing ?
<wpwrak> ah, great. checking ...
<xiangfu> before
<wpwrak> ah yes, the usual single-word NOR corruption
<wpwrak> now ... what exactly did you do in the session before it happened ?
<xiangfu> I last command I remember is tested the jtag-boot yesterday night.
<xiangfu> before that I leave the m1 for ~40 hours
<xiangfu> before the 40 hours I think I test reflash_m1.sh a lot
<xiangfu> wpwrak, what should I do when I meet the NOR corruption next time? 1. check CRC 2. read standby.bin 5 times 3. ?
<wpwrak> when you tested jtag-boot, were you doing a regular boot (through standby) before or after ?
<wpwrak> xiangfu: yes, reading standby.bin and running the CRC check to see if there's damage in other partitions as well
<wpwrak> xiangfu: also, record what happened since the last time the M1 booted (through standby)
<wpwrak> was your standby partition locked ?
<xiangfu> wpwrak, no. I am not doing regular boot either before nor after. what I do is: plug the m1 power cable, test jtag-boot three times(I am not wait m1 to rendering, just saw some output from serial console then jtag-boot again), 3, I just un-plug the power cable
<xiangfu> wpwrak, (locked) cann't remember that. test reflash_m1.sh a lot.
<wpwrak> okay. so you did ... 1) some things yesterday, including a lot of reflashing; 2) booted M1 regularly and left it running for ~40 hours; 3) while still with the same ~40 hours uptime, reboot via jtag-boot three times; 4) powered down over the night/morning; 5) when trying to power up, it didn't start. is this correct ?
<xiangfu> 2) not booted m1. just leave m1 there without power for ~40 hours
<wpwrak> ah, i see
<wpwrak> so at 3), you powered up and rebooted via jtag-boot. before jtag-boot, did you see if the LEDs were normal for standby ?
<wpwrak> oh, nice. i have a standby failure, too :)
<wpwrak> how do i read back standby.bin ?
<xiangfu> wpwrak, (LEDs) didn't notice that. but great. you got the failure.
<xiangfu> wpwrak, then reflash_m1.sh --read-flash
<xiangfu> it will download fjmem.bit automatic
<wpwrak> thanks ! nice :) it's reading ...
<xiangfu> it will output the read back standby.bin path when finish read
<xiangfu> ~700 power cycles you finally get the failure.
<xiangfu> very aggressive :D
<wpwrak> yeah. took some 12 hours. glad i didn't have to press any buttons ;-)
<wpwrak> aw: do you still remember what you usually did before you got those NOR corruptions ? i.e.,did you usually boot into flickernoise and see the M1 render ? or did you just go to the test software or the rtems shell ?
<aw> wpwrak, when got NOR corruptions, most that I was testing "rendering test", i.e., repeatedly following steps:
<aw> 1. power on
<aw> 2. press middle btn
<aw> 3. waiting for rendering led is fully on
<aw> 4. once monitor screen shows up video effect then start to count 30s
<wpwrak> aw: what did the M1 render at that time ?
<aw> 5. power off
<aw> be noticed that duration is roughly 3 ~ 5 seconds between step 1 and step 5
<aw> wpwrak, what?
<aw> it's rendering that screen shows video effect.
<aw> "what did the M1 render at that time ?"  --> what you wanted to say?
<wpwrak> 3-5 seconds from 1 to 5 ? or from 5 to 1 ?
<aw> from 5 to 1
<Thihi> Obviously 5->1 since 4 has 30 seconds wait
<wpwrak> which patch did it show when rendering ? the fullscreen camera (the default setting) ? or something else ?
<wpwrak> Thihi: just checking ;-)
<aw> wpwrak, just the first patch video effect(default setting), I don't try to press SW1 to go next patch.
<wpwrak> aw: great, thanks !
<Thihi> wpwrak, yeah, better safe than ...
<aw> if later you see 'dimly lit' on D2/D3 after power-cycled, then you get probably the err you want. ;-)
<wpwrak> nice. at least i got a double failure for all my insistence: http://pastebin.com/eLSUa1HZ
<aw> wow...double
<wpwrak> i hadn't checked the status for some ~150 cycles, though. so they probably developed in successive runs.
<wpwrak> now, how do i run the CRC check ?
<aw> wpwrak, how many channels on your scope? maybe a six-channels to see 'power up/down ramp'?
<wpwrak> aw: (six channels) yeah, i wish ;-))
<wpwrak> aw: i have a lousy 2 analog channels, just like you
<aw> wpwrak, did you install 'flterm' already?
<aw> wpwrak, ha..i see
<wpwrak> i don't know flterm.  i just used good old neocon
<wpwrak> (for the serial console. maybe flterm can do more than that, though ?)
<aw> wpwrak, good question, but i don't know them.
<aw> second
<aw> commands: $ flterm --port /dev/ttyUSB0 --kernel boot.4e53273.bin
<aw> xiangfu, can you point wpwrak that how to install 'flterm'?
<wpwrak> ah yes, i see that flterm has some extra features. building ...
<aw> xiangfu, i meant that the link of flterm server
<aw> wpwrak, aha...great
<wpwrak> i'm just cloning git://github.com/milkymist/milkymist. then i have everything :)
<xiangfu> yes
<xiangfu> you needs clang installed
<wpwrak> for flterm ?
<wpwrak> naw, compiles flawlessly with gcc ;-)
<xiangfu> wpwrak, I got a error when use gcc "flterm.c:36:17: fatal error: sfl.h: No such file or directory" so I just install clang :)
<wpwrak> you forgot the -I. ;-)
<wpwrak> frame.payload[0] = (current_address & 0xff000000) >> 24;
<wpwrak> someone's very afraid ;)
<wpwrak> ok, flterm is running.  i'm at the rtems shell. is this normal so far ? how do i start the crc check ?
<xiangfu> wpwrak, no. you should not boot to rtems.
<xiangfu> wpwrak, when BIOS is start, keep press 'ESC' in flterm. goto the BIOS console.
<wpwrak> ah, good. i'm there
<xiangfu> the flterm command should like "flterm --port /dev/ttyUSB0 --kernel boot.4e53273.bin"
<xiangfu> then input 'serialboot'
<wpwrak> yes, that's what i have
<wpwrak> aah, nice
<wpwrak> very good. only standby,fpg has a CRC error
<xiangfu> after boot to test image. the first 'a' is for CRC
<xiangfu> definitely  :-)
<xiangfu> I mean it should be.
<wpwrak> naw, we don't really know yet what's going on. but i'm glad only standby got hit
<wpwrak> by the way, the link to fjmem.bin.bz2 on http://milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#download_fjmem is wrong
<wpwrak> not sure what the "official" location should be. http://milkymist.org/updates/2011-07-13/for-rc3/fjmem.bit ? sounds a little temporary
<wpwrak> in fact, the whole http://milkymist.org/msd/ doesn't exist anymore (it's referenced elsewhere on that page)
<xiangfu> I am use "http://milkymist.org/updates/2011-07-13/for-rc3/fjmem.bit" in reflash_m1.sh, there is no fjmem.bit.bz2 at that time.
<wolfspraul> xiangfu: I don't understand 'for-rc3' either
<wolfspraul> what is that?
<wolfspraul> I would think our releases are binary compatible with rc2 and rc3?
<xiangfu> those files only needed by factory release.
<xiangfu> factory reflash I mean
<wpwrak> interesting .. reflashed standby and it still doesn't want to configure. let's see what happened ...
<xiangfu> wpwrak, after reflash, sometimes needs re plug the power cable.
<wpwrak> yes, i did that (via labsw). i didn't to the eraseflash, maybe that's the problem. anyway, i'm downloading the standby partition, so i'll see in a moment what's wrong
<wpwrak> oh, cute. it's byte-swapped ;-))
<wpwrak> did i miss then "endian" command ... ?
<wpwrak> hmm, apparently
<wpwrak> let's do it again then
<xiangfu> 'endian big'
<xiangfu> in jtag batch file
<wpwrak> yeah. must somehow missed it in copy & paste
<wpwrak> standby is up again. victory ! :)
<wpwrak> thanks ! both links in  http://milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#pre-compile_images  are broken, too
<xiangfu> fixed :)
<wpwrak> kewl. thanks ! the 2nd one would have been hard to guess :)
<xiangfu> the 'reflash_m1.sh' support it. all you need to is './reflash_m1.sh --snapshot milkymist-firmware-09072011-0325'
<xiangfu> :)
<wpwrak> heh :) reflash_m1.sh does a bit too many things for these experiments :) i prefer the low-level commands, so i see what i'm doing. e.g., i want full control over the locking
<xiangfu> yes. sure.
<xiangfu> the latest milkymist source code not working. I have tried the build all images today. after boot to flickernoise, the screen keep black. and rtems shell also dead. :(
<xiangfu> I am try to write the pre-compile patches source code.
<xiangfu> I will use CRC result as the compiled patches file name. like Lekernel - FullScreen Video-in Preview.fnp.87c1d210
<xiangfu> since the rtems already support crc
<wpwrak> sounds good. and crc is fast :)
<wpwrak> i also wonder if the first patch shown shouldn't be something other than the camera fullscreen. if you don't have the camera connected (or if it doesn't work), you just get a blue screen. not a nice welcome.
<xiangfu> maybe there is one options in patch files in future, like "require_videoin" , if no camera connect, just skip the patch.
<xiangfu> ok. Ralf finally merger the small patch to upstream. let's test a little.
<GitHub185> [scripts] xiangfu pushed 1 new commit to master: http://git.io/aKzK-w
<GitHub185> [scripts/master] compile-lm32-rtems: update gcc patch, rtems upstream merged hardware divider patch - Xiangfu Liu
<lekernel> xiangfu, you can simply check if the patch sets the video_a variable
<lekernel> this requires some messing up in fpvm though... but i'll need to refactor that part of the code to support more variables anyway
<lekernel> so just wait for now
<xiangfu> checking now
<xiangfu> without any patches installed. flickernoise works fine. now copy some patches to m1.
<lekernel> xiangfu, btw, you are using git head + rtems cvs?
<lekernel> btw,  everything rtems is merged upstream now
<lekernel> it should "just work" except for the "lag" bug I mentioned
<lekernel> wpwrak, I wonder if the bug is also able to unlock flash sectors...?
<xiangfu> lekernel, I use all GITs under github../milkymist/...
<lekernel> xiangfu, ok. i'll probably remove the "rtems" repository at some point - there are issues (like zlib) with git-cvs, everything is upstream atm, and there's no immediate need for large RTEMS patching
<wpwrak> lekernel: good question. for now, i'm trying to make it happen a little more quickly. two hits in 12 hours is a bit slow ...
<wpwrak> lekernel: xiangfu had a corruption today too, but doesn't know if he had the NOR locked at the time or not
<xiangfu> lekernel, when I start one patch(Illusion & Che - The Piper.fnp) the rtems shell will stop working. after exit the rendering mode. the flickernoise became very very slow like some thread take 100% cpu, and the [performance] windows keep display "Compiling patches..."
<lekernel> xiangfu, yes, this is the lag bug
<lekernel> it triggers when you render a patch, or use the variable monitor or video input preview
<lekernel> it appeared when updating RTEMS
<xiangfu> is there a patch for it ?
<lekernel> no
<lekernel> I don't know what's happening. maybe some IRQ handling fuckup - the LM32 code was totally broken in the latest RTEMS version, even a "hello world" wouldn't work
<lekernel> I fixed it a bit and now Flickernoise can boot, but obviously there are more bugs
<lekernel> it can be a FN bug though (race condition or such), which is simply uncovered by a different behaviour of the new RTEMS version ...
<xiangfu> 'Power off' and 'Reboot' buttons not working.
<xiangfu> 'shutdown' command in rtems shell not working, but 'halt' works fine
<xiangfu> not working mean make system hang. have to press all three buttons for reset
<lekernel> after the lag bug manifested itself, or every time?
<xiangfu> everytime. what I do is:   boot to m1 --> click 'reboot' in flickernoise --> then system hang
<lekernel> ok
<lekernel> there has been major changes in that part of the code
<lekernel> let me find the rtems pr again
<lekernel> I remember testing it though...
<xiangfu> when click the 'Power off' and "reboot" buttons, only flickernoise hang. the rtems shell still work.
<xiangfu> input 'shutdown' in rtems shell. the shell hang. the flickernoise just like meet the lag bug
<lekernel> ah, this one is interesting
<lekernel> rtems_shutdown_executive() already took a uint32_t as a parameter.  This value is now stored in CPU0's idle task return status
<xiangfu> something wrong inside "rtems_shutdown_executive"
<lekernel> maybe the LM32 port does some tricks with the idle task return status
<lekernel> which could explain both bugs
<xiangfu> googling 'lm32 idle task return status' :)
<lekernel> btw, I used GDB during the lag bug, and it seems the CPU spends lots of time in the idle task
<lekernel> sounds like a scheduler wreck
<wpwrak> newflash: after about 600-700 quick cycles (power cut while rtems is still booting), standby its unhappy. and indeed, there's a single-word corruption: http://pastebin.com/VmDPzDkL
<wpwrak> checking the other partitions ...
<roh> nand always has corruption. thats why one has to use ecc and badblocks.. or did i miss something?
<lekernel> it's nor
<roh> well.. then we know it should be error free on buying it. but it also will degrade. not that fast and hard, but i guess some ecc isnt a bad idea
<lekernel> this is incredibly annoying. had you locked the sector that had the corruption?
<lekernel> and is it still locked now?
<wpwrak> again, only standby.fpg is affected
<roh> lekernel: agreed. flash is purely annoying
<wpwrak> no, i didn't try locking yet. first, i want to narrow down how to make it happen.
<lekernel> ah, ok :-)
<wpwrak> but i guess i can give it a run with locking for a while. this time it tool only ~4 hours before it struck.
<wpwrak> s/tool/took/
<lekernel> btw, if you erase the flickernoise partition, the BIOS will report a boot error and stay there
<lekernel> then, if you still get corruption, it means it's not a flickernoise/rtems bug
<wpwrak> hehe, that would help against being slow with Esc ;-)
<wpwrak> ah, i see
<wpwrak> by the way, the message "I: Press Q or ESC to abort boot" seems to be misleading. at least on serial, "q" doesn't seem to have any effect. Esc works as expected, though.
<lekernel> it's a capital Q
<wpwrak> you bastard ;-)
<wpwrak> indeed
<wpwrak> maybe say "Shift+Q" ? after all, i don't have an "ESC" key either. just "Esc" :)
<kristianpaul> lekernel: had you done something with milkymist + osc from puredata?
<lekernel> no
<kristianpaul> I'm a stub in puredata but i posibly will demo milkymist this october 28 to some local media*lab people
<kristianpaul> okay, so arduino and midi should be enought to start.. and a simple osc client i guess
<kristianpaul> btw for your arduino workshop what are you connecting to the arduino to interact with people?
<kristianpaul> I mean some push buttons, light sensors?
<kristianpaul> i still dont see a clear use for and arduino and milkymist for VJing..
<lekernel> you can send OSC from puredata directly into the M1 via the local ethernet network
<kristianpaul> (directly) yes i'm aware of that
<lekernel> it's not exactly for vjing, it's for more general performances... there's a small community of people who like to have all sorts of sensors on stage :-)
<kristianpaul> he, may be some big keyboard interfaced with arduino to the milkymist
<kristianpaul> so people can jump and modify running patch :)
<kristianpaul> lekernel: (sensors) got it :-)
<kristianpaul> Anyway thats good, people feel better if can do soemthing arduino* most of the time
<kristianpaul> gotta go read you later !
<aw> rc3 case assembly status:
<aw> 1. so far now assembled 9 sets, some of them were shipped out. Five sets are packed for sale, one is in rendering test for one hour.
<aw> 2. here will continue to assemble the rest
<aw> 3. two problems of 'clean' issue I met now: you can check the pictures folder here: http://downloads.qi-hardware.com/people/adam/m1/pic/case_assembly/
<roh> ah. nice. how did you get the shield so nice and clean?
<roh> i tried using high-percentage alcohol (ethanol) to get rid of the spots
<aw> 3.1 one is clean for shielding-sheet, the incoming parts are not always good surface on metal side, so I have to use liquid composed of "Surfactant" elements : http://en.wikipedia.org/wiki/Surfactant
<aw> a liquid of that I can get from normal cleaner-kitchen-used to clean it.
<aw> 3.2 the other one is "bits and small pieces" after tearing off films, you can see those pictures shown up.
<roh> sure. thats normal. but much better than lasering without film (which means one gets a lot of ugly residue from the lasering itself
<aw> all the acrylic side case I have to clean it with a 3M tape:
<roh> looks like its intended to hold bandages together
<wpwrak> roh: by the way, is there also acrylic that's not "clear as glass" ? maybe a bit of milkiness could make the whole thing less sensitive to fingerprints and such
<aw> i tried to use normal tape in reel, then the acrylic surface will be adhered that normal tape's glue which things get worse.
<aw> i also tried to use our official "Qi- Cleaner" item 07: http://en.qi-hardware.com/wiki/File:06-accessories.JPG
<aw> also things won't be get better.
<wpwrak> "official qi cleaner" is smell a branding opportunity ;-))
<roh> wpwrak: of course. you can basically get all colors. its just 'paint' ;)
<aw> so far now I ONLY use 3M tape to absorb those irritating clean jobs but just will take me a lot of time to do every set. phew~
<roh> well.. inside the acryllic. mixed into the transparent
<aw> so everytime before I cover all side-case, I have to clean all inside surface of case
<aw> and after assembly then clean/absorb outside surface.
<wpwrak> aw: have you considered an ultrasound bath ? not sure if it would be good at removing the lasered remains, but it worked quite nicely for removing the more obnoxious dust in my milled FR4 boards
<wpwrak> there's a cheap CC one that may be big enough ... googling ...
<wpwrak> err, "cheap" is redundant ;-)
<aw> so those "bits and small pieces" are residual of <Frictional force-oriented, Coherency and static electricity>.
<aw> wpwrak, good thinking
<aw> but I've still have no suitable ideas for current goal
<roh> so maybe a electric cloth could help?
<roh> i mean.. one thats non-isolating to break up the static which keeps the protective foil on. or how does that work?
<aw> roh, yup...possible, also a good idea
<aw> i was thinking to use air blow from compressor for it
<aw> but didn't do it since this will messy my room though. also not good idea
<wpwrak> aw: you may be able to find this kind of ultrasonic cleaner at your electronics mall. you'd have to bring a M1 front or bottom plate to check the size, though, since the specifications can't be quite trusted
<aw> roh, yes, i just need to find an electric cloth.
<aw> wpwrak, agreed
<wpwrak> aw: (this device is even available in argentina. alas, it's probably too rough for electronics. so i bought a different model that is smaller and has less power)
<aw> so i just posted here and tired to know if there's quick and easy way i can use. ;-)
<roh> not really. i use fingernails and a clean cloth to wipe it afterwards
<wpwrak> aw: i think you need to experiment a bit. one problem is that the surface scratches easily. otherwise, you could use something like this: http://www.transtools.co.uk/store/prod_4302/geologist-tools/estwing-erc/7c-geologist-rock-chisel-wide-with-rubber-grip-and-striking-cap.html
<aw> wpwrak, yup...i'm search web here firstly
<wpwrak> if an ultrasound bath works, that would be the most convenient solution. you just put the stuff in the bath and let the machine work for a few minutes while you have a beer ;-) what i don't know is if the ultrasound bath would be strong enough to remove these residues.
<aw> wpwrak, so you always use ultrasound bath to remove the more obnoxious dust in all your milled FR4 boards?
<roh> i dont believe so. also you would need to single out parts. if they touch inside the bath they would scratch
<roh> -> food.
<aw> what's it inside your ultrasound bath's lumen?
<wpwrak> roh: you could probably separate them with something rubberish. i wouldn't worry about scratching. the force is very gentle. but if you put them on each other, the liquid couldn't reach everwhere
<wpwrak> aw: volumen ? hmm, mine has about 1 l, i think. checking ...
<aw> i used 3M since I believe its elements won't scratch glass surface also no residaul.
<wpwrak> (my ultrasound) it's less. about 0.5-0.6 l. mine would be too small for the M1 boards. i bought it for electronics, mainly for flux removal
<wpwrak> i tried it for removing milling residues the first time for the labsw face plate. and it worked quite well. of course, the water is now full of little FR4 dustballs, so i'd drain it before doing electronics again.
<aw> so for flux and dust while milling FR4 boards....sounds good but not sure if can remove my status, since the dust after lasered process.
<wpwrak> yes, i honestly don't know whether it would work for M1 or not
<aw> hm...water
<wpwrak> i cleaned mine manually. didn't think of putting it in the ultrasound
<wpwrak> (water) or you can also use other liquids if you want. e.g., alcohol. be just tap water should be sufficient in this case. for electronics, i use de-mineralized water (car supplies), to avoid adding salts
<wpwrak> s/be //
<aw> http://www.codyson.com.tw/products.html   here have alot, just need to know if can solve my condition.
<aw> wpwrak, no on alcohol. ;-) i tried my old rc2 case which is bad. also if using alcohol, needs to use very softy cleaner like Qi, but still scratch a little. :(
<aw> mm... de-mineralized water.
<wpwrak> "The requested URL /english/index.php was not found on this server." grrr :)
<GitHub97> [rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/33cc35a0d49fef709e697670c37841cbd49a07fb
<GitHub97> [rtems-yaffs2/master] Moved memory management. - Sebastian Huber
<wpwrak> but the descriptions are mostly english anyway. nice
<aw> wpwrak, yes
<wpwrak> aw: for this kind of work, you'd want to have one with a lot of power. ultrasonic cleaning is used for many things and the devices vary in their specialization. for example, it's used for cleaning fuel injectors for cars and such. some of those cleaners have a lot of power.
<GitHub19> [rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/05a982c0f544a0ff32092307253240fa73126f8a
<GitHub19> [rtems-yaffs2/master] Avoid NULL pointer access. - Sebastian Huber
<wpwrak> aw: for electronics, you want very little power. plus, you want to vary the frequency, so that you don't accidently hit the resonant frequency of any chip, and damage it.
<aw> wpwrak, yes, need to study such product more
<aw> what frequency you're using now?
<aw> i meant for FR4 pcb dust/flux goal. :)
<wpwrak> mine has constant frequency but it's relatively weak. so it's a compromise. it's not idea for electronics, but i hope it won't mistreat them too badly. the problem is that the "nice" ones with variable frequency are hard to get here in argentina. they exist, but what i found costs about 3-4x as much as one of the simpler models, and i didn't want to spend a lot on my first experiments with ultrasound.
<wpwrak> lemme check the frequency ...
<aw> oah~ sure the first equipment you tried, get a lower cost product firstly
<wpwrak> about USD 150
<GitHub86> [rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/5e960a990b062988ce2fb1dc883baff2292c618e
<GitHub86> [rtems-yaffs2/master] Implemented data synchronization. - Sebastian Huber
<aw> wpwrak, okay..thanks, btw i have to study more and ask vendor. ;-)
<wpwrak> let's hope they can help you. having to manually clean up all these cases sounds rather nasty :)
<GitHub8> [rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/2def83667b99c3f196a030687e69ea6470400ec4
<GitHub8> [rtems-yaffs2/master] Check the device read-only property during mount. - Sebastian Huber
<aw> wpwrak, yes, really nasty and unproductive. :(
<aw> roh, thanks for your electric-oriented cloth idea, need to check/ask. ;-)
<roh> no clue if it works
<wpwrak> aw: i think for the next production run, you should invite wolfgang and jon to visit you. then they can help with all this nasty stuff :)
<aw> roh, just need to try/work out but not now though. ;-)
<aw> wpwrak, ;-)
<aw> thanks guys, good night.
<wpwrak> roh: maybe you can ask the laser-cutting fab what they recommend.
<roh> they cut without foil and ignore teh residue
<roh> but it looks ugly then and foggy
<wpwrak> maybe they know what other customers do, if there are any others who prefer to have the foil
<GitHub119> [rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/6c4875892e2710a9ff106136d469850cd0ced8ca
<GitHub119> [rtems-yaffs2/master] Changed seek mechanic. - Sebastian Huber
<GitHub73> [rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/6b598375456932c774c4ac64dd802e8e3e732343
<GitHub73> [rtems-yaffs2/master] Use UNIX time instead of seconds since boot. - Sebastian Huber
<roh> wpwrak: i think i was the biggest of their customers yet. mostly they only do small stuff, art etc
<roh> wpwrak: http://lokolo.eu/
<wpwrak> roh: oh, i see :)
<kristianpaul> roh: nice link !!
<kristianpaul> like lamp s a LOT
<roh> kristianpaul: check out http://opendesigncity.de/ .. a more commercial place that raumfahrtagentur.org but they have quite some lamp-enthusiasts
<lekernel> what's lamp? linux apache php mysql?
<larsc> :D
<larsc> i think they talk about the kind of lamp that emits light
<kristianpaul> :)
<kristianpaul> yup
<wpwrak> with locking, 11112 cycles without trouble so far. encouraging.
<wpwrak> oops, typo. only 1112. still not quite twice the number of cycles i needed until a certain first failure before.
<wpwrak> i'll let it run until 2000 or such
<wpwrak> whee, looks cool !
<wpwrak> btw, standby still looks good after ~1800-2000 cycles. (there's a bug in labsw that makes it miss some cycles)