Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
cladamw has joined #qi-hardware
antgreen has joined #qi-hardware
xiangfu has joined #qi-hardware
Openfree` has joined #qi-hardware
cladamwa has joined #qi-hardware
xiangfu has joined #qi-hardware
<qi-bot> [commit] Werner Almesberger: m1/xbrd/: reduced CB from 25 mm to 22 mm, reducing overall length to 82.08 mm (master) http://qi-hw.com/p/wernermisc/5bf0b30
xian9fu has joined #qi-hardware
orson_zhai has joined #qi-hardware
AwAyla has joined #qi-hardware
<xian9fu> kristianpaul, Hi I tried milkyminer some days ago.
<xian9fu> I flash the soc.fpg by 'm1nor soc.fpg' then
<xian9fu> it's only worked once. spend 5 minutes for get the result. then what even I send to milkyminer. nothing return.
<xian9fu> do you think we should build the 'soc' branch?
jekhor has joined #qi-hardware
cladamw has joined #qi-hardware
<kyak> xian9fu: do you have an idea why this error happens from time to time (ERROR: "irq_set_chip_and_handler_name" [drivers/ieee802154/spi_atusb.ko] undefined!)?
<kyak> i mean, during the build, which has failed
<kyak> xian9fu: also, what's the difference between ~xiangfu/build-nanonote/ and ~xiangfu/building/Nanonote/Ben/ ?
<xian9fu> when build was success it will move to ~xiangfu/building/Nanonote/Ben/
<kyak> it seems like the minimal build always fails
<xian9fu> sorry. all success will move to ~xiangfu/build-nanonote/
<kyak> perhaps we miss something from config-minimal
<xian9fu> kyak, we should not build atusb.ko under config.minimal. I think I already disable that.
<kyak> ok.. is it building in a loop or you start it manually?
<xian9fu> building in a loop
antgreen` has joined #qi-hardware
<kyak> cool, so it started the full build now
<xian9fu> yes.
<xian9fu> I think the at_usb.h miss the irq.h
<xian9fu> s/at_usb.h/at_usb.c
<qi-bot> xian9fu meant: "I think the at_usb.c miss the irq.h"
<xian9fu> spi_atusb.c
* xian9fu testing the spi_atusb now... (by add irq.h)
<kyak> looks like this.. wonder why it works in full image
<xian9fu> kyak, full image don't build spi_atusb
<xian9fu> disabled under config.full
<kyak> ah!
DocScrutinizer has joined #qi-hardware
GeorgeH_ has joined #qi-hardware
cladamw has joined #qi-hardware
orson_zhai has joined #qi-hardware
cladamw has joined #qi-hardware
<qi-bot> [commit] Xiangfu: nanonote: config.minimal: disable spi_atusb since we don't have usb host (master) http://qi-hw.com/p/openwrt-packages/e702c87
<xian9fu> kyak, I just disable the atusb under minimal config. I cannot find out the root cause faster. disable it first. when I work on WPAN patches. will try to make it working.
<kyak> xian9fu: atusb doesn't make sense for Ben anyway, right?
<xian9fu> right. we don't ahve usb host.
xiangfu has joined #qi-hardware
jivs_ has joined #qi-hardware
orson_zhai has quit [#qi-hardware]
<wpwrak> kyak: you'd have to implement USB host first :)
<wpwrak> perhaps we should make a press release whenever Milkymist creator and chief architect Sebastien had a good morning dump ? ;-)
<lekernel> chief architect has better plans, like turning the patch editor into something a bit like the first parts of this: http://vimeo.com/36579366
<wolfspraul> here's hoping that migen gives an upside in several directions
<lekernel> well this will come after migen. migen is about making the SoC more featureful, faster and more portable.
<wpwrak> lekernel: (immediate feedback) sounds nice
zrafa_ has joined #qi-hardware
wej has joined #qi-hardware
<viric> So, there is a working linux on milkymist SoC already?
<lekernel> uclinux
<viric> ah ok, no mmu
<lekernel> Fallenou is working on a MMU
<viric> ok
<lekernel> you can, too. that's the beauty of MM SoC.
<viric> :) clear
<viric> If you want to be well served, make the bed yourself.
jekhor has joined #qi-hardware
<wolfspraul> viric: we can get you interested in Milkymist? :-)
<viric> I'm interested in seeing some information about its software performance and power usage.
<wolfspraul> right now it runs an RTEMS realtime/minikernel, and a specific app on top of that for the video synthesis
<viric> aha
<wolfspraul> power consumption is about 5W total
<viric> with how much ram?
<wolfspraul> 128 megabytes ddr1
<wolfspraul> I don't think the ram's power consumption matters much at all btw
<wolfspraul> but I have no exact number right now
<viric> ok
<viric> Could you publish a run of "openssl speed" in it?
<wolfspraul> sorry don't understand. what exactly do you want to execute?
<viric> "openssl speed"
<viric> I imagine you can run openssl there. :)
<viric> I don't know much about benchmarking... I use 'openssl speed' everywhere, when I want to compare performances.
<wolfspraul> actually I don't think openssl is ported to m1 today
<viric> it should be ansic code
<wolfspraul> sure someone could do it
<viric> ok
<viric> well, I mean it's a benchmark quite broad and easy to build :)
<wolfspraul> it's not very 'meaningful' for m1, but I 100% agree we should first publish any benchmark, so people have a starting point for their thinking
<wolfspraul> you could then proceed to a hardware accelerated openssl speed benchmark :-)
Ayla has joined #qi-hardware
LunaVorax has joined #qi-hardware
<wolfspraul> I'm trying to build a mobile & rechargeable battery pack for an m1 setup
<wolfspraul> so basically I need 12V and 5V out of it
<wolfspraul> I found nice little battery packs like this one http://www.iphonemili.com/products_detail/&productId=8f5df92b-03a0-441f-91bb-d444f512a769&comp_stats=comp-FrontProducts_list01-1311553918454.html
<wolfspraul> so that works well, but I would like to use standard batteries, something more flexible
<wolfspraul> I was hoping to find teeny tiny dc-dc converters that just allow me to put some wide voltage in, and get a stable 12V or 5V DC out, but cannot find them
<wolfspraul> they have a lot of nice dc-dc chips, someone should make breakout boards for them :-)
woakas has joined #qi-hardware
<wpwrak> wolfspraul: you may be able to find some development boards. even for such simple things, they often make some. not sure how cost-effective they are, though
<wolfspraul> well there are suppliers of battery packs, like that mili one
<wolfspraul> but it's amazing how expensive they are, and of course no standard batteries
<wolfspraul> they tend to use charging ics from TI like bqxxxx
<wolfspraul> but in general I find the situation a little unflexible
<wpwrak> that pack looks very stylish. maybe that explains the price :)
<roh> what unit is that? 99 foo?
<roh> us$?
<wolfspraul> yes
<roh> well... there are cheaper ones for sure... but will they do what you want and have a case?
<wolfspraul> case not needed
<roh> there is no standard in user serviceable lithium cells without packaging and security circuit, so they get integrated like in that pack
<wolfspraul> how about every normal rechargeable aa battery?
<roh> how many do you need? i think if its only for prototyping, just buy that thing
<wolfspraul> sure, already done
<wolfspraul> but don't tell me I shouldn't dig deeper :-)
<roh> aa etc sucks. doesnt allow for lithium based cells
<wolfspraul> why couldn't you fit a lithium-ion polymer into an aa case?
<roh> wrong voltage, bad ratio of weight/case/power
<wolfspraul> I didn't pay attention to battery chemicals yet indeed
wej has joined #qi-hardware
<roh> li based stuff has between 2.9 and 4.4V per cell, depending on chemistry and charge state
<roh> mostly its between 3.9 and 4.2 or 3.0 and 3.4V... the first for li-ion and li-po based stuff, the latter for li-fe and similars
<roh> and you need a balancing circuit for keeping proper care which has one line to every cell when used in series. parallel is doable, but needs low manufacturing tolerances in cell chemistry. so its much easier to just use one of the typical used 'plastic bag' packges and add standard industry charge control and safety chips (or outsource that)
<wolfspraul> that's what those mili guys are doing (and similar vendors)
<roh> sure. they buy cells and package them with some circuit i bet is very similar to the appnotes of the chips used
<roh> or the reference design
<wolfspraul> sure
<roh> sparkfun and similars, some arduino boards and stuff watterott has also uses simple li-chargecontrollers and dc-dc switchers. not that complicated to use/design with. mostly its just some caps, some inductivity and a fast diode in addition to the chip
<roh> but they use 'prepackged' cells, mostly single ones, but also small packs which then include the security and balancing chips
<wolfspraul> interesting, ok. that's helpful!
<roh> very similar (basically identical) to what one gets for cellphones, just with a hard shell there
<roh> i can name you a book if you like to read up on more details on battery chemistry
<wolfspraul> please, always
<roh> 'moderne akkumulatoren richtig einsetzen' von andreas jossen und wolfgang weydanz im reichardt verlag
<wolfspraul> thanks!
<wolfspraul> will take a little time to get it and read, but it's queued :-)
<roh> ;)
<roh> its worth having when one has some detail question.. and rare indeed
<roh> we got a copy in our raumfahrtagentur-library
LunaVorax has joined #qi-hardware
wej has joined #qi-hardware
GNUtoo has joined #qi-hardware
wej has joined #qi-hardware
GNUtoo-desktop has joined #qi-hardware
rejon has joined #qi-hardware
emeb has joined #qi-hardware
kilae has joined #qi-hardware
<kyak> jow_laptop: it just caught my eye that OpenWrt-Toolchain-* doesn't have "for-Linux-x86_64/i686" in its name any more (unlike SDK). What does it mean?
<jow_laptop> nothing, it was just forgotten I suppose
<kyak> ah, so it's a bug then :)
<jow_laptop> likely
dptech has joined #qi-hardware
dptech has joined #qi-hardware
GNUtoo-desktop has joined #qi-hardware
jurting has joined #qi-hardware
jekhor has joined #qi-hardware
<mth> kyak: I can reproduce the gmenu2x problem now
LunaVorax has joined #qi-hardware
<LunaVorax> Hello everyone!
<kyak> mth: using Ben?
<mth> no, using Dingoo
<kyak> so you couldn't reproduce it before?
<viric> Do you think linux 2.4 could run in the ben using less resources than 2.6?
<viric> or 3
<viric> or the configuration granularity still allows to achieve similar results, in relation to the features provided?
<mth> kyak: no, but I was probably testing a binary from the wrong location then, so an older version instead of the one I just compiled
<kyak> viric: i think you would spend more time porting 2.4 to Ben
<viric> well I agree
<viric> I just thought if in general linux is becoming too big.
<viric> or the compile time configuration puts all in a good place.
<Ayla> viric: it's becoming big because it have more drivers
<kyak> viric: we could measure performance between 2.6 and 3.2.. probably you will not notice any changes, but who knows?
<viric> but drivers can be disabled at build time
<viric> Maybe linux is forgetting a bit the uniprocessor systems nowadays .)
<viric> :)
<viric> I always thought linux 2.2 was the fastest since 2.0 ;)
<viric> and 2.4 the slowest.
<viric> but I can't prove it :)
<kyak> you are old! :) i barely touched 2.4
<viric> I started at 2.0.34 :)
<kyak> oooold! :)
<viric> haha
<viric> RH 5.2 it was. 5 is a big number.
LunaVorax_ has joined #qi-hardware
<zrafa_> kyak: viric is as old like me I guess :)
<viric> :)
<viric> We went to the magazine store to get updates ;)
<viric> "Mama, can you bring me the latest kernel, at the time you buy your yellow press magazines? Thank you"
<qi-bot> [commit] Maarten ter Huurne: Fixed GCC warning about initialization order. (master) http://qi-hw.com/p/gmenu2x/92d221a
<qi-bot> [commit] Maarten ter Huurne: Don't overwrite link action provided to constructor. (master) http://qi-hw.com/p/gmenu2x/ed8b0c3
<mth> kyak: that second commit should fix it
<mth> viric: compile time configs help a lot, for example a lot of locking ops are reduced to nothing if you have 1 CPU and no kernel preemption
<mth> but I do see the OpenDingux kernel growing over time and we're not writing that much code
<mth> still, it's probably less effort to optimize 3.x than to backport to 2.4
wej has joined #qi-hardware
<viric> mth: that would mean using a non-SMP kernel, right?
<viric> mth: or it's dynamically set?
<mth> yes
<mth> you can make a non-SMP kernel by config
<viric> I know
<viric> but there is the "nosmp" commandline, or "cpu=1", I can't recall... it isn't equivalent enough?
<viric> I remember in 2.2 that preemption never helped me.
<mth> I don't think so: checking that option might be slower than just doing the lock
<jow_laptop> kyak: since a toolchain is not bound to a particular target it might also make sense to replace BOARD with ARCH
<jow_laptop> kyak: so it reads OpenWrt-Toolchain-mipsel-for-Linux-x86_64-gcc-4.6-linaro_uClibc-0.9.33.tar.bz2
<viric> mth: I should try in my nonsmp systems.
<viric> In fact I don't own any SMP.
<mth> my desktop is a Core 2 quad-core
<mth> it's very using when doing big compiles
<mth> *useful
<viric> :)
<viric> I don't doubt it
<jow_laptop> kyak: and maybe replace -for- with -on-
<viric> the 7h of battery of mine are very useful too ;)
<viric> mth: 'perf' won't show me anything about the locks, right?
<mth> it's connected to the wall socket and power outages are rare here, fortunately
<jow_laptop> kyak: and prepend the -for- before the ARCH (toolchain-for-mipsel-on-linux-x86...)
<viric> :)
<mth> I've got a laptop with an i7 and that battery lasts about 7h as well, but not when doing make -j8 ;)
abushcrafterfor1 has joined #qi-hardware
<viric> mth: ah very good
<mth> I don't know 'perf'
<viric> I'll try about the preemption and all that...
<mth> kernel preemption will likely make things slower, not faster
<mth> it only helps if drivers are doing too much work in big chunks
<viric> aha
<viric> userspace preemption will still be there, right?
<mth> yes, that's always there
<mth> the kernel preemption is about whether a syscall or kernel thread can be preempted
<viric> clera
<mth> I guess it could protect against a user doing a denial of service attack by calling lots of expensive syscalls in a row
<mth> but that's not very likely on single-user systems
<viric> aha
<viric> and what do you think of NO_HZ?
<mth> it's good, but it's not perfect yet
<mth> it only turns off the timer ticks when the CPU is idle, we recently found out
<viric> and how is it bad?
<viric> as for performance, may it be bad?
<mth> it's not bad, it's just not always good enough
<mth> in the sense that if you're running for example mplayer, the CPU won't be idle much
<mth> but since there is only 1 process that wants to run, you could omit the timer ticks
<viric> mth: PREEMPT_NONE/PREEMPT_VOLUNTARY/PREEMPT
<mth> but the current kernel does not do that
<viric> ah clear.
<mth> someone is working on a patch to change that, but last time I checked it was still very experimental
<viric> I imagine it's some kind of variable rate scheduler
<mth> in OpenDingux we originally switched to HZ=1000 + NO_HZ, but that increased the overhead significantly
<mth> so now we're using HZ=250 + NO_HZ
<mth> the advantage is that sleep accuracy is now 4 ms instead of 10 ms
<viric> ok
<mth> a lot of emulators want 60 Hz output, so 10 ms is over half a frame, not fine grained enough
<viric> hm
<viric> Ok, I'll go 250 for my desktop too
<mth> hmm, we're using PREEMPT_VOLUNTARY at the moment, maybe we should try PREEMPT_NONE instead
<mth> although the description of PREEMPT_VOLUNTARY says it only preempts at selected places, so maybe that's not so often
<Ayla> PREEMPT_NONE means a much higher latency
<viric> but it's the *kernel* preemption, no?
<viric> latency in what?
LunaVorax has joined #qi-hardware
<mth> yes, but kernel preemption includes syscalls, so it's not fully independent of user space
<mth> Ayla: according to the docs or measured on OD?
<viric> but if the syscalls wait...
<viric> they go away of the scheduler
<viric> I don't know. I'll try PREEMPT_NONE in my desktop.
<Ayla> mth: I did test it on OD, I honestly didn't see the difference
<mth> if a syscall cannot get a semaphore for example, the process will be put in a wait state indeed
<Ayla> but on OD, we rarely have more than one program running
<mth> but with PREEMPT_VOLUNTARY even if the semaphore is available, other processes will get a chance at that point
<mth> Ayla: and was there a different in throughput? (gpmark)
<Ayla> I don't remember the details, that was a long time ago
<Ayla> when we switched to 1000Hz
<viric> what is gpmark?
<Ayla> it's a program we use to benchmark the video driver
<viric> ok
<viric> Do you know any piece that, given a result of 'lsmod', would tell me the kernel options to enable? :)
<viric> localmodconfig
<viric> incredible
<Ayla> make localmodconfig
<viric> and it still keeps them as modules.
<viric> hm interesting
LunaVorax has joined #qi-hardware
kuribas has joined #qi-hardware
LunaVorax has joined #qi-hardware
GNUtoo has joined #qi-hardware
LunaVorax has joined #qi-hardware
<qi-bot> [commit] Maarten ter Huurne: SettingsDialog: Code layout cleanup. (master) http://qi-hw.com/p/gmenu2x/fd642ff
<qi-bot> [commit] Maarten ter Huurne: Surface cleanup. (master) http://qi-hw.com/p/gmenu2x/b248aaf
<qi-bot> [commit] Maarten ter Huurne: Touchscreen: Avoid constructing an SDL_Rect for is-inside tests. (master) http://qi-hw.com/p/gmenu2x/58d6077
<qi-bot> [commit] Maarten ter Huurne: BrowseDialog: Code layout cleanup. (master) http://qi-hw.com/p/gmenu2x/46f2edb
<qi-bot> [commit] Maarten ter Huurne: Explicitly convert 32-bit integers to 16-bit. (master) http://qi-hw.com/p/gmenu2x/8f57afc
<Ayla> whohooo!
<mth> we're back at 0 warnings :)
<wpwrak> mth: so how do you know that the mechanism that generates warnings isn't broken ? :)
<mth> I'm hoping GCC has unit tests for that
<wpwrak> heh :)
<whitequark> viric: openssl is in openwrt, isn't? and I'm pretty sure it is a requirement for some pretty basic apps
<Ayla> mth: with binutils 2.20.1, uClibc 0.9.31 (so, old versions) and GCC 4.7.0 *without* LTO, the libdl bug is still present
<mth> ok, interesting
<viric> whitequark: I hoped so, but we talked about the milkymist
<viric> does the milkymist run owrt?
<whitequark> ah. no idea.
<whitequark> I misread your message then
<viric> :)
<viric> hm using flashplayer... makes my cs/s go to 4000...
<viric> ha, 1000 came from firefox.
<viric> vimprobable2 the same
<viric> mth: if a software makes the cpu go to 4000/5000 cs/s....
<viric> I better blame the sw, no?
<mth> cs/s?
<Ayla> context switch per second, I guess
<viric> yes
<mth> I don't know what a normal amout is, but 4000 does sound very high
<mth> s/amout/amount/
<qi-bot> mth meant: "I don't know what a normal amount is, but 4000 does sound very high"
<viric> I've no idea why this happens. maybe some preemption
<Ayla> it should be equal to HZ, if the program never sleeps
<mth> flash player is the easiest way to drain your battery in any case
<viric> it's firefox with its multiples threads
<Ayla> a context switch will occur if the thread waits for some I/O to finish, is blocked on a mutex, or calls usleep()
<viric> Ayla: this is HZ_250 + NO_HZ, PREEMPT_NONE
<mth> sometimes I'm not doing anything CPU intensive and notice the laptop getting slightly warn... then it's probably a flash ad in a web page that's still open
<Ayla> so the number of context switches is HZ minimum, but can be much higher
<viric> Ayla: due to NO_HZ?
<mth> with NO_HZ the number of switches can be lower as well
<viric> ok
<Ayla> viric: no, due to the fact that < Ayla> a context switch will occur if the thread waits for some I/O to finish, is blocked on a mutex, or calls usleep()
<viric> yes, clear
<mth> maybe flash uses a lot of threads that block on semaphores or something
<Ayla> that's the case for Firefox at least
<viric> yes
<viric> then you get firefox+flash...
<mth> or is a different thread in the same process the same context?
<viric> which adds up
<viric> mth: no, not the same context
<mth> most browsers just take up a lot of memory, but not CPU if you're not interacting with them
<viric> ha.
<mth> while flash keeps consuming CPU even in the background
<viric> there is javascript, flash, ...
<mth> poorly written javascript can also be a problem, yes
<viric> animated gifs
<viric> in firefox, even downloading files takes a lot of cpu
<Ayla> mth: a "context" is just the state of the CPU registers, so two threads of the same process don't have the same context
<mth> animated gifs don't have to be updated unless the animation is currently visible
<viric> "dont have to"... :)
<mth> yeah, theory and practice are often not the same
<viric> with elinks, my cs/s average goes ~ 100/s :)
<viric> mplayer playing a flash video, 500/s
<viric> all looks like too much for me
<viric> it only gets reasonable when doing nothing nothing.
<Ayla> why should it be "too much"?
<Ayla> getting a lower number of context switches won't make your system faster
<mth> well, a context switch is overhead, so it does help to reduce the count, the question is when it's significant and when not
<mth> speaking of context switches, we should add register saving for MXU
lekernel has joined #qi-hardware
<Ayla> good idea
<mth> with a check whether MXU is enabled for the current context: no need to save/restore it if it's not in use
<Ayla> it'd be useful to add the MXU instructions to binutils too
dvdk has joined #qi-hardware
<dvdk> could somebody please remove the spambot user "Bailey Helton" who spammed some qi-hw wiki pages last week? can his changes be reverted automatically?
<dvdk> kristianpaul^ wolfspraul^
<Ayla> mth: do you know a practical way to make the MXU instructions visible?
<Ayla> I mean something like a lib
<mth> visible in what way?
<Ayla> so that they could be used by several apps or libs, like libpng or mplayer
<wolfspraul> dvdk: a spammer went through unnoticed? wait I check
<mth> I don't think we need a lib for that, just inline asm support
<mth> or maybe intrinsics
<dvdk> wolfspraul: ha, good to meet you here. just wanted to drop a mail; sharims.cc/blog has problems with recent iceweasel webbrowser (i.e. debian's firefox)
<mth> MXU will only be used in performance critical code and it's not easy to write code that is both very efficient and generic
<wolfspraul> oops
<wolfspraul> thanks!
<wolfspraul> just blocked helton
<wolfspraul> I think you reverted the edits already, no?
<dvdk> wolfspraul: wrt shop website, see screenshot im mail
<wolfspraul> yes will do, thanks a lot!
<dvdk> wolfspraul: yes found out how to revert.
<dvdk> wolfspraul: just sent mail. hope you remember your GPG password :)
<dvdk> think website problem is certificate-related. CSS is accessed via https://?
<wolfspraul> maybe the cert just expired? :-) I'll check
<dvdk> wolfspraul: riht, on april 1st. ha that was simple
<dvdk> btw typo above it's sharism.cc/shop, not /blog