[08:50] <hrw> elo
[09:07] <cwillu_at_work> hrw, can you fix my network driver?
[09:07] <cwillu_at_work> actually, I wonder if they have a useable datasheet
[09:08] <hrw> cwillu_at_work: I am not kernel hacker sorry
[09:08] <cwillu_at_work> and?
[09:09] <suihkulokki> cwillu_at_work: I guess you can google for the datasheet faster than hrw :P
[09:10] <cwillu_at_work> hmm
[09:10] <cwillu_at_work> I wonder if this stick on the chip is actually intended for heat sinking purposes or something, or if it's just a qa thing
[09:10] <cwillu_at_work> given that it completely covers the chip
[09:11] <cwillu_at_work> also, who took my small screwdriver?
[09:12] <cwillu_at_work> never a prpplague around when you need one :/
[09:13]  * cwillu_at_work gets some rubbing alcohol
[09:20] <cwillu_at_work> 80 pages
[09:20] <cwillu_at_work> this might be useful
[09:20] <hrw> ;D
[12:19] <bernard_> hi. who could i prod to make a change to the images here? http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/
[12:20] <bernard_> i'm not sure if the omap4 ones are meant to be pandaboard-specific (some bits are), but currently it doesn't allow overriding the kernel cmdline arguments
[12:21] <bernard_> which makes it difficult to add a console= argument to get any sign of life
[12:23] <rsalveti> bernard_: after writing the image to your sd card you're free to mount the first disk partition and change the boot.scr file
[12:23] <bernard_> yep, i know this
[12:23] <rsalveti> with the proper cmdline arguments you need
[12:23] <rsalveti> so, what exactly do you want to do?
[12:23] <bernard_> but other people are running into the same issue. and it seems odd that it doesn't do so out of the box
[12:24] <bernard_> i just add console=ttyO2,115200n8 to the cmdline
[12:24] <bernard_> which if it's a pandaboard-specific image is probably fine to do
[12:24] <rsalveti> yeah, there was a decision to avoid enabling console by default
[12:24] <rsalveti> the omap 4 image is basically targeting panda, so that's ok
[12:25] <bernard_> please take this as a vote to enable console by default :)
[12:25] <bernard_> the kernel can be booted with quiet, so as to not slow down boot, and then a getty put on the terminal
[12:26] <rsalveti> yeah, I don't see why we can't at least enable a valid getty for it
[12:27] <bernard_> that would rock
[12:27] <bernard_> a way to append to bootargs without having to edit the SD card would be awesome too!
[12:27] <ogra_ac> wont happen unless you convince TI to add NAND
[12:27] <ogra_ac> there is no ways to save them
[12:28] <bernard_> i want to be able to override from u-boot (mainly for dev)
[12:28] <bernard_> e.g. trying to figure out what args to pass to the kernel to get video working how i want
[12:28] <rsalveti> iirc sakoman was working in a way to save the env somewhere else than nand
[12:28] <ogra_ac> if you add the above console= parameter to treh cmdline *before* first boot it will set up a serial console for you automatically
[12:28] <rsalveti> don't remember if it was just emmc though
[12:29] <ogra_ac> yes, we might switch to a raw partition intead of vfat in natty
[12:29] <rsalveti> ogra_ac: did you test that, because the all cmdline arguments kernel patch to init was applied later on
[12:29] <ogra_ac> that way you can treat iut like NAND and have some area to saveenv to
[12:29] <rsalveti> and we had to create a different uImage for blaze at least
[12:29] <ogra_ac> iirc jasper parses /proc/cmdline still
[12:30] <ogra_ac> so the kernel patch shouldnt be needed
[12:30] <rsalveti> hehe, some files parse /proc/cmdline and other don't
[12:30] <rsalveti> ogra_ac: but why can't we just enable the getty for uart by default?
[12:30] <ogra_ac> i will have to check the code
[12:31] <rsalveti> I mean, for natty
[12:31] <ogra_ac> rsalveti, see the jasper-rewrite spec ...
[12:31] <ogra_ac> we will if upstart allows it
[12:31] <ogra_ac> it has to happen there
[12:31] <rsalveti> yeah, it's hardware specific =\
[12:32] <ogra_ac> for x in $(cat /proc/cmdline); do
[12:32] <ogra_ac>     case ${x} in
[12:32] <ogra_ac>         console=tty[A-Z]*)
[12:32] <ogra_ac> so the kernel patch shouldnt matter
[12:32] <ogra_ac> but its essential to do it before first boot
[12:32] <rsalveti> cool
[12:32] <rsalveti> yep
[12:33] <bernard_> i found it a little bit creepy that the first boot modified the system and then rebooted. what does it do?
[12:34] <ogra_ac> all things the debian-installer would do otherwise
[12:34] <rsalveti> bernard_: mainly resize the sd card
[12:35] <bernard_> ah, fair enough
[12:36] <ogra_ac> it also sets up the board specific stuff
[12:37] <ogra_ac> it will change a lot in next release, but the resizing will have to stay
[12:38] <bernard_> oh, so an interesting bug report - when I dd'd the image to my SD card, the ext3 partition wasn't where it was supposed to be.
[12:38] <bernard_> running "file - < /dev/sdb2" just reported "data"
[12:39] <bernard_> i ended up running mkfs and copying the files in manually from the image.
[12:39] <ogra_ac> thats why the resizing bit is there
[12:39] <ogra_ac> you shouldnever tinker with it after dd
[12:39] <bernard_> the image didn't even boot though, because the partition table was pointing to the wrong place.
[12:40] <bernard_> i'm not sure what it was about the SD card, but i can dig deeper tomorrow morning (in about 9 hours, here)
[12:41] <ogra_ac> its a 4G or bigger card, right ?
[12:41] <bernard_> 4G SD card, yep
[12:41]  * ogra_ac only has heard of probs if people didnt stick to the minimal card size
[12:42] <bernard_> dd didn't complain, cmp against the ungzip'd image matched.
[12:42] <bernard_> i didn't dig much deeper at the time, but i can have another look in the morning.
[12:42] <ogra_ac> oh, you gunzipped
[12:42] <ogra_ac> rit, you said dd ...
[12:43] <ogra_ac> just use zcat ;) dont waste your diskspace
[12:43] <bernard_> to write the image, i did 'zcat foo.img | dd of=/dev/sdb'. to do a compare, i had to unzip, and then did 'cmp foo.img /dev/sdb'
[12:45] <ogra_ac> thats completely worng
[12:45] <ogra_ac> which install doc did you follow
[12:46] <ogra_ac> https://wiki.ubuntu.com/ARM/OMAP
[12:47] <bernard_> i was following what i normally do for writing images to media, not the instructions, sorry!
[12:47] <bernard_> is there really a difference between piping to dd of=/dev/sdb and using > /dev/sdb ?
[12:48] <ogra_ac> no idea, i never tested, but the instructions on the wiki were tested by many people
[12:48] <bernard_> the wiki also says that if the > method doesn't work, to gunzip and dd instead.
[12:48] <ogra_ac> we usually do quite some QA before releasing something ;)
[12:49] <ogra_ac> hrm, wo added that
[12:51] <bernard_> maybe there is something crazy about my sd card. i really can't see why they should differ.
[12:51] <bernard_> as i said, i'll reproduce it tomorrow and find out where exactly the image went.
[12:53] <bernard_> will anyone here be awake in 9 hours? ;)
[12:53] <rsalveti> berco: sure
[12:53] <rsalveti> ops
[12:53] <rsalveti> bernard_: sure
[12:54] <bernard_> cool. so i'm not in the craziest timezone!
[12:56] <lilstevie> heh 9 hours == business hours
[14:44] <berco> ogra: hi!
[14:44] <berco> ogra: can you please enable natty on our PPA?
[14:44] <ogra_ac> hey berco
[14:44] <davidm> jayabharath, do you have any beyond repair Panda boards?  I need something to test size and spacing with.
[14:45] <ogra_ac> berco, did you ask in #launchpad ?
[14:45] <davidm> jayabharath, completely dead is perfect if you have any.
[14:45]  * ogra_ac doesnt know why that wouldnt happen automatically
[14:45] <jayabharath> Yes I think we have a couple sitting in our office... will 1 or 2 board do?
[14:45] <berco> ogra_ac: I think I did last week but never got a real reply
[14:45] <berco> ogra_ac: maybe everyone was at UDS/ELC...
[14:46] <ogra_ac> or plumbers :)
[14:46] <davidm> jayabharath, 2+ is a perfect amount of boards, 1 is better then nothing. :-)
[14:46] <berco> ogra_ac: I thought it was you. Shall try again on #launcpad?
[14:46] <davidm> jayabharath, 2+ allows me to test spacing for the 19" rack case
[14:46] <ogra_ac> ask for a LOSA (launchpad admin)
[14:46] <jayabharath> I have 1 in my office. I do know we burned one more board recently.. so we can give 2 boards to you. How can we get them to you
[14:47] <davidm> jayabharath, I am more then happy to drive over to the TI offices to pick them up
[14:47] <jayabharath> ok great.
[14:48] <davidm> jayabharath, thanks, that will really help me with the layout of the 19" case and cable assemblies, just let me know when to come get them.  Thanks again.
[14:49] <jayabharath> I will get my hands on the boards this morning and will email you. You can drop by anytime after 3.30pm today
[14:49] <davidm> jayabharath, perfect, wow it's coming together nicely
[14:49] <jayabharath> nice
[15:39] <rsalveti> ogra_ac: told you that they never tested qt neon autodetection on a non neon capable machine
[15:39] <rsalveti> it's now an upstream bug
[15:40] <rsalveti> even affecting natty
[15:40] <ogra_ac> yeah
[15:40] <rsalveti> good that this also affects meego
[15:40] <ogra_ac> do you think that will be solved soon with a suitable patch for maverick ?
[15:40] <ogra_ac> else i'd prefer to do the static build again
[15:41] <rsalveti> let's wait until tomorrow's eof
[15:41] <rsalveti> *eod
[15:41] <ogra_ac> like if it takes months it doesnt help much in maverick
[15:41] <ogra_ac> k
[15:41] <rsalveti> if not, at thursday we just push the disabled neon version for maverick
[15:42] <ogra_ac> well, i'm fine even waiting another week or so
[15:42] <rsalveti> the bug is critical, but then I saw that most qt bugs are critical hehe :-)
[15:42] <ogra_ac> just not months
[15:42] <rsalveti> ok then, let's wait at least this week then
[16:53] <prpplague> davidm: ping
[16:53] <davidm> prpplague, good morning
[16:53] <prpplague> davidm: greetings earthling
[16:53] <davidm> by the by the AC100 is 19 V
[16:54] <prpplague> davidm: i haven't seen an email come across by inbox, just curious if you are still working on the project?
[16:54] <prpplague> davidm: ahh interesting
[16:57] <davidm> Yes you might want to have a look at: https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster
[16:57] <hrw> davidm: let me guess: 19V 2.1A?
[16:57] <davidm> Where I have the beginnings of the documentatation
[16:57] <davidm> Nope 1.5x 30W
[16:57] <davidm> Nope 1.5xA 30W that is
[16:58] <davidm> Tiny
[16:58] <davidm> The wiki page has some ASCI art on the relay schematic
[16:58] <davidm> Very rough
[16:59] <davidm> I'm coming by TI today to pickup 2 dead panda boards so I can do sizing and such
[16:59] <davidm> I will then take some perfboard and make "daughter" cards to size
[17:00] <davidm> and make up my "10" stack for sizing into the 19" rack case
[17:00] <prpplague> davidm: ok, i'd like to show you something when you come by
[17:01] <hrw> have a nice rest of day
[17:02] <prpplague> hrw|gone: later
[17:03] <davidm> prpplague, OK I'll mention that to jay when I come in.
[17:03] <prpplague> davidm: i have something that might slightly impact your physical format
[17:03] <prpplague> davidm: but would make things a little easier to work with
[17:04] <davidm> I'm not sure how to bias the transistor so the relay will latch and not sure what pin to use to poke it for unlatching
[17:04] <davidm> prpplague, cool
[17:04] <ogra_ac> easier ++
[17:04] <ogra_ac> :D
[17:04] <devilhorns> ogra_ac, !!!! :P
[17:05]  * prpplague is still tinkering with a netbook interface kit for the pandaboard
[17:05] <davidm> prpplague, the transistor must allow latching with the panda board hard off (no power applied)
[17:05] <prpplague> davidm: yea looking over your diagram now
[17:06] <davidm> prpplague, please be gentile remember its ascii art ;-P
[17:07] <prpplague> davidm: np, let me work through the logic and create a schematic over the next few days
[17:08] <davidm> OK
[17:08] <prpplague> davidm: here is the relay i suggest using - http://www.mouser.com/ProductDetail/NEC/UB2-3NU/?qs=c5n%252bvICFHOa2OX6vjaAytg%3d%3d
[17:08] <prpplague> davidm: low noise, surface mount and is available in several different coil configurations
[17:09] <davidm> prpplague, the URL shows coil voltage at 3V will 5V damage it?
[17:10] <davidm> Or is that the min pullin voltage?
[17:10] <prpplague> davidm: it is available in a wide range of coil voltage configurations, that just happens to be the 3V nominal part
[17:11] <prpplague> davidm: http://www.mouser.com/Electromechanical/Relays-I-O-Modules/_/N-5g31?Keyword=UB2&FS=True
[17:12] <davidm> Cool, then we are good with 5V, perfect
[17:12] <davidm> YEs, I like that relay, nice
[17:54] <rsalveti> ogra_ac: the problem is not only the kernel tree development, it's more the long term maintenance of it
[17:54] <rsalveti> I know the linaro folks will integrate most ubuntu sauce and stable fixes
[17:55] <rsalveti> so I believe we'll be ok for the release, but don't know then how the long term maintenance will work
[17:55] <ogra_ac> as long as the config is fine
[17:55] <ogra_ac> we might need a different config from what linato wants to use
[17:55] <ogra_ac> (more drivers)
[17:55] <rsalveti> that's ok
[17:56] <rsalveti> we'll have some kind of linaro-ubuntu tree
[17:56] <rsalveti> and we can use the config we want at the package level
[17:59] <ogra_ac> right, so security and version alignment is our only issues
[18:02] <rsalveti> ok, at least for omap 3 I believe we'll be fine
[18:02] <ogra_ac> right
[18:02] <rsalveti> I'll also help on what I can to make sure we have a good working kernel for it
[18:02] <ogra_ac> i'm more concerned about possible upcoming platforms
[18:02] <rsalveti> my concern is if we get the same kind of request for other hardware vendors
[18:02] <rsalveti> yup
[18:02] <rsalveti> :-)
[18:03] <rsalveti> this shouldn't be a common solution
[18:03] <rsalveti> omap 3 will be maintained this way because it's important for the community
[18:03] <ogra_ac> even demoting omap3 to a community image if we cant get security would be fine by me
[18:03] <rsalveti> yeah
[18:03] <ogra_ac> but not for possible other arches
[18:04] <ogra_ac> if we have commitment we need to support them
[18:04] <rsalveti> sure
[18:29] <prpplague> davidm: ok i follow the ascii art but it needs some cleanup and conversion into a proper schematic
[18:29] <prpplague> davidm: i'll start work on that
[18:30] <prpplague> davidm: have you prototyped the circuit yet?
[18:36] <davidm> prpplague, nope, I've done the latching side many many times, but first time with a transistor to drop it
[18:37] <davidm> The prior cases I used a mechanical switch to open the relay
[18:37] <davidm> different use case
[18:38] <prpplague> davidm: ok, i'll do a prototype setup along with the schematic
[18:38] <davidm> By the by I'll be at TI about 3PM today
[18:38] <prpplague> dandy
[18:38] <davidm> I'll call Jay for an escort
[18:38] <prpplague> :)
[18:39] <davidm> Do you have a suggestion on what GPIO pin might be safest to use?
[18:41] <prpplague> davidm: generally speaking they will be about the same, but i'd want to read over the x-load code for blaze/sdp/panda to see if there are any commonalities that might create problems
[18:42] <prpplague> davidm: i'd probably suggest using GPMC_AD13 as an initial item, which is on the secondary expansion header
[18:42] <prpplague> davidm: this leaves the other ones untouch incase you need to rev the board for other features
[18:43] <davidm> prpplague, OK that works, thanks.  I figure you know the board better then I do.
[18:44] <prpplague> davidm: i should be able to get some quick turn boards for the relay section one week from today
[18:48] <davidm> I have some prototyping boards here I can breadboard if that helps
[18:48] <davidm> That was what I was going to do anyway
[18:56] <prpplague> davidm: naw, this will be quick turn boards with the correct footprints and everything
[18:56] <prpplague> davidm: basically flush out any issues with the schematic and such
[18:57] <davidm> Works