<turtlee> and these tools allow you to make physical RAM pretend that it's swap?
<qwebirc91025> is there any way to compile the hello world C application for nanonote and execute it on the platform without actually recompiling the whole kernel
<turtlee> welcomes qwebirc
<wolfspraul> we need to publish the toolchain or some kind of SDK...
<nebajoth> haha
<nebajoth> not just pretend to be swap
<nebajoth> pretend to be swap, and compress and decompress on the fly in and out
<turtlee> nebajoth: just making sure I understand what you're doing. =D
<wpwrak> yes !!!! :)
<nebajoth> most distros seem to be using this already
<nebajoth> at least for their installers
<nebajoth> turtlee: yes
<qwebirc91025> anybody having a solution for my problem
<wpwrak> wolfspraul: keep is simple. toolchain and selected headers/libraries. like in openmoko. that worked great.
<wpwrak> s/is/it/
<nebajoth> why would you have to recompile the kernel?
<wpwrak> nebajoth: probably as part of building all of openwrt ...
<qwebirc91025> yes exactly
<nebajoth> oh
<nebajoth> I dunno anything about that
<nebajoth> I run openwrt on my routers :P
<nebajoth> not my gtd nn
<qwebirc91025> cant we have any toolchain only to compile the C file and port it on nanonote using usbnet and run it
<wpwrak> qwebirc91025: i just bit the bullet, ran the whole build, and then symlinked all the executables into /usr/local/bin
<nebajoth> qwebirc91025: yeah that should work
<nebajoth> hell I'm running openwrt compiled sound modules in my debian I think
<qwebirc91025> but how ?
<qwebirc91025> can you plz tell me the procedure
<nebajoth> I'm not sure I know it
<nebajoth> I have to compile with a mips toolchain myself
<qwebirc91025> right now I just need to develop a C aplication to print some thing on console
<nebajoth> I was either going to do it with openwrt
<nebajoth> or right on the nn
<nebajoth> you can compile on the NN with debian :P
<wpwrak> once done,  ln -s staging_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.32/usr/bin/mipsel-openwrt-linux-* /usr/local/bin/
<qwebirc91025> wpwrak : if i go with this procedure then i need to port the kernel image ?
<qwebirc91025> am I correct  ?
<turtlee> does the basic pyneo debian install slow the NN noticably more than the stock OpenWRT?
<wpwrak> i think it builds a kernel in the process. you will be asked a few questions. just hit enter to accept the defaults.
<nebajoth> turtlee: I didn't keep openwrt on there long enough to know really
<nebajoth> but yeah probabl
<nebajoth> y
<nebajoth> I still find it totally usable though
<nebajoth> bootup takes a little longer
<nebajoth> it could probably be optimized though
<qwebirc91025> but ultimately we need to port the whole kernel image ? isnt
<wpwrak> qwebirc91025: why worry about the kernel ? there's plenty more junk in openwrt ;-)
<wpwrak> qwebirc91025: the build process takes care of it all. you don't have to pay attention to all the things it builds.
<wpwrak> qwebirc91025: for the configuration, instead of "menuconfig" use "oldconfig". i.e., accept things as they are.
<nebajoth> rofl: "When code from the staging tree is loaded in the kernel, a warning message will be printed to the kernel log, and the kernel will be tainted with the TAINT_CRAP flag."
<nebajoth> epic
<wpwrak> sounds like Greg :)
<turtlee> would snort his beverage out his nose if he had a beverage.
<nebajoth> wpwrak: yep
<qwebirc91025> I am worrried about that because in software development for a minor in my application I will have to port the whole kernel again and again
<nebajoth> install debian, compile on the Nanonote itself :D
<wpwrak> qwebirc91025: the kernel is already ported, openwrt merely compiles it one more time :)
<wpwrak> qwebirc91025: and no, you don't need to go through that ritual again once you have built your toolchain
<wpwrak> qwebirc91025: you'll have a mipsel-openwrt-linux-gcc, mipsel-openwrt-linux-ld, etc., which you then use for cross-compiling
<qwebirc91025> I am little bit confused now
<qwebirc91025> let me tell you what all I have already done
<qwebirc91025> I have downloaded source code and toolchian from Ben nanonote website
<wpwrak> qwebirc91025: the "toolchain" or the "tools" ?
<qwebirc91025> and configured it as per http://en.qi-hardware.com/wiki/Building_Software_Image
<nebajoth> does this thing have an internal clock?
<qwebirc91025> I am having one folder namely toolchain having binutils , gcc etc varous folders
<qwebirc91025> and tools folder is also present but not in toolchain directory
<wpwrak> qwebirc91025: sounds good so far
<rafa> nebajoth: what do you mean?
<rafa> rtc?
<nebajoth> I mean
<nebajoth> that it loses the date
<nebajoth> and I have to rdate it back
<nebajoth> I haven't looked into it at all
<nebajoth> maybe this has already been addressed on the wiki or mailing list
<nebajoth> maybe its debian specific
<nebajoth> do you have that issue with jLime?
<rafa> nebajoth: no.. rtc works okey
<nebajoth> ok
<nebajoth> so its a debian thing
<rafa> nebajoth: but it did not do before.. I had to add /dev/rtc* device files..
<rafa> so hwclock -w .. etc works
<nebajoth> aha
<nebajoth> just add the device files and it works?
<rafa> nebajoth: well.. it has several parts.. you need a kernel with rtc driver, etc..
<nebajoth> awesome
<rafa> then you need the proper files under /dev/*
<rafa> and then to test hwclock/date commands ;)
<nebajoth> yeah, I'm about to compile 2.6.36 anyway
<nebajoth> I'll check for rtc driver now
<nebajoth> you have it compiled into the kernel or as a module?
<qwebirc91025> now if I go to openwrt-xburst directory and execute make menuconfig FORCE=1 cmd then kernel configuration screen pops up
<rafa> inside the kernel
<qwebirc91025> now tell me what to do next ?
<nebajoth> I'm sure its turned on actually
<nebajoth> I grabbed your config file
<nebajoth> to build on
<wpwrak> qwebirc91025: i would run  make oldconfig, not menuconfig. just hit ENTER for all the questions.
<qwebirc91025> ok
<nebajoth> or yes "" | make oldconfig
<wpwrak> qwebirc91025: also, FORCE doesn't work reliably. you'll have to edit out the silly test in include/prereq-build.mk
<rafa> nebajoth: you can check you rtc driver in nn kernel with :
<rafa> Jlime$ dmesg | grep -i rtc
<rafa> jz4740-rtc jz4740-rtc: rtc core: registered jz4740-rtc as rtc0
<rafa> jz4740-rtc jz4740-rtc: setting system clock to 2010-06-20 20:30:31 UTC (1277065831)
<nebajoth> "yes "" | make oldconfig"
<rafa> (for example)
<nebajoth> damned double quotes
<nebajoth> but you get my point
<nebajoth> this is my favourite irc channel
<nebajoth> yes
<nebajoth> I'm using the older qi-hw kernel
<nebajoth> 2.6.32.10
<nebajoth> and yes, rtc is on
<nebajoth> but
<nebajoth> [    9.660000] jz4740-rtc jz4740-rtc: setting system clock to 1970-01-01 00:00:00 UTC (0)
<nebajoth> 1970!
<nebajoth> /dev/rtc0 exists
<rafa> did you change the time at some moment? :)
<rafa> date,...hwclock ?
<qi-bot> [commit] Werner Almesberger: Added register definitons and simplified register naming. http://qi-hw.com/p/ben-wpan/1d777aa
<qi-bot> [commit] Werner Almesberger: fw/atspi/atspi.c (reset_rf): added reset timing measurement http://qi-hw.com/p/ben-wpan/44f0c38
<qi-bot> [commit] Werner Almesberger: Enter TRX_OFF to enable DVDD regulator. Plus minor cleanup. http://qi-hw.com/p/ben-wpan/7a534d2
<qwebirc91025> what has to be done to remove FORCE=1 option ?
<nebajoth> I've set it with rdate
<nebajoth> multiple times
<nebajoth> rdate -s time.nrc.ca
<nebajoth> aha
<nebajoth> but
<wpwrak> qwebirc91025: where it says "define Require/non-root", change the next line to "true"
<nebajoth> after running rdate
<nebajoth> the command "date" shows the new correct time
<nebajoth> but hwclock
<nebajoth> still shows 1970
<nebajoth> ok
<nebajoth> ran hwclock -w
<nebajoth> lets see how it goes now :P
<nebajoth> thx rafa
<qwebirc91025> can you plz tell me the syntac
<qwebirc91025> in next line "[ "$$(shell whoami)" != "root" ] is written
<rafa> nebajoth: you are welcome
<qwebirc91025> I have made it "== root"
<qwebirc91025> so dont need to use FORCE=1
<qwebirc91025> now what ?
<nebajoth> is the LED connected via GPIO?
<wpwrak> qwebirc91025: yes "" | make oldconfig
<wpwrak> qwebirc91025: make -j <number_of_cores_you_have_plus_1>
<wpwrak> e.g., make -j5
<wpwrak> lean back and relax while openwrt builds all the stuff
<wpwrak> your toolchain will be in staging_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.32/usr/bin/
<wpwrak> hmm. i better get some sleep. barbecue in 12 hours. terrace oblige :)
<rafa> is not barbecue some meat made with fire only? :)
<wolfspraul> barbecue, nice - 'night
<qwebirc91025> how to chek that hwo many cores are there
<nebajoth> haha terrace oblige
<nebajoth> how many cores are where?
<nebajoth> in your computer?
<nebajoth> cat /proc/cpuinfo |grep processor|wc -l
<qwebirc91025> are you talking about processor or ?
<nebajoth> OK gentlemen
<nebajoth> I believe he was
<nebajoth> what other kinds of core are there?
<nebajoth> OK gentlemen, I'm undertaking a kernel compile FOR the nanonote, ON the nanonote
<nebajoth> I am timing it :P
<nebajoth> I'll let you know what the results are
<nebajoth> ... in a few days
<nebajoth> ... when its complete
<qwebirc91025> fine
<qwebirc91025> I got it
<osokuro> nebajoth: thanks for the advice. wish me luck on my debian install.
<nebajoth> ah yes
<nebajoth> good luck :D
<nebajoth> lmk how it goes
<nebajoth> I'll be here for a bit still
<osokuro> Heh. I won't. time for sleeping. will try the flash over the next day or two.
<nebajoth> ok
<nebajoth> good luck :)
<nebajoth> I eventually intend to release a new rootfs
<nebajoth> but I want to get this new kernel working first
<nebajoth> NN is gonna be busy for the next couple days
<nebajoth> compiling :P
<osokuro> Very cool.
<osokuro> Oh!
<osokuro> one more thing.
<osokuro> any recommendation on how to go about formatting and setting up a swap part on the nand?
<nebajoth> are you going to use the whole thing or partition it?
<nebajoth> actually
<nebajoth> not sure it would be very easy to partition it
<nebajoth> ummm, you can either use the whole mtd partition
<nebajoth> or you can make a swap file
<nebajoth> up to you
<nebajoth> guess you don't need that big a swap file
<nebajoth> er that big a swap
<nebajoth> so I'd make a swap file on the nand and use that
<nebajoth> that tickles my memory of something on the mailing list involving xiang-fu
<osokuro> ohh,
<nebajoth> but I didn't see it while cruising through the last 6 months yesterday
<osokuro> swap file is super-obvious. sorry.
<osokuro> alright. time for sleeping.
<osokuro> see you later.
<nebajoth> he's a nice fellow
<wolfspraul> nebajoth: yes we are lucky with the people that show up. it drives me nuts that the NanoNote is not more useful from a regular user standpoint today. argh. but the direction is right...
<nebajoth> we'll get there
<viric> wolfspraul: one program I lack in the nanonote is something that would allow me to store and navigate maps
<viric> I have to try that nanomap still.
<wolfspraul> viric: yes, nanomap :-) but I haven't tried it myself yet...
<wolfspraul> definitely I want that too though
<wolfspraul> bbl
<qi-bot> [commit] Andres Calderon: ddr-vref improved placement http://qi-hw.com/p/xue/1ba7525
<viric> Hello
<viric> anyone using mpg321 in the nanonote?
<kristianpaul> nope that i'm aware off
<kristianpaul> did you tried gmu?
<kristianpaul> there is also a command line program to play music called: oggplay
<viric> I'll try
<viric> I simply saw that mpg321 seems to require more cpu power than the ben has
<viric> while madplay seems to have plenty of cpu
<urandom__> mpg321? well gmu plays mp3 fine but uses mpg123 i think
<urandom__> cpu power shouldnt be any problem at all for playing music
<viric> hm
<viric> mpg123 should be using floating point, while mpg321 should not
<viric> (for what I read about them)
<viric> so mpg321 should work *faster* in a cpu without fpu
<viric> and at the end, mpg321 uses libmad, that of madplay too.
<viric> wier.d
<urandom__> well mpg123 works fine so just use it
<viric> I'll try.
<urandom__> if you need binarys, use the ones from the dingoo version of gmu
<viric> no no, I build myself
<viric> thank you
<wejp> mpg321 is very old and generally should not be used
<wejp> also, mpg123 has both floating point and fixed point decoders included
<viric> ahh
<viric> There was a time when mpg321 was newer than mpg123 :)
<wejp> that is long ago
<wejp> mpg123 is actively maintained
<viric> ahh
<wejp> last mpg123 release is from july 11th 2010
<viric> great
<wejp> yeah, works really good
<viric> do you use softvol?
<viric> I'd like to get from someone the alsa config for that.
<viric> I could not manage to get it working
<qi-bot> [commit] Andres Calderon: some eth-phy to s6 nets has been routed http://qi-hw.com/p/xue/4193109
<qi-bot> [commit] Andres Calderon: some eth-phy to s6 nets has been routed http://qi-hw.com/p/xue/195bfb9
<hike85> hello everybody
<hike85> I'm trying to compile the toolchain for the new image, but I get this error:
<hike85> In file included from ./include/bits/syscalls.h:11,
<hike85>                  from ./include/sys/syscall.h:34,
<hike85>                  from ./libc/sysdeps/linux/common/sysdep.h:20,
<hike85>                  from ./libc/sysdeps/linux/mips/sysdep.h:25,
<hike85>                  from libpthread/nptl/sysdeps/mips/tcb-offsets.c:1:
<hike85> ./include/errno.h:69: error: thread-local storage not supported for this target
<hike85> ./include/errno.h:69: warning: `tls_model' attribute ignored
<hike85> make[4]: *** [libpthread/nptl/sysdeps/mips/tcb-offsets.s] Error 1
<viric> wejp: I just built mpg123 (generic-cpu optimizations), and it looks like not having enough cpu either
<viric> 99% of the CPU spent on 'system'
<viric> using the 'alsa backend'
<viric> clearly something goes wrong
<wejp> viric, you nee to build it with generic_no-fpu
<wejp> the generic decoder uses floating point math, you really need to tell configure to use the no_fpu decoder
<viric> ah ok
<viric> ah, hence the 'system' load! I guess it's using the kernel fpu emulation
<wejp> with that decoder gmu is able to decode mp3 files with any bitrate with less than 25 % cpu load on the ben
<viric> I've seen 22% on madplay
<wejp> hehe, yeah kernel fpu emulation is especially slow ;)
<wejp> yeah, madplay is a little slower than mpg123 but still okay
<viric> nevertheless I don't know what code my gcc generated, so that the kernel fpu operations are used
<wejp> for ARM cpus mpg123 has an even more optimized decoder, but that doesn't help you on mips cpus ;)
<viric> I did not expect my gcc to produce code for fpu
<viric> I have a sheevaplug, but no sound card on it.
<viric> Maybe for the gp2x I could do something :)
<wejp> you could attach an usb soundcard :D
<viric> :) yes
<wejp> yeah, gmu on the gp2x uses mpg123 with the arm optimized version :)
<viric> How can I know if gcc generated fpu instructions?
<viric> there may be an elf flag for it
<wejp> you can tell gcc to explicitly use its own fpu emulation layer, i think it is -mfloat-abi=softfp
<wejp> but you don't want that
<viric> I know how to set that explicit
<wejp> it is much faster than kernel emulation, but still damn slow
<viric> Wa! Here I go!
<viric> 13% user cpu, 2% system1 :)
<viric> :)
<viric> 192kbps stereo
<wejp> yep :)
<viric> far below 25% :)
<wejp> yeah, just decoding mp3 is pretty fast
<viric> well, it plays.
<viric> so it goes to the sound card
<wejp> gmu does some graphics output too, which needs some cpu, but it is still pretty fast even with that
<viric> ok
<viric> nothing I need, that gmu :)
<viric> thank you very much
<wejp> you're welcome :)
<viric> Aren't you using softvol, btw?
<wejp> yeah
<viric> can you paste your softvol configuration so I could take a look?
<viric> I could not manage to configure it
<wejp> what exactly do you mean? the source code?
<viric> the asoundrd file
<viric> asoundrc
<wejp> oh, sorry, no i do not use alsa for software volume control
<viric> it should have the description of the softvol mixer setting
<viric> Then what volume do you use?
<viric> the hardware mixer? :)
<wejp> i scale the audio signal itself before giving it to alsa (or whatever audio driver is being used)
<viric> ahm
<viric> mpg123 can do that?
<wejp> no
<viric> oh :)
<wejp> i use mpg123 just for decoding mp3 data, the volume control and audio output takes place at another point
<viric> ah..
<viric> maybe I could pipe it to sox
<wejp> that should be possible
<wejp> i think the mpg123 executable can output the data to stdout
<viric> but doing that on the *decoded* signal looks like a heavy job.
<viric> many samples a second
<wejp> it is not that bad and actually you could not even do it easily on the encoded signal
<wejp> and even if you could, you would not want to do that in a music player that is capable of decoding lots of different file formats
<viric> I mean that if mpg123 did that, it would not that be that a heavy task I guess
<viric> for the cpu
<viric> anyway, I have mp3 playing. Great! :)
<viric> I wonder what I need more...
<wejp> it could be even worse, the decoding process is quite complex ;)
<viric> I should try to start X some day.
<wejp> :D
<wejp> i think X is a bit overkill on such a device
<viric> there is the tiny keith X
<viric> it should run fine there
<viric> I could cross-build it, but I did not go into configuring. :)
<wejp> i've used X on the zipit z2 (which has similar specs) and it is rather slow and the screen resolution does not help either ;)
<viric> hm
<wejp> but it is possible
<wejp> should be possible on the Ben too
<viric> What other options are, to run GTK or qt programs?
<wejp> you can use fbdev for video output
<viric> for mplayer I know
<viric> maybe people use qtopia on the fbdev?
<wejp> you can use fbdev for X and there is a gtk port which outputs to fbdev directly
<wejp> there were some problems with that on the ben, though
<viric> ah
<wejp> yeah, qtopia runs on fbdev too
<viric> there are plenty of things to learn :)
<wejp> maybe one could run a tiny x server instead of xorg
<viric> The keith server I said
<viric> It comes with xorg.
<viric> build the server with "--enable-keith" and you are there
<wejp> yeah, you could try that one
<viric> it runs on fbdev
<viric> --enable-kdrive, sorry
<viric> I built it, but I did not try to start it
<wejp> yep right, kdrive was the name :)
<viric> kdrive is made by Keith. I always mix that :)
<viric> I'm busy with another mips... kdrive for another day.
<hike85> guys, sorry to interrupt, but I'm trying to compile the mpg123 lib for gmu
<hike85> but I get errors when compiling the tool-chain :(
<wejp> what kind of errors? could you show us some error log?
<hike85> In file included from ./include/bits/syscalls.h:11,
<hike85>                  from ./include/sys/syscall.h:34,
<hike85>                  from ./libc/sysdeps/linux/common/sysdep.h:20,
<hike85>                  from ./libc/sysdeps/linux/mips/sysdep.h:25,
<hike85>                  from libpthread/nptl/sysdeps/mips/tcb-offsets.c:1:
<hike85> ./include/errno.h:69: error: thread-local storage not supported for this target
<hike85> ./include/errno.h:69: warning: `tls_model' attribute ignored
<hike85> make[4]: *** [libpthread/nptl/sysdeps/mips/tcb-offsets.s] Error 1
<hike85> this is where it stops... I'm on Ubuntu 10.04 and I have all the dependencies needed
<wejp> hm
<hike85> I just added qt and libSDL to the config file
<nebajoth> woop
<nebajoth> 373 minutes, 20 seconds
<nebajoth> to compile 2.6.36 kernel
<nebajoth> ON the nanonote
<nebajoth> actually that's not as bad as I thought it would be
<Antaga> oO
<nebajoth> sup
<viric> nebajoth: with gcc?
<viric> nebajoth: I would not expect gcc to have enough ram
<nebajoth> it doesn't
<nebajoth> that's why I gave it 1G of swap :P
<nebajoth> I run debian
<nebajoth> I had to assign swap anyway, just to run apt-get
<viric> uh :)
<viric> swap on SD?
<viric> or a network block device?
<viric> (just not to wear down Flash memory :)
<nebajoth> microsd
<viric> You don't love that microsd very much :)
<nebajoth> #1 no
<nebajoth> I don't
<nebajoth> I have 4 others identical to it
<nebajoth> #2 wearing out takes forever
<nebajoth> much longer than I'll likely have a practical use for it
<nebajoth> people get really upset about wearing of flash memory
<nebajoth> and I don't really understand why
<nebajoth> when they generally outlive their mechanical cousins
<viric> ok
<viric> I never got a flash memory to wear down too
<nebajoth> right
<nebajoth> I'm sure it does happen
<nebajoth> but last time I looked at the numbers
<nebajoth> it was like
<nebajoth> years
<viric> I have some friends that worked on embedded systems, and they are used to flash wearing down
<viric> But maybe they write the flash a lot.
<viric> argh, there is 2.6.35.3 already.
<mth> you can swap to zram too, by the way
<mth> a compressed block device stored in RAM
<mth> gives you some extra memory before swapping to SD
<viric> how much you set for zram?
<mth> Ayla set it to 10 MB on Dingux, afaik
<viric> dingux is a device or a gnu distribution?
<mth> Dingux is Linux for the Dingoo A320/A330
<viric> does that have also 32MB of RAM?
<mth> yes
<viric> ah
<mth> zram is new in 2.6.35
<viric> great
<mth> I backported it to 2.6.34 though
<viric> I run 2.6.35
<viric> I could try.
<viric> (with 2.6.34, mmc does not work for me)
<mth> there was a bug fixed in the MMC insert detection, I don't know if that's related?
<nebajoth> mth: yes
<nebajoth> I have it compiled into the kernel that took 6h to compile :P
<nebajoth> zram, that is
<nebajoth> in fact, that's the entire reason I undertook to build the kernel
<mth> 6h? you compile it on the NanoNote itself?
<nebajoth> yup
<nebajoth> I was interested in how long it would take
<nebajoth> 6h was a lot shorter than I expected, tbh
<nebajoth> I thought it'd still be going when I woke up toda
<nebajoth> y
<viric> mth: no, the insert detection worked fine. It simply did not understand my sd card
<kristoffer> nebajoth, 6hours isnt that bad :) good to know that it works
<nebajoth> does anybody know if there's anything special that must be done to compiled kernel before it can be flashed to the NN?
<wejp> nothing special, you just need the compiled uImage
<qi-bot> [commit] Andres Calderon: s6 to eth-phy connections has been completed http://qi-hw.com/p/xue/30b1282
<qi-bot> [commit] Andres Calderon: nand routing just started http://qi-hw.com/p/xue/de965fa
<rafa_> nebajoth: you really need to learn how to use a toolchain man
<rafa_> nebajoth: building on host is nice and fun.. but it is not to suffer
<rafa_> nebajoth: you can do the same using a toolchain.. and you will have a kernel built in just a few seconds.. or minutes
<nebajoth> rafa: oh totally, I was just curious and didn't feel like setting up a toolchain yet
<nebajoth> I'll definitely be doing that this week