<kyak>
viric: since you are the only known qemu expert to me, let me ask you some questions :)
<kyak>
first of all, i decided to start with a regular ext2 image as a rootfs.. i did dd, mke2fs, mounted image, copied rootfs files there - this stage had no problem i think
<kyak>
then i append root=/dev/hda, but qemu outputs some weird messages about "pgrep: No matching criteria specified"
<kyak>
and then thereis kernel panic
<kyak>
my roots is mounted fine as i see above from kernel output
<viric>
kyak: maybe the kernel is not calling 'init' properly
<viric>
kyak: you may need to pass init= to the cmdline
<viric>
it looks like calling pgrep instead of init. How, I don't know :)
<kyak>
xiangfu: i use staging_dir/target-mipsel_uClibc-0.9.30.1/root-xburst/*
<kyak>
viric: ok, lemme check
<kyak>
what troubles me though is that there's staging_dir/target-mipsel_uClibc-0.9.30.1/root-xburst/init and staging_dir/target-mipsel_uClibc-0.9.30.1/root-xburst/sbin/init
<kyak>
two different files
<kyak>
viric: btw, i tryed to remove the pgrep from rootfs - didn't help :)
<xiangfu>
kyak: by default openwrt kernel will only try "/etc/preinit"
<kyak>
i even tryed to remove init
<kyak>
nothing had changed
<kyak>
xiangfu: it's malta kernel
<xiangfu>
kyak: ok.
<viric>
set init=/etc/preinit
<kyak>
the one qemu has support for
<viric>
if it's what openwrt meant to be as init
<kyak>
init=/etc/preinit made the pgrep error go away
<kyak>
now i have just "Kernel panic - not syncing: Attempted to kill init!"
<viric>
What is that 'init'? busybox init?
<viric>
Do you have /dev/console in the filesystem?
<kyak>
init is a link to busybox
<kyak>
thereis not /dev/console. isn't it created automatically?
<viric>
no
<viric>
You need to become root and 'mknod' the files into the filesystem, or use a 'device table' :)
<viric>
at the time of making the filesystem
<kyak>
strange.. i thought  all files in /dev are created automatically
<kyak>
during boot
<viric>
kyak: well, you need a minimum of them
<viric>
kyak: /dev/console *only*, in fact.
<viric>
or init will die.
<kyak>
ok, will create it now
<viric>
mkfs.ext2 does not allow for a device table though. You'll have to become root, mount the fs and mknod it
<kyak>
cd dev; mknod console c 5 1
<kyak>
didn't help -\
<kyak>
i wonder why it dies silently... almost impossible to debug
<viric>
maybe /dev/console is not enough
<viric>
let me check...
<viric>
I can't find my notes about that
<viric>
I recall only /dev/console
<kyak>
i wonder how does openwrt boot if it doesn't have those
<viric>
kyak: it should have those. you may have done something wrong in the ext2
<viric>
:)
<kyak>
i'll try unpacking the rootfs.tar.gz now instead of copying those files from root-xburst
<viric>
that device_table.txt says what I have in /dev
<viric>
Maybe you need /dev/null to?
<viric>
too
<kyak>
i'll create all of those if they are not in tar.gz
<xiangfu>
kyak: check "root-xburst/lib/preinit/*" which exec by /etc/preinit of openwrt.
<viric>
now I think console and null are the needed. :)
<xiangfu>
s/exec/execute
<kyak>
xiangfu: hm.. an amount of scripts there.. i assume some of them fails?
<kyak>
ok, the /dev in tar.gz is empty,  too
<viric>
make console and null
<kyak>
hey-hey-hey!!
<kyak>
it worked!
<kyak>
Linux BenNanoNote 2.6.36-20850-gace61dc #1 SMP Mon Nov 22 09:43:21 MSK 2010 mips GNU/Linux
<viric>
Ha! :)
<kyak>
viric: thanks :)
<viric>
All this is full of non trivialities I had once to defeat :)
<viric>
now that you know all I know, go and spread it!
<kyak>
viric: oh, i created the /dev/null in case you didn't understand :)
<viric>
I know I know
<kyak>
i think some of those preinit script create these files
<viric>
I was almost sure 'null' had to be there
<kyak>
but maybe they fail
<viric>
I think that without /dev/console, the kernel cannot run the init
<viric>
maybe it needs null too.
<wolfspraul>
yes please, write it up on some wiki page...
<kyak>
now, the thing i wanted to do for a long time
<viric>
I mean that maybe it's not up to 'init', but up to the kernel
<kyak>
compare gcc speed on real Ben and on emulated Ben :)
<kyak>
though that malta board is slower than Ben
<viric>
kyak: I don't think qemu is emulating the 'slowness' haha
<viric>
kyak: how much ram you use there?
<viric>
xiangfu: having jtag access to the xburst cpu is only a matter of wiring on the board?
<wpwrak>
viric: the JTAG signals should all be accessible on test points
<wpwrak>
viric: not sure what the software support side looks like, though
<wpwrak>
viric: what would you use it for ? i've been looking for a strong reason to support jtag in idbg, but haven't found one so far
<xiangfu>
viric: I think so.
<viric>
wpwrak: I think openocd has files for it
<viric>
for xburst...
<viric>
wpwrak: not one? attaching a gdb to the kernel is nice. :)
<viric>
wpwrak: I used that to debug a kernel failing to boot on the sheevaplug
<viric>
with such a developed kernel, maybe now is not needed.
<viric>
I think that the nanonote community now has few people having even their own build kernels
<viric>
so few deal with kernel related trouble (like kyak felt some minutes ago in qemu)
<wpwrak>
viric: (only few people) yeah, that's true
<wpwrak>
viric: i remember from the OM days that the main use of JTAG there was to do the initial NAND load of the system. but we don't need JTAG for this on the ben
<viric>
wpwrak: ah, I was supposing the processor jtag would allow for breakpoints and things like that
<wpwrak>
viric: in OM, i hardly ever used JTAG to debug kernel problems. maybe 2-3 times. the tricky ones were often in the suspend/resume path anyway, which conflicted with JTAG
<viric>
oh
<wpwrak>
viric: yes, breakpoints and all that should be there
<wpwrak>
viric: (OM) another problem was of course that, in addition to the general fragility of openocd, our debug board had reliability of its own. so many times, trying to jtag meant to spend half the day just fighting reticent infrastructure.
<viric>
ah
<wpwrak>
viric: on the ben, we could at least overcome the hardware side of the unreliability. at least i don't see wolfgang or adam add a cute little fpc with external debug board anytime soon ;-)
<wpwrak>
or, in this case, more accurately, "fragile piece of crap" :)
<wolfspraul>
wpwrak: you've asked about boom timing the other day
<wolfspraul>
Adam is making good progress on Milkymist One RC2, so maybe in 3 weeks or so that project could wrap up
<wolfspraul>
there are still details like power adapter, jtag-serial board, case
<wolfspraul>
so maybe add a week or two
<wolfspraul>
but right after that I will start with Xue, and I think first of all that means the boomification
<wpwrak>
viric: it really had everything: excessive manufacturing tolerances, material fatigue on the connectors at both ends, easily triggered fatal failure modes (breakage) on both ends, hairline cracks in the cable itself, ...
<wpwrak>
wolfspraul: (boom timing) excellent ! that'll work very well
<wolfspraul>
another item on my todo list is to add some more command lines to KiCad, similar to your --plot, but for layout generation, and bom .lst file generation, etc.
<wolfspraul>
I should also get to that in December hopefully
<wpwrak>
wolfspraul: ah, ready to face the C++ dragon ? :)
<wolfspraul>
no worries
<wolfspraul>
yes, ready
<wolfspraul>
remember my past as a paid coder
<wolfspraul>
once upon a time I had the passion, energy, enthousiasm to read entire Stroutroup books cover to cover, trying to understand every detail of that language
<wolfspraul>
that bastard stole my youth :-)
<wpwrak>
;-)))
<wolfspraul>
seriously
<wpwrak>
now we know where old bitter coders come from :)
<wolfspraul>
determined, not bitter
<wolfspraul>
FOCUS
<wolfspraul>
that's what you learn from C++
<wolfspraul>
:-)
<wolfspraul>
so yes, no worries I'm sure I get those command lines in there. it has to be, no complaining.
<wpwrak>
great. a bit more scriptability will go a long way.
<wolfspraul>
btw, I'm happy to report that Milkymist One software is really getting somewhere
<wolfspraul>
Adam is diving in, able to reflash, run test software, etc.
<wolfspraul>
that's a great sign both for the state of software, and also for Adam's ability to survive in the sometimes harsh FOSS world
<wolfspraul>
"hey, no attachments!"
<wolfspraul>
and so on...
<wolfspraul>
:-)
<wpwrak>
very good ! does the hardware look sane so far ?
<wolfspraul>
sane?
<wolfspraul>
we have made PCBs
<wpwrak>
i mean, no surprise bugs
<wolfspraul>
if it's not sane now we are insane
<wolfspraul>
well who knows
<wolfspraul>
no risk no fun
<wpwrak>
;-)
<wolfspraul>
I sure hope so, it's my money that is on the line.
<wolfspraul>
pcbs are made, and back in the warehouse
<wolfspraul>
all components are in the warehouse
<wpwrak>
ah, no smt yet. good.
<wolfspraul>
now we are preparing the files for the SMT place, and schedule an appointment there
<wpwrak>
you just had a small number of samples smt'ed, right ?
<wolfspraul>
in parallel Adam is exercising his testing muscles
<wolfspraul>
maybe SMT next week? depends on the SMT house (Minbo again)
<wolfspraul>
we are a small customer, that has pros and cons. At least we are a repeat customer (4th time now).
<wolfspraul>
because we are small, they can squeeze us in somewehre to fill idle times between or within larger jobs
<wolfspraul>
then we do x-ray, lots of testing, jtag-serial, power adapters, etc. etc.
<wolfspraul>
still lots of work
<kyak>
viric: (ram on malta) more than necessary :) 128 Mb.. you are right, comparing speed is useless, it can't "slow down"
<wpwrak>
(smt) ah, none yet. i misunderstood adam't mail then. that's just the boards. i had already wondered why there was no mention of whether the board(s) worked at all and such :)
<wpwrak>
(repeat customer) you're already family ;-)
<wolfspraul>
no SMT yet, like I described
<wolfspraul>
we will mail them the files to ask for an appointment in a day or two
<wpwrak>
how many units will you make in this run ?
<wolfspraul>
then we need to get a date, unrealistically late this week, more realistically sometime next week, if they are very busy even later
<wolfspraul>
our goal is 35 functioning units
<wolfspraul>
we made 52 pcbs
<wolfspraul>
so don't know, maybe smt 40?
<wolfspraul>
you can react on the line, to a degree
<wolfspraul>
depends on how quick everybody is, and how quick good decisions can be made :-)
<wpwrak>
(react) good. i remember from OM that is was basically one board at a time until the beasties would come up at all
<wpwrak>
so "the rest of the batch" may start the morning after, with people finishing at 3 am or so :)
<wolfspraul>
no no
<wolfspraul>
we are a bit quicker than that :-) that's chaos mode and Adam wouldn't want to work like this.
<wolfspraul>
that's why I said it's great that software is really improving nicely
<wolfspraul>
that helps a lot on the line
<wpwrak>
hmm. sounds like a reasonable mode of operation to me. of course, you have to come prepared ...
<wolfspraul>
I need to take a closer look at the invoice.
<wolfspraul>
I think basically you are renting the line per hour.
<wolfspraul>
(including the people at the line)
<wolfspraul>
then extras depending on what happens or what is needed
<wpwrak>
ah ! so the preparation better be good :)
<wolfspraul>
so there is no problem in 'slowing' down, say you make 1 board and want to test is a bit. the line can wait, 30 minutes, longer, no problem.
<wolfspraul>
they don't care since you pay by the hour.
<wolfspraul>
so like I said you need to be able to quickly make good decisions.
<wpwrak>
yup. no problem until you run out of cash :)
<wolfspraul>
of course if you have to carry everything home, big discussions, etc. etc. then it gets complicated, slow and expensive.
<wpwrak>
you basically need a test plan a few steps deep. also with plan B, C, and D for each item.
<wpwrak>
ideally, with pre-made go/no go decisions.
<wolfspraul>
well maybe not C, D, but yes, in general that's the way to go
<wolfspraul>
good test software, good understanding of the board/system, ability to react (test software needs to have some flexibility)
<wolfspraul>
most important decision is whether something is reworkable by hand later, and at what cost (cash and time)
<wpwrak>
yup
<wolfspraul>
because if it is, it may not be worth to slow down the pick&place/reflow/aoi line
<wolfspraul>
but yeah, needs preparation...
<wolfspraul>
so we see
<wpwrak>
do you use any kind of test hardness (hardware) ?
<wolfspraul>
I don't think so
<wpwrak>
harness
<wolfspraul>
just jtag cable
<wpwrak>
ok. good old scope and jtag then :)
<wolfspraul>
also keep in mind it's only the second run, and only 35 units
<wolfspraul>
last time (the first 6 board) were made entirely 'blind' (on Adam's side)
<wpwrak>
every > 10 is scary for manual testing :)
<wpwrak>
everyTHING
<wolfspraul>
he could only do very basic current checks
<wolfspraul>
compared to that we have a whole SUITE of software now that can run and test all sorts of things...
<wolfspraul>
needless to say it's 100% gpl
<wpwrak>
kewl
<wolfspraul>
(for the records, who knows when this is googled :-))
<wpwrak>
to make the suite, you need *something* that works. so i guess it's normal for the very first ones to be made "blindly"
<wolfspraul>
sometimes they try to pull all people/brains in for that
<wolfspraul>
maybe you remember Harald traveled to Taipei for some OLPC first/early run, etc.
<wolfspraul>
wpwrak: I have a question, maybe you can share some knowledge :-)
<wolfspraul>
when we make PCBs, we get those microsection pictures
<wpwrak>
and it's from manufacturing, not reverse engineering. okay, then the paramters should be in the spec :)
<wpwrak>
hmm no, can't figure it out, sorry
<wolfspraul>
no problem, I'll dig up more information at the next opportunity.
<wolfspraul>
PCB manufacturing is one of my weakest spots.
<wpwrak>
when will you take the first kicad-made design to the pcb fab ?
<wolfspraul>
hmm
<wolfspraul>
for the jtag-serial boards Yanjun Luo made, he already used KiCad
<wolfspraul>
of course they are very simple, 2 layer I think
<wolfspraul>
we need to make more of them
<wolfspraul>
not sure whether that counts :-)
<wolfspraul>
at a 'bigger' level the next one will be Xue, with all boomification, schematics review etc. still outstanding I'd say actually sending those GERBERs to a PCB maker is at least 2 months out
<wolfspraul>
also i don't want to rush it actually because we need to 'open' the process, it's one part of the exercise...
<wpwrak>
jtag-serial had boards made at a pcb house ? that's already a good start then
<wolfspraul>
yes sure
<wpwrak>
xue will be more complex/intersting, of course :)
<wpwrak>
jtag-serial was hand-soldered, right ?
<wolfspraul>
yes
<wolfspraul>
have to think how we do the next 40
<wpwrak>
could be a good test for kicad-to-smt
<wpwrak>
if anything goes wrong, the damage is limited :)
<wolfspraul>
yes sure but documenting is slow, of course we try to add a little bit more every time
<wolfspraul>
you can see in the wiki in many areas it's already quite nice now
<wolfspraul>
but from where I think this can be, maybe we only have really opened up 20% or so of the total process, in a good way
<wolfspraul>
ok maybe 50% :-)
<wpwrak>
50% would be quite a lot :)
<wolfspraul>
from KiCad to producable gerbers is missing, from KiCad to outsourceable SMT is missing
<wolfspraul>
well yeah, let's say 20 then
<wolfspraul>
boomification is missing, except for some very early beginnings in ben-wpan and mmone-jtag-serial
<wpwrak>
you still need kicad-to-smt, automated production testing, etc.
<wpwrak>
yup. the big boom hole, too
<wolfspraul>
for Milkymist and Xue there will be no problem on the testing side
<wolfspraul>
since those things are developed out in the open from day 1
<wpwrak>
also a schematics "style guide"
<wolfspraul>
for Ben, we still need to retrofit some GPL testing codes, but the infrastructure gets better so this gets closer and closer
<wolfspraul>
sure that 'style guide' is included in my boomification
<wpwrak>
(testing) do you have automated tests ? and the corresponding interface hardware ?
<wolfspraul>
then the whole mechanical thing, of course roh's laser-cutting with QCad and DXF is a great first step, and your scanning on the other side
<wolfspraul>
but it's heavily 'work in progress' so don't ask me for URLs now
<wpwrak>
(mech) yeah, roh is making the first real case :) that's pretty cool
<wolfspraul>
but 100% is out in the open from day 1
<wolfspraul>
lekernel has really done a remarkably good job on the testing side so far
<wolfspraul>
no 'test harness' yet (if you mean a hardware fixture), really the volumes are too low and any sort of real manufacturing problems are not yet understood well enough (because the volumes are too low), for that to be economical
<wolfspraul>
but of course, if volumes ever go up and test fixtures become economical, you bet that will all be in the same KiCad/boom/whatnot process as well, of course
<wpwrak>
(fixture) i'm thinking of cooking something up for ben-wpan. particularly atusb won't be trivial (e.g., needs the firmware upload), and a quick RF check would be nice to have, too
<wpwrak>
(fixture) nothing overly sophisticated, of course. probably a PCB plus a piece of wood.
<wolfspraul>
is it a fixture to help you developing the design, or to help with manufacturing road bumps/tolerances/etc?
<wpwrak>
mainly to get rid of the "solder connector to board, flash, then remove connector" step
<wolfspraul>
for the latter you need to see differences in components and how they behave during production first, I think
<wolfspraul>
of course that can also be a 'home production line'
<wpwrak>
it would be to flash/test in "production" (also including test after manual soldering, of course)
<wolfspraul>
you would only want to test something that is worth testing
<wolfspraul>
sure there needs to be some way to bootstrap :-)
<wpwrak>
it would be more along the line of "see if it performs at all"
<wpwrak>
e.g., if the signal is off by 10 dB, then something is clearly wrong. or if the supply voltage suffers drops.
<wolfspraul>
wpwrak: did you see Andrey's latest post on correcting image sensor pictures based on the individual lense characteristics?
<wolfspraul>
makes total sense to me given that each individual lense will always have differences
<wolfspraul>
(as he writes there)
<wolfspraul>
so the best is to 'calibrate' the system after sensor + lense are installed
<wolfspraul>
not sure whether something like this is necessary somewhere in RF land
<wolfspraul>
at OM we always had calibrating this and that, but many things were driven so largely out of incompetence, I rather throw away those experiences and try to find out where exactly this is actually necessary and benefitial...
<wpwrak>
(lens calibration) very nice indeed
<wpwrak>
for rf, the only thing i can calibrate is the oscillator. and that only on atusb, not atusd (the latter used the ben's clock, so it better be good :)
<wolfspraul>
so (for the lense) basically you are holding your test pattern at a certain distance and in certain light conditions, run your calibration software, and boom, performance can be much better
<wpwrak>
(rf) ben-wpan i mean. other rf stuff can of course have other parameters
<wpwrak>
(lens) yup. hubble reloaded :)
<wolfspraul>
and in Andrey's case all software is 100% gpl as well
<wolfspraul>
(the hardware too, of course, though he struggles with the same kind of proprietary tool problems we are struggling with)
<wpwrak>
so xue will have auto-calibrating lenses as well ? :)
<wolfspraul>
luckily this is not production related
<wpwrak>
(tools) once you've made xue, you can "sell" him kicad :)
<wolfspraul>
I'm happy if the first boards boot :-)
<wpwrak>
*grin*
<wpwrak>
btw, what's happening with the xue review ? on hold until you have time for boomification ?
<wolfspraul>
he
<wolfspraul>
I guess so, on my side
<wolfspraul>
I tried to contact some people, zero results so far as you can see :-)
<wolfspraul>
the best feedback was your mail
<wolfspraul>
Andres started with a BOOKSHELF now
<wolfspraul>
it'll be slow, but we get there...
<wpwrak>
all i saw in terms of a reaction was a tentative attempt at making a BOOKSHELF file (i don't think it's expected to work, though)
<wolfspraul>
yep
<wpwrak>
(contact people) it would be good to get the basic cleanup out of the way first
<wpwrak>
once you have the attention of reviewers, you want to put it to good use. if they have to skip over 80% of the design because of incomplete information, you're wasting the opportunity
<wpwrak>
(waste) first, because they may not have time/interest to do it again, but even if they do, they may not spot things they've already mentally checked off
<wpwrak>
of course, sometimes simple mistakes are an indicator that the designer was tired/distracted, and there's more to find in the vicinity :)
<wolfspraul>
all agreed, it will take some time though, I think
<wpwrak>
(works great for code. when you see, say, harald commit coding style violations, then there's a fair chance that there's a logic bug there, too :)
<wpwrak>
(take time) it seems that the beads/inductors/filters may be a bit tricky. at least that's how i interpret the complete absence of any sort of characteristics.
<wpwrak>
(no charcateristics) some of that can be expected, because they may depend on difficult design parameters, such a total current of a subsystem, but it's a bit unusual that none of the them have anything
<kyak_>
maybe we should set up a virtual Ben machine and allow people login and play with it remotely :)
<kyak_>
killall: qemu-system-mipsel: no process killed
<kyak>
wops
<wolfspraul>
wpwrak: you mean the inductors, beads and filters in Xue have no values at all?
<wpwrak>
well, some do. the inductors in the PSU, for example
<wpwrak>
but FB1 or FB2 on DBG_PRG.sch don't have any hint
<wpwrak>
at least the .cmp file reveals that they have a 0402 footprint
<wpwrak>
oh, and on the PSU, R44 and R45 have no resistance. haven't spotted that one before ;-)
<wpwrak>
likewise for R77, R78, R35, R36, R34, ..
<wpwrak>
FB3 on sensor_psu.sch is also unspecified
<wpwrak>
and there are more unknown resistors on taht sheet as well
<wpwrak>
the mysteries continue with L4, L5 on USB.sch
<wpwrak>
and so on
<wpwrak>
i.e., you'll have fun ;-)
<wolfspraul>
hmm
<wpwrak>
i suspect some of the mystery Rs are 0 Ohm or NC. but that's really something the designers should specify. it's a little silly if you have to do all the guesswork. well, it may be interesting as a learning experience :)
<wpwrak>
sort of a cloze text ("lueckentext") ;-)
<kyak>
building kernel on Ben running in qemu
<viric>
kyak: enjoying, eh? :)
<kyak>
just more convenient than directly on Ben ;) i wonder if it would really succeed
<kyak>
viric: yeah, so much fun
<viric>
kyak: do you use -nogrpahic, or you have framebuffer?
<kyak>
so far i'm using -nographic, but i already enabled frambeffur in malta (only will be able to test at home)
<viric>
I don't know what controller malta has. Maybe its' a vga on its pci bus
<viric>
kyak: you know about ctrl-a in -nographic, right? :)
<kyak>
yup
<kyak>
yeah, if the framebuffer works, this would be great
<viric>
it will not be the same resolution as the ben though
<kyak>
right..
<viric>
how many openwrt commands are from busybox? or.. how much of busybox is used in openwrt?
<wolfspraul>
wpwrak: you will like this
<wolfspraul>
I'm just chatting with Andres about the missing values
<wolfspraul>
he says those values are not critical, and in the past they just used what they had in stock :-)
<wolfspraul>
not that I suggest we introduce such rules into boom, something like the 'garbage collector' value
<wolfspraul>
'put any excess item with the correct footprint here'
<kyak>
oh, this is not an output from default openwrt build.. i have enabled busybox "desktop" option
<viric>
ah
<wpwrak>
wolfspraul: yeah, some default may be good, though. there are already some. and of course, anything unspecified gives you the cheapest part, whatever it is :-)
<wpwrak>
wolfspraul: and while a "whatever" bead makes some sense, there's no such thing for resistors. zero, infinity, and things in the middle, are all rather popular values ;-)
<wpwrak>
wolfspraul: (defaults) there's one things i'm not quite sure about. that's "minimum standards". e.g., there are capacitors with incredibly wide tolerance ranges. so if you don't specify the capacitor type, boom may pick one of these (they're cheap, too)
<wolfspraul>
sure we'll get to it
<wolfspraul>
we only need to be careful to not wear out people over worthless discussions
<wolfspraul>
I noticed it slightly with the /250V rating issue on that one resistor on the jtag-serial board
<wpwrak>
wolfspraul: on the other hand, for many caps, you just want "something reasonable". this tends to translate to X5R, X7R, NP0, and a few others. which one depends in manufacturer (e.g., some have a lot of X7R and not so much X5R anymore, while others only have X5R) and capacitance (for low values, everything becomes NP0)
<wpwrak>
wolfspraul: (caps) alas, boom doesn't have lists of possible values so far
<wpwrak>
wolfspraul: (250V) bah, they've probably just been too lazy to think this through ;-)
<wolfspraul>
it's good to have priorities
<wolfspraul>
so anyway, let's do one by one
<wolfspraul>
I mentioned the ones you listed earlier to Andres
<wolfspraul>
he understands in an open project you may want to be a bit more clear :-)
<DocScrutinizer>
quite nice of designer to bother about gnd loops. But honestly if it exceeds 250V you're in severe trouble somewhere else
<wpwrak>
i wonder. intel recommend to simply ground it directly and be done with it. this RC circuit seems to originate from audio designs and similar low-frequency stuff.
<wpwrak>
yeah, GND at 250 V -> ough ! :)
<DocScrutinizer>
this RC is to keep gnd loop parasitary DC and 50Hz from flowing thru shielding
<DocScrutinizer>
imagine you got 2 devices with metal case, and both are mounted on remote points of a car. You don't want starter current to flow thru your USB cable shielding
<wpwrak>
heh :) so how do you do RF interconnects in such an environment ?
<DocScrutinizer>
that's more from network engineering rather than audio. Like where to connect gnd of a switch/hup star topoligy
<DocScrutinizer>
wpwrak: balun (RF)
<kyak>
hm.. i hope my Ben didn't take it personally that i've been playing with qemu... cause it won't turn off -\
<kyak>
it's just a simple coincidence
<wpwrak>
DocScrutinizer: so you float the shield on one side ?
<DocScrutinizer>
yep
<wpwrak>
kyak: coincidence ... "make it look like an accident" :)
<wpwrak>
DocScrutinizer: hmm, scary
<DocScrutinizer>
why?
<wpwrak>
DocScrutinizer: you may end up floating it on both sides, if the exact role of the device isn't fixed
<DocScrutinizer>
;-D
<DocScrutinizer>
that's why you need experts to properly design such stuff
<wpwrak>
and expert users :)
<kyak>
wpwrak: really... it scares me
<DocScrutinizer>
for a ethernet star topology (central hub) you usually require matching patch cables to connect 'peripherals'. Depending on whether the case has PE or not, you need a patch cable without or with shield contacts on both sides
<DocScrutinizer>
thee's different types of RJ45 jacks for that
<wpwrak>
probably easier to let whatever happens happen to shield and run the signal on a differential pair;-)
<DocScrutinizer>
a design like the one with that RC circuit is good for all usecases
<wpwrak>
(and hope there are no starter currents that find the shield a convenient path :)
<DocScrutinizer>
and yes, if there's lightning nearby, those RC circuits usually emit blue magic smoke, no matter if rated 250 or 1kV
<wpwrak>
hmm, if you mix it with a shield = sgnal gnd design, won't you then risk getting those things on the signal gnd line ?
<DocScrutinizer>
you shouldn't mix
<wpwrak>
(mix) but you're likely to, considering that signal gnd = shield gnd is what's recommended for USB.
<DocScrutinizer>
on the design like above, you can't eliminate the signal gnd line and abuse shielding for that. Except if you short signal gnd and shielding in both plugs of the cable. This won't fly though, as you have no differential design anymore
<DocScrutinizer>
cables that do botch on this detail are the ones that regularly fail with some devices while working ok with others
<wpwrak>
well, direct ground or bead. they have both.
<wpwrak>
ah no, that's for signal ground. so just direct
<wpwrak>
(it's clear in figure 12)
<DocScrutinizer>
yes, as usually you don't see PE on GND of USB devices
<DocScrutinizer>
the whole purpose is to avoid gnd loops
<wpwrak>
PE = protective earth ?
<wpwrak>
in the case of a pc, it's certainly there, though
<DocScrutinizer>
in a design like fig12, if you had a metal housing with PE, you need to connect the metal housing to gnd plane via some RC circuit like in JTAG design
<wpwrak>
and there's nothing preventing a pc from being connected to another device that's on mains (printer, etc.)
<DocScrutinizer>
...and avoud conductive connection from housing to USB recepatcles
<wpwrak>
then you need to isolate the connectors from the chassis. sounds weird.
<wpwrak>
yup, exactly
<wpwrak>
nobody does that ;-)
<DocScrutinizer>
not many do this
<wpwrak>
quite to the contrary. they usually try to close all the gaps, for EMI
<DocScrutinizer>
I've seen it in a few proper designs
<wpwrak>
so the choice is to either do it properly, and run into problems if you connect to the many improper devices, or to do it improperly, and to occasionally run into problems, too. nice :)
<DocScrutinizer>
yes, basically
<wpwrak>
sigh
<DocScrutinizer>
or have a design that simply doesn't offer attack vectors for any problems. E.G. plastic case, no PE
<wpwrak>
galvanic separation of all usb signals ;-)
<DocScrutinizer>
hmm, should. Yes
<wpwrak>
or just go wireless - solved ;-)
<DocScrutinizer>
though USB isn't designed for large topologies
<wpwrak>
yet there we are ...
<DocScrutinizer>
so even if you create a gnd loop by connecting 3 devices to each other with 3 cables, the loop still is of small geometric size
<wpwrak>
so you're saying the RC circuit is good, even considering that it lives in a world that connects signal ground to shield and shield to chassis ?
<DocScrutinizer>
yes
<wpwrak>
(loop) you could have things like PC to hifi, both fed from mains
<wpwrak>
hifi may be usb host and device
<DocScrutinizer>
worst thing that can happen is it's short circuited and has no effect
<wpwrak>
(rc good) okay, thanks
<DocScrutinizer>
yw
<wpwrak>
now, how do devices like scopes do it ? where does their probe ground go ?
<DocScrutinizer>
a good question
<DocScrutinizer>
you should check carefully on your particular scope
<DocScrutinizer>
usually probe GND is either floating or connected to case with a RC
<DocScrutinizer>
on some scopes you even can switch
<DocScrutinizer>
nota bene probe tips are unipolar, means shielding ends there and is not mandatory to get connected to DUT GND at this very spot
<wpwrak>
hmm, but the grould loop acts on the signal
<DocScrutinizer>
in a general case? or specifically with scopes and USB?
<wpwrak>
even if you just use the clip vs. the spring, you get degradation. if you close the loop via mains, it ought the be even more fun
<wpwrak>
in general
<wpwrak>
usb gets more complex ;) then it's scope -> usb -> pc -> usb -> device, or the same with mains :)
<DocScrutinizer>
in general you have several unipolar probes (chan1,2, trigger) plus *one* dedicated connection of scope GND to DUT GND
<DocScrutinizer>
scope test GND is not supposed to connect to PE or anything else, so scope becomes part of your DUT GND domain
<wpwrak>
hmm, what i read is that it should be close to the signal ground where the signal originates
<DocScrutinizer>
for a rule of thumb, and simple one channel/probe cases, that's correct
<DocScrutinizer>
that's why probes have an option to connect a GND clip to the probe head
<wpwrak>
yup. also produces noticeable cleaner signals
<DocScrutinizer>
o/
<kyak>
ok, restored my ben
<viric>
lucky you :)
<kyak>
i wonder why i had to find the "Unbrick" page in wiki via google
<kyak>
perhaps wiki search is broken
<kyak>
btw, last thing i remember i was trying to ubiattach my datafs in jlime (booted from SD)
<kyak>
i also attached the uboot partition, but i'd like to believe this is not related, or i might have made mistake somewhere
<viric>
hmm
<viric>
'nix' noticed as if the commit 3244d5e on openwrt-xburst had different contents than it had some time ago
<viric>
Did someone rebase there?
<lekernel__>
discovers linux-libre and laughs
<larsc>
:)
<Textmode>
what?
<lekernel__>
I seriously have trouble understanding people who argue that no driver is better than a driver with a blob
<lekernel__>
what do they want? the manufacturers to put their blobs into flash memory? why increase hardware cost and complexity this way?
<wpwrak>
i'm a bit puzzled about it myself. are they just removing drivers ? or are they modifying them ? the latter could make sense
<lekernel__>
it seems they're just removing them
<wpwrak>
the former seems to be a .config-editing task
<lekernel__>
hey, yes, but don't advertise non-free software :)
<wpwrak>
duh
<lekernel__>
if someone buys a computer with hardware that requires the tiniest bit of non-free software, it must be hard for them to get it to work
<larsc>
the funny thing is blobs are ok if they are in a rom
<lekernel__>
besides, GCC and GNU/Autocrap also seem pretty obfuscated to me :)
<lekernel__>
larsc: yeah, that's a totally stupid FSF idea
<larsc>
i wonder if a computer with a winxp burned into a flash chip would be ok for them ;)
<lekernel__>
yes, it is
<lekernel__>
it would be fun to make one, if you have spare time
<lekernel__>
there are already winxp live cds, which could be a nice base to start from
<larsc>
and to run additional (closed) software you have to insert cardriges
<viric>
what 'blobs' are there for the nanonote?
<wpwrak>
larsc: only if they cut the Write Enable line :)
<viric>
just curiosity
<larsc>
none
<viric>
larsc: btw, is upstream 2.6.36 totally ready for the nanonote?
<larsc>
viric: well it boots
<larsc>
but some parts are missing
<viric>
ah
<viric>
so the qi-hardware 2.6.35 is still 'better' than upstream 2.6.36?
<larsc>
there is a qi-hw 2.6.36
<viric>
I imagine
<viric>
I don't have it at hand :)
<viric>
can all there go upstream soon? or it needs rework?
<kyak>
so why don't you just get it? :)
<larsc>
viric: i'm working on it
<wpwrak>
larsc: hmm, given that the ben can do TCP/IP, are you sure there's no network-attached whatever that could conceivably load some blob ?
<viric>
thank you very much
<viric>
kyak: uaaa laziness.
<wpwrak>
larsc: remember, for the obsessively politically correct, there's no soup without at least a few atoms that can be attributed to a hair :)
<viric>
Why xiangfu recommends using linux to erase the rootfs partitions? Can that work? (the linux running in that rootfs...)
<larsc>
well, it will work more or less. you should remove power as soon as it is done eraseing the partition
<viric>
:)
<wpwrak>
larsc: and make sure no "dirty" buffers are pending for writing back while the erase is in progress :)
<viric>
it looks optimistic to me :)
<larsc>
it is
<wpwrak>
viric: it looks like something where your choice is between it not working and it working, but not the way you intended it to ;-)
<viric>
:)
<viric>
I hope he will fix that problem
<viric>
I just built uboot and the kernel to revive the thing
<viric>
hm I need aluminum paper
<wpwrak>
viric: CIA spy satellites putting ideas into your brain when you sleep ?
<viric>
crossing the 'usbboot' on the nanonote back :)
<wpwrak>
ah, *that* kind of Al paper :)
<viric>
hm. We name it here 'silver paper' or 'aluminum paper'
<viric>
(literally translating)
<wpwrak>
viric: yeah,i understood what you means. in english, they also use "tin foil". my joke was about "tin foil hats"
<wpwrak>
"One may wear the hat in the belief that it acts to shield the brain from such influences as electromagnetic fields, or against mind control and/or mind reading; or attempt to limit the transmission of voices directly into the brain."
<viric>
ah, it may help those unluckily having demodulators in their brains
<viric>
When I have to flash with "-n" (nprog) and when not?
<viric>
does anybody have some kind of datasheet for the LCD? I'd like to see its peculiarity
<viric>
larsc: there is no way to scroll-up the 2.6.35 qi-hardware kernel, if it panics before mounting the rootfs, right?
<viric>
I remember something like you planned all the keymap to be set in userland
<viric>
kyak: nice. I'm still using terminal menus
<viric>
the terminal menus remembers me the DOS times; many had a menu shown on autoexec.bat
<viric>
larsc: 9600bps?
<larsc>
57600
<viric>
maybe it's me, but I don't see anything at 57600...
<viric>
ah it works.
<viric>
great
<viric>
[Â Â Â Â 7.590000] UBIFS error (pid 1): validate_sb: LEB size mismatch: 524288 in superblock, 516096 real
<viric>
(thank you, open hardware!)
<lekernel__>
what does it have to do with open hardware?
<viric>
in open hardware I can come to irc, ask "how to debug bla bla", and I get answers :)
<lekernel__>
all NAND flashes suffer from this kind of problem...
<lekernel__>
ah :)
<lekernel__>
ok, sorry
<kyak>
lekernel was about to get agressive :)
<viric>
hehehe
<kyak>
night
<viric>
hmm what did the xburst qi-hardware kernel call as init? /sbin/preinit?
<viric>
ah found. it's the last patch... /etc/preinit
<viric>
larsc: is /dev/console the serial line, or the screen?
<viric>
hm... the serial line says:Â Â /bin/sh can't access tty; job control turned off
<viric>
while nothing appears on the screen
<bartbes>
viric: isn't /dev/console current tty?
<viric>
no
<viric>
/dev/tty is the current tty
<viric>
/dev/console is where the kernel is said to throw messages (the console=...)
<viric>
humm I see very tricky things in the openwrt patches for the kernel
<wpwrak>
viric: (minicom) nice ... so is that four or only three times obsolete ? 1) move from almighty root to more fine-grained permissions. 2) Linux capabilities that give non-root users special powers. 3) SELinux that restricts what root can do. 4) VMs where you often don't really care anyway. I guess someone, somewhere is still struggling with the future shock that came with the invention of the cave ... :)
<kristianpaul>
Now i realize why we need  a evoluted OSM
<kristianpaul>
OSm + Wikipedia + ...
<kristianpaul>
yeah camera is important and geolocation
<jad>
hey all
<kristianpaul>
hello jad
<jad>
i want to buy a external hard drive and i want to know wich one u advice me to buy ?
<jad>
lg
<jad>
WD
<jad>
seagate
<jad>
....
<jad>
wich brand is the best ?
<kristianpaul>
well..
<jad>
anybody can help me to choose plz ?!
<jad>
i found many articles on google but not all are the same
<jad>
some say maxtor is the best some say wd
<kristianpaul>
try on #electronics
<jad>
i joined and it says  cannot send to channel
<jad>
:(
<jad>
i dont know why
<kristianpaul>
bad boy ! :)
<jad>
lol
<kristianpaul>
afk
<wpwrak>
hmm. i wonder if something like  Provides: erlang-erts=5.7 ...  is really valid. (found it in the OpenWRT Packages). neither Jlime nor Ubuntu use = in "Provides"
<wpwrak>
not that it would make sense in some way ...
<qi-bot>
[commit] Werner Almesberger: qpkg: move "struct pkg" and its allocation from gobble.c and qpkg.h to pkg.[hc] http://qi-hw.com/p/wernermisc/bbf9c42
<qi-bot>
[commit] Werner Almesberger: qpkg/TODO: some open policy questions (cyclic dependencies and use of Provides) http://qi-hw.com/p/wernermisc/c95d064
<qi-bot>
[commit] Werner Almesberger: qpkg: light cleanup of prereq.c:resolve and change forgotten in last commit http://qi-hw.com/p/wernermisc/068264e
<wolfspraul>
I think the scripts/feeds update -a && scripts/feeds install -a should be before the yes ""|make oldconfig in the earlier paragraph
<wolfspraul>
maybe I restructure this a bit
<wolfspraul>
plus the instructions under 'Downloading sources' are not just about downloading, they do everything including building the entire image
<kristianpaul>
i put  the make old, i felt was missing, sorry i dint look on the order
<wolfspraul>
or we remove some of those commands since they are listed in the sections below again
<wolfspraul>
I'll just try to edit a bit, see whether it gets better...
<kristianpaul>
please :)
<wolfspraul>
what's the difference between aptitude and apt-get?
<wolfspraul>
I never use aptitude...
<kristianpaul>
aptitude is smart !
<kristianpaul>
scaring smarting i could say ;-)
<kristianpaul>
s/smarting/smart
<wolfspraul>
what's the advantage over apt-get?
<kristianpaul>
"yes sr i will isntall foo package and in the mean time i think package a,b,c d and are not needed any more, so dont care i will make this srity work for you"
<wolfspraul>
hey it's a wiki, I'm editing so I will change to what I think is the 'better' command, apt-get :-)
<kristianpaul>
is a ncruses or whatever dpkg fronted
<kristianpaul>
eye candy on console is handy some times
<kristianpaul>
s/srity/dirty
<xiangfu>
when using 'aptitude' remove package. it will also remove depends . apt-get don't
<kristianpaul>
agreed
<wolfspraul>
so I think apt-get is safer
<kristianpaul>
:D
<wolfspraul>
if someone wants to build OpenWrt images on his system, why do we have to direct him to a command that will also 'cleanup' unnecessary packages on his system?
<wolfspraul>
looks like asking for trouble to me
<wolfspraul>
I moved some of the commands to the later sections
<wolfspraul>
I think there is a bit too much text between the commands, need to cut that shorter still.