<wolfspraul>
I guess the story was good enough, compared to the other things available at the time
<kristianpaul>
yeah
<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.
<kristianpaul>
seems beta-like stories can pass trough
<wolfspraul>
so every day he comes to work, starts... picks the first one, second one, third one, etc.
<wolfspraul>
that's not how it works
<kristianpaul>
hehe
<wolfspraul>
anything can pass
<wolfspraul>
the editor is under time pressure
<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 :-)
<kristianpaul>
also under lekernel submissions presure ;-)
<wolfspraul>
well I'm happy for lekernel, if they take it that's great
<wolfspraul>
we all should submit more milkymist stories all over the internet :-)
<kristianpaul>
oh, sure !
<wolfspraul>
Milkymist has potential for dozens of good stories, they just need to be written.
<kristianpaul>
I'm happy too
<wolfspraul>
and then someone needs to carry them, so we have to shop those stories around, not bury them silently on some unread blog
<wolfspraul>
that's all. there is no other magic.
<kristianpaul>
yup
<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.
<wolfspraul>
kristianpaul: there is a Spanish slashdot variant, forgot the name
<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...
<kristianpaul>
barra punto, yeah
<kristianpaul>
\. ^
<wolfspraul>
fire away :-)
<wolfspraul>
follow the footsteps of fantastic Spanish language writers...
<kristianpaul>
hehe i need to take a look to that first :-)
<kristianpaul>
but yeah, should be easier than english at least
<wolfspraul>
oh you should definitely do that
<wolfspraul>
the story has a much higher chance to be taken if the language is good
<wolfspraul>
unfortunately most non-English articles will not be picked up elsewhere, but from English to any other language works easily
<wolfspraul>
so you are confined to the Spanish readers. but that's a lot, and you can definitely have an impact.
<kristianpaul>
confined =|
<wolfspraul>
well it's true. in technology everybody can at least read English.
<wolfspraul>
so the news flow is English ... any other language
<wolfspraul>
but if some real original news pops up elsewhere, it will not move to any other language
<wolfspraul>
nobody translates Japanese news stories into English
<wolfspraul>
even though there are a huge number of interesting things going on in Japan
<wolfspraul>
in technology
<wolfspraul>
but even there it's very rare/never to be translated
<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.
<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.
<kristianpaul>
qwebirc87931: hi
<qwebirc87931>
hi
<wolfspraul>
hey!
<wolfspraul>
you are very welcome here, but the core milkymist channel on freenode is #milkymist
<wolfspraul>
but keep going
<qwebirc87931>
ah, i just found this from the wiki/webpage
<wolfspraul>
you are absolutely in the correct place
<wolfspraul>
qi hardware is a copyleft hardware project, our focus is hardware and manufacturing
<wolfspraul>
we are manufacturing the Milkymist One video synthesizer
<wolfspraul>
there is quite some overlap in people between #qi-hardware and #milkymist
<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
<wolfspraul>
:-)
<qwebirc87931>
ah, ok, this really is more on the HDL side, not sure where you draw the hardware boundaries.
<kristianpaul>
(overlap) and lekernel is here to catch you comment as he developed the tmu2 core :-)
<wolfspraul>
Sebastien, the founder of Milkymist, hangs out on #qi-hardware as well
<wolfspraul>
I just wanted to clarify the two channels to you first, you an feel at home in both.
<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...
<wolfspraul>
but if you found a bug - that's great!
<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
<qwebirc87931>
which, might not match the sims as the sims have the bug.
<wolfspraul>
qwebirc87931: what do you think about the Milkymist project overall? any ideas for the future you may have?
<qwebirc87931>
Well, I'm mainly an FPGA dev, I saw the project on slashdot.
<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.
<wolfspraul>
skeptical is good
<wolfspraul>
'better' in which sense, what are you comparing?
<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
<wolfspraul>
hey btw, if you have some spare time, there's a number of things that could be added in the fpga
<wolfspraul>
from memory - some people started to think about MMU design (it has no mmu right now)
<wolfspraul>
there is the idea to support s-video and tv-out over the vga (with a converter cable, but needs SoC support first)
<wolfspraul>
real-time video encoding and streaming over Ethernet would be cool, maybe VP8...
<qwebirc87931>
Well, i really mean in terms of the core processing.  thing like optimized architectures for things like VP8 and such
<wolfspraul>
ok but that's just theory
<wolfspraul>
what is your point?
<wolfspraul>
say we make a car, it's a really cool car
<wolfspraul>
and you say "but if the car would be 10 times faster it would be better"
<wolfspraul>
ok - yes. you are right :-)
<wolfspraul>
milkymist one is a product first of all, a video synthesizer
<wolfspraul>
it works, it's very very interesting
<wolfspraul>
now we invite more people to join, if they want to, if they see something in it that interests them
<qwebirc87931>
I always question why someone would place a CPU on an FPGA.  There certainly would be reasons to do so.
<wolfspraul>
from my perspective: saves 1 chip, allows for integration between core instruction processing and peripherals
<wolfspraul>
if you have cpu+fpga, you definitely have a more complicated system in terms of tools than if you just have an fpga
<wolfspraul>
oh btw, since you are an fpga guy, there's also the llhdl/antares project you might find interesting
<kristianpaul>
qwebirc87931: xilinx is already tought on that for spartan7
<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.
<qwebirc87931>
but having high BW, low latency busses for a CPU does make a lot of sense
<kristianpaul>
qwebirc87931: but oddly, or no? altera is ecoraging the use of mips softcores.. so.. there is a way to go o this topic
<kristianpaul>
of course we stick on free/open stuff, but i wanted to make some comparison
<wolfspraul>
gee can't find the llhdl sources right now :-) guess they are being moved
<wolfspraul>
qwebirc87931: again. I understand your theory.
<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.
<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
<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
<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.
<wolfspraul>
it would make the design very difficult, and create lots of growth problems in the future, imho (my theory ;-))
<kristianpaul>
what aboy  having a 128bit cpu running at 60Mhz? :p
<wpwrak>
qwebirc87931: where's the problem with reconfig ? that the chips can't do it properly or that the tools mess it up ?
<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
<kristianpaul>
or specilized softcores for ie improve lzma descompresion time..
<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).
<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.
<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 ;-)
<kristianpaul>
:-)
<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).
<wolfspraul>
thus we are not building an fpga computer
<wolfspraul>
the thought process of most/all people here goes like this:
<wolfspraul>
1) we love free technology (gpl/bsd), we think we can build really cool products out of free technology
<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
<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.
<wolfspraul>
3) we picked a Xilinx fpga as a chip, similar to us picking an Analog Devices video decoder, or Wolfson Micro audio codec
<wolfspraul>
we are staying away from using proprietary Xilinx fpga features (the design should easily be portable to an Altera, for example)
<wpwrak>
wolfspraul: well, some of us don't care much about 2) but find the thing cool regardless ;-)
<kristianpaul>
yeah :-)
<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"
<wolfspraul>
but nobody here thinks like that
<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
<wolfspraul>
the ARM chip is missing partial reconfiguration :-)
<wolfspraul>
it's just a difference in what thought/idea is first, and what is a second step/consequence
<wolfspraul>
the first idea is free tech here, the second idea is fpga. not the other way round.
<wolfspraul>
sorry gotta run, bbl
<kristianpaul>
bye..
<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.
<kristianpaul>
keep it simple... :-)
<kristianpaul>
wich btw qwebirc87931 mm1 is not that soo complex system some people tend to think it is
<wolfspraul>
wpwrak: yes, but nobody here looked at fpga vs. asic first, and then said "I pick an fpga over an asic because..."
<wolfspraul>
the thought process of the Milkymist project is different
<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 ;-)
<kristianpaul>
yay !
<qwebirc87931>
back.  In anycase I guess part of the project is itself to make an open CPU.
<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.
<kristianpaul>
qwebirc87931: sure thats our basis
<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.
<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
<kristianpaul>
Is not just the CPU, as wpwrak pointed, the system (SoC) is the whole thing working torwards a new way of computing,
<kristianpaul>
ie for now video manipualtion, this cool milkydrop effects, etc..
<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
<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 :-)
<kristianpaul>
okay time to check some rtem custom commands (WIP)
<wpwrak>
kristianpaul: (kernel) yeah, and get linux properly on the beast ;-)
<tklive>
anyone i can ask about cpu-z
<dvdk>
compile error
<dvdk>
can't open file at /home/pub/spock/src/qi/openwrt-xburst/scripts/kconfig.pl line 32.
<dvdk>
:(
<wpwrak>
dvdk: you want to build from plain kernel sources, trust me on this ;-)
<dvdk>
does that mean i cannot build from openwrt-xburs.git 'trunk'?
<dvdk>
i mean you've been committing there... without testing?
<kyak>
dvdk: hi :)
<kyak>
sure you can build from trunk
<kyak>
i just thought you specifically wanted the bare kernel
<dvdk>
tried to rebuild.  saw teh error message i posted?
<dvdk>
no, want to tweak kernel config for next release
<kyak>
that's a strange message
<dvdk>
but kernel doesn't compile
<kyak>
i didn't experience such
<dvdk>
maybe make clean doesn't suffice
<kyak>
maybe
<dvdk>
ok, maybe my perl version is incompatible?
<dvdk>
running ubuntu 11.04
<kyak>
i doubt that.. i prefer to really clean it out before build
<dvdk>
ok, it means it can't open the kernel config.  huh?
<dvdk>
it's inside uclibc
<dvdk>
toolchain/uclibc
<kyak>
no, the kernel config is openwrt-xburst/build_dir/linux-xburst_qi_lb60/linux-2.6.37.6/.config
<dvdk>
do i need to update feeds.conf!?
<dvdk>
no, uclibc uses kconfig for uclibc .conf, too
<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
<kyak>
config-0.9.30.1 wtf?
<dvdk>
it's uclibc
<kyak>
you are sure you are on trunk?
<wpwrak>
giggles
<kyak>
it's uClibc-0.9.32
<dvdk>
git checkout origin/trunk
<kyak>
toolchain-mipsel_gcc-linaro_uClibc-0.9.32
<dvdk>
you're right it shows 0.9.32
<dvdk>
s toolchain/uClibc/
<dvdk>
config-0.9.32  Config.in  Config.version  Makefile  patches-0.9.32
<dvdk>
hmm.
<dvdk>
maybe 'make distclean'?
<kyak>
dvdk: maybe you could start by really cleaning up the mess left from backfire :)
<kyak>
yes, distclean
<dvdk>
running, will take a few minutes
<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)
<xiangfu>
dvdk: (make distclean) better backup the dl/ folder :)
<dvdk>
xiangfu: too late :(
<dvdk>
but running a squid proxy anyways
<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
<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
<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
<kyak>
wpwrak: there is an SDK
<kyak>
xiangfu: btw, how was your buildhost progress for master/trunk?
<xiangfu>
kyak: master is :Â Â 0 19 */2 * * /home/xiangfu/bin/compile-openwrt-xburst.sh full_system
<xiangfu>
crontab ^
<kyak>
xiangfu:Â Â error: conflicting types for 'versionsort'
<kyak>
seems you haven't pulled the openwrt-packages/trunk
<wpwrak>
kyak: so ... why isn't dvdk using it ? :)
<kyak>
the versionsort patch was relevant for backfire, but must be removed in trunk
<xiangfu>
kyak: yes. add switch to openwrt-package/trunk to build script file now.
<kyak>
wpwrak: i don't know :) i don't use it because i like to watch it all build :)
<wpwrak>
kyak: tv so bad in your area ? ;-)
<kyak>
wpwrak: you are close, i rarely watch television :)
<xiangfu>
:)
<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)
<kyak>
these efl/xfce/phone contain outdated/unusable packages anyway
<xiangfu>
kyak: yes. then let's just remove them.
<kyak>
xiangfu: in nanonote-files/data/qi_lb60/conf/feeds.conf they are pinned to a specific svn revision.. Should we leave it?
<kyak>
i wonder how you do it in your build script..
<xiangfu>
kyak: those 'svn revision' is for 'release', it's always keep the latest release package svn revision.
<kyak>
ahh, oh, i remember now
<xiangfu>
kyak: I am not using the feeds.conf, only when release. we modify that revision.
<kyak>
ok, i see
<xiangfu>
the 'make distclean' will not remove the 'feeds.conf' :)
<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
<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
<wpwrak>
yeah. the world at a glance. just what we need for our domination plans :)
<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
<kyak>
dvdk: i was running your mplayer-jz in trunk, haven't noticed any difference to backfire :)
<kyak>
error: pathspec '97dc86b793efb9c6ac604cdfff4027fe27efa12c6' did not match any file(s) known to git.
<kyak>
damn.. not this again
<kyak>
i removed the dl/ dir, it became > 2 Gb :)
<kyak>
hm, ffmpeg devs somehow managed to screw up this revision, too
<kyak>
despite of the fact that i got their whole git tree
<kyak>
the only explanation now is that specific commit had been reverted
<kyak>
dvdk: the latest mplayer from svn won't compile -\ sticking to r33341 and ffmpeg is updated to 3b6bbfa0631d237f2bbc85a7b43907733bea1e82
<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
<dvdk>
hmm, cannot push
<dvdk>
error: failed to push some refs to 'git@projects.qi-hardware.com:openwrt-xburst.git'
<dvdk>
git pull:
<dvdk>
You are not currently on a branch, so I cannot use any
<dvdk>
'branch.<branchname>.merge' in your configuration file.
<dvdk>
ok needed --track -b when doing git checkout (?)
<kristianpaul>
dvdk: just git checkout branch_name i thikn
<dvdk>
kristianpaul: did that (i think), but then i couldn't push.
<dvdk>
well --track -b did the job this time.  going to try a pure 'checkout' next time
<kristianpaul>
git push origin branch_name ?
<kristianpaul>
well, origin or whatever name for remote repository
<kristianpaul>
hmm
<dvdk>
kristianpaul: ah, that might have done the job. Â
<plaes>
have there been plans for nanonote v2?
<wpwrak>
plaes: ideas, many :)
<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.
<plaes>
has been pondering about data acquisition platform supporting various sensors
<plaes>
I know about Vernier LabQuest, but these are all stupidly expensive :S
<wpwrak>
you could probably make sensors that connect via UBB. for that money, you can make quite a few ;-)
<wpwrak>
of course, the ben isn't quite so rugged ...
<plaes>
UBB is basically a SPI bus + plain GPIO?
<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
<wpwrak>
in the case of ubb-vga, i switch between 1) and 3), but that's an unusual mode of operation.
<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
<plaes>
hm
<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
<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.
<dvdk>
on the master branch I get now after clean checkout and recompile:
<dvdk>
configure: error: in `/home/pub/spock/src/qi/openwrt-xburst/build_dir/target-mipsel_uClibc-0.9.30.1/libtool-2.4':
<dvdk>
configure: error: C compiler cannot create executables
<dvdk>
ok, my fault: renaming the openwrt-xburst directory is not possible (without distclean), it seems
<kyak>
dvdk: i wouldn't touch mplayer if i didn't have to update ffmpeg git revision.. But i got your point :)
<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
<kyak>
something like this...
<kyak>
in other works, the trunk branch is to temporary keep patches required for openwrt trunk, but not working/tested in backfire
<kyak>
i think xiangfu said it yesterday, but i wasn't very attentive..
<dvdk>
kyak: now i get on 'git stash pop'
<dvdk>
mplayer/Makefile: needs merge
<dvdk>
what do i enter now?
<dvdk>
to take your version of the file?
<kyak>
depending on what changes you have inside your version of Makefile
<dvdk>
only a different ffmpeg rev from yours
<kyak>
so you can just take my version
<kyak>
git co mplayer/Makefile
<dvdk>
git: 'co' is not a git command. See 'git --help'.
<kyak>
then you can git pull
<kyak>
oh, sorry.. i have some shortcuts :)
<kyak>
git checkout mplayer/Makefile
<dvdk>
maysbe just git stash drop
<kyak>
heh, maybe, i didn't know abotu that :)
<dvdk>
seems to have worked
<dvdk>
kyak: but lost some other change.  not important one.
<kyak>
ah yes.. checkouting this individual file would've been better then..
<dvdk>
hnmm.
<dvdk>
git checkout mplayer/Makefile
<dvdk>
error: path 'mplayer/Makefile' is unmerged
<dvdk>
git rm first?
<kyak>
hm ok, now you have to manually resolve the conflict i think...
<dvdk>
what's the command. svn would be 'svn resolved'
<kyak>
there should be lines like >>>> inside mplayer/Makefile
<kyak>
marking the conflict
<dvdk>
git reset --hard HEAD
<dvdk>
kyak: you mean it parses inside these files?  that would be cool.
<kyak>
oh yeah, that one would work.. also smashing your changes :)
<dvdk>
but too late already did 'rm' which didn't help, then reset
<kyak>
ok.. learned how to pick commits from one branch to another :)
<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 :)
<kyak>
git is kinda smart on resolving conflicts btw
<kyak>
i'd say, in most cases it would resolve automatically
<wpwrak>
hmm, i'd say it's more or less at the smartness level of patch(1)
<wpwrak>
(if it doesn't actually use patch(1) :)
<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
<kyak>
dvdk: you should include this change in openwrt-xburst/master, too. xiangfu told he was going to release another backfire-based image
<kyak>
i think it's only in trunk so far
<dvdk>
kyak: you mean change the 2.6.32 config?
<kyak>
yeah
<dvdk>
oh the headaches come back
<dvdk>
:)
<kyak>
git is a beast, right? :)
<dvdk>
my brain is too small for it
<xMff>
+1
<kyak>
when i think that i "mastered" git enough for my daily needs, something always shows up.. And i have to google.. every time :)
<dvdk>
hmm, does it automatically rebuild the kernel, if i just touch the config-2.6.32?
<dvdk>
not sure whether it did anything. Â
<dvdk>
still compiling, though.  does it recompile the full userspace?
<dvdk>
let's just see whether *uImage.bin is new in the end
<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