22:00 <enyc> pcb layout week iirc

22:01 <Joerg-Neo900> yeah, ahycka starting layout weekend

22:50 <enyc> Joerg-Neo900: i'm itching to see preety-pcitures, also wondering how many layers is likely anyway ;p

22:52 <enyc> Joerg-Neo900: whats' being worked on in parallel/meantime to 'layout' ?

22:53 <Joerg-Neo900> I guess layout will create enough question and requests for support so we won't be bored

22:57 <enyc> =)

22:57 <enyc> ok i just wonedred more if there was anything else 'already started' that needs doing

22:58 <enyc> e.g. any useful prep to help preparations for kernel/drivers/testsuite for board for starters...

23:00 <Joerg-Neo900> already checking status and preparing a list of all drivers needed for what's in block diagram will help a lot for sure

23:01 <jonwil> Anyone with reverse engineering skills could help by working on FPTF stuff (e.g. remaining pieces of Nokia audio blobs)

23:02 <Joerg-Neo900> like: "aah, touchscreen driver (clicks datasheet link in popup) mhm it's a crtouch12b (browses linux upstream repos to find a driver for that chip)"

23:12 <wpwrak> and even if there's no driver for something yet, a little i2c test script (for things that are on i2c, which is almost everything) could be very useful. e.g., 1) try to talk to the chip in question and read some bit pattern that identifies it (some vendor code, revision, etc., most chips have something of this sort. doesn't have to be unique, but preferably not just 0x00 or 0xff.)

23:12 <wpwrak> 2) make the chip do something observable. or, if it's a sensor, read something that can be easily affected from the outside.

23:15 <wpwrak> in v2 there will be two types of problems: 1) anything we got wrong in the design, 2) anything that went wrong during assembly. so it should be very useful to have a set of quick tests that will indicate the overall condition of a board.

23:17 <Joerg-Neo900> see i2cget i2cset

23:18 <Joerg-Neo900> as well as

23:18 <Joerg-Neo900> ~bq27k-detail

23:18 <infobot> i heard bq27k-detail is http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail2, or ~bq27

23:18 <Joerg-Neo900> as an example

23:18 <Joerg-Neo900> ~bq27

23:18 <infobot> well, bq27 is http://maemo.cloud-7.de/maemo5/usr/local/sbin/ bq27*, or http://maemo.cloud-7.de/maemo5/patches_n_tools/

23:19 <wpwrak> yup. a bunch of shell scripts using these should be able to accomplish a lot. doesn't have to be complicated :)

23:19 <Joerg-Neo900> not at all, the simpler the better

23:20 <Joerg-Neo900> everybody may do 'complicated, but in simplicity lies true excellence

23:36 <ds3> LMV221SD-WRONGPACK ????

23:39 <wpwrak> LMV221SD, with an associated footprint (from the eagle days), but the footprint isn't right (was already wrong in eagle)

23:41 <ds3> ah

23:41 <ds3> btw - shouldn't there be pads for series resistors on the SDIO interface for the wifi?

23:41 <ds3> oh my other window has me

23:44 <ds2> should note on S902: Avoid routing high current traces near or underneath it

23:45 <Joerg-Neo900> ack

23:46 <Joerg-Neo900> + keep away from magnets (vibrator)

23:53 <Joerg-Neo900> wpwrak: are you keeping track?

23:56 <Joerg-Neo900> enyc: actually I think the common case is direct i2c tests are simpler than tests via specific drivers. However whenever a driver avaulable, we may want to test the subsystem functionality via such driver too

23:59 <ds2> magnets aren't as nasty

23:59 <Joerg-Neo900> e.g. for the touchscreen crtouch12b we should try to actually get a working pointer device in a UI that shows the effect

23:59 <Joerg-Neo900> ds2: only when they're static

23:59 <ds2> that can be cal'ed out (hard iron correction) provided it doesn't saturate it

23:59 <ds2> yes but unless you are running heptics 24x7....

23:59 <Joerg-Neo900> particularly kickstand and vib motor... :-/