[07:38] Nice job: http://theironlion.net/blog/2010/06/06/ubuntu-arm-board-and-i-walk-bar/ [07:38] RON LION [07:38] That's what I get at 150% fullzoom. [08:19] morning === XorA|gone is now known as XorA === amitk is now known as amitk-afk [11:20] lool, what are you fiddling with upstart ? it didnt FTBFS since two uploads [11:20] ogra: Fiddling? [11:20] * ogra wonders if the -fpic is still needed [11:21] ogra: I don't understand your remark [11:21] lool, oh, it was -fpie not pic, why did you make that change to libnih ? [11:21] ogra: I reverted an armel-specific workaround, read the changelog [11:22] oh, oops [11:22] sorry, misread [11:22] * Re-add -fPIE to the testsuite on armel, removing all armel-specific tests; [11:22] current gcc-4.4 don't seem affected by the ICE anymore (see LP #398403). [11:22] Launchpad bug 398403 in upstart (Ubuntu) (and 4 other projects) "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error (affects: 2) (heat: 20)" [Undecided,Fix released] https://launchpad.net/bugs/398403 [11:22] yeah === amitk-afk is now known as amitk [13:46] mythripk: how do you identified all the supported timing values for omap4 in the hdmi driver? [13:46] I was thinking if it can be compatible with omap 3 too [13:47] robclark: maybe you also know the answer :-) ^ [13:51] lool, wrt your filesystem corruption issue from the weekend, do you use the initrd from the image and also the boot.scr ? [13:52] lool, i wonder how you even got fsck output on stdout, the scripts in initramfs redirect all that to the jasper.log [13:53] lool, also you wont be able to use that image without dd'ing it to a bigger img file (or min. 4G SD card), did you do that ? [13:54] (thre images we produce are really not suited for qemu usage without a lot of fiddling) [13:59] rsalveti: not sure how the timings were identified.. I think that is a question for mythripk [14:00] but I'm not sure how similar the beagle hdmi driver is.. but I assume there must be a table somewhere that the bootargs map to [14:00] robclark: yeah, could be, will have a look at it [14:01] robclark: omap3 did not checked edid [14:01] because the hdmi driver basically fetch the edid and then finds the best resolution that has a matching timing [14:01] hrw: but I assume it still uses timings somewhere under the hood... when you set code/mode bootargs, those must map to some supported timings [14:02] don't know if the code/mode is actually supported at beagle [14:02] there is a map of resolutions in omap3 driver [14:02] we have a spec to implement using EDID under omap3 [14:02] fyi [14:02] ogra: I know, that's why I'm asking all these questions :-) [14:02] that map should contain the timings, I would guess.. since at some point that needs to be programmed in to the hw to generate correct signal [14:03] ogra: but without going to highest possible I hope [14:03] robclark: hm, true, will try to find it [14:04] hrw, with going to highest possible the current monitor and driver support [14:07] ogra: 1680x1050x16@24 omap3 can generate, my display probably will display but I prefer to not go more then 1280x800 on it [14:07] hrw, you are free to change the generated cmdline [14:07] its just to get a good default entry [14:07] sure [14:08] indeed preferably the omap3 driver would do the same the omap4 one just learns and wouldnt need cmdline args :) [14:09] but since we dont put much effort into omap3 development the cmdline will do for now [14:19] armel-cross-toolchain 1.16 sent to PPA for build [14:31] ogra: As noted in my email, I don't touch the image at all and run it without resizing [14:31] lool, yeah, but did you use the cmdline from boot.scr and the initrd from the image ? [14:31] ogra: I understand it might not be expected to work out of the box under QEMU, but my experience seems to indicate an underlying bug which might be worth looking into [14:31] ogra: I'm not touching the image [14:31] ogra: So it uses everything in there [14:31] (the corruption is surely on buildd side, i'm just wondering why you get that output at all) [14:32] so you use u-boot to boot it ? [14:32] The u-boot in your image [14:32] right [14:32] thats weird [14:32] and when do you see the error ? before or after the automatic reboot [14:33] (there shouldnt be an fsck at all apart from teh jasper one before the boot and all jasper output is logged silently to a file) [14:33] s/boot/reboot/ [14:36] ogra: On first boot [14:36] thats strange [14:36] there is only one forced fsck during the resize process, then it should reboot right after jasper prints "reboot check" [14:37] if you see the fsck after "reboot check" its likely not following the process [14:37] i.e. reboot doesnt work [14:38] its also very likely that it doesnt do the resizing and reformatting at all in your case, which will definitely cause issues [14:40] (partitioning or filesystem size doesnt matter at all since we rewrite the whole partition table and reformat/resize the filesystems before the rootfs gets ever mounted) [14:40] so the corruption doesnt matter for functionality if the resizing works [14:45] ndec, try to re-upload to the PPA, it should build armel now === bjf[afk] is now known as bjf [15:08] ogra: well, in fact it's not showing armel, but it does show sparc and powerpc ;-) [15:09] ogra: you should be able to see the PPA, i have uploaded [15:09] well, it was just changed, it should build armel now [15:09] i think you need to re-upload [15:09] ogra: I uploaded after you told me about it... is there any delay? [15:14] ndec, ok, i'm told it should be fixed *now* [15:16] ogra: i just tried to upload a package with arch=armel only, and it seems that the upload worked. we will see in a few mins. [15:16] yep [15:16] seems armel needed special treatment for enabling [15:16] enabling the ports just gave ia64, sparc and ppc [15:16] ah, your ubuntu4 upload looks good [15:17] ogra: ubuntu3 looks good too. it has arch=any, and armel is there. [15:18] ah, i didnt look at 3 :) [15:18] but right, seems ok now [15:18] ndec, so i'd say enjoy your PPA :) [15:19] (and give me a list with other trusted uploaders at some point) [15:19] ogra: i can add them myself since you made me admin, no? [15:19] i didnt make you admin, i think asac did though [15:20] but yes, you should be able to [15:20] ogra: i will try. for now we will try to put all the packages in the PPA for review, and let you know. [15:21] great :) [15:50] mopdenacker: hey, do i need to send another confirmation for my ELF-EU presentation, or was that just for the people who were CC'd on that email? [15:53] prpplague: no, you don't have to. I already have your confirm. :-) [15:53] mopdenacker: dandy [15:54] mopdenacker: i've got to finish testing some new boards this morning, then this afternoon i'll be back on your display issue [15:55] prpplague: perfect. Thank you very much! I'm excited to meet you in Cambridge at last :-) [15:55] Good luck! [15:56] mopdenacker: me too === zyga is now known as zyga-afk === fta_ is now known as fta [17:15] robclark: hey, so you think we need to trace through the resize notification to track down this issue? [17:18] hmm, that bit about the log redirecting to jasper.log... shouldn't it use "tee"? [17:19] prpplague: yes.. I think so [17:19] robclark: can you recommend a function call to start looking at? [17:19] DanaG, why = === hrw is now known as hrw|gone [17:19] s/=/?/ [17:20] So you can get them over stdout. [17:20] Or is it not possible to lose jasper.log anyway? [17:20] Say the thing fails in some way that makes you unable to retrieve the log... can that even happen? [17:21] prpplague: hang on, I'll swing by [17:21] DanaG, it cant get lost but in some stages it can get hard to access the log [17:22] robclark: thanks [17:23] Ah, pidgin died: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/622831 [17:23] DanaG: Error: Bug #622831 is private. [17:24] ah [17:24] Would pidgin bug logs have passwords? === zyga-afk is now known as zyga [17:26] ah yeah, the core dump has my irc password. [17:57] GrueMaster, so the oem-config fix works fine, as soon as dyfet has fixed telepathy-glib the images should build again and we should have a working install process again [18:01] cool, finally :-) [18:02] and oem-config has a cute panel now [18:02] which suspiciously looks like upanel [18:03] (the thing we dropped because DX didnt provide the code for it) [18:04] anyway [18:04] * ogra calls it a day [18:04] cool [18:05] ogra: I'm going to be spending the day trying to figure out how I am going to manage 3 new platforms into my office layout. Should be ready for testing later today. [18:36] robclark: looks like i can replicate that problem with the dvi display [18:52] rsalveti: Timings supported by omap4 are based on functional spec and max /supported pixel clock values that can be generated by hdmi pll [18:52] mythripk: hm, ok [18:53] mythripk: I was thinking about omap 3, how can we check the supported timings? [18:55] rsalveti:not all omap4 timings are supported by omap3,it has limited set of timings is what i believe ,I can check with pulukuru,srinivas in case you dont have his contacts and get back to you. [18:55] mythripk: nice, that would for sure help :-) [18:55] because then we can try to identify the best supported video mode for omap 3 [18:57] prpplague: oh good.. I can swing by in a bit [18:59] rsalveti:720P is the maximum supported timing in omap3 is what im aware of.. other timings i need to confirm [19:00] mythripk: hm, I thought it would support higher timings [19:00] mythripk: but please, confirm it if possible :-) [19:11] rsalveti : confirmed max omap3 supports is 720P [19:17] I think, that you can do 1080i/1080p@30 on beagle [19:21] ynezz: the pixel clock seems to limit you [19:21] mythripk: nice, thanks [19:22] rsalveti: yes, it depends on TV/monitor also, if it can do lower sync rates [19:22] but I've read, that somebody was able to run 1080p30 at beagle === fta_ is now known as fta [19:28] ynezz: cool [19:30] http://markmail.org/message/b7fii2z6qcf3di3x [19:56] heh, I'm blind or need more cofee, but where could I enter here new bug/feature request? :-) https://bugs.launchpad.net/~beagleboard-kernel [20:06] ynezz: If you wish to file it as a bug against the Ubuntu kernel for omap3, file it against linux-image-omap. Use linux-image-omap4 for omap4 kernels. [20:06] Mark importance as wishlist. [20:07] Oops, excuse me, that should be linux-ti-omap & linux-ti-omap4. [20:09] ah, thanks :) [20:12] is there a mobile meeting tomorrow? [20:13] ian_brasil_: yep, every week [20:14] ian_brasil_: 9 am for you, I guess [20:15] rsalveti: thx === fta_ is now known as fta [21:10] weird... plymouth doesn't work on the beagleboard. [21:11] ah, I see... it won't splash if serial console is present. === fta_ is now known as fta [22:32] ogra: FYI libnih built fine === JaMa is now known as JaMa|GoNe === bjf is now known as bjf[afk] === fta_ is now known as fta [23:28] Weird... flash-kernel hangs the board at "erasing kernel NAND space..." [23:28] er, wait, it unfroze. [23:29] to upgrade to maverick but leave the kernel, uboot, and firmware alone on a iMX51, is using update-manager a stupid idea ? [23:29] It's spewing: [ 6632.227600] uncorrectable error : [23:30] [ 6631.614959] Buffer I/O error on device mtdblock3, logical block 124 === fta_ is now known as fta