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>
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.
<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"
<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