<wpwrak>
wolfspraul: for IEEE 802.15.4, I can work around it by outputting some high levels on data lines. that flows via the pull-ups into the uSD supply and charges the capacitors. once they
<wpwrak>
're full, it's safe to switch on the FET
<wolfspraul>
hmm
<wpwrak>
wolfspraul: in openmoko, we learned to love this under the name of "the Vsys issue" ;-)
<wpwrak>
it's a small world :)
<wolfspraul>
the sdio wifi card works
<wpwrak>
interesting. maybe they're doing some inrush current limiting. well, i'm not sure about what exactly is allowed at that interface. the "simplified spec" doesn't talk about this kind of details
<wpwrak>
but then, all i add are 2 uF, and that seems to be enough
<wolfspraul>
yes I was just wondering about that. what does the spec say, and does the NanoNote SDIO perform up to spec or not. If it does, does it still make sense to make some of those breakout boards, or is sdio just too weak on the power side for any interesting applications?
<wolfspraul>
I think you are able to get some 'power' out of that, otherwise how can the wifi card work. But of course I cannot follow the details of your argument "capacitive load" "inrush current" etc., only the bottom line.
<wpwrak>
in the ben, sdio power is not really limited. the problem is inrush current. there is no current limit either. maybe an inductor could help.
<wolfspraul>
inductor where? on the side of the ben, or the side of the breakout pcb/cable/breadboard?
<wpwrak>
there is the average power/current and the peak power/current. if you open the FET (transistor) to empty capacitors, they can draw a lot of current for a short moment
<wpwrak>
(inductor) better on the ben, but also outside can help
<wolfspraul>
you tell me :-) can we find out more about the exact SDIO spec? is it interesting to know?
<wolfspraul>
with your latest findings on the "peak power", is the breakout board still interesting? (I was planning to make some...)
<wpwrak>
i think what's interesting to know is how the power performs in the ben at the moment. sdio specs could also be useful background information, of course.
<wpwrak>
i think it is. just with some constraints.
<wolfspraul>
how can we find out how the power performs?
<wpwrak>
connect a scope to +3.3V, switch uSD power on :)
<wpwrak>
it's just on the wrong side of the board for my current experiments, but i'll get to it
<wolfspraul>
would it help you if I sent you one of those spectec wifi cards?
<wolfspraul>
I was stupid to not include it in your gift package...
<wolfspraul>
I think I have 2 remaining here. And a 3rd one I loaned to someone who is doing nothing with it, but also doesn't respond to emails anymore :-)
<wpwrak>
a packrat never says no :) but they would only provide one data point of what can happen
<wpwrak>
i think the main problem may be the capacitors in the ben - not a much on the supply side and a lot on the uSD side
<wolfspraul>
at least you could plug it in, it should get turned on and even start the RF right away. I think it works out of the box. Then you could see what it does to power.
<wolfspraul>
ah yes sure, I understand.
<wolfspraul>
I don't plan to recharge the e-car with the ben, over sdio. Like the xphone can.
<wolfspraul>
but I think we should understand the sdio spec. if we do something that is out-of-spec it's not going to give us much joy anyway, sooner or later.
<wpwrak>
my uSD board should add only 2 uF to the 10.1 uF that are already there. so if that's really all it takes to kill the system, it's very close to the edge
<wpwrak>
it could of course be that there's another problem. i'm not 100% sure about that.
<wolfspraul>
well that's why I point to the wifi card
<wolfspraul>
in my naive thinking about this, I can only compare 'a little' and 'a lot' of power
<wolfspraul>
I would think the wifi card needs 'a lot'?
<wpwrak>
"a lot" of power can be okay if it's continuous
<wpwrak>
the problem is if you need "infinite" power for a brief moment
<wolfspraul>
yes I got that. but there may be a 'peak' spec, and maybe any SDIO card/breakout just has to know and respect that, if it wants to be sdio compatible at least.
<wolfspraul>
so my question is - where should we fix this - on the side of the ben, or on the side of the sdio application
<wpwrak>
an ideal empty capacitor can draw an infinite current. a real capacitor doens't so that, of course, but it can still be huge
<wolfspraul>
ok maybe I'm asking too early. let's see. keep me posted.
<wolfspraul>
I am still planning to make some of those breakout boards, unless they are useless.
<wpwrak>
i don't know (yet) how well we can control inrush current on the board side
<wolfspraul>
yes but maybe it's just required, at least if you want to be sd/sdio compatible
<wpwrak>
i also have another somewhat unsettling experiment: a 100 Ohm resistor connecting uSD VDD with GND. that one also kills the system.
<wpwrak>
in this experiment, all the resistor does is create a base load and make sure the capacitors in the ben don't precharge
<wpwrak>
again, maybe some contact problems with the pseudo-uSD cards may get mixed into this
<wpwrak>
so a meaningful test would be without any card. just to see what the stuff inside the ben does.
<wpwrak>
sdio spec is only relevant for sdio :) so yes, it does matter as far as we want to connect sdio peripherals. but for breakout board stuff, the benchmark would be whatever people would ""typically" want to connect;.
<wpwrak>
some fat capacitors may be among it
<wpwrak>
of course, the breakout cable could also have an inductor :)
<wpwrak>
and even software may be able to solve it, e.g., by pulsing power
<wpwrak>
(pulsing) when you open the FET, +V3.3 will not drop instantly but it will take some time to drop to the critical level. so if you close the FET quickly enough, the capacitors in the uSD side will be a little charged but +V3.3 will not be compromised. then repeat this a few times, and the uSD capacitors will be at a safe level.
<wolfspraul>
hmm
<wolfspraul>
carlos and others want to attach an fpga/cpld to sd/sdio, does that make sense given the power limitations?
<wolfspraul>
(I understand the peak/continuous/capacitor stuff... just trying to find 'action items' for me to do :-))
<wolfspraul>
maybe none yet... too early I think
<wpwrak>
i would expect some suffering :)
<wpwrak>
(bah, router/server just stopped. just like that.)
<wpwrak>
a quick look at the schematics shows about 20 uF on the ben side and 10 uF on the uSD side. if the ben side is fully charged and you turn on the FET, you get the same energy distributed over 30 uF, so that would be around 2.6 V.
<wpwrak>
add more on the outside and it gets worse
<wpwrak>
there are 10 uF more behind a bead that may come to the rescue. and eventually, the regulator will catch up.
<wpwrak>
well .. let's just see. now i'm curious enough :)
<wpwrak>
hmm. system is dead, scope didn't trigger. grmbl. let's try again
<wpwrak>
very strange. i don't see any problem on +v3.3, but the system still dies
<wpwrak>
hmm, for some reason, my scope doesn't trigger. but some change certainly happens.
<wpwrak>
better. i see a dent :) now, without the rf board
<kyak>
for some reason, qt4-packages are not selected automatically during menuconfig.. ie.. i can select them (need CONFIG_PACKAGE_qt4-drivers-gfx-directfb for NanoMap) manually, but every time i run manuconfig again, they are deselected.
<kyak>
i saw you changed back to uClibc-0.9.32.. is it working?
<kyak>
xiangfu: i asked mirko already, but you might know, too:
<kyak>
for some reason, qt4-packages are not selected automatically during menuconfig.. ie.. i can select them (need CONFIG_PACKAGE_qt4-drivers-gfx-directfb for NanoMap) manually, but every time i run manuconfig again, they are deselected.
<xiangfu>
kyak:Â Â yes. same here. don't know why.
<xiangfu>
and is the build is involved by cron jobs the rootfs.ubi only 20M
<xiangfu>
s/is/if
<kyak>
hm, how do you start it?
<xiangfu>
kyak: make distclean -- cp the config file -- feeds update, install -- make
<kyak>
you might know, cron doesn't have your interactive shell (even if it's started under your user), so some env. variables are missing
<kyak>
oh
<kyak>
i'd suggest make distclean -- make package/symlinks -- cp the config file -- make
<kyak>
because make package/symlinks (same as feeds update/install) deface your .config
<kyak>
xiangfu: what about uClibc-0.9.32?
<xiangfu>
kyak: oh. yes.
<xiangfu>
kyak: not test the ubi image today.
<xiangfu>
kyak: ok. I will compile again. if finished I will give you some feedback :)
<kyak>
i'm afraid uClibc-0.9.32 will do bad
<kyak>
but i'm compiling right now
<xiangfu>
kyak: hmm.. we need fix the uClibc-0.9.32
<xiangfu>
kyak: I will try to work on that. we will see :)
<xiangfu>
kyak: NanoMap doesn't work in  2010-09-06, because the make menuconfig didn't select the QT-linux-fb... driver.
<kyak>
xiangfu: yeah, i know about NanoMap, i had to select qt4-drivers-gfx-directfb manually to make it work
<kyak>
xiangfu: startdict is also not working for a long time now
<kyak>
it just hangs during start
<xiangfu>
kyak: in 2010-09-06, works fine in my Nanonote.
<kyak>
xiangfu: maybe because i tested with uClibc-0.9.30.1
<xiangfu>
kyak: the 2010-09-06 is using the 0.9.30.
<xiangfu>
the startdict not work with 0.9.32
<xiangfu>
but , since Mriko vogt update to 0.9.32. let's focus on the 0.9.32 :)
<kyak>
yes, good point
<kyak>
there is 0.9.32 without nptl support
<kyak>
maybe that would work
<kyak>
i don't understand why stardict doesn't work for me, could you please provide your build log for stardict?
<kyak>
maybe some libraries from my host are messing the compilation
<kyak>
ruby is still 1.9.1-p376, won't compile with openssl-1.0
<kyak>
well ok, don't need it anyway
<wpwrak>
hm. something does not compute. i'm beginning to see what i expected to see, but the timing is all wrong.
<wpwrak>
ah, found it :)
<wpwrak>
and killed the ben without external help. heh :)
<wpwrak>
first time i manage to do that :)
<wolfspraul>
xiangfu: when I compile the latest config.full_system, I run into a Qt error
<wolfspraul>
.obj/release-shared-emb-mipsel/qauthenticator.o: In function `qNtlmPhase3(QAuthenticatorPrivate*, QByteArray const&)':
<wolfspraul>
qauthenticator.cpp:(.text+0x2b84): undefined reference to `QDataStream::QDataStream(QByteArray*, int)'
<xiangfu>
wolfspraul: I am still compiling. start at 16:30 today. :)
<xiangfu>
wolfspraul: I try to grep the build log. seems the qauthenticator.o compile fine here.
<xiangfu>
wolfspraul: ok. compile fine here.
<xiangfu>
wolfspraul: have you run "./scripts/feeds update -a && ./scripts feeds install -a " ??
<wolfspraul>
I did, but I'll just do it again
<larsc>
well, there is someone working on the qt package. so the breakage might be the result of some recent commits
<wolfspraul>
larsc: how is the backfire branch handled. I'm confused. Does OpenWrt originally (upstream) have svn or git? are there branches for backfire?
<wolfspraul>
the xburst branch in openwrt-xburst, is it based on backfire? or just on upstream trunk?
<larsc>
openwrt uses svn
<larsc>
there is a branch of the basesytem for backfire
<larsc>
the package repository though is shared between different releases
<larsc>
openwrt-xbursts xburst branch is based on backfire
<GNUtoo|laptop>
hi,lol about openwrt names, specially the kamikaze name, because even it's a coctail it makes people thing it's the development unstable branch
<xiangfu>
larsc: do you know if there is public backfire-branch git ??  because I saw the the openwrt-xburst xburst branch merge the backfire from a git service
<wolfspraul>
that's an example of it (ignore the left columns, just scroll to the far right first)
<wolfspraul>
you see the commits into the Xue camera kicad git repository (on the right)
<wolfspraul>
and in the columns left of it, each column stands for 1 page of the schematics
<wolfspraul>
and the green and red stuff visualizes the changes introduced by each commit
<wolfspraul>
you can click on one of the small overview graphics to get a bigger one, and if you click on that you even get a PDF with separate before/after apges
<wolfspraul>
absolutely brilliant stuff!
<tuxbrain>
:o
<tuxbrain>
WOOOOOOOOOOWWWW!
<tuxbrain>
this is the best fucking graphical example of what qi-hardware is about
<kristianpaul>
:)
<tuxbrain>
lack of enough hands to clamp
<tuxbrain>
clap
<larsc>
the visual diff is awesome :)
<tuxbrain>
the hole thing is very intuive, :) there is a name for such thing?
<wolfspraul>
no name
<wolfspraul>
it's not live yet (on the qi server), that's on my end now
<wolfspraul>
maybe one day it can be extended for layout too, but my part is first to get this thing live...
<wpwrak>
wolfspraul: i still need to move it to a better place.  i think i'll skip the history migration to save time, though.
<wpwrak>
wolfspraul: the history is "personal" anyway, nobody really looked at the code until perhaps the last one or two commits. so the old history doesn't convey much useful information.
<wpwrak>
wolfspraul: trading style for expeditiousness :)
<wolfspraul>
you mean the history of the scripts?
<wpwrak>
yes
<wolfspraul>
sure, the authorship is clear anyway
<wpwrak>
that too :)
<wpwrak>
tuxbrain: (name) the script is called schhist2web :)
<wpwrak>
maybe i'll just call it schhist. can't think of a nice name.
<tuxbrain>
:o leds blinking!!!! :) :) :) :)
<wpwrak>
tuxbrain: you got it to work ? congratulations ! :)
<tuxbrain>
it works on debian (where I compile while flashing the 600Mb of the beta nanowar edition distro) and now is working on the jlime nanowar edit. where is my video camera!!!!!
<tuxbrain>
???
<wpwrak>
tuxbrain: i think you need a camera team ;-) and you should send the video of you doing eight things at the same time to Bruce Schneier. he likes squid :-)
<tuxbrain>
wpwrak: hey and all knowing barelly nothing about nothing :)
<wpwrak>
tuxbrain: you'll make it far ;-)
<tuxbrain>
wpwrak: just if I can parasite knowledge from people like you :P
<wpwrak>
sounds like an efficient strategy :)
<kristianpaul>
parasite
<leviathan>
tuxbrain: hi
<GNUtoo|laptop>
leviathan, pm him
<leviathan>
GNUtoo|laptop: ok
<tuxbrain>
hi
<GNUtoo|laptop>
because qi-hardware is specific to qi-hardware such as the ben nanonote,the milkymist etc...
<GNUtoo|laptop>
copyleft hardware
<GNUtoo|laptop>
fully free software
<GNUtoo|laptop>
etc...
<tuxbrain>
:) totally try GNUtoo|laptop :)
<GNUtoo|laptop>
lekernel, for the milkymist imagine a FLOSS SOC
<GNUtoo|laptop>
s/FLOSS/free
<lekernel>
?
<GNUtoo|laptop>
oops sorry
<GNUtoo|laptop>
s/lekernel/leviathan
<GNUtoo|laptop>
lekernel, you're french btw?
<lekernel>
yes
<GNUtoo|laptop>
ok
<GNUtoo|laptop>
me too
<kristianpaul>
GNUtoo|laptop: ah i tought you 're Italian
<GNUtoo|laptop>
I live in italy
<GNUtoo|laptop>
but that doesn't means I'm italian
<wpwrak>
hmm, i think i'll have to unearth the "myroot" build system soon, to have a lean alternative to openwrt but with "regular" programs. the things busybox does are plain scary. e.g., running
<wpwrak>
strace -f sh -c 'echo jz4740-mmc.0 >/sys/bus/platform/drivers/jz4740-mmc/unbind'
<wpwrak>
twice. the second run gets an ENODEV and then all hell breaks loose.
<wpwrak>
try to write. oh no, that didn't work. try to write a bit less then. still no go. try again. give up ... and write to stdout instead ! what kind of surrealist dreams up this sort of thing ?
<emeb>
gnarly
<emeb>
so this is all due to busybox subsuming almost all ordinary commands in the system?
<emeb>
(and presumably not quite getting it right)
<wpwrak>
emeb: this is the sort of productivity killers that are lurking in those "light" tool replacements, dropbear, busybox, dash, and the like. every once in a while you run into a completely baffling anomaly and it takes you a long while to realize it's not some bizarre effect caused by whatever it is you're doing.
<emeb>
:)
<emeb>
has fought with dropbear in the past
<wpwrak>
emeb: (busybox taking over) yup, /bin/sh is a link to busybox
<emeb>
busybox is probably not necessary on the Ben - there's enough room in the flash for a real system
<emeb>
it's more a hold-over from the openWRT roots
<emeb>
wpwrak: google doesn't turn up anything meaningful for 'myroot'
<wpwrak>
yup. the ben shouldn't need this kind of diet. we've had the same story in openmoko. at the beginning, also everything was those reduced tools. and every once in a while, some new trap was found.
<wpwrak>
finally, after years, they got replaced with the real things.
<wpwrak>
(buildroot) naw, i have a system that builds a small rootfs from packages (for the openmoko environment). svn.openmoko.org/developers/werner/myroot/
<emeb>
ah - quotes around 'myroot' turns up the openmoko stuff...
<emeb>
looks a bit more lightweight than buildroot...
<emeb>
but using std tools...
<wpwrak>
it'
<wpwrak>
s ver lightweight. needs a package repository to work from, though. perhaps jlime would be a good basis.
<emeb>
*nod*
<wpwrak>
i'll have to chat with rafa about this when he's back.
<Textmode>
shudders
<Textmode>
text editing on the nanonote, never hated the default 8-space tab so much in my life :P
<kristianpaul>
heh having 23 register to drive gpio may sound crazy but at the end gives more organization :)
<kristianpaul>
okay now i got this,  do i need write memory directly? or that could end in linux be mad with me? ;)