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