<qi-bot> [commit] Andres Calderon: USB D routing started http://qi-hw.com/p/xue/bbf8fde
<kyak> unclouded: hi, did you actually get nightsky working?
<kyak> because 1) it won't build, but i fixed it with -rpath-link and 2) it runs, but hangs and does nothing
<unclouded> kyak: yes, I installed the package to my NN and it started
<kyak> hm, that's strange
<unclouded> does it write anything to stdout before hanging?
<kyak> do you have the latest everthing?
<kyak> no, it writes nothing
<unclouded> afaik
<kyak> when i strace it, the last line is getuid() = 0 and then nothing
<unclouded> it's looking for the user's home directory
<kyak> yeah, i know
<unclouded> the next call should get getpwuid
<kyak> i tried to change it (i.e. hardcode the path to yml file), but it still hangs
<kyak> in a weirdest way
<kyak> there are two ioctl's, and after that - nothing
<unclouded> scratches head
<unclouded> is path_to_data set to some really long path or is it the default?
<unclouded> also, I thought the Makefile used rpath-link already?
<unclouded> kyak, could it be RAM?  how much free RAM have you got?
<kyak> for the RAM, i have swap enabled, so should be no problem
<kyak> i have warnings about rpath-link not enabled that prevent from building.. so i had to add it manually to TARGET_LDFLAGS in openwrt's Makefile
<kyak> then it builds.. i rememeber you use openwrt SDK instead of toolchain, could it be the difference between us?
<kyak> i tried to printf path_to_data, but it won't output (i.e. it doesn't even call "write")
<kyak> it hangs somewhere before
<kyak> and the strangest thing is, when i uncomment this line where is checks for home dir, strace output is finished after getuid()
<kyak> unfortunately, i can't check anything right now.. would be good to check this path_to_data before call to getuid()
<unclouded> which is the SDK and which is the toolchain?  Just now I did git pull on openwrt-xburst  and did package/nightsky/{clean,install} V=99, reinstalled in on the NN and that works
<kyak> than it's toolchain that you have
<kyak> i me, too
<kyak> we should be on the same level then
<kyak> with the same hardware :)
<kyak> weird!
<unclouded> exactly.  we shouldn't see any differences! :(
<unclouded> could it being a glibc/uClibc thing?
<kyak> did you do make package/symlinks?
<kyak> i think recently they switched to uClibc-0.9.32
<kyak> do you have it in your build_dir?
<unclouded> I don't remember.  probably not, just scripts/feeds update -a && scripts/feeds install -a
<unclouded> let me check
<kyak> ah, this is the same
<unclouded> no, I've got: build_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1
<kyak> now this is the difference!
<kyak> toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.32
<kyak> i've got
<unclouded> maybe you used to use 0.9.31 and there are still bits of it around?
<kyak> mm, i rememeber is cleaned up
<kyak> but a good idea, i will cleanup
<kyak> i suggest you clean up, too :)
<unclouded> didn't I read somewhere there's a separate toolchain clean?
<kyak> there's a make clean
<kyak> also make toolchain/clean etc
<kyak> because i noticed that make clean doesn't clean everything
<unclouded> it will take me a while to rebuild.  old hardware
<kyak> me too
<kyak> also, my CPU heats up to 92 C :)
<unclouded> wow.  what type of CPU?  Intel?
<unclouded> there's a make distclean too apparently
<kyak> no-no
<unclouded> it says that "make clean" does not clean the toolchain.  is uClibc considered part of the toolchain?
<kyak> distclean is bad :)
<kyak> it removes your downloaded packages
<unclouded> sure?  that page says "cleans up everything expect $(TOPDIR)/.config and $(TOPDIR)/dl/"
<kyak> i did: make clean, make target/clean, make toolchain/clean, make tools/clean
<unclouded> maybe it's out of date
<unclouded> ok, I'll do the same
<kyak> Pentium(R) Dual-Core  CPU      E6500  @ 2.93GHz
<kyak> my CPU
<kyak> now to update and rebuild
<unclouded> not that old then!  I'm building on Mobile AMD Athlon(tm) 64 Processor 3200
<kyak> $ du -sh build_dir/
<kyak> 6,8G    build_dir/
<kyak> strange.. i think i'll just rm al manually
<kyak> what is the machine you have there? a laptop?
<unclouded> yes
<kyak> old good laptop is living his last days somewhere under your bad :)
<kyak> *bed
<kyak> so i'm wondering.. maybe you're right and we need to make distclean
<kyak> i don't like these leftovers in build_dir
<unclouded> it's pretty good as an Internet gateway.  doesn't use much electricity and runs OpenVZ and apache2 and so on just fine
<kyak> i expected them to disappear
<unclouded> not so hot for building but better than my actual laptop, which is a Pentium4M - even slower
<unclouded> is build_dir there when you first "git clone"?
<kyak> no
<kyak> should not be
<unclouded> must be safe to remove then: it's all been generated
<kyak> so i just made distclean
<kyak> be warned, dl/ dir disappeared
<kyak> i'll re-download, that would compensate for my CPU "speed" and we should finish together :)
<unclouded> which command are you using to "make".  can I avoid compiling the kernel again?
<kyak> brb, sorry.
<unclouded> no worries
<kyak> i just "make".. or what do you mean?
<kyak> also, distclean removed the .config.. i'll take the one from data/qi_lb60/conf/config
<kyak> ok, i used the default config, only chose "nightsky", now making
<unclouded> that doc must be old then sorry.  it says it -won't- remove .config
<unclouded> also, I could just give you an .ipk to see if that works on your NN.  then we'd know for sure that it's something in the build system
<kyak> that's a good idea
<unclouded> does that work on your NN?
<kyak> unclouded: won't be able to try it for at least another 8 hours
<unclouded> the build or the .ipk?
<kyak> the .ipk
<kyak> building now, but will also try later at home
<unclouded> ok, no problem.  I'll leave the file up there then
<kyak> ok, thanks!
<qi-bot> [commit] Werner Almesberger: Update IRQ_RF after reworking both boards. IRQ_RF was erroneously connected http://qi-hw.com/p/ben-wpan/738618a
<qi-bot> [commit] Werner Almesberger: Finished and tested TX/RX. (LQ doesn't work yet, the rest does.) http://qi-hw.com/p/ben-wpan/73043a5
<unclouded> kyak, I rebuilt my OpenWRT from clean with "make tools/install toolchain/install package/nightsky/install" and it built ok.  hope yours rebuilds ok from clean
<kyak> tslib.cpp:42:19: error: tslib.h: No such file or directory
<kyak> stupid qt4 won't compile again
<kyak> Clock.h:10:21: error: SDL/SDL.h: No such file or directory
<kyak> this is nightsky
<kyak> actually, something is wrong with your toolchain
<kyak> it should NOT compile nightsky
<kyak> because it depends on sdl, and by make package/nightsky/install you don't  build dependcies
<kyak> at what point exactly was your libsdl and sdl-image build exactly after cleanup?
<unclouded> true.  I didn't rm build_dir as you did
<unclouded> so libsdl must still have been lurking there
<kyak> indeed
<kyak> now i'll just wait for someone to fix qt4
<kyak> (as usual)
<kyak> damn i get so pissed every time is is broken AGAIN upstream
<kyak> how are they testing??
<unclouded> can you build libsdl and libsdl-image without building qt4?
<kyak> i'd like to avoid it
<kyak> it means manually building dependencies for libsdl and libsdl-image and dependencies of depenedcies.. and so on]
<unclouded> not fun
<unclouded> shame the build system can't do it auto.  the data is there
<unclouded> once a package has been ported to openwrt-packages, what has to happen before it's available for installation via opkg?
<kyak> i think it has to be included in the next build :)
<kyak> i mean, next release of image for Ben
<qi-bot> [commit] Werner Almesberger: Setting the transmit power was broken. (And LQ works, by the way.) http://qi-hw.com/p/ben-wpan/2514804
<wolfspraul> kyak: when you say qt4 is broken 'upstream' - where do you mean?
<wolfspraul> in openwrt?
<wolfspraul> I think mirko is quite active on all things qt4
<wolfspraul> does he know what is broken? what is broken? :-)
<kristianpaul> wpwrak: hey
<kristianpaul> you planning use CPLD to interface SPI?
<kristianpaul> hmm i have XC2C64A board from digilentic if you need try a core or something
<kristianpaul> i need SPI plus some glue logic too
<qi-bot> [commit] Andres Calderon: USB A Phy has been routed http://qi-hw.com/p/xue/3eea348
<qi-bot> [commit] Andres Calderon: minor routing progress http://qi-hw.com/p/xue/c3ab9ef
<wpwrak> kristianpaul: i was inquiring about how hard/easy it would be to make an SPI to SPI bridge for the software-defined GPS wolfgang is considering. it would basically be a chip that outputs an SPI-like stream of quadrature samples at a few Mbps.
<wpwrak> kristianpaul: since the ingenic cpu can only be an spi master, not an spi slave, we would need some glue logic with a (very) little buffer to translate between the two.
<wpwrak> kristianpaul: my question is just if the simplest and cheapest CPLD is already good enough or this or if we need something more powerful. i'd leave the implementation to the experts ;-)
<kristianpaul> :)
<wpwrak> (well, if sebastien one day writes a free synthesis tool for fgpas and such, i might be interested to play with programmable logic. verilog looks kinda nice :)
<kristianpaul> yeah is nice :)
<kristianpaul> i'm learning using the MM SoC
<wpwrak> nice way to get started ;-)
<kristianpaul> i can acept Xilinx for now is the only non-free stuff i use in electronics
<kristianpaul> btw are your aware of GPS signaniling and processign ?
<kristianpaul> i'm just learning too amazinf topic btw
<kristianpaul> amazing*
<kristianpaul> ah i founded losts of free sofware projects involved around, great !
<wpwrak> i have one non-free thing crawling about on my systems, and that's the windows-only (and non-wine) 3d scanning application. that's already more than enough for my taste ...
<kristianpaul> i have my heekscad is okay for my 3d needs
<wpwrak> (gps) i don't really know about. wolfgang just asked me a few questions about which rf frontends would generally fit, assuming you want to do as much as possible in software. there's someone else working on a dsp-based gps reciver we could then adapt. (or that's the theory)
<kristianpaul> i see
<wpwrak> alas, heekscad doesn't speak the proprietary protocol my cnc mill uses when scanning :-( and reverse-engineering it isn't quite easy either. it's already hard to snoop it in a useful way :-(
<kristianpaul> :(
<kristianpaul> 3d is hobbiest so i dont hurge for high advanced features
<wpwrak> well, one day i'll try ... but for now, i'll just live with having an enemy (i.e., a windows box) in my camp
<wpwrak> very high-end 3D gets expensive anyway ;-)
<kristianpaul> if you can handle is okay
<kristianpaul> indeed
<kristianpaul> btw what do you think is the trugput that the Ben Xbust can support on its gpio pins?
<kristianpaul> i dint check datasheets in depth hoping find that info
<wpwrak> hmm, you mean the highest frequency at which you can toggle a gpio ?
<kristianpaul> yeap
<kristianpaul> (sorry my english dictionaary is small)
<wpwrak> i would expect a few dozen mhz. almost certainly < 100 MHz, though. the limiting factor should be cpu cycles and the internal busses.
<kristianpaul> ok
<kristianpaul> good
<wpwrak> you can write a little assembler program that sets a gpio on and off. you probably need to unroll the loop, though, for an accurate measuement.
<kristianpaul> any Xburst hacker around?
<kristianpaul> ywah i was thinking in asm right now
<kristianpaul> i need fast gpio response
<kristianpaul> and i dont trust linux for that !
<kristianpaul> i guess will be slow
<wpwrak> linux will be slow :) my guess would be that a memory/register access costs you at least 2 cycles, so a "write 0" followed by "write 1", infinitely unrolled, would need 4 cpu cycles per cycle of the signal. so that's 84 Mhz.
<kristianpaul> yeah i think i need check code examples from SIE  Unal guys did great work documenting gpio and low level stuff
<kristianpaul> s/Unal/UNAL
<wpwrak> if you want to, say, output some data in parallel, a la SPI, that would be  shift_data(1), write_carry(2), write0(2), write1(2) = 7 cycles or 48. this is quite optimistic. not sure if the xburst can be so efficient. if it needs an add or, worse, a jump in this case, expect even less
<kristianpaul> well may the CPLD save the day, just in case ;)
<wpwrak> bit-banging serial protocols almost always sucks :)
<kristianpaul> or a dual core Xburst :D
<kristianpaul> yeah :(
<kristianpaul> well i pics (my previous experience) is okay for simple stuff but well protocols with Mhz is soemthing i need to deal with
<kristianpaul> s/i/in
<wpwrak> hmm yes, i'll have to speed up the little spi in my rf board as well. right now, it should be crawling at less than 1 Mbps ... (not that it matters so far)
<wpwrak> and then there's of course the frequency counter board that stubbornly refuses to do anything. that one should work up to 6 MHz, although with hardware support.
<kristianpaul> oh thats hihg
<kristianpaul> high*
<wpwrak> the latter is for calibrating my crystals. the idea is to count the 1/2/4/... MHz clock derived from the crystal, then compare this with NTP time. after a day or so, i should have 1 ppm accuracy :)
<kristianpaul> ohh
<wpwrak> saves me buying a USD 3000 frequency counter :)
<wpwrak> (of course, the latter would still be nice to have. ah, prorities, priorities ...)
<kristianpaul> money, money money..
<wpwrak> yeah. so useless yet so important ...
<qi-bot> [commit] Juan64Bits: Routing DDR-B http://qi-hw.com/p/xue/4edf66b
<qi-bot> [commit] Andres Calderon: USB Phy re-routed http://qi-hw.com/p/xue/2e8564b
<qi-bot> [commit] Andres Calderon: 2 new decoupling caps http://qi-hw.com/p/xue/7825f69
<qi-bot> [commit] Werner Almesberger: f32xbase didn't build on ancient Gentoo due to missing include. http://qi-hw.com/p/f32xbase/bc37839
<qi-bot> [commit] Werner Almesberger: Requests following a rejected SETUP requests failed too, which sometimes http://qi-hw.com/p/f32xbase/fd09655
<qi-bot> [commit] Werner Almesberger: lib/usb.c (open_usb): libusb documentation claims that considerable http://qi-hw.com/p/f32xbase/a77a9a6
<qi-bot> [commit] Werner Almesberger: Added list of to do items and known bugs. http://qi-hw.com/p/ben-wpan/c01a5e0
<qi-bot> [commit] Werner Almesberger: Minor potential improvements of USB robustness. http://qi-hw.com/p/ben-wpan/8f744bb
<qi-bot> [commit] Werner Almesberger: Literature consistently calls the Link Quality Indication LQI, not LQ. So do http://qi-hw.com/p/ben-wpan/bb7b049
<kristianpaul> xiangfu: hello :-)
<xiangfu> kristianpaul: hi
<kristianpaul> Can you point me examples of using asm for the Ben Xburst?
<kristianpaul> do we have datasheets for the Xbusrt 4720 btw?
<kristianpaul> i need find out more info about some electrincal characteristics..
<kristianpaul> oh nv
<kristianpaul> :p
<kristianpaul> xiangfu: ahh uboot is the clue ! :)
<kristianpaul> thanks
<qi-bot> [commit] Juan64Bits: Kernel image uploading http://qi-hw.com/p/nn-usb-fpga/1ef32f4