#milkymist IRC log for Thursday, 2011-09-22

wolfspraulhey btw, I just did a little counting01:31
wolfspraulthe rc3 yield as of right now is 49 100% perfect units01:32
wolfspraul49 out of 9001:32
wolfspraulthe original goal was 80 (out of 90)01:32
wolfsprauladam takes a few days off from tomorrow (friday) to tuesday, and then he's back at bringing this up more01:34
wolfspraulnext target: 6001:34
wolfspraul:-)01:34
wolfspraulwho knows maybe in the end we can get close to the original 80... too early to tell now, have to wait and see which troublemakers remain at the end and what analysis shows for them01:35
wolfspraulaw: thanks a lot for the hard and persistent work!01:38
wolfspraulhttp://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Test_Results01:38
awwolfspraul, you are welcome, i ought to. will back to continue rest.01:40
wolfspraulhe :-)01:42
wolfspraulwerner would love that typo01:42
wolfspraulaw: you probably mean "back to continue test" not "back to continue rest"01:42
wolfspraulbut if you want to rest a little - GO AHEAD! :-)01:42
awwolfspraul, oah~ yes, typed wrong...is "continue to test"..:-)01:44
wpwrakgood typo indeed :)03:04
wpwrakbtw, good news: http://downloads.qi-hardware.com/people/werner/m1/perf/chart-20110921b03:05
wpwraki now made the test for equivalent output more comprehensive/strict. and the latest version(s) produce perfect matches for all patches we have.03:06
wolfspraulwow03:06
wpwrakthe generated code is now a bit less efficient that what i had on monday. so now there are four patches that get longer even with optimization. all the rest is about the same and some significantly more compact.03:08
wpwrakwithout optimization, it still gets a bit worse. in all cases, the new scheduler is a lot faster than the original one. with profiling, no optimization (-O), on x86-64, and including parsing and all other compilation steps, on average about 10x faster.03:10
kristianpaulwow indeed03:11
wpwrakthe next step is to build flickernoise and see how it works in its native context. i would expect the new scheduler to optimize (-O) better than the old one, because all frequently traveled code paths are in the same compilation unit and there are no terms greater than O(n^2) in any of the processing.03:12
wpwrakand even O(n^2) would be a degenerate case. things like foo = <expression> and then gazillions of varN = fn(foo), i.e., everything becomes executable after the first operation03:14
wpwrakthe O(n^2) would hit the optimizer (the longest critical path first algorithm) hardest, because it always considers all available choices. (i could defang it with a merge sort, but that's probably excessive)03:16
wpwrakof the bad things that may still happen, we have the relatively inefficient parser. it relies heavily on string compares and identifier lookups are always O(n*m) while they could be O(m) or at last O(m+C*log n). n would be the number of known identifiers, m the average length of an identifier, C a constant.03:21
wpwrakbut we'll see. maybe it doesn't matter so much and the scheduler dominates.03:23
wpwrakwolfspraul: in what categories do the remaining gremlins in M1 fall ? i know we have a few (2 ?) "NOR suddenly going completely mad" cases, which may be damaged chips, but what are the rest ?03:33
wolfspraulhaven't tried to categorize yet03:39
wolfspraulsorry bbiab03:40
wpwrakthen i guess, while aw is taking his days off, wolfgang will be data mining in the mines of mordor :)03:45
larscone bug to break them all!03:51
wpwrakthat would be too easy ;-)03:54
wpwraksometimes i hate statistics. after realizing that the NOR corruption distribution seems to lack a very "late" corruption, my M1 promptly proceeded to have a run that takes forever to have a corruption. now in the 4th day ...03:57
kristianpaul:/03:58
wpwraki somehow suspect that temperature does have an effect after all. the last days were relatively warm (today, the first day of spring brought excellent weather)03:58
kristianpaul(warm) good !!03:59
larsctime to make room in the fridge03:59
wpwraki might have to return to the idea of putting the M1 into the fridge ... well, i could also cool my guest room down to 18 C and move things over there04:00
wpwraklarsc: yeah :)04:00
larscany suspicions what might case the corruption?04:01
wpwrakkristianpaul: of course, outdoors events in winter may be about the last places where you want a surprise NOR corruption :) at least they should be less common than hot indoors events04:01
wpwraki suspect it's some glitches caused by power ramping down unevenly04:02
kristianpaulthere is no winter here ;)04:02
kristianpaulramping?04:02
kristianpaulleakage?04:02
wpwrake.g., I/O power still good but FPGA core power dropping out of range, and the core then acting crazy04:03
wpwrakafter cutting power04:03
wpwrakadam documented this here: http://en.qi-hardware.com/wiki/File:M1rc2_powerOnOff_sequences_manuscript.jpg04:04
larscbut it should be possible to powerdown the flash before the fpga, or not?04:04
wpwrakwith a little hardware change, we could hold it in reset, yes04:05
wpwrakalas, the current reset circuit only does this reliably when powering up, not when powering down04:05
larscbut there is nothing on the board which asserts reset globally if the voltage drops below a certain threshold?04:10
wpwraka) there's no global reset, and b) the voltage the reset monitors is 3V3, not the 5 V input. so if the input drops but one rail stays up longer than the others, things can get nasty04:13
wpwrakhttp://milkymist.org/wiki/index.php?title=RTEMS_build_instructions  "This page has been accessed 2,936 times."  wow !04:41
wolfspraulwpwrak: back. I think it's too early to categorize already. let's wait until more dust settles.05:20
wolfspraulthere are probably a lot more low hanging fruits in terms of boards that will pass all fixes and tests just fine05:21
wolfspraulthen we focus on analyzing the rest05:21
wpwrakgood. let's hope for the best then :)05:22
wpwrakthe ones with mad NOR will be tricky05:22
wpwrakwe should try to see if we can detect them reliably with a boundary scan05:23
wolfspraullet's see what you find in the end05:23
wolfspraulif you feel you can reliably reproduce the nor corruption, one angle is to manually rework a board with the planned rc4 design (if that is possible)05:24
wpwrakno, i mean the ones where the NOR gets some oscillations. not the single-word corruption05:24
wolfspraulincluding gate and 4.4v reset ic05:24
wolfspraulif that prooves that the nor corruption becomes unreproducible, at least we have an exit path05:24
wpwrakyup. i think for NOR corruption the path is clear. just need to find the hidden variables :)05:24
wolfspraulI'm not clear about the difference between nor oscillation and single-word corruption right now05:24
wolfspraulwaiting for dust to settle...05:25
wolfspraulmeanwhile I feel good about the rc3 we sell05:25
wolfspraulAdam hasn't seen a single problem in 49 boards now05:25
wpwrak(the two types of NOR corruptions) i think they're radically different. single-word corruption seems to affect all boards and the cause appears to be relatively benign (some glitch). the oscillation is signals that should be unrelated getting synchronized, with a strong smell of chip-level damage.05:27
wolfspraulwhich chip? the nor chip?05:27
wolfspraulthen we just replace it :-)05:27
wpwrakwell, NOR problems actually. i'm not sure if we;ve actually seen corruption connected to the oscillation05:27
wpwrakprobably the FPGA05:27
wolfspraulah ok05:27
wpwraktrickier :)05:28
wolfspraulthen replace that, or write off the board05:28
wolfspraulxray etc will also still come05:28
wolfspraulwhat do you mean with "some glitch"?05:28
wpwraklet's hope the number of such boards stays around 2. i wouldn't really trust a board where the FPGA has been reworked.05:28
wolfspraulyou mean something fixable in software/soc ?05:28
wolfspraulwhy not [fpga rework]05:29
wpwrakaccording to joerg, the smt fab grade xray won't show anything. but we can of course try. maybe there are surprises.05:29
wolfspraulthe smt fab xray is only good for checking the soldering joints05:29
wpwrak(49 good boards) yes, it seems we have a neat division between trouble boards and regular boards. that's encouraging.05:29
wolfspraulit cannot see much inside a chip, unless a really big burn maybe05:30
wpwrak(fpga rework) seems difficult -> good chance of creating new/more problems05:30
wolfspraulnah, that's why we run tests afterwards05:31
wolfspraulI can still use such boards, for example for internal units (like my own, xiangfu, sebastien), or for journalist review units, etc.05:31
wpwrakwhich may or may not catch them :)05:31
wpwrakof course, yes05:31
wolfspraulthen the test needs to be improved05:31
wolfspraulI trust the test, by definition05:31
wpwrakthe problem with this testing approach is that you drive the bugs into a corners your tests don't reach05:32
wolfspraulwell let's see05:32
wolfspraulI have no problem reworking the fpga, if the smt fab (who would do it) thinks they can do it then why not05:32
wpwraki think the tests are still relatively narrowly focused. you'd need very broad coverage to catch truly exotic bugs that way.05:32
wolfspraulmaybe but everybody is testing05:33
wolfspraulwe don't need to be worried about ghosts or invisible things, I am not05:33
wolfspraullet's just see05:33
wolfspraulalso the smt fab etc. have a lot of rework experience. they can give us advice what makes sense and what not.05:34
wpwrak(some glitch) my current pet theory is that, when powering down, the FPGA core loses power before the I/O (3V3) does. then the core may act funny but since the I/O is still sufficiently powered, it would send out all the dying spasms of the core at full power. some of that may be write pulses to the NOR05:34
wpwrak(everybody is testing) with tests designed for broad coverage you have a reasonable chance. but i don't think the current process is very strong there. i'm not saying that it's bad but that the tests are fairly narrow and probably high-level, too. e.g., some glitches may even get auto-corrected without you noticing.05:37
wolfspraulthat glitch would be fixed with the gate+4.4v reset ic solution planned for rc4, no?05:37
wpwrak(4V4 reset) i would expect that, yes05:38
wpwrakmeanwhile, my suspicion grows that temperature has an effect, too. the last few days and nights have been quite warm and lo and behold, i've had a run that's been free of NOR corruption for > 3 days. and still counting. it could of course be coincidence, but ... :)05:39
wpwraki wonder if i already have enough data points for a frequency domain analysis ... a temperature pattern should show up as a ~24 hours cycle, too05:41
wpwrakanyway, i don't think we're in a great hurry with this (yet :). so i'm taking my time to collect data and improve my analysis methods. will be handy when a real emergency hits.05:42
wpwrakah, and after the latest firmware improvements, i haven't seen a single glitch of labsw. so i think my sw-based debouncing/denoising works well. the next hw revision will also have analog filters, for even better interference hardening.05:45
wpwrakmy plan is, once the new scheduler is done, to update the labsw design, make another prototype, and if it behaves well, also make one for adam. then he can do his testing in his sleep, much like i do ;-)05:46
wpwrakthen i should document the new schedule while my memory is still reasonably fresh. the efficiency comes at the price of some non-obvious dependencies. maybe i'll also find some bugs when documenting. wouldn't be the first time :)05:49
wpwrak(document) white paper style. like this critter: http://abiss.sourceforge.net/doc/elv-wp-0.ps05:50
wolfspraulhmm05:55
wolfsprauldo you think tuxbrain can sell labsw boards?05:55
wolfspraulor anybody?05:55
wolfspraulmaybe that is something sparkfun/adafruit and friends could be interested in...05:56
wpwraki don't know. if there's enough interest, it would make sense to make proper boards, yes. also for internal use.05:56
wpwrakyou could then add all the loose components and sell it as a kit. save assembly ;-)05:56
wolfspraulsure sure05:56
wolfspraulI'd leave that to sparkfun :-)05:56
wolfspraulI haven't looked at the tech details of labsw at all yet, I confess05:57
wpwrakone problem is the case. i use a locally sourced case and replace the front (and later also the rear) plate. works great but may not be very portable.05:57
wolfspraulmaybe as part of the 10-01 news05:57
wpwrakhehe ;-)05:58
wpwrakah yes, just a few days left. time flies :)05:58
wpwrakscheduler comparison chart with highlighting: http://downloads.qi-hardware.com/people/werner/m1/perf/chart-20110921b.html06:23
rohhm.. we were looking into making 'kits'06:25
wpwrak"kits" of what ?06:26
rohwell.. in that case its difficult.. maybe all non-smt parts06:30
rohkits are not really much trouble weee wise... devices are more complicated06:31
wpwraklabsw is a bit messy to build, yes. a bit of smt at the bottom, but then plenty of through-hole on top. and then a lot more items on the front panel.06:33
wpwrak(weee) is see ;-)06:33
wpwraks/is/i/06:33
wpwrakhmm, the flickernoise build instructions imply removal of flex and bison. very funny :-(06:44
xiangfu_wpwrak, Hi if you want build flickernoise. you may want use the old SDK. : http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-07062011-0000/Flickernoise-lm32-rtems-4.11-SDK-for-Linux-x86_64.tar.bz206:53
wolfspraulroh: kits of what?06:54
wolfspraulkits of labsw?06:54
xiangfu_wpwrak, all recently build use the latest RTEMS code. which have some problem now. flickernoise became very slow. let me find the IRC log.06:54
xiangfu_wpwrak, or build from source: check those file may some help: https://github.com/milkymist/scripts06:55
wpwrakxiangfu_: (sdk) ah, thanks ! does that have the slowdown issue too ?06:55
wpwrakyes, i'm currently on my way through README.html :)06:55
xiangfu_wpwrak, "http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-07062011-0000/Flickernoise-lm32-rtems-4.11-SDK-for-Linux-x86_64.tar.bz2" this one works fine.06:55
xiangfu_all the build start "09082011-1842/" to "09182011-1746/" have the slow problem.06:56
wpwrakso if i build from source, i would also have the slowdown ?06:56
xiangfu_wpwrak, yes.06:57
wpwrakah, then i better don't do that. my objective is to make it faster, not slower ;-)06:58
xiangfu_wpwrak, check here: http://en.qi-hardware.com/mmlogs/milkymist_2011-09-07.log.html#t08:5006:58
wpwrakdoes the slowdown also happen if i rebuild the things in the milkymist (for libfpvm) and flickernoise (for src/compiler.c) repos ?06:59
xiangfu_wpwrak, no. it's RTEMS bug.07:00
wpwrakexcellent ;-)07:00
xiangfu_wpwrak, unless there is a new bug in your new libfpvm or compiler.c :D07:00
wpwrakwe'll see :)07:01
xiangfu_wpwrak, what can I do for help you about speed up compiler.c?07:01
wpwraklet's see how the SDK and then the build goes07:04
wpwrakif i'm lucky, i can just drop in the new scheduler and things will fly07:04
wpwrakof course, if think murphy won't agree with this plan, as usual :)07:04
wpwraknow the moment if truth ... compiling flickernoise ...07:22
wolfspra1lif we have a mmu and really good Linux support one day, what are the reasons that still go for rtems then?07:24
wolfspra1lor is rtems just a temporary placeholder because Linux is harder to pull off?07:24
wolfspra1lwill rtems always be smaller and easier to customize?07:25
wpwrakit'll probably be smaller. but i think switching to linux would make a lot of sense. more drivers and protocols, widely known environment, standard tools, and so on.07:26
wpwrakof course, all the RT aspects need to be handled as well. not sure how demanding flickernoise is in the regard. and i also don't know the status of the RT extensions (some RT features are in the standard kernel, but there's more stuff)07:27
wpwrakhmm, make -C compile-flickernoise flickernoise.fbi  still seems to build the SDK. let's see how this goes ...07:29
wpwrakor maybe not ... confusing :)07:30
xiangfu__not SDK. but all depends libs. like RTEMS, gtk etc..07:31
xiangfu__those libs + cross toolchain  is the SDK :)07:31
wpwrakokay. now i get a build failure:07:32
wpwraktarget architecture: lm32.07:32
wpwrakmake[3]: Entering directory `/home/qi/m1/scripts/compile-flickernoise/build_dir/bsp-milkymist/tools/build'07:32
wpwrakconfigure: configuring in ../../cpukit07:32
wpwrakchecking whether CLOCK_PROCESS_CPUTIME_ID is declared... no07:32
wpwrakconfigure: error: missing define CLOCK_PROCESS_CPUTIME_ID07:33
wpwrakconfigure: error: /bin/bash '/opt/milkymist/rtems/c/src/../../cpukit/configure' failed for ../../cpukit07:33
xiangfu__wpwrak, what toolchian you using?07:33
wpwrakwhatever "make -C compile-flickernoise flickernoise.fbi" uses :)07:33
wpwraki see  --target=lm32-rtems4.1107:33
xiangfu__wpwrak, do you have 'lm32-rtems4.11-gcc' installed?07:34
wpwrakyes. and it's in the PATH07:34
xiangfu__where you get it? compiled from scripts.git?07:34
wpwrakwhich lm32-rtems4.11-gcc07:34
wpwrak/opt/rtems-4.11/bin/lm32-rtems4.11-gcc07:34
wpwrakfrom the SDK07:34
xiangfu__the ***-0000 sdk is gcc 4.5.2 and old newlib code. which is can not build latest source code :(07:35
xiangfu__you have to use 4.5.307:35
wpwrakso the SDK is useless ?07:36
xiangfu__wpwrak, if you already have SDK and you want compile flickernoise. no needs the script.git07:36
xiangfu__just clone the flickernoise.git and compile it07:36
wpwrakah :) okay. let's see how this goes ...07:37
xiangfu__wpwrak, make -C compile-flickernoise flickernoise.fbi will compile all from 007:37
wpwrakcd /opt/milkymist/flickernoise.git/src#07:37
wpwrakmake07:37
wpwrakyaffs.c:27:31: fatal error: yaffs/rtems_yaffs.h: No such file or directory07:38
xiangfu__wpwrak, checkout to 'stable_1.0' branch07:38
xiangfu__the compiler.c is same in 'master' and 'stable_1.0'07:38
wpwrakmuch better :)07:39
xiangfu__too many update here and there. :)07:39
wpwraknow i have a bin/flickernoise07:40
xiangfu__'make load' will compile a bin and copy to ftfp folder for netboot. then you don't needs to reflash07:41
xiangfu__if you want reflash, there is a flickernoise.git/flash/flash.sh07:41
xiangfu__wpwrak, for netboot, the m1 will setup ip address 192.168.0.42, and try to fetch 'boot.bin' from 192.168.0.1407:42
wpwrakhmm, but i didn't see it rebuild milkymist/software/libfpvm/   i guess i need to build there too ...07:44
wpwraki'll try flashing via jtag. haven't even set up ether yet.07:44
wpwrakah, nice. make bin/flickernoise.fbi   that was easy :)07:45
wpwraknow the milkymist libs ...07:45
xiangfu__wpwrak, libfpvm. you can manually compile it. and copy the 'libfpvm.a' to '/opt/rtems-4.11/lm32-rtems4.11/milkymist/lib'  then recompile flickernoise by 'make clean load'07:46
wpwrak... make bin/flickernoise.fbi   works. excellent :)07:49
wpwrakdoes stable_1.0 already have the skipping of patches that use the camera if there's no camera connected ?07:50
xiangfu__wpwrak, no.07:51
xiangfu__but cherry-pick should works fine.07:51
wpwrakpity. that'll be a great feature to have.07:51
wpwrakpheew. make the tree grow stranger and stranger ;-)07:51
xiangfu__wpwrak, for libfpvm, just found there the Makefile is under: 'milkymist.git/software/libfpvm/lm32-rtems'07:52
xiangfu__'make clean install' should works fine at that folder.07:52
wpwrakcool, even better07:53
xiangfu__(skip video) needs those three commits: 'f8e9008016285560e1826a48e0716d719d330387' '2776d11c50d88aa88f4372adabace3803004779e' '9523567c8bdc07b750e6b922e5c0d3acf90865f6', just run git cherry-pick ... should ok.07:56
xiangfu__it will also skip MIDI, OSC, DMX07:57
wpwrakwriting it down ...08:00
wpwrakwould there be an easy way to make the master branch compile ? i'd rather be at the current head, also for making patches08:01
xiangfu__it not skip compile them, it skip render those patches. just fyi08:01
xiangfu__wpwrak, I guess recompile and install the new yaffs libs should ok.08:02
wpwrakheh, skipping compilation would be something ;-)08:02
xiangfu__try 'make -C compile-flickernoise rtems-yaffs2' under scripts.git08:03
xiangfu__then compile the 'master' branch08:03
xiangfu__I am trying now. :)08:05
wpwrakhmm, it's unhappy. after make -C compile...08:06
xiangfu__not working,  the new yaffs2 needs new RTEMS API.08:06
wpwrakrtems/rtems_yaffs.c:839:13: error: 'rtems_filesystem_default_write' undeclared here (not in a function)08:06
wpwrak(and more errors)08:06
xiangfu__yes.08:06
xiangfu__wpwrak, there are not much update in 'master'08:06
xiangfu__there are new 'yaffs' api and new 'skip video' code in 'master'08:07
xiangfu__we should fix the rtems bug fast.08:07
xiangfu__then we will happy on 'master'  branch08:08
wpwrakdo you already know what the rtems bug is ? in the irc log, it looks as if it hadn't been quite identified yet08:10
xiangfu__wpwrak, I don't know that. :(08:12
wpwrakfor further study then :)08:16
xiangfu__yes.08:20
xiangfu__wpwrak, I meet the NOR error again, here is the standy diff: http://pastebin.com/rvu4kGyz09:12
wpwrakfunny address. but indeed, it's our old friend. is that an rc2 or an rc3 board ?09:14
xiangfu__rc2 board.09:14
wpwrakseems that rc2 gets NOR corruption more often than rc3. the reset circuit in rc3 probably does help a bit..09:16
wpwrak(at least my rc3 needs on average 500 power cycles)09:17
xiangfu__wpwrak, I will reflash standby.bin now. there is not much info from me. just normal use. normal reflash09:17
wpwrakyes. i think that's "normal" for rc2. if it was as rare as in rc3, it may have gone unnoticed.09:20
lekernelxiangfu__, just a quick test. can you take FN 1.0RC1 (the old RTEMS/YAFFS and such) and verify that the flash write function does not get called at inappropriate times in YAFFS?09:24
lekernelxiangfu__, there's a task that periodically flushes the YAFFS cache every 10 seconds or so09:25
lekernelmaybe it triggers flash writes everytime, even when the cache is in sync. that would be bad in every case, not only because it can cause unexpected corruption when the power is shut down in the middle, but also because it wears out the flash09:26
xiangfu__lekernel, ok. I will do that. I have old stuff in my system.09:27
lekernelin every case I made a binary snapshot of everything except Flickernoise: http://milkymist.org/3rdparty/rtems-fn1.0.tar.bz209:31
lekernelyou'd just need to recompile YAFFS and relink/recompile FN09:31
xiangfu__downloading.09:32
xiangfu__yes.09:32
lekernelwell, if you still have the old stuff, just use it :)09:32
lekernelI'm providing the binary snapshot just in case you have something missing ...09:32
xiangfu__I have the SDK. like: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-07062011-0000/09:33
xiangfu__this is the old yaffs2 right? : https://github.com/milkymist/rtems-yaffs2-old09:33
xiangfu__I will try to use the SDK and rtems-yaffs2-old.09:34
lekernelyes09:34
wpwraklekernel: btw, latest scheduler comparison: http://downloads.qi-hardware.com/people/werner/m1/perf/chart-20110921b.html09:35
xiangfu__I will do that today(if I have time), I will on the train to ChangeChun, 3 hours later. I will do this today or next few days.09:35
xiangfu__I ask some days off, but will read email as always :-)09:35
lekernelha wow09:35
wpwraknow produces functionally identical code to your scheduler for all the patches. i'll give it a spin on the M1 after a nap.09:35
lekernelLCPF = long latency instructions first?09:35
wpwrakLongest Critical Path First. also considers the dependant operations.09:36
lekerneland "new (no optimizer)" is the same as my basic scheduler, except that it schedule the instruction with the largest latency when there are several choices?09:37
Action: wpwrak realizes that "longest" and "critial path" are a bit redundant09:37
wpwrakit schedules the one that comes first in fpvm09:38
GitHub152[rtems-yaffs2] sebhub pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/734a675a484bed7fd870048d15e4a6ab8370b83a09:39
GitHub152[rtems-yaffs2/master] Fixed return value of ycb_file_lseek(). - Sebastian Huber09:39
lekernelthis is cool, I never thought someone would contribute something on PFPU. I'm impressed :)09:39
xiangfu__indeed.09:40
wpwrakwell, no, one more level: in each cycle, it adds the instructions that become available to its "to do" list. each list of additions is sorted by fpvm position. but the to do list doesn't get reordered. so the ones that become available first usually get issued first (unless the destination slot is blocked)09:41
wpwrakthe pfpu design is quite nice and straightforward. maybe with a bit of tweaking of the handling of static registers, even my scheduler could get a bit simpler.09:42
lekernelwpwrak,  "the flickernoise build instructions imply removal of flex and bison"?09:51
lekernelmh?09:51
lekernelyou can install both flex/bison and re2c/lemon at the same time09:51
xiangfu__I added some 'printf' to : https://github.com/milkymist/rtems-yaffs2-old/blob/master/direct/rtems/rtems.c#L11110:00
xiangfu__my_write()10:00
wpwraklekernel: for ubuntu, there's deinstallation of M4, which in turn deinstalls flex and bison. i could of course manually install them again later. but it's not so nice if you're forced to have a lot of manually installed packages.10:03
lekernelseems it's an ubuntu-specific bug10:08
wpwraksigh. cycles without trouble. time to make room in the fridge ...10:08
wpwraks/cycles/4000 cycles/10:08
wpwrakhmm, does RTEMS/FN show the build date somewhere ?10:12
xiangfu__the "About"10:13
xiangfu__in Control Panel""10:14
wpwrakgreat, thanks !10:14
xiangfu__now add some printf to 'yaffs_flush_whole_cache'10:21
wpwrakgrmbl. it hits an assertion. now .. where did i go wrong ...10:21
lekernelxiangfu__, add it to the flash write function10:22
lekerneland check that the flash doesn't get written when it's only rendering10:23
lekernelyou shouldn't need to dive into the cache flushing code unless you see that it's writing the flash when it should not10:24
xiangfu__lekernel, yes. I have added some printf to my_write.10:27
xiangfu__there is no 'my_write' called when rendering.10:27
lekernelok. then it's not the problem10:29
lekernelbbl10:29
lekernelthanks for testing10:29
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09222011-1112/10:49
wpwrakhmm, rtems isn't very smart when if comes to concurrent console output, isn't it ? even an abort concurrent with a printf from the same program yields alphabet soup :)14:03
wpwraks/abort/assert/14:04
kristianpaulwpwrak: rtems have some surprises :)14:48
kristianpauli baically uses because network support, but i'm actually using a hacked version of m1 bios, as i dont need too much troughput14:49
kristianpaul(labsw) for my personal case, will be nice for full control of a milkymist one remotelly14:50
kristianpaulso far i always my m1 turn on, and thanks to jtag-boot i can do remotelly soemthing before i needed to do in place (push button ;))14:50
kristianpaulalso your neocon logging support is extremely usefull for me now :)14:52
wpwrakyeah, with jtag control, you need to power cycle only in some rare cases. i like how well urjtag works. at openmoko, we used openocd. that was a complete and utter nightmare. locked up at the slightest difficulty. and because it was daemon plus client, it wasn't easily scripted either.14:54
wpwrak(neocon logging) sometimes it's the simplest things ... ;-)14:54
wpwrakhmm, the wayward compilation spits out slightly different registers. interesting. let's see if the code input is the same ... about the only thing i can think of that might seriously derail the scheduler would be an incorrect value in nbindings.14:56
wpwrakvalgrind is very happy with my code. also -O9 doesn't have any complaints. this normally means that it should work ;-)14:57
lekernelwolfspraul, who's Christiaan Virant ?16:20
wpwrakvery interesting. same source, but scheduler input is a little different on lm32 and on x86-64. hmm ...16:23
lekernelinput or output?16:27
wpwrakinput ! and the output (of my scheduler) has troubles, too. not sure yet whether that's because of something weird in the input or a yet undiscovered bug.16:28
wpwrakLekernel & Rovastar & Fvese - Subconscious Objects.fnp, lm32 has 108 bindings, x86 has 106 bindings (just unnamed constants). how peculiar. maybe this has something to do with the conversion in get_registers. the rest of the code looks pretty tame, though.16:52
lekernelhm, maybe FN feeds the patch code differently to libfpvm than your x86 test program?16:52
lekerneldoes it work?16:52
wpwraknope. my scheduler trips over an assert. so there's something it doesn't like. still searching ...16:55
wpwrakhmm, but nourishment first. this feels as if it may take a while to sort out ...17:01
GitHub23[llvm-lm32] jpbonn pushed 659 new commits to master: http://git.io/GJe5RA19:54
GitHub23[llvm-lm32/master] Make IC_VEX* not inherit from IC_*. Prevents instructions with no VEX form from disassembling to their non-VEX form. Also prevents weak filter collisons that were keeping valid VEX instructions from decoding properly. Make VEX_L* not inherit from VEX_* because the VEX.L bit always important. This stops packed int VEX encodings from being disassembled when specified with VEX.L=1. Fixes PR10831 and PR10806. - Craig Topper19:54
GitHub23[llvm-lm32/master] Pass signed (not unsigned) 10 bit field to SPU 'ori' instruction. - Kalle Raiskila19:54
GitHub23[llvm-lm32/master] Compare type size instead of type _store_ size to make sure that BitCastInst - Jakub Staszak19:54
wpwrakhmm, -DPRINTF_FLOAT ... where on earth would not setting it make sense, ever ? :)23:49
--- Fri Sep 23 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!