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
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
woakas [woakas!~woakas@200.106.218.64] has joined #qi-hardware
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
woakas [woakas!~woakas@200.106.218.64] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
panda|x201 [panda|x201!~hzhang@221.219.117.186] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<DocScrutinizer> moo
<wpwrak> how was survival in the first days of this new year ?
* DocScrutinizer is a fan of forbidding use of short options in scripts ;-D
<DocScrutinizer> well, things get a lil bit less demanding
<DocScrutinizer> playing with Lauterbach is way more fun than ClearCase with proprietary policy enforcement wrapper XP
<wpwrak> lauterbach ... some little known contemporary philosopher ?
<DocScrutinizer> some ugly hw in circuit emulator
<wpwrak> ah :)
<wpwrak> a neighbour :)
<DocScrutinizer> I guess the expensive part has to be the complex software though, not the ugly hw which I can't see how it may cause costs of 15..20k per licence/unit
<wpwrak> it's the invisible power of ignorance :)
<DocScrutinizer> hehe
<DocScrutinizer> D-85635 Höhenkirchen-Siegertsbrunn -- a neighbour? not exactly
<wpwrak> ah . that was the fair
<wpwrak> (nuernberg, the first thing you see when you load their home page)
<DocScrutinizer> well, since I don't travel to TPE 6 times a year anymore, my take on what's a neighbour probably changed a bit
<DocScrutinizer> o.O
<DocScrutinizer> aaah, embedded world - yeah
<wpwrak> yeah, in those days, anything within a lightmonth was "pretty close" ;-)
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
<DocScrutinizer> hehe
<DocScrutinizer> indeed
<DocScrutinizer> "as long as it pings"
<wpwrak> how's the internal jet-lag ?
<wpwrak> if it answers to ping, it's not dead yet :)
<DocScrutinizer> getting better, awoke today after 5h sleep just 30min early of my alarm clock
<wpwrak> your superego is strong but inaccurate
<DocScrutinizer> actually I had a weird dream about timeslices or sth that probably made me wake up
<DocScrutinizer> yesterday I got a new "consultant" colleague - his acconts are working better after 4h than my whole account and PC installation after 4 weeks :-S
<wpwrak> ah, being haunted by work even while your brain ought to enjoy nocturnal wish fulfillment
<DocScrutinizer> yep
<wpwrak> (consultant) hehe ;-)
<DocScrutinizer> that's when I quit my last employment, some 30 years ago
<DocScrutinizer> rationale: nobody paying me for the thinking done when I'm asleep
<wpwrak> wow, all because of a bad dream
<DocScrutinizer> unless I am paid for tasks rather than time
<wpwrak> hmm, didn't this kind of role exist in the "minority report" universe ?
<DocScrutinizer> unpaid role, yes :-D
<wpwrak> not sure if they were too happy about their jobs, though
<DocScrutinizer> definitely they weren't
<DocScrutinizer> the most annoying thing: now may days are too short to keep up the voluntary work I've done so far while also doing this 9-5 job
<DocScrutinizer> 8-6 actually
<wpwrak> yeah, that's a normal effect of "regular work"
<wpwrak> if you truly had plenty of time left, the work day would be longer
* DocScrutinizer ponders to have another coffee or leave for work
<DocScrutinizer> wpwrak: yep, so true, so sad
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
* DocScrutinizer decides for coffee
<DocScrutinizer> ...and a bit more IRC chatting
<wpwrak> ;-)
<DocScrutinizer> coffee, IRC, and marzipan :-D For minutes I love my life :
<wpwrak> until you crash from the sugar high :)
* DocScrutinizer idly ponders about the ~25% of your income you have to pay for health insurance here.
<wpwrak> you'll see the value of it when it comes to that expensive lung cancer medication :)
<DocScrutinizer> lung cancer medication is probably 11g of lead
<DocScrutinizer> ~1$
<wpwrak> heh, such things tend to disappoint the optimist as well as the pessimist
<wpwrak> the optimist thinks nothing bad will happen, yet it does
<wpwrak> meanwhile, the pessimist hopes for a swift ending, yet that won't happen either, for various reasons. but then, all this just means that life is full of surprises :)
DocScrutinizer [DocScrutinizer!~halley@openmoko/engineers/joerg] has joined #qi-hardware
<DocScrutinizer> hmm, 24h disconnect, missed the pessimist part :-)
<wpwrak> meanwhile, the pessimist hopes for a swift ending, yet that won't happen either, for various reasons. but then, all this just means that life is full of surprises :)
<DocScrutinizer> hehe
<wpwrak> but i guess i should give you a less gloomy perspective for today's journey :)
<DocScrutinizer> nah, no problem
<DocScrutinizer> this raspberry Pi board seems so extremely cheap in money... Might be worth to have a look at it
<wpwrak> hmm. i realize that one of the difficulties of marketing milkymist is to understand how the various effects will work with the audience, considering that a good portion of them will be on ecstasy
<DocScrutinizer> hehe
<wpwrak> remember the $100 laptop ? watch the pi do the same sort of "inflation" :)
<DocScrutinizer> which inflation do you mean?
<DocScrutinizer> prices generally dropping?
<wpwrak> dropping in relation to purchase power but increasing in numeric value
<DocScrutinizer> mhm
<wpwrak> e.g. OLPC sold their units for a lot more than USD 100
<DocScrutinizer> yep
<wpwrak> so maybe that was "USD 100" in some frame of reference
<wpwrak> but ...
<DocScrutinizer> in the end a "normal laptop" was more economic
<wpwrak> with a little help from intel, to exterminate that amd weed
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<DocScrutinizer> "intel! hah! I feel like starting/continuing with tizen bashing
<wpwrak> enjoy kicking the dead ? :)
<wpwrak> well, stillborn even
<wpwrak> or maybe even zombified in the womb. who knows.
<DocScrutinizer> yeah, here I actually do. They not only wasted everybody's time but also managed to ruin maemo, and meego
<DocScrutinizer> well, in ruining meego Nokia had their good share
<wpwrak> i'm kinda puzzled how they succeed in being so consistent in mis-managing this
<pabs3> the git repos tizen folk released are pretty loltastic
<DocScrutinizer> I can't help but thinking it's intentional to follow a secret plan
<wpwrak> i mean it's intel. c'mon. if they have a halfway decent plan, they can pull it through. they don't need to add sickly partners like nokia.
<DocScrutinizer> microsoft couldn't have come up with a better strategy to fsck linux
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<wpwrak> indeed :)
<roh> DocScrutinizer: lets wait how long broadcom pays for that uboot ;)
<wpwrak> of course, google are having a merry dance on that grave :)
<DocScrutinizer> hi roh :-D
<wpwrak> roh: probably until it goes olpc^Wbelly up
<roh> wpwrak: olpc is brmc now also? i meant the rasberry
<wpwrak> roh: i meant the price explosion
<wpwrak> roh: usd 25 is probably too low, considering volume
<roh> wpwrak: wouldnt say that. considering they pay nothing for the chips and have not case...
<wpwrak> yeah. no case = no volume :)
<wpwrak> or, if volume > noise then case :)
<roh> or do you mean something readymade?... and even then.. for 16-25 euros one can buy complete routers with 500mhz cpus.. including case
<wpwrak> they seem to be aiming at the uk educational market. kinda like acorn did millenia ago.
<roh> my guess is that its only possible while brcm endorces the thing by sponsoring development and part cost
<wpwrak> eventually, they'll have to pay for their bom. and then the price inflates.
<wpwrak> and the tcos is much higher anyway, given that they're targetting pc-less households
<wpwrak> i.e., i don' think keyboards and mice are free in the uk
<wpwrak> they're of course cheap. but still, they have some transaction cost
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<wpwrak> anyway, time for a nap before the evil day star scorches the land
* DocScrutinizer waves and heads out for a slaves' day of work
<roh> there it is.... (daystar)
<larsc> it hides behind the clouds
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
jekhor [jekhor!~jek@vulture-nat-37.telecom.by] has joined #qi-hardware
jluis|work [jluis|work!~jpddb@83.247.136.72] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
orsonzhai [orsonzhai!~zhai@1.202.15.210] has joined #qi-hardware
stefan_schmidt [stefan_schmidt!~stefan@guest232.ibr.cs.tu-bs.de] has joined #qi-hardware
Textmode [Textmode!~boneidle@adsl-syd-2-209.ozonline.com.au] has joined #qi-hardware
Ayla [Ayla!~paul@28.95.13.93.rev.sfr.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
tradej [tradej!tradej@nat/redhat/x-owruejqsnqcpzmot] has joined #qi-hardware
Jay7 [Jay7!jay@2.94.64.108] has joined #qi-hardware
jivs [jivs!~jivs@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
orson_zhai [orson_zhai!~orson@114.254.74.93] has joined #qi-hardware
wolfspraul [wolfspraul!~wolfsprau@p5B0ABD37.dip.t-dialin.net] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
jekhor [jekhor!~jek@mx2.promwad.com] has joined #qi-hardware
<Ayla> guys, gmenu2x is broken here
<Ayla> the ./configure builds a test program to check if SDL has been installed, but that code loads the SDL.h header using quotes
<Ayla> ie. #include "SDL.h"
<Ayla> shouldn't it be #include <SDL.h> instead?
<Ayla> as a result the ./configure complains that SDL has not been installed
<mth> SDL should be located using sdl-config, which will return a -I flag for the include path
<mth> so both "SDL.h" and <SDL.h> should work
<Ayla> AFAIK, "SDL.h" means it's on the same directory
<Ayla> and <SDL.h> means it's on one of the header paths
<mth> both "" and <> are looked for in the include paths, but the priority is different
<mth> or maybe not the priority but whether system or current dir is checked as well
<mth> sdl-config should be picked from the toolchain though, not sure if configure does that by default
<Ayla> it does
<mth> ./configure --host=mipsel-linux --enable-platform=dingux --with-sdl-prefix=/opt/opendingux-toolchain/usr
<mth> I'm specifying the SDL location explicitly there
<Ayla> ok, I found the problem
<Ayla> this works:
<Ayla> ./configure --host=mipsel-linux --enable-platform=dingux
<Ayla> this does not:
<Ayla> ./configure --host=mipsel-linux-uclibc --enable-platform=dingux
<mth> is the legacy toolchain in your $PATH as well
<mth> ?
<Ayla> no
<Ayla> the "legacy" toolchain is long time gone ;)
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
<Ayla> mth: I am modifying how the cursor moves, I would like your opinion about this
<Ayla> currently, when you press Right the cursor will move up to the last column of the row, then wrap to the first column of the same row
<Ayla> I propose that the cursor wraps to the first column of the next row
<mth> I'm not sure that would be better
<mth> why would someone use that feature rather than using the down button?
<Ayla> correct, but then why should the cursor wrap at the first column when you press Right?
<mth> if the cursor position is preserved after you launch something (is it?), you can use it to quickly go to the first column
<mth> with either scheme you can do that, but it's more straightforward if it only changes the column and not the row
<Ayla> it is saved yes, but I don't see why it'd be faster
<mth> not faster; what is faster depends on where the target you're going towards is
<mth> it's simpler
<mth> I guess it depends on whether you see the apps as a list or as a grid
<mth> for a list, switching to the next row on wrap makes more sense, for a grid staying on the same row makes more sense
<mth> if an item is removed, the app are reordered though, so maybe it is more of a list actually
valhalla [valhalla!~valhalla@81-174-23-109.dynamic.ngi.it] has joined #qi-hardware
paroneay` [paroneay`!~user@c-67-175-218-235.hsd1.il.comcast.net] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
wpwrak [wpwrak!~werner@94-163-231-201.fibertel.com.ar] has joined #qi-hardware
B_Lizzard [B_Lizzard!~havoc@athedsl-425284.home.otenet.gr] has joined #qi-hardware
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
skynet-2000 [skynet-2000!~skynet-20@unaffiliated/skynet2000] has joined #qi-hardware
orson_zhai [orson_zhai!~orson@114.254.74.93] has quit [#qi-hardware]
skynet-2000 [skynet-2000!~skynet-20@unaffiliated/skynet2000] has joined #qi-hardware
urandom__ [urandom__!~user@ip-88-152-215-14.unitymediagroup.de] has joined #qi-hardware
mr0101000 [mr0101000!~no@71-81-27-105.dhcp.gwnt.ga.charter.com] has joined #qi-hardware
skynet-2000 [skynet-2000!~skynet-20@unaffiliated/skynet2000] has joined #qi-hardware
mr0101000 [mr0101000!~no@71-81-27-105.dhcp.gwnt.ga.charter.com] has quit ["Leaving"]
<viric> Does 'iostat' show anything for you in the nanonote, about the nand?
<viric> maybe I'd need some kernel options
jekhor [jekhor!~jek@vulture-nat-37.telecom.by] has joined #qi-hardware
pabs3 [pabs3!~pabs@d175-38-172-79.per801.wa.optusnet.com.au] has joined #qi-hardware
skynet-2000 [skynet-2000!~skynet-20@99-62-100-172.lightspeed.tukrga.sbcglobal.net] has joined #qi-hardware
skynet-2000 [skynet-2000!~skynet-20@unaffiliated/skynet2000] has joined #qi-hardware
stefan_schmidt [stefan_schmidt!~stefan@p4FC77AC2.dip.t-dialin.net] has joined #qi-hardware
<wpwrak> DocScrutinizer: how was surviving the day ? :)
jekhor [jekhor!~jek@vulture2-nat-41.telecom.by] has joined #qi-hardware
<DocScrutinizer> time consuming as usual
<DocScrutinizer> at least I managed to set my first breakpoint in lauterbach to a chosen position
<wpwrak> so the rest of the day was spent with lavish celebration ? champagne, fireworks, ...
<DocScrutinizer> next I probably have to learn ARM assembler, bot thumb and err whatever the other was
<DocScrutinizer> both
<wpwrak> btw, i have a mystery for you: in M1, we use the WM9707 codec: http://www.wolfsonmicro.com/products/codecs/WM9707/
<DocScrutinizer> :nod:
<wpwrak> now, it has line out and "line level" out. wolfson make no mention what "line level" means and how it would differ from "line"
<wpwrak> they don't even list the "line level" in the parameters, only "line"
<DocScrutinizer> errr
<wpwrak> also, i haven't found any other wolfson codec that would have something like that
<wpwrak> you're my last hope. does any of this ring any bells ? :)
<DocScrutinizer> alas not really
<DocScrutinizer> I could only think of "line level" being a line-out with a non-matched impedance
<DocScrutinizer> a proper line-out should have ~1.5V @ 100Ohm
<DocScrutinizer> I.E a 1.5V source with a 100R series max source impedance
<DocScrutinizer> while a "line level" output might have a few kR source impedance
<wpwrak> hmm. if it's that high, then it's useless without specification
<wpwrak> fwiw, they define "line out" with a 10 kR load
<DocScrutinizer> :nod:
<viric> hm
<viric> I'm failing to use xbboot
<DocScrutinizer> 10kR load is "normal" for line-in
<wpwrak> page 5
<wpwrak> okay
<viric> Error - set_addr() returned -110
<larsc> -110 is timeout
<viric> mmh
<larsc> which means no response to a usb request
<viric> Error - get_info() returned -71
<viric> ?
<larsc> no idea
<larsc> but you can check errno.h
<viric> ah it's errno?
<wpwrak> hmm. page 24 calls it "e optional stereo headphone out"
<larsc> viric: yes. 71 is EPROTO
<viric> #define EPROTO 71 /* Protocol error */
<viric> aha
<viric> I wrote
<viric> # xbboot -u 0x80600000 vmlinux.bin
<viric> it sid
<viric> said
<viric> Info - found XBurst boot device.
<viric> set_addr 80002000h
<viric> bulk_write successfully wrote 6088 bytes.
<viric> start1 80002000h
<viric> Error - get_info() returned -71
<viric> so, the numbers don't match
<viric> what a big address I wrote...
<larsc> could be the wrong firmware
<larsc> it has to load the first stage loader first
<larsc> i think
<viric> hm
<viric> ok
<larsc> or maybe something in your config is wrong
<larsc> which causes the jz4740 to crash
<viric> well, the address is wrong
<DocScrutinizer> wpwrak: I think it's an absolutely identical auxiliary stereo out
<viric> where physically are the 32MB?
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
<DocScrutinizer> wpwrak: the line-out PGA is called "MASTER VOLUME" iigir
<wpwrak> (master) yeah
<DocScrutinizer> so "line-level" might just mean that this is _not_ controlled by "MASTER LEVEL"
<wpwrak> i think the chip may be some sort of clone for the LM4550B. but the LM seems to have a real headphone amp while the wm doesn't seem to be entirely decided on what it has
<wpwrak> it seems to have just an independent pga
<wpwrak> (reg 0x02 vs. reg 0x04)
<DocScrutinizer> yep
<DocScrutinizer> (not the (typ) in () there)
<DocScrutinizer> whatever that means
<wpwrak> hmm, where's that "(typ)" ?
<DocScrutinizer> in chip block
<larsc> viric: 80002000h is inside the icache
<wpwrak> ah, and wolfson recomment 10 uF caps, which would be 1.6 Hz with 10 kOhm. we have 1 uF. does this look like something we ought to change ? (our audio isn't supposed to be super high quality)
<DocScrutinizer> C25 to C29
<DocScrutinizer> 10μF
<DocScrutinizer> Output AC coupling caps to remove VREF DC level from outputs.
<DocScrutinizer> hmm, I'd not worry about 4.7uF. ! though...
<DocScrutinizer> 1
<DocScrutinizer> maybe bearable
<wpwrak> indeed, the "typ" is weird. "this it _typically_ the address of the volume control register" ? ;-)
<wpwrak> kewl
<DocScrutinizer> just 10uF is a "de facto standard" for ine-out
<DocScrutinizer> I'm not sure though about how much of non-linear distortion a small capacitor may introduce
<wpwrak> and we have 1 uF blockers on input while wolfson recommend 470 nF. i guess that's nothing to worry about ?
<DocScrutinizer> by offsetting the virtual 0-point for the amp output
<wpwrak> (amp output) hmm
<DocScrutinizer> no, too large C on input should be OK
<DocScrutinizer> well, nobody but me will notice any difference I'd guess
<wpwrak> ;-)
<DocScrutinizer> there are still users out there that argue 1uF for headphones on GTA02 is absolutely OK
<wpwrak> now, one more mystery: the infamous "CD" input with its own DC-blocked ground. do you remember that critter ?
<DocScrutinizer> yep, siure
<DocScrutinizer> DC-decoupling ground feels odd
<wpwrak> if you had to pick an audio input for expansion, but you don't know what people will do with it, would you pick that "CD" thingy (with its odd ground) or rather just AUX, which goes to audio ground ?
<DocScrutinizer> hard
<DocScrutinizer> what purpose of the input?
<wpwrak> maybe that CD ground thing is meant to break ground loops ? not sure if it works that way, though
<DocScrutinizer> wpuldn't help
<DocScrutinizer> could break DC shorts
<DocScrutinizer> but no 50Hz GND-loop hum
<wpwrak> (purpose) unknown. it's for expansion circuits. if someone wants to add something (i.e., with a expansion board), they can plug into this
<DocScrutinizer> a differential input though could
<DocScrutinizer> and you could route both minus-in of L and R to same GND level
<DocScrutinizer> like on a EKG where all differential opamps have minus-in on one common electrode
<wpwrak> adam has found a rather enigmatic comment on that CD input: http://en.qi-hardware.com/wiki/Milkymist_One_Layout_Criteria#Audio_Codec
<wpwrak> "This can improve the input SNR for a stereo source with a good common ground but precision resistors may be needed in any external attenuators to achieve the necessary balance between the two channels."
<wpwrak> i'm not entirely sure where between school physics and metaphysics this is located :)
<viric> larsc: I don't know what means 'inside the icache' :)
<DocScrutinizer> yeah, a bit enigmatic but supporting my prev comment
<wpwrak> (differential) so you're saying our "CD" thing may be this kind of differential input ?
<DocScrutinizer> yep
<DocScrutinizer> again, what purpose has the input?
<viric> xbboot -u 80010000 vmlinux.bin this worked fine (the command), but I don't see the kernel booting :)
<larsc> viric: the CPUs instruction cache is mapped at 0x80000000
<wpwrak> it would go to an unpopulated header footprint
<viric> larsc: I imagine I've to read a bit more then, to continue
<DocScrutinizer> usecase
<wpwrak> the question is if that should be CD* or AUX*
<wpwrak> DIY expansion
<DocScrutinizer> that's no usecase
<wpwrak> ;-)
<wpwrak> the one doing the DIY defines the specific use case :)
<larsc> viric: the bootrom is loaded at 0x80000000 which is used to load the first stage loader to 0x80002000, which will initialize the peripherals and then load the actuall payload
<larsc> the kernel in your ase
<DocScrutinizer> well then define it as low-fi inmput and you're fine
<wpwrak> so, should we use the traditional AUX + AGND or the fancy CD + CDGND for this ?
<DocScrutinizer> you should provision footprints for antiseriel Zeners
<viric> larsc: but the kernel has its own start address...
<DocScrutinizer> use CD
<larsc> viric: yes
<viric> larsc: isn't it... 0xffffffff8031d150 ?
<wpwrak> perfect
<larsc> 0x80010000
<viric> ah ok
<DocScrutinizer> floating GND is a good thing for a genral purpose lo-fi input
<viric> and what is the kernel "entry point"?
<viric> anything relevant?
<DocScrutinizer> think about clipping input voltage at ~4V
<larsc> the first instruction to be executed
<DocScrutinizer> clamp diodes to VDD, VSS after C
<DocScrutinizer> after all 3
<larsc> viric: do you load a compressed kernel?
<viric> no
<DocScrutinizer> plus a series R ~1k
<DocScrutinizer> series to C
<wpwrak> naw, no clamps. let's keep this simple. we don't even know if this goes outside the box.
<DocScrutinizer> hey, I said FOOTPRINTS
<DocScrutinizer> quite obviously you also want some minimalistic RF blocking
<DocScrutinizer> = 47pF to GND, after the series 1kR
<wpwrak> i'd just keep the rabble we currently have
<viric> larsc: that'd be 'vmlinuz', no?
<wpwrak> nothing RF-ish there, though
<DocScrutinizer> RF is *everywhere*
<wpwrak> i mean rf-aware cicuitry
<DocScrutinizer> and that's one of the disadvantages of such a electronically balanced input
<DocScrutinizer> it *is* RF sensitive
<DocScrutinizer> and NO GND to shield the RF away
<larsc> viric: yes. but the compressed kernel needs a different load address
<wpwrak> oddly enough, wolfson themselves don't suggest any rf caps either. just dc block.
<wpwrak> maybe there's an internal low-pass ?
<viric> larsc: ok. No, I'm using vmlinux.bin
<viric> so I try:
<viric> xbboot -u 80010000 vmlinux.bin
<viric> Then:
<DocScrutinizer> wolfson doesn't suggest a lot of things, as they are not specific for their circuit. That'S common best practice
<viric> xbboot start2 80010000
<DocScrutinizer> wolfson also doesn't suggest to place receptacle there
<viric> ah wait
<viric> it takes that as decimal
<wpwrak> :)
<DocScrutinizer> if that's 7mm copper trace to next chip's output, you'd obviously not need any RF measures
<DocScrutinizer> nor any clamp diaodes or a series R
<wpwrak> do you remember the circuit ? http://milkymist.org/mmone/rc3_schematics.pdf
<DocScrutinizer> yes, I remember it
<DocScrutinizer> I'm DocScrutinizer
<wpwrak> the input path, from source: 6.8 kOhm series, the 6.8 kOhm to ground, then DC block, and finally the codec
<DocScrutinizer> not sure about RC3 though
<viric> larsc: I'd say I want to upload the kernel to 0x80010000, and execute at the entry point.
<viric> But the xbboot "-u" means upload at X, and execute at X
<larsc> the entry point should be 0x80010000,
<wpwrak> now ... do we actually need those "pull downs" ?
<viric> hm
<viric> larsc: that's not the entry point in case of 'mkimage'
<larsc> hm
<wpwrak> or would the footprints be better used for your 47 pF caps ?
<DocScrutinizer> yeah!!!! and the 6k8 in GND are WRONG
<wpwrak> *grin*
<wpwrak> does that apply to LINEIN{L,R} as well ?
<DocScrutinizer> you can't do such a thing to a stereo bal-in, with common GND
<viric> larsc: KERNEL_ENTRY is the address of the 'kernel_entry' symbol
<larsc> viric: hm, yes
<viric> 80316830 T kernel_entry
<wpwrak> ah yes, combined with the floating ground, it looks even more funny :)
<viric> (says nm)
<larsc> for the compressed kernel load and start address are the same
<DocScrutinizer> bo, line-in has clean direct GND
<wpwrak> btw, you're still joerg@openmoko.org ?
<viric> larsc: ah ok. Maybe I need a loader for xbboot '-u' to work
<viric> I'll go with the compressed
<DocScrutinizer> s/bo/no/
<qi-bot> DocScrutinizer meant: "no, line-in has clean direct GND"
<DocScrutinizer> sure
<viric> larsc: it fails to build, btw
<larsc> viric: 0x80600000 is the address
<viric> (vmlinuz)
<viric> arch/mips/boot/compressed/decompress.c:105:2: error: implicit declaration of function ‘decompress’
<wpwrak> okay, so no pull-downs on CD* but keep them on LINEIN*
<viric> ah I need kernel gzip..
<DocScrutinizer> replace the pulldowns by 47pF
<wpwrak> is there a problem with having 6k8 instead of the 1k you suggested ?
<larsc> viric: or another compresor
<viric> ok
<larsc> decompressor
<viric> I can't find the option :)
<DocScrutinizer> all of them
<viric> 'F8' in nconfig says it's in General setup...
<DocScrutinizer> err, not on the outputs though
<larsc> viric: 'Kernel compression (...)' or something like it
<viric> "Kernel compressino choice"....
<viric> I may be blind :)
<viric> ah it's disabled
<viric> I could make nconfig "show all options"
<viric> it shows 'XXX'
<viric> depends on HAVE_KERNEL_GZIP...
<viric> what a party :)
<wpwrak> yeah, only on input. don't want to "pop" on output :)
<larsc> hm, which kernel do you use?
<DocScrutinizer> HAH, on outputs you *got* 220pF
<DocScrutinizer> no idea what for
<viric> larsc: jz-3.2
<wpwrak> regarding the differential CD ground, if the source also decides to decouple GND, we would have a problem, right ? is this something that's like to happen ?
<DocScrutinizer> no
<wpwrak> (output 220 pF) probably since it worked during the last zombie attack, or whatever ;-)
<DocScrutinizer> your outputs make nice inputs ;-P
<viric> larsc: I can't find the magic combination :)
<wpwrak> that's where cargo cult meets voodoo meets ancient rituals meets paranoia ;-)
<larsc> viric: there is a patch _somewhere_
<viric> larsc: oh? a patch for what?
<wpwrak> except for the 10 k pull-downs, right ? :)
<larsc> for enabling the option
<viric> :D
<larsc> mth: pin
<larsc> g
<Ayla> what are you trying to achieve?
<DocScrutinizer> wpwrak: L1 looks ODD
<wpwrak> with non-differential use of CD*, we wouldn't know a difference, right ?
<wpwrak> L1 is "0" :)
<viric> Ayla: boot a kernel with xbboot
<whitequark> lol zombie attack
<DocScrutinizer> or, depending on where from you look at it, C30 is incorrectly placed
<viric> larsc: why isn't that in jz-3.2?
<viric> larsc: I can try any other branch that works
<wpwrak> we have a number of dead indictors. i think this is just one more of them.
<Ayla> what's the difference with jzboot?
<viric> what is jzboot?
<viric> :)
<larsc> viric: nah, you need to manually port them
<DocScrutinizer> gona TV&sleep
<DocScrutinizer> o/
<larsc> viric: the better xbboot
<wpwrak> it's the digital VDD anyway. that's supposed to be able the handle a bit of noise
<larsc> viric: written by whitequark
<wpwrak> DocScrutinizer: thanks a lot for helping to puzzle this out !
<DocScrutinizer> wpwrak: also supposed to have quite some surges
<viric> larsc: is there any reason for that patch not to be in jz-3.2?
<DocScrutinizer> that'S why you don't wanna have inductors without buffer C on digital VDD
<DocScrutinizer> yw
<DocScrutinizer> n8
<larsc> viric: nobody ported it
<larsc> viric: it is from the jz4760 branch
<viric> larsc: Message:stash ? :)
<larsc> yes, and it was not even supposed to be pushed onto the servers
<viric> aah.
<larsc> that particular commit, just a bunch of random changes
<viric> so I should branch from jz-3.2, and have that in my branch
<wpwrak> ah, the 6k8 series on input. should they be smaller ? or is 6k8 acceptable ?
<viric> larsc: (maybe I ask basic questions... I've no idea about how do you work :)
<DocScrutinizer> is OK
<larsc> sounds fine
<DocScrutinizer> I'd have picked 10k though
<viric> error: could not apply 9a83f48... stash
<viric> :)
<larsc> yes
<larsc> you need to manually apply the first three hunks with some fuzz
<larsc> select SYS_SUPPORTS_ZBOOT_UART16550 needs to go in arch/mips/Kconfig under MACH_JZ4740
<larsc> the second hunk is fine as it is
<viric> hm
<viric> ok. I'll do that slowly
<larsc> and the third one should use CONFIG_MACH_JZ4740 instead of CONFIG_MACH_JZ4760
<larsc> and 0xB0030000 instead of 0xB0031000
<Ayla> shouldn't those be commited?
<viric> yes. I'll complain to the owner.
<viric> :)
<viric> ok, got vmlinuz
<viric> larsc: so... vmlinuz built. I run
<viric> # xbboot -u 0x80600000 vmlinuz
<viric> and it does not boot :)
<larsc> and you don't have a serial right?
<viric> hm could have.
<viric> would it help?
<viric> I've the console to tty0...
<viric> the lcd does not switch on
<larsc> the decompressor should print some mesages to the serial console
<viric> oh
<viric> what serial console?
<larsc> the hw serial console
<viric> aren't there two? :)
<viric> ttyS0 and ttyS1
<larsc> yes, but only one is accessible
<viric> accessible by who or what?
<viric> I've that of the battery.
<larsc> i'm talking about this one http://en.qi-hardware.com/wiki/Serial_console
<viric> ah ok. yes yes
<viric> 57600...
<viric> larsc: nothing
<wolfspraul> wpwrak: I'm looking at the 'solder mask clearance setting ignore' but again
<wolfspraul> bug
<wolfspraul> it's messy even in the GUI
<wolfspraul> the solder mask and paste clearance seem to be saved in the .pro, not the .brd file
<larsc> viric: i think you need to build with DEBUG_ZBOOT
<wolfspraul> the menu has two different Save options (in HEAD)
<larsc> =y
<viric> I disabled that when asked...
<wolfspraul> Preferences -> Dimensions -> Save
<wolfspraul> and Preferences -> Save Preferences
<wolfspraul> both seem to do the same thing (not sure though)
<viric> ok, let me try again
<wolfspraul> in my quick tests, the solder mask clearance is indeed saved in the .pro, but the solder paste clearance is lost, even when saving manually
<larsc> viric: and vmlinuz.bin
<larsc> not vmlinuz sorry
<viric> ah oh
<larsc> vmlinuz is the elf binary, i think
<wolfspraul> the values are only reloaded next time if you open the .brd file via the kicad binary and .pro. if you open via pcbnew directly pointing to the .brd file, even settings saved in the .pro are not picked up, unless you manually 'load' the preferences
<wolfspraul> so there are bugs and inconsistencies already in the GUI
<Ayla> larsc: it's the gzipped vmlinux.bin IIRC
<wolfspraul> would it help if we made this a command line option?
<viric> I don't remember seeing vmlinuz.bin
<viric> vmlinux is elf sure...
<wolfspraul> so we would just pass the solder mask and paste clearance in (whichever you need)
<Ayla> anyway once it works, if you need a bootloader, you could use ubiboot :D
<wolfspraul> that won't help if you want them to be loaded from the .pro though
<larsc> viric: make vmlinuz.bin
<viric> ah, can do
<viric> boots!
wolfspraul [wolfspraul!~wolfsprau@p5B0ABD37.dip.t-dialin.net] has joined #qi-hardware
<larsc> party!
<viric> :D
<viric> can't open root... but well... that next :)
<viric> danke schun
<wpwrak> lost solder paste clearance sound like un-fun
<wolfspraul> I am not 100% sure, there are too many inconsistencies
<wolfspraul> one would need to unwind this one by one
<wolfspraul> my questions:
<wolfspraul> which one of 1) solder mask clearance 2) solder paste clearance 3) solder mask ratio clearance do you actually need?
<wolfspraul> do you need those values to come from the .pro file (the only place they are stored, and it seems not even all of them), or is it enough to pass them in over the command line?
<wpwrak> let's see ...
<wpwrak> atben.brd: Pad2MaskClearance, Pad2PasteClearance, and apparently ZOptions ties into this as well. then atben.pro VEgarde
<viric> I can't get the serial port working though...
<wpwrak> (ben-wpan commit daaac58f885cdc017bad91fa98c36dba37c3c26a)
<viric> hm I connected for a while TX/GND inversed
<viric> can that break the serial port?
<wpwrak> they're part of the design, so they should be in the file
<wolfspraul> hmm, but where do Pad2MaskClearance and Pad2PasteClearance in the .brd file come from in the GUI?
<larsc> viric: not really
<wolfspraul> if I open pcbnew, and change the values in Preferences -> Dimensions -> Pads Mask Clearance, those values in the .brd file are not affected
<wpwrak> maybe ask on the list ? :)
<wpwrak> i think there are several places where you can and have to save preferences
<larsc> viric: the serial port is a mystery for tomorrow night ;)
<viric> :) yes
<larsc> at least for me
<viric> me too.
<viric> thank you!
<wolfspraul> midnight, lars is becoming civilized
<wolfspraul> the system gets you!
<larsc> wolfspraul: well, i have to be at the office at 8am
<wolfspraul> oh I can imagine
<wpwrak> i don't remember how the clearances (radio vs. absolute) get mixed in the end. i remember having to track it down in the sources before i could figure out how to do it in the gui, though.
<wolfspraul> I miraculously always had the freedom to do whatever I wanted
<wolfspraul> show up at lunch time :-)
<wolfspraul> but infantilization rules
<wolfspraul> you get a free soda (yuhuuuu), but you have to be there at 9am sharp...
<wolfspraul> nothing much you can do, hope you survive :-)
<larsc> so far nobody has complained when i showed up 9:30, but i'm trying to not making it the norm
<Ayla> what's your job?
<larsc> linux :)
<wpwrak> i remember getting funny looks when leaving at 8 am :)
<Ayla> larsc: you're paid to work on Linux?
<wolfspraul> wpwrak: ok here's what I do: I will leave a comment in TODO, and try to get this committed first
<wolfspraul> there are still many details, your patches need to be up-leveled as well, etc.
<wolfspraul> I just wait until the bug reports come in, then look at this again
<larsc> Ayla: yes! unbelievable isn't it?
<Ayla> yes
<Ayla> you take applicants? :D
<larsc> I just started myself a few month ago
<wpwrak> wolfspraul: sounds good. it's better to get feedback from upstream early on anyway. no point in working three years on the perfect patch set, just to have it summarily rejected
<wolfspraul> oh of course
<wolfspraul> I am just focused to get our stuff back in shape
<wolfspraul> there's quite a number of little things in there
<Ayla> that's the sort of job I want to have. When it'll be time for me to seek a 'real' job, I'll ask you some advices
<mth> larsc: pong (reading backlog now)
<larsc> mth: problem solved
<larsc> Ayla: make sure to get your patches upstream.
<Ayla> yep, I believe it helps
<wpwrak> wolfspraul: (little things) yeah, they have that tendency of piling up :)
<Ayla> I also plan to do the GSoC
<larsc> there are a lot of people who apply for a linux job, but have actually no much of an idea how the upstream development process works
<mth> is there anything to be merged into jz-.3.2 to simplify things for other people?
<mth> I don't know if what viric is doing is standard or non-standard
<Ayla> the defconfig should contain CONFIG_SYS_SUPPORTS_ZBOOT_UART16550
<mth> we actually have a patch forcing VMLINUZ_LOAD_ADDRESS:=0x80600000 already for OpenDingux
<Ayla> I've had that issue when dealing with ubiboot
<mth> I regenerate the defconfig every kernel release, so if the flag isn't there, it is because none of the Kconfigs set it
<mth> SYS_SUPPORT flags are not set by the user afaik
<Ayla> AFAIK it requires a change on arch/mips/boot/compressed/uart-16550.c too
<Ayla> otherwise the PORT() macro is not defined
<larsc> viric: can you send the patch to the mailinglist?
<wpwrak> larsc: (inexperienced applicants) so you're helping out in HR now ? ;-)
<larsc> wpwrak: just something i've heard
<larsc> but i guess it always depends for kind of position you are hiring someone
<qi-bot> [commit] Wolfgang Spraul: uplevel cmdline patches (entire set won't build right now) (master) http://qi-hw.com/p/eda-tools/a277779
<wolfspraul> wpwrak: alright, first step. do you actually want to move to kicad head?
<wolfspraul> if so I need to go through your patches as well
<wpwrak> larsc: yeah, there's probably a lot of demand for upstream-agnostic developers ...
<wpwrak> moving to kicad head would be great
<wolfspraul> I took the liberty to break backward compatibility in the cmdline options
<wolfspraul> in favor of staying close to the GUI
<wolfspraul> here's what it looks like now http://pastebin.com/4xucpRLa
<wpwrak> nice ! a test script
<wolfspraul> a very basic one, just for myself
<wolfspraul> I type fast, but don't like to repeat
<wpwrak> hehe :)
<wolfspraul> the test script just calls the major options one by one, and lists the output files
<wolfspraul> no fancy checks with the generated files
<wolfspraul> can you look over the pastebin - let me know if you spot anything wrong
<wolfspraul> so I will work on the rest of the set now
<wpwrak> why cryptic abbreviations like --plot-gb-ex-pcb-edge ?
<wolfspraul> on one hand I try to stay close to the text in the GUI
<wolfspraul> on the other hand I don't want the option to be too long to --help still looks good
<wolfspraul> there's some space with that one, we can make it longer
<wolfspraul> gb-exclude-edges ?
<wolfspraul> --plot-gb-exclude-edges
<wpwrak> s/gb/gerber/ :)
<qi-bot> wpwrak meant: "why cryptic abbreviations like --plot-gerber-ex-pcb-edge ?"
<wpwrak> grr
<wolfspraul> :-)
<wolfspraul> gets too long, --help won't look good
<wpwrak> you can put the option and the beginning of the description on separate lines
<mth> --plot-gerber-noedges?
<wolfspraul> I try to follow the text and structure of the GUI
<wpwrak> --very-very-long-option=with-parameters,even-a-list-of-them
<wpwrak> \tthis does absolutely nothing
<wolfspraul> the GUI is our baseline I believe
<wpwrak> \t(default: enabled)
<wpwrak> or such
<wpwrak> using the same terminology as the GUI is good
<wolfspraul> I don't have that much room to influence how --help looks like because this is the wx framework system
<wpwrak> too easy to make a confusing mess otherwise
<wpwrak> oh, i see
<wolfspraul> let me see what looks good :-)
<wpwrak> drop the "plot-" prefix ?
<wolfspraul> I actually can look at --help now, before was just a mountain of characters
<wpwrak> ;-)
<wolfspraul> yes we could drop plot-
<wolfspraul> we risk an overlap with another dialog then, but so what
<wolfspraul> we can wait until we have such a conflict
<wolfspraul> namespaces can never be perfect...
<wolfspraul> --plot-gerber-exclude-edge and --plot-gerber-aux-origin still looks good
<wolfspraul> should we remove all plot- ?
<wolfspraul> actuall the aux-origin exists in the drill and plot dialogs
<wolfspraul> so we have --drill-origin-aux and --plot-gerber-aux-origin right now
<wpwrak> can they be merged ?
<wolfspraul> they could, but that's what I want to avod
<wolfspraul> avoid
<wolfspraul> two different dialogs
<wpwrak> :)
<wolfspraul> let's map the dialogs
<wolfspraul> I am certain the dialogs will change more
<wolfspraul> options are moving around, dialogs get merged, etc.
<wolfspraul> so there are only 2 paths
<wolfspraul> one is that the cmdline options completely have their own design
<wolfspraul> given that we only offer 5% of what's available now I don't think that's a good idea at all
<wpwrak> --plot-exclude-pcb-edge exclude PCB edge (Gerber only)
<wolfspraul> or the second one is to follow the GUI, even if that means some redundancy and changes/breaks in the cmdline options
<wpwrak> --plot-aux-origin Use aux axis as origin (default: abs; Gerber only)
<wolfspraul> anything in between will be a total mess
<wolfspraul> thanks to the wx command line system, I cannot repeat options in the --help output
<wpwrak> -drill-aux-origin Use aux axis as origin (def: abs)
<wolfspraul> I think I cannot
<wolfspraul> yes aux-origin, better
<wpwrak> (use aux-origin or origin-aux but better don't mix)
<wolfspraul> aux-origin
<wpwrak> (wx) the joy of overbearing frameworks :)
<wolfspraul> pcbnew --help http://pastebin.com/aiSAb6ZC
<wolfspraul> I think this is ok for now
<wpwrak> ah, we can probably drop the "ERC pin exceptions" patches. that doesn't quite work anyway and it's incompatible with the kicad belief system
<wpwrak> yes, looks good
<wolfspraul> then there is only streamline-erc.patch left
<wolfspraul> two are about aux-origin for DXF (will do that)
<wolfspraul> and two are about the erc exceptions you want to drop
<wolfspraul> erc-exceptions.patch and fix-pinedit-collision.patch
<wolfspraul> correct?
<wpwrak> no, i want to keep fix-pinedit-collision.patch (if it's still needed)
<wolfspraul> ok
<wolfspraul> so both fix-pinedit-collisions and streamline-erc
<wpwrak> streamline-erc.patch is merely cleanup. not needed by us if there's no erc-exceptions.patch
<wolfspraul> ok. then only fix-pinedit-collisions (plus DXF aux origin)
<wpwrak> yup
<wpwrak> these two are hopefully not too messy
<wolfspraul> should not. OK I hope to get it all to build tomorrow then
<wolfspraul> do you want installable packages or do you rather build from source anyway?
<wolfspraul> there will definitely be bugs in the cmdline patches, it was quite a lot of lifting around and *lots* of changes in the KiCad sources
<wpwrak> i build from source
<wolfspraul> ok
<wolfspraul> then I will ask xiangfu to upstream the whole thing
<wolfspraul> add it to his nearly infinite (tm) todo list
<wolfspraul> I'm adding about 1-2 items / day to that list :-)
<wolfspraul> luckily xiangfu ignores most of it