2011-05-11 00:09 <wpwrak> yeah. i added a slightly more positive comment
2011-05-11 00:48 <mth> if I compile gmenu2x with GCC 4.3.3, the first libstdc++ function I call causes a segfault, with libstdc++ from GCC 4.5.1
2011-05-11 00:49 <mth> is that expected or did I do something wrong either compiling gmenu2x or compiling GCC?
2011-05-11 00:49 <mth> I thought GCC 4.x was ABI compatible
2011-05-11 00:49 <mth> and the version number of libstdc++ is 6.0.10 vs 6.0.14, so that should be binary compatible
2011-05-11 01:33 <kristianpaul> http://hardware.slashdot.org/story/11/05/10/232229/Consumer-Device-With-Open-CPU-Out-of-Beta-Soon
2011-05-11 01:37 <wolfspraul> he :-)
2011-05-11 01:37 <wolfspraul> they took it?
2011-05-11 01:37 <kristianpaul> yeah, i wonder why actually ;-)
2011-05-11 01:38 <wolfspraul> why not :-)
2011-05-11 01:38 <wolfspraul> I guess the story was good enough, compared to the other things available at the time
2011-05-11 01:38 <kristianpaul> yeah
2011-05-11 01:38 <wolfspraul> come on this is simple stuff. an editor E constantly has the job to fill up his queue, let's say 10 stories / day.
2011-05-11 01:38 <kristianpaul> seems beta-like stories can pass trough
2011-05-11 01:38 <wolfspraul> so every day he comes to work, starts... picks the first one, second one, third one, etc.
2011-05-11 01:38 <wolfspraul> that's not how it works
2011-05-11 01:38 <kristianpaul> hehe
2011-05-11 01:38 <wolfspraul> anything can pass
2011-05-11 01:39 <wolfspraul> the editor is under time pressure
2011-05-11 01:39 <wolfspraul> if by lunch he is supposed to have finished 5 stories, but he only has three, then he has to speed up in the afternoon :-)
2011-05-11 01:39 <kristianpaul> also under lekernel submissions presure ;-)
2011-05-11 01:39 <wolfspraul> well I'm happy for lekernel, if they take it that's great
2011-05-11 01:39 <wolfspraul> we all should submit more milkymist stories all over the internet :-)
2011-05-11 01:39 <kristianpaul> oh, sure !
2011-05-11 01:40 <wolfspraul> Milkymist has potential for dozens of good stories, they just need to be written.
2011-05-11 01:40 <kristianpaul> I'm happy too
2011-05-11 01:40 <wolfspraul> and then someone needs to carry them, so we have to shop those stories around, not bury them silently on some unread blog
2011-05-11 01:40 <wolfspraul> that's all. there is no other magic.
2011-05-11 01:40 <kristianpaul> yup
2011-05-11 01:41 <wolfspraul> write it well, good language. authentic, not invented bs. slowly you will build up a reputation with editors and your stories will make it through the competition easier and easier.
2011-05-11 01:41 <wolfspraul> kristianpaul: there is a Spanish slashdot variant, forgot the name
2011-05-11 01:42 <wolfspraul> you can try there, in your native language so maybe you can write at a higher level than English, and chances are better that it's taken...
2011-05-11 01:42 <kristianpaul> barra punto, yeah
2011-05-11 01:42 <kristianpaul> \. ^
2011-05-11 01:42 <wolfspraul> fire away :-)
2011-05-11 01:43 <wolfspraul> follow the footsteps of fantastic Spanish language writers...
2011-05-11 01:43 <kristianpaul> hehe i need to take a look to that first :-)
2011-05-11 01:43 <kristianpaul> but yeah, should be easier than english at least
2011-05-11 01:43 <wolfspraul> oh you should definitely do that
2011-05-11 01:44 <wolfspraul> the story has a much higher chance to be taken if the language is good
2011-05-11 01:44 <wolfspraul> unfortunately most non-English articles will not be picked up elsewhere, but from English to any other language works easily
2011-05-11 01:44 <wolfspraul> so you are confined to the Spanish readers. but that's a lot, and you can definitely have an impact.
2011-05-11 01:44 <kristianpaul> confined =|
2011-05-11 01:45 <wolfspraul> well it's true. in technology everybody can at least read English.
2011-05-11 01:45 <wolfspraul> so the news flow is English ... any other language
2011-05-11 01:45 <wolfspraul> but if some real original news pops up elsewhere, it will not move to any other language
2011-05-11 01:45 <wolfspraul> nobody translates Japanese news stories into English
2011-05-11 01:46 <wolfspraul> even though there are a huge number of interesting things going on in Japan
2011-05-11 01:46 <wolfspraul> in technology
2011-05-11 01:46 <wolfspraul> but even there it's very rare/never to be translated
2011-05-11 02:54 <qwebirc87931> saw the article today on slashdot and looked at the code in milkymist.  There are some possible sim bugs in a few of the files in tmu2.
2011-05-11 02:55 <qwebirc87931> it looks like a handful of processes were converted into synchronous processes, but left with blocking assigns to signals used outside of the process, and that are not clocks.
2011-05-11 02:56 <kristianpaul> qwebirc87931: hi
2011-05-11 02:56 <qwebirc87931> hi
2011-05-11 02:57 <wolfspraul> hey!
2011-05-11 02:57 <wolfspraul> you are very welcome here, but the core milkymist channel on freenode is #milkymist
2011-05-11 02:57 <wolfspraul> but keep going
2011-05-11 02:58 <qwebirc87931> ah, i just found this from the wiki/webpage
2011-05-11 02:58 <wolfspraul> you are absolutely in the correct place
2011-05-11 02:58 <wolfspraul> qi hardware is a copyleft hardware project, our focus is hardware and manufacturing
2011-05-11 02:58 <wolfspraul> we are manufacturing the Milkymist One video synthesizer
2011-05-11 02:58 <wolfspraul> there is quite some overlap in people between #qi-hardware and #milkymist
2011-05-11 02:59 <wolfspraul> milkymist is the free IC design project (the milkymist SoC), plus the Milkymist One video synthesizer (the first product made around the Milkymist SoC), and the Flickernoise video synthesis GUI
2011-05-11 02:59 <wolfspraul> :-)
2011-05-11 02:59 <qwebirc87931> ah, ok, this really is more on the HDL side, not sure where you draw the hardware boundaries.
2011-05-11 02:59 <kristianpaul> (overlap) and lekernel is here to catch you comment as he developed the tmu2 core :-)
2011-05-11 03:00 <wolfspraul> Sebastien, the founder of Milkymist, hangs out on #qi-hardware as well
2011-05-11 03:00 <wolfspraul> I just wanted to clarify the two channels to you first, you an feel at home in both.
2011-05-11 03:01 <wolfspraul> can you give us more information on the tmu bugs you found? can you send a patch to the mailing list? I know very little/nothing about Verilog/HDL...
2011-05-11 03:01 <wolfspraul> but if you found a bug - that's great!
2011-05-11 03:04 <qwebirc87931> Ah, it shouldn't be hard to find.  Basically the simulator might not correctly simulate some files.  The synthesizer works differently and will give consistant results
2011-05-11 03:04 <qwebirc87931> which, might not match the sims as the sims have the bug.
2011-05-11 03:05 <wolfspraul> qwebirc87931: what do you think about the Milkymist project overall? any ideas for the future you may have?
2011-05-11 03:06 <qwebirc87931> Well, I'm mainly an FPGA dev, I saw the project on slashdot.
2011-05-11 03:07 <qwebirc87931> I'm always a bit skeptical.  There wasn't a lot of details on what specifically makes this better than a CPU, GPU, lowpower CPU+GPU, or lowpower CPU+FPGA.
2011-05-11 03:13 <wolfspraul> skeptical is good
2011-05-11 03:13 <wolfspraul> 'better' in which sense, what are you comparing?
2011-05-11 03:15 <qwebirc87931> better in any sense.  an FPGA only is difficult to program and develop for.  a CPU only might not have enough performance.  GPU's can do quite a bit.  in terms of power, they do make low power CPUs and low power GPUs, and obviously low power FPGAs
2011-05-11 03:15 <wolfspraul> hey btw, if you have some spare time, there's a number of things that could be added in the fpga
2011-05-11 03:15 <wolfspraul> from memory - some people started to think about MMU design (it has no mmu right now)
2011-05-11 03:16 <wolfspraul> there is the idea to support s-video and tv-out over the vga (with a converter cable, but needs SoC support first)
2011-05-11 03:16 <wolfspraul> real-time video encoding and streaming over Ethernet would be cool, maybe VP8...
2011-05-11 03:17 <qwebirc87931> Well, i really mean in terms of the core processing.  thing like optimized architectures for things like VP8 and such
2011-05-11 03:17 <wolfspraul> ok but that's just theory
2011-05-11 03:17 <wolfspraul> what is your point?
2011-05-11 03:17 <wolfspraul> say we make a car, it's a really cool car
2011-05-11 03:18 <wolfspraul> and you say "but if the car would be 10 times faster it would be better"
2011-05-11 03:18 <wolfspraul> ok - yes. you are right :-)
2011-05-11 03:18 <wolfspraul> milkymist one is a product first of all, a video synthesizer
2011-05-11 03:18 <wolfspraul> it works, it's very very interesting
2011-05-11 03:18 <wolfspraul> now we invite more people to join, if they want to, if they see something in it that interests them
2011-05-11 03:19 <qwebirc87931> I always question why someone would place a CPU on an FPGA.  There certainly would be reasons to do so.
2011-05-11 03:20 <wolfspraul> from my perspective: saves 1 chip, allows for integration between core instruction processing and peripherals
2011-05-11 03:20 <wolfspraul> if you have cpu+fpga, you definitely have a more complicated system in terms of tools than if you just have an fpga
2011-05-11 03:20 <wolfspraul> oh btw, since you are an fpga guy, there's also the llhdl/antares project you might find interesting
2011-05-11 03:21 <kristianpaul> qwebirc87931: xilinx is already tought on that for spartan7
2011-05-11 03:21 <qwebirc87931> do you?  In my experiences, having a dedicated CPU and FPGA has always worked better.  mainly because you have good tools for the CPU, and FPGA tools for the FPGA, and can debug each seperatly.
2011-05-11 03:22 <qwebirc87931> but having high BW, low latency busses for a CPU does make a lot of sense
2011-05-11 03:22 <kristianpaul> qwebirc87931: but oddly, or no? altera is ecoraging the use of mips softcores.. so.. there is a way to go o this topic
2011-05-11 03:22 <kristianpaul> of course we stick on free/open stuff, but i wanted to make some comparison
2011-05-11 03:22 <wolfspraul> gee can't find the llhdl sources right now :-) guess they are being moved
2011-05-11 03:22 <wolfspraul> here's a starting point http://lists.milkymist.org/listinfo.cgi/llhdl-milkymist.org
2011-05-11 03:23 <kristianpaul> https://github.com/sbourdeauducq/llhdl
2011-05-11 03:23 <kristianpaul> wolfspraul: yeah moved time ago..
2011-05-11 03:24 <wolfspraul> qwebirc87931: again. I understand your theory.
2011-05-11 03:24 <wpwrak> we're probably just at the beginning of seeing serious cpu core development. intuitively, i would also expect a cpu-asic plus an i/o fpga to offer the best performance. but maybe one can shrink the difference to a point where it doesn't matter so much anymore.
2011-05-11 03:24 <qwebirc87931> As for the altera/xilinx current FPGAs, one of my other issues is that they don't have the partial reconfiguration support to the point of being useable, and the FPGA has to be programmed even to use the hard-ip CPUs
2011-05-11 03:25 <wolfspraul> I think in terms of usability, it depends on each case. I have never seen anyone arguing for adding a non-fpga cpu core to Milkymist One
2011-05-11 03:25 <wpwrak> much like you're usually faster in assembler than in C, but only few people are desperate/crazy enough to do much programming in assembler.
2011-05-11 03:25 <wolfspraul> it would make the design very difficult, and create lots of growth problems in the future, imho (my theory ;-))
2011-05-11 03:25 <kristianpaul> what aboy  having a 128bit cpu running at 60Mhz? :p
2011-05-11 03:26 <wpwrak> qwebirc87931: where's the problem with reconfig ? that the chips can't do it properly or that the tools mess it up ?
2011-05-11 03:26 <wolfspraul> and today, the video synthesizer works flawlessly and we have many ideas how to improve it, and none of those ideas include adding another core CPU
2011-05-11 03:26 <kristianpaul> or specilized softcores for ie improve lzma descompresion time..
2011-05-11 03:27 <wolfspraul> qwebirc87931: yes we love partial reconfiguration, why not. It's not officially supported in the spartan-6 and probably never will be, and the practical usefulness is open for debate too (in our case, video synthesizer).
2011-05-11 03:27 <wpwrak> kristianpaul: yes, with an fpga you can "grow" little coprocessors. e.g., how about a cache that can do a bit of math of its own ? people have poked in this direction already, but usually with asics, so this was very slow.
2011-05-11 03:28 <wpwrak> kristianpaul: once you take the fpga as a given, you probably find it much easier to move around. also, once the shackles of the proprietary tools are removed ;-)
2011-05-11 03:28 <kristianpaul> :-)
2011-05-11 03:29 <wolfspraul> qwebirc87931: one thing is important I think. we are not an fpga shop. we didn't see fpga and had some theory on how this technology is superior (or not).
2011-05-11 03:29 <wolfspraul> thus we are not building an fpga computer
2011-05-11 03:29 <wolfspraul> the thought process of most/all people here goes like this:
2011-05-11 03:30 <wolfspraul> 1) we love free technology (gpl/bsd), we think we can build really cool products out of free technology
2011-05-11 03:30 <wolfspraul> 2) we picked a video synthesizer as a starting point because we thought this is a cool first product, and it can later grow into other products
2011-05-11 03:30 <wpwrak> kristianpaul: all this reminds me a bit of the situation we had in operating system kernel development before 386bsd and linux. not much happened because it was all centered on proprietary closed code bases. only once that was overcome, all of a sudden lots of people dived into it and started to innovate.
2011-05-11 03:31 <wolfspraul> 3) we picked a Xilinx fpga as a chip, similar to us picking an Analog Devices video decoder, or Wolfson Micro audio codec
2011-05-11 03:31 <wolfspraul> we are staying away from using proprietary Xilinx fpga features (the design should easily be portable to an Altera, for example)
2011-05-11 03:31 <wpwrak> wolfspraul: well, some of us don't care much about 2) but find the thing cool regardless ;-)
2011-05-11 03:32 <kristianpaul> yeah :-)
2011-05-11 03:32 <wolfspraul> wpwrak: yes I just try to explain the thought process, because some people look at this and say "ah, fpga computer. done that, failed. theory is wrong, bla bla bla"
2011-05-11 03:32 <wolfspraul> but nobody here thinks like that
2011-05-11 03:32 <wolfspraul> fpga is just a chip, yes it's great because we can run more free technology in it that we could run on an ARM chip
2011-05-11 03:32 <wolfspraul> the ARM chip is missing partial reconfiguration :-)
2011-05-11 03:33 <wolfspraul> it's just a difference in what thought/idea is first, and what is a second step/consequence
2011-05-11 03:33 <wolfspraul> the first idea is free tech here, the second idea is fpga. not the other way round.
2011-05-11 03:33 <wolfspraul> sorry gotta run, bbl
2011-05-11 03:33 <kristianpaul> bye..
2011-05-11 03:34 <wpwrak> wolfspraul: well, the concerns about fpga being unsuitable matter of course. afaik, little as it is, mm1 is much more efficient than those previous attempts. in terms of gate count (fpga size), processing power, performance of peripherals.
2011-05-11 03:34 <kristianpaul> keep it simple... :-)
2011-05-11 03:35 <kristianpaul> wich btw qwebirc87931 mm1 is not that soo complex system some people tend to think it is
2011-05-11 03:35 <wolfspraul> wpwrak: yes, but nobody here looked at fpga vs. asic first, and then said "I pick an fpga over an asic because..."
2011-05-11 03:35 <wolfspraul> the thought process of the Milkymist project is different
2011-05-11 03:35 <wpwrak> kristianpaul: exactly. someone commented that they had somehow half a system and could have done the rest if they had just had a virtex. well, that big expensive virtex is just the thing we'd rather not need ;-)
2011-05-11 03:36 <kristianpaul> yay !
2011-05-11 03:37 <qwebirc87931> back.  In anycase I guess part of the project is itself to make an open CPU.
2011-05-11 03:38 <wpwrak> wolfspraul: i'd say there's an fpga way and an asic way. sebastien chose the fpga way and this agrees in many ways with what the rest of us like, too.
2011-05-11 03:38 <kristianpaul> qwebirc87931: sure thats our basis
2011-05-11 03:39 <wpwrak> qwebirc87931: from what i gather, there's a lot of value in having a properly finished soc implementation. finished in the sense that there's a full set of peripherals and they are properly integrated and debugged.
2011-05-11 03:39 <qwebirc87931> It's just that, if you are making an open source CPU for audio/video, I would have expected to see more audio-video structures.  though some might be there
2011-05-11 03:40 <kristianpaul> Is not just the CPU, as wpwrak pointed, the system (SoC) is the whole thing working torwards a new way of computing,
2011-05-11 03:40 <kristianpaul> ie for now video manipualtion, this cool milkydrop effects, etc..
2011-05-11 03:41 <wpwrak> qwebirc87931: have you seen the thesis from this this originates ? there, sebastien talks a bit about optimizations for video, among other things: http://www.milkymist.org/thesis/thesis.pdf
2011-05-11 03:41 <kristianpaul> just matter of find a good fit between kernel, apps, libs and hardware that can do lot of stuff not just been only a CPU :-)
2011-05-11 03:41 <kristianpaul> okay time to check some rtem custom commands (WIP)
2011-05-11 03:42 <wpwrak> kristianpaul: (kernel) yeah, and get linux properly on the beast ;-)
2011-05-11 06:13 <tklive> anyone i can ask about cpu-z
2011-05-11 07:36 <dvdk> compile error
2011-05-11 07:37 <dvdk> can't open file at /home/pub/spock/src/qi/openwrt-xburst/scripts/kconfig.pl line 32.
2011-05-11 07:37 <dvdk> :(
2011-05-11 07:39 <wpwrak> dvdk: you want to build from plain kernel sources, trust me on this ;-)
2011-05-11 07:40 <kyak> dvdk: http://en.qi-hardware.com/wiki/Ben_NanoNote/Kernel - decent instructions how to build kernel from qi-kernel repo. http://en.qi-hardware.com/wiki/Git - some info about your adventures with branches "master" and "trunk" :)
2011-05-11 07:44 <dvdk> morning kyak
2011-05-11 07:44 <dvdk> does that mean i cannot build from openwrt-xburs.git 'trunk'?
2011-05-11 07:44 <dvdk> i mean you've been committing there... without testing?
2011-05-11 07:45 <kyak> dvdk: hi :)
2011-05-11 07:45 <kyak> sure you can build from trunk
2011-05-11 07:46 <kyak> i just thought you specifically wanted the bare kernel
2011-05-11 07:46 <dvdk> tried to rebuild.  saw teh error message i posted?
2011-05-11 07:46 <dvdk> no, want to tweak kernel config for next release
2011-05-11 07:46 <kyak> that's a strange message
2011-05-11 07:46 <dvdk> but kernel doesn't compile
2011-05-11 07:46 <kyak> i didn't experience such
2011-05-11 07:46 <dvdk> maybe make clean doesn't suffice
2011-05-11 07:47 <kyak> maybe
2011-05-11 07:47 <dvdk> ok, maybe my perl version is incompatible?
2011-05-11 07:47 <dvdk> running ubuntu 11.04
2011-05-11 07:47 <kyak> i doubt that.. i prefer to really clean it out before build
2011-05-11 07:48 <dvdk> ok, it means it can't open the kernel config.  huh?
2011-05-11 07:48 <dvdk> it's inside uclibc
2011-05-11 07:48 <dvdk> toolchain/uclibc
2011-05-11 07:49 <kyak> no, the kernel config is openwrt-xburst/build_dir/linux-xburst_qi_lb60/linux-2.6.37.6/.config
2011-05-11 07:49 <dvdk> do i need to update feeds.conf!?
2011-05-11 07:49 <dvdk> no, uclibc uses kconfig for uclibc .conf, too
2011-05-11 07:49 <dvdk> "  /home/pub/spock/src/qi/openwrt-xburst/scripts/kconfig.pl -n   ./config-0.9.30.1/mipsel > /home/pub/spock/src/qi/openwrt-xburst/build_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/.config
2011-05-11 07:50 <kyak> config-0.9.30.1 wtf?
2011-05-11 07:50 <dvdk> it's uclibc
2011-05-11 07:50 <kyak> you are sure you are on trunk?
2011-05-11 07:50 <wpwrak> giggles
2011-05-11 07:50 <kyak> it's uClibc-0.9.32
2011-05-11 07:50 <dvdk> git checkout origin/trunk
2011-05-11 07:50 <kyak> toolchain-mipsel_gcc-linaro_uClibc-0.9.32
2011-05-11 07:51 <dvdk> you're right it shows 0.9.32
2011-05-11 07:51 <dvdk> s toolchain/uClibc/
2011-05-11 07:51 <dvdk> config-0.9.32  Config.in  Config.version  Makefile  patches-0.9.32
2011-05-11 07:51 <dvdk> hmm.
2011-05-11 07:51 <dvdk> maybe 'make distclean'?
2011-05-11 07:51 <kyak> dvdk: maybe you could start by really cleaning up the mess left from backfire :)
2011-05-11 07:51 <kyak> yes, distclean
2011-05-11 07:52 <dvdk> running, will take a few minutes
2011-05-11 07:53 <kyak> check that you don't have env variables left like ARCH or CROSS_COMPILE (they could be left if you tried compiling the kernel manually)
2011-05-11 07:57 <xiangfu> dvdk: (make distclean) better backup the dl/ folder :)
2011-05-11 07:57 <dvdk> xiangfu: too late :(
2011-05-11 07:57 <dvdk> but running a squid proxy anyways
2011-05-11 08:00 <wpwrak> it's really not a good idea to lead people in the direction of using a distro build process as sort of a super-make for development on individual applications
2011-05-11 08:01 <wpwrak> we had that mess at openmoko for some application development and it was a total nightmare. people must have spent half of their waking time just chasing build system excursions or just waiting for vast quantities of completely irrelevant stuff to be built over and over again
2011-05-11 08:02 <wpwrak> better to have a proper cross-development toolchain and environment, with the ability to install -dev packages directly into the cross-development environment, and build exactly what you need
2011-05-11 08:06 <kyak> wpwrak: there is an SDK
2011-05-11 08:06 <kyak> xiangfu: btw, how was your buildhost progress for master/trunk?
2011-05-11 08:07 <xiangfu> kyak: trunk: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.trunk-full_system-05112011-0430/
2011-05-11 08:07 <xiangfu> kyak: master is :  0 19 */2 * * /home/xiangfu/bin/compile-openwrt-xburst.sh full_system
2011-05-11 08:07 <xiangfu> crontab ^
2011-05-11 08:07 <kyak> xiangfu:  error: conflicting types for 'versionsort'
2011-05-11 08:08 <kyak> seems you haven't pulled the openwrt-packages/trunk
2011-05-11 08:08 <wpwrak> kyak: so ... why isn't dvdk using it ? :)
2011-05-11 08:08 <kyak> the versionsort patch was relevant for backfire, but must be removed in trunk
2011-05-11 08:09 <xiangfu> kyak: yes. add switch to openwrt-package/trunk to build script file now.
2011-05-11 08:09 <kyak> wpwrak: i don't know :) i don't use it because i like to watch it all build :)
2011-05-11 08:10 <wpwrak> kyak: tv so bad in your area ? ;-)
2011-05-11 08:12 <kyak> wpwrak: you are close, i rarely watch television :)
2011-05-11 08:12 <xiangfu> :)
2011-05-11 08:17 <kyak> xiangfu: i see there are still those efl/xfce/phone feeds in feeds.conf. Maybe they should be disabled? (i only have qipackages/packages/desktop)
2011-05-11 08:17 <kyak> these efl/xfce/phone contain outdated/unusable packages anyway
2011-05-11 08:18 <xiangfu> kyak: yes. then let's just remove them. 
2011-05-11 08:20 <kyak> xiangfu: in nanonote-files/data/qi_lb60/conf/feeds.conf they are pinned to a specific svn revision.. Should we leave it?
2011-05-11 08:21 <kyak> i wonder how you do it in your build script..
2011-05-11 08:21 <xiangfu> kyak: those 'svn revision' is for 'release', it's always keep the latest release package svn revision.
2011-05-11 08:21 <kyak> ahh, oh, i remember now
2011-05-11 08:21 <xiangfu> kyak: I am not using the feeds.conf, only when release. we modify that revision. 
2011-05-11 08:23 <kyak> ok, i see
2011-05-11 08:24 <xiangfu> the 'make distclean' will not remove the 'feeds.conf' :)
2011-05-11 08:31 <qi-bot> [commit] Werner Almesberger: tools/lib/usbopen.h: moved to tools/include/, to allow for sharing http://qi-hw.com/p/ben-wpan/6fc2128
2011-05-11 08:31 <qi-bot> [commit] Werner Almesberger: libatrf: new function usb_rescan to force next open_usb to scan tree again http://qi-hw.com/p/ben-wpan/3deac41
2011-05-11 08:31 <qi-bot> [commit] Werner Almesberger: tools/lib/usbopen.c: make vendor and/or product optional http://qi-hw.com/p/ben-wpan/55d220b
2011-05-11 08:31 <qi-bot> [commit] Werner Almesberger: tools/usbwait/: new tool to wait for a USB device to appear http://qi-hw.com/p/ben-wpan/7037858
2011-05-11 08:31 <qi-bot> [commit] Werner Almesberger: tools/usbwait/usbwait.c: new option -r to require removal before appearance http://qi-hw.com/p/ben-wpan/62a03bb
2011-05-11 08:31 <qi-bot> [commit] Werner Almesberger: atusb/fw/Makefile: new target "update" to update the application via DFU http://qi-hw.com/p/ben-wpan/b82db55
2011-05-11 08:47 <dvdk> xiangfu: i'm currently try to get CONFIG_PROC_PAGE_MONITOR=y into kernel config
2011-05-11 08:47 <dvdk> is the 2.6.37 or .38 going into next release?
2011-05-11 08:47 <dvdk> need the PAGE_MONITOR for cleaner DMA implementation in mplayer video
2011-05-11 08:48 <xiangfu> dvdk: you can add it to 'openwrt-package.git' trunk branch, which is for the 2.6.37 or .38 kernel.
2011-05-11 08:48 <dvdk> xiangfu: so add it to both kernels?
2011-05-11 08:49 <xiangfu> sorry. it's openwrt-xburst.git
2011-05-11 08:49 <dvdk> xiangfu: already working on a trunk checkout of openwrt-xburst.git
2011-05-11 08:49 <dvdk> it's using gcc 4.5 now, is it?
2011-05-11 08:50 <xiangfu> by default it's using 2.6.37, but you can push both I think :)
2011-05-11 08:50 <dvdk> ok
2011-05-11 08:50 <xiangfu> yes. 'trunk' using gcc4.5
2011-05-11 08:50 <xiangfu> gcc-linaro-4.5-2011.02-
2011-05-11 08:50 <dvdk> so next release will be gcc 4.5, too?
2011-05-11 08:51 <dvdk> maybe gives us some speedup for mplayer/theora.  that can never hurt.
2011-05-11 08:51 <xiangfu> dvdk: I am not sure. I guess 80% still backfire. let's see how 'trunk' build on build-host. 
2011-05-11 08:52 <dvdk> xiangfu: ah, ok so you have to merge between branches for new built
2011-05-11 08:54 <xiangfu> dvdk: here: http://en.qi-hardware.com/wiki/Git#openwrt-xburst.git_rebase_on_upstream_trunk
2011-05-11 08:54 <wpwrak> today, also slashdot.jp picked up ubb-vga. nice to see the wave go around the globe ;-)
2011-05-11 08:54 <xiangfu> most of the patches is useless in 'trunk', also kyak have finished a lot of work, :)
2011-05-11 08:55 <dvdk> wpwrak: (slashdot.jp): "hack that uses micro sd card slot as vga port" no word aof abuse
2011-05-11 08:56 <wpwrak> they're too polite ;-)
2011-05-11 08:57 <dvdk> trying to decipher the story.  pretty much rewritten.  
2011-05-11 09:01 <wpwrak> the comments are quite a bit more disciplined than over at /.
2011-05-11 09:02 <dvdk> wpwrak: that's not unexpected, is it :)
2011-05-11 09:03 <wpwrak> *grin*
2011-05-11 09:06 <dvdk> cool, i now have a 5 digit slashdot ID
2011-05-11 09:06 <dvdk> ... slashdot.jp ID :)
2011-05-11 09:10 <dvdk> wpwrak: now i'm curious how much visitors we get through slashdot.jp.  enough for another slashdot effect?
2011-05-11 09:11 <wpwrak> 95 until ~8:30 am UTC
2011-05-11 09:12 <wpwrak> about 159 from /. for MM1. but that's qi-hw. milkymist.org as the primary landing site probably has a lot more
2011-05-11 09:12 <wpwrak> also 86 visitors from downloads.qi-hardware.com ;-)
2011-05-11 09:13 <dvdk> wpwrak: can't seem to find anybody from /.jp on http://en.qi-hardware.com/piwik
2011-05-11 09:14 <wpwrak> http://en.qi-hardware.com/piwik/index.php?module=CoreHome&action=index&idSite=1&period=day&date=2011-05-11#module=Dashboard&action=embeddedIndex&idSite=1&period=day&date=2011-05-11
2011-05-11 09:14 <dvdk> ah, it says date=yesterday here
2011-05-11 09:17 <dvdk> wpwrak: it now even shows japan on the map
2011-05-11 09:18 <wpwrak> yeah. the world at a glance. just what we need for our domination plans :)
2011-05-11 10:40 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/: quick and dirty IPv4 over 802.15.4 tunnel (in progress) http://qi-hw.com/p/ben-wpan/dbad7ae
2011-05-11 11:03 <kyak> dvdk: i was running your mplayer-jz in trunk, haven't noticed any difference to backfire :)
2011-05-11 11:06 <kyak> error: pathspec '97dc86b793efb9c6ac604cdfff4027fe27efa12c6' did not match any file(s) known to git.
2011-05-11 11:06 <kyak> damn.. not this again
2011-05-11 11:06 <kyak> i removed the dl/ dir, it became > 2 Gb :)
2011-05-11 11:09 <kyak> hm, ffmpeg devs somehow managed to screw up this revision, too
2011-05-11 11:09 <kyak> despite of the fact that i got their whole git tree
2011-05-11 11:11 <kyak> the only explanation now is that specific commit had been reverted
2011-05-11 11:28 <kyak> dvdk: the latest mplayer from svn won't compile -\ sticking to r33341 and ffmpeg is updated to 3b6bbfa0631d237f2bbc85a7b43907733bea1e82
2011-05-11 13:29 <dvdk> kyak: don't update mplayer just for fun.  it takes quite some time to test through all kinds of sample files to make sure still everything works
2011-05-11 13:33 <dvdk> hmm, cannot push
2011-05-11 13:33 <dvdk> error: failed to push some refs to 'git@projects.qi-hardware.com:openwrt-xburst.git'
2011-05-11 13:33 <dvdk> git pull:
2011-05-11 13:33 <dvdk> You are not currently on a branch, so I cannot use any
2011-05-11 13:33 <dvdk> 'branch.<branchname>.merge' in your configuration file.
2011-05-11 13:33 <dvdk> huh?
2011-05-11 13:50 <qi-bot> [commit] David Kühling: linux kernel: add CONFIG_PROC_PAGE_MONITOR=y to allow for clean user-space DMA http://qi-hw.com/p/openwrt-xburst/e9141de
2011-05-11 13:50 <dvdk> ok needed --track -b when doing git checkout (?)
2011-05-11 14:02 <kristianpaul> dvdk: just git checkout branch_name i thikn
2011-05-11 14:03 <dvdk> kristianpaul: did that (i think), but then i couldn't push.
2011-05-11 14:03 <dvdk> well --track -b did the job this time.  going to try a pure 'checkout' next time
2011-05-11 14:04 <kristianpaul> git push origin branch_name ?
2011-05-11 14:05 <kristianpaul> well, origin or whatever name for remote repository
2011-05-11 14:06 <kristianpaul> hmm
2011-05-11 14:12 <dvdk> kristianpaul: ah, that might have done the job.  
2011-05-11 15:30 <plaes> have there been plans for nanonote v2?
2011-05-11 15:31 <wpwrak> plaes: ideas, many :)
2011-05-11 15:34 <wpwrak> plaes: but there's no concrete work on making one. one little issue is that this would cost a bit more money than anyone around here has at hand.
2011-05-11 15:36 <plaes> has been pondering about data acquisition platform supporting various sensors
2011-05-11 15:37 <plaes> I know about Vernier LabQuest, but these are all stupidly expensive :S
2011-05-11 15:40 <wpwrak> you could probably make sensors that connect via UBB. for that money, you can make quite a few ;-)
2011-05-11 15:41 <wpwrak> of course, the ben isn't quite so rugged ...
2011-05-11 15:44 <plaes> UBB is basically a SPI bus + plain GPIO?
2011-05-11 15:47 <wpwrak> it's mainly plain GPIO. you have three typical configurations: 1) 6 GPIO + 3.3. V power on/off; 2) 5 GPIO + 3.3 V power on/off + clock output (frequency is configurable, up to at least 56 MHz); 3) MMC/SD/SDIO
2011-05-11 15:48 <wpwrak> in the case of ubb-vga, i switch between 1) and 3), but that's an unusual mode of operation.
2011-05-11 15:50 <wpwrak> in 1) and 2), you can bit-bang SPI but you don't hardware-acceleration for SPI, so it's not so efficient if you have to move lots of data
2011-05-11 15:50 <plaes> hm
2011-05-11 15:58 <wpwrak> perhaps you can actually drive some SPI devices with hardware support, if using the tricks i used with ubb-vga. i realize with a bit of sadness that the signal arrangement of atben doesn't allow for any optimization along these lines
2011-05-11 16:02 <wpwrak> not sure if it would actually be faster, though. such a thing would be more useful for SPI devices that transfer continuously but at a low bit rate. that way, you could just fill the fifo or set up dma, then go away. atben works in relatively fast bursts.
2011-05-11 16:06 <dvdk> on the master branch I get now after clean checkout and recompile:
2011-05-11 16:06 <dvdk> configure: error: in `/home/pub/spock/src/qi/openwrt-xburst/build_dir/target-mipsel_uClibc-0.9.30.1/libtool-2.4':
2011-05-11 16:06 <dvdk> configure: error: C compiler cannot create executables
2011-05-11 16:20 <dvdk> ok, my fault: renaming the openwrt-xburst directory is not possible (without distclean), it seems
2011-05-11 16:27 <kyak> dvdk: i wouldn't touch mplayer if i didn't have to update ffmpeg git revision.. But i got your point :)
2011-05-11 16:37 <qi-bot> [commit] David Kühling: mplayer_jz47xx: upgrade to 0.1.5 version that supports /proc/<pid>/pagemap http://qi-hw.com/p/openwrt-packages/54ae318
2011-05-11 16:38 <qi-bot> [commit] David Kühling: mplayer_jz47xx: fix md5-sum for updated version http://qi-hw.com/p/openwrt-packages/46bda1e
2011-05-11 16:59 <dvdk> kyak: did you break mplayer?
2011-05-11 16:59 <dvdk> error: pathspec '97dc86b793efb9c6ac604cdfff4027fe27efa12c6' did not match any file(s) known to git.
2011-05-11 17:03 <kyak> dvdk: me?? i was the one who reported this problem
2011-05-11 17:03 <dvdk> kyak: didn't you say you just upgraded ffmpeg?  i had to downgrade it again
2011-05-11 17:04 <dvdk> set to FFMPEG_REV:=95f163b33b4f13cfe650f53ee2c3746788122def
2011-05-11 17:04 <kyak> i did upgrade it, but i didn't commit
2011-05-11 17:04 <kyak> and before, i said:
2011-05-11 17:04 <kyak> 15:06:16 < kyak> error: pathspec '97dc86b793efb9c6ac604cdfff4027fe27efa12c6'  did not match any file(s) known to git.
2011-05-11 17:05 <dvdk> kyak: sorry, wasn't here when you wrote that.  scrolled off.
2011-05-11 17:05 <dvdk> kyak: maybe you better commit?
2011-05-11 17:07 <kyak> dvdk: i can do this. but actually i'm now wondering how should we do
2011-05-11 17:07 <kyak> cause we have master and trunk in openwrt-packages
2011-05-11 17:07 <kyak> and they are starting to diverge
2011-05-11 17:07 <dvdk> i never commit in packages' trunk
2011-05-11 17:08 <kyak> i never did, too, until yesterday
2011-05-11 17:08 <dvdk> hates this branches.  too many headaches
2011-05-11 17:10 <qi-bot> [commit] kyak: update ffmpeg to a working git revision http://qi-hw.com/p/openwrt-packages/73ca357
2011-05-11 17:11 <kyak> i commited it in master.. i guess we will tag this branch when we migrate to next openwrt release.. and then commits from trunk branch will go on top
2011-05-11 17:11 <kyak> something like this...
2011-05-11 17:12 <kyak> in other works, the trunk branch is to temporary keep patches required for openwrt trunk, but not working/tested in backfire
2011-05-11 17:13 <kyak> i think xiangfu said it yesterday, but i wasn't very attentive..
2011-05-11 17:16 <dvdk> kyak: now i get on 'git stash pop'
2011-05-11 17:16 <dvdk> mplayer/Makefile: needs merge
2011-05-11 17:16 <dvdk> what do i enter now?
2011-05-11 17:16 <dvdk> to take your version of the file?
2011-05-11 17:17 <kyak> depending on what changes you have inside your version of Makefile
2011-05-11 17:17 <dvdk> only a different ffmpeg rev from yours
2011-05-11 17:17 <kyak> so you can just take my version
2011-05-11 17:17 <kyak> git co mplayer/Makefile
2011-05-11 17:18 <dvdk> git: 'co' is not a git command. See 'git --help'.
2011-05-11 17:18 <kyak> then you can git pull
2011-05-11 17:18 <kyak> oh, sorry.. i have some shortcuts :)
2011-05-11 17:18 <kyak> git checkout mplayer/Makefile
2011-05-11 17:18 <dvdk> maysbe just git stash drop
2011-05-11 17:18 <kyak> heh, maybe, i didn't know abotu that :)
2011-05-11 17:18 <dvdk> seems to have worked
2011-05-11 17:19 <dvdk> kyak: but lost some other change.  not important one.
2011-05-11 17:19 <kyak> ah yes.. checkouting this individual file would've been better then..
2011-05-11 17:19 <dvdk> hnmm.
2011-05-11 17:19 <dvdk> git checkout mplayer/Makefile
2011-05-11 17:19 <dvdk> error: path 'mplayer/Makefile' is unmerged
2011-05-11 17:20 <dvdk> git rm first?
2011-05-11 17:20 <kyak> hm ok, now you have to manually resolve the conflict i think...
2011-05-11 17:20 <dvdk> what's the command. svn would be 'svn resolved'
2011-05-11 17:20 <kyak> there should be lines like >>>> inside mplayer/Makefile
2011-05-11 17:20 <kyak> marking the conflict
2011-05-11 17:21 <dvdk> git reset --hard HEAD
2011-05-11 17:21 <dvdk> kyak: you mean it parses inside these files?  that would be cool.
2011-05-11 17:21 <kyak> oh yeah, that one would work.. also smashing your changes :)
2011-05-11 17:21 <dvdk> but too late already did 'rm' which didn't help, then reset
2011-05-11 17:39 <qi-bot> [commit] David Kühling: mplayer_jz47xx: upgrade to 0.1.5 version that supports /proc/<pid>/pagemap http://qi-hw.com/p/openwrt-packages/36bcb9e
2011-05-11 17:39 <qi-bot> [commit] David Kühling: mplayer_jz47xx: fix md5-sum for updated version http://qi-hw.com/p/openwrt-packages/f342c3b
2011-05-11 17:39 <qi-bot> [commit] kyak: update ffmpeg to a working git revision http://qi-hw.com/p/openwrt-packages/71d83e9
2011-05-11 17:40 <kyak> ok.. learned how to pick commits from one branch to another :)
2011-05-11 17:48 <wpwrak> dvdk: i'm not sure if it parses the files (didn't dare to commit a file containing unresolved conflicts yet :), but it marks them inside the files. kinda Augmented Reality :)
2011-05-11 17:51 <kyak> git is kinda smart on resolving conflicts btw
2011-05-11 17:51 <kyak> i'd say, in most cases it would resolve automatically
2011-05-11 17:55 <wpwrak> hmm, i'd say it's more or less at the smartness level of patch(1)
2011-05-11 17:55 <wpwrak> (if it doesn't actually use patch(1) :)
2011-05-11 18:29 <dvdk> btw the mplayer_jz47xx now uses /proc/self/pagemap if present.  should make sure that the next version really has the kernel support CONFIG_PROC_PAGE_MONITOR=y
2011-05-11 18:31 <kyak> dvdk: you should include this change in openwrt-xburst/master, too. xiangfu told he was going to release another backfire-based image
2011-05-11 18:32 <kyak> i think it's only in trunk so far
2011-05-11 18:32 <dvdk> kyak: you mean change the 2.6.32 config?
2011-05-11 18:32 <kyak> yeah
2011-05-11 18:32 <dvdk> oh the headaches come back
2011-05-11 18:32 <dvdk> :)
2011-05-11 18:33 <kyak> git is a beast, right? :)
2011-05-11 18:33 <dvdk> my brain is too small for it
2011-05-11 18:33 <xMff> +1
2011-05-11 18:35 <kyak> when i think that i "mastered" git enough for my daily needs, something always shows up.. And i have to google.. every time :)
2011-05-11 18:39 <dvdk> hmm, does it automatically rebuild the kernel, if i just touch the config-2.6.32?
2011-05-11 18:39 <dvdk> not sure whether it did anything.  
2011-05-11 18:41 <dvdk> still compiling, though.  does it recompile the full userspace?
2011-05-11 18:41 <dvdk> let's just see whether *uImage.bin is new in the end
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/: -d now generates terse output; -d -d dumps full content http://qi-hw.com/p/ben-wpan/29e56c7
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/: introduced terse debug messages also for timeouts http://qi-hw.com/p/ben-wpan/a1a508e
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/dirtpan.c (open_net): turn off WPAN_WANTACK http://qi-hw.com/p/ben-wpan/171500e
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/dirtpan.c (timeout): fencepost error when normalizing tv_usec http://qi-hw.com/p/ben-wpan/354789d
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/dirtpan.c (rx_pck): immediately ack all data packets http://qi-hw.com/p/ben-wpan/2c7d06f
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/dirtpan.c (rx_pck): break tie if both sides are in s_tx http://qi-hw.com/p/ben-wpan/e17881c
2011-05-11 19:51 <qi-bot> [commit] Werner Almesberger: tools/dirtpan/: if given an interface conf command, run it with tunX in $ITF http://qi-hw.com/p/ben-wpan/de72af3