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