=== hrw|gone is now known as hrw [08:19] morning [09:38] ogra: does USB EHCI of ES2.0 work with our Ubuntu daily live image? [09:39] yep [09:39] kbd and mouse work fine on 6 and 8 layer for me [09:40] the NIC too (usb NIC) [09:41] nice [09:42] ok, let me try again. [09:42] thx, man [09:42] do you have issues ? [09:43] * ogra_ac didnt try todays image, yesterdays worked fine [09:46] ogra_ac: i am trying Sep 11 daily image [09:46] but usb EHCI doesn't work [09:48] weird [09:49] cooloney, 6 or 8 layer ? [09:50] ogra_ac: 8 layers [09:51] ogra_ac: i tried EHCI ports before with maverick rootfs from rootstock [09:51] it works on my 8 layers [09:52] well, all i can say is that it works flawless here [09:52] ogra_ac: if you think yours is working fine, never mind. maybe it's my bad. [09:52] ogra_ac: ok, got it. [09:52] with teh dsailsy it should just work for you too [09:52] *daily === amitk is now known as amitk-afk [09:53] * ogra_ac recommends to zsync to the latest [09:54] though there wasnt a kernel change between 11th and today afaik [09:56] oh, wait [09:56] the metapackage was screwed until teh 12th [09:57] you might still have the old ES1.0 kernel on the image from the 11th [09:57] oh, i'm just wanna zsync that [09:57] ogra_ac: ok, i got it. [09:57] ogra_ac: let me zsync it [09:57] yeah, use todays [09:58] intresting that it boots at all [09:58] i think mine got stuck on teh 6 layer when i tried it with the old kernel [09:58] during first boot [10:01] ogra_ac: thanks for helping this. i'm zsyncing [10:01] cool [11:07] ogra: Is there any reason why the ES2.0 wouldn't boot with CONFIG_PM enabled? [11:07] lag, ask ndec [11:07] (if he returns) [11:08] lag, all i was told is that the HW doesnt support it yet [11:08] and wont for maverick [11:08] k [11:08] I've done some testing and it doesn't even boot [11:08] No boot-up messages at all [11:08] but ndec should be able to tell you if it gets in our way [11:09] ah, so it does then :) [11:09] I'll move on to something else for the time being [11:09] Quite [11:09] you could fix some userspace bugs if you are bored :P [11:09] we have enough of them [11:20] lag, how about ASoC stuff ? [11:21] we still have no working sound and TI wants to use asound.conf,getting the driver improved to not need that would be an awesome fix [11:25] ogra: I though it worked? [11:25] ogra: Or was that ES1.0? [11:25] HDMI might [11:25] no it never worked properly [11:26] for the normal system we should default to the earphone plug ... with an option to switch over to HDMI in the sound prefs [11:26] prpplague was working on it [11:26] I'm sure he submitted patches [11:26] in ES1.0 i saw the HW at least but couldnt switch (and i think with that sound came out of HDMI) [11:27] with ES2.0 i dont see a sound device at all atm [11:27] lag, he is working on a very raw implementation that requires asound,conf [11:27] Create a bug [11:27] And assign me [11:27] our audio team usually doesnt allow using that file [11:28] (though we'd do it as a workaround from jasper if we cant get it fixed, but if there is any opportunity to get it fixed properly that would be better) [11:48] ogra: Have you reported a bug yet? [11:48] nop [11:52] lag, bug 637947 [11:52] Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/637947 [11:57] Ta [12:06] persia, i'm wondering if we couldnt just use a case statement for jasper cmdline parsing ... if anything is set we just dont touch it [12:06] lag, I recall you and I discussing this about a month ago: it either needs proper quirking *OR* board-drivers. [12:07] persia, talking about sound or PW ? [12:07] err [12:07] PM [12:07] Sound. [12:07] well, TI brought it up on friday and they say there is no time to fix it in driver on their side [12:08] so asound.conf would be our last resort [12:08] Assuming you're talking about bug #605831, the issue with a case statement is that we only want to set things if they *aren't* present. You'd have to track a lot of state. [12:08] Launchpad bug 605831 in jasper-initramfs (Ubuntu Maverick) (and 1 other project) "Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 73)" [Medium,Triaged] https://launchpad.net/bugs/605831 [12:08] but i'D rather not use it if we can make it happen properly anyhow [12:08] Those aren't the only choices (and asound.conf is a very poor choice). [12:09] In addition to those two, we have 1) kernel quirking to hint various devices if they don't report properly (this is done *extensively* for Intel HDA, as an example). [12:09] well, feel free to make suggestions for fallbacks on the bug above [12:09] we can surely create an asound.conf from jasper as last resort ... any better solution is indeed preferred [12:10] And 2) the extensible constructed ALSA configuration, which happens dynamically in /usr/lib/alsa-lib [12:11] Please, please, don't create an asound.conf in jasper. [12:11] If nothing else, that will likely break all USB audio. [12:11] Potentially bluetooth as well. [12:11] well, all suggestions are welcome [12:12] if you have a better way we shoudl use that one [12:12] Drop a conf fragment in /usr/share/alsa/ somewhere that only gets used for omap. [12:12] We'll end up with broken support for omap boards other than those identified for testing, but it won't be more broken than an asound.conf, and will be much easier to fix. [12:13] I *think* the best place is probably under /usr/share/alsa/init/omap or similar [12:13] k, can you add a comment on the bug [12:14] sure [12:14] (make sure though thats its a fallback, preferred solution is still in kernel) [12:15] persia: Yes we did [12:15] prpplague: Are you here yet? === amitk-afk is now known as amitk [12:19] ogra, please review that comment: I hope it's clear enough. [12:19] lag: where is here? [12:19] prpplague, In front of a device connected to IRC and viewing this channel :) [12:19] i guess he meant there :) [12:19] * prpplague is travelling today and be back in the office tomorrow [12:19] hehe [12:21] lag: whatcha working on now? [12:22] prpplague, i just created bug 637947 for him [12:22] Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/637947 [12:22] (which is why you got pinged i assume) [12:23] prpplague: Hi David [12:23] We were speaking about audio a few weeks ago [12:23] I believe you were going to release some patches to make it work on the ES1.0 [12:24] A board driver? [12:29] lag: yea there was a handoff, the announcement went on the pandaboard list [12:29] lag: you can get the latest sources at gitorious/pandaboard [12:29] lag: the L24.9 branches [12:33] prpplague: And they will make sound work on the ES2.0? [12:33] I believe we have the majority of L24.9 [12:50] prpplague: When you say the pandabaord list, do you mean on IRC, or is there a mailing list? [12:57] lag: the last audio patches I pushed on my tree (for-ubuntu-2.6.35) are post L24.9, and are not in prpplague's tree [12:58] sebjan: I have just fetched from your tree, which is building now [12:58] :) [12:58] lag: ok, cool :) [12:58] :) [13:02] cooloney: ping [13:18] lag: there is a mailing list [13:18] I've has a quick Google for it, but to no avail [13:18] Would you be so kind as to link me to it please? [13:22] lag: email: pandaboard@googlegroups.com [13:22] lag: Link: http://groups.google.com/group/pandaboard [13:24] ogra: i just subscribed you to 587632. any chance this can be fixed for 10.10? the problem is that when gst-ugly is installed it will superseed gst-ffmpeg which works fine on arm. [13:24] bug 587632 [13:24] Launchpad bug 587632 in libmad (Ubuntu) "Sound very distorted on armel (affects: 2) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/587632 [13:24] berco: I did find that [13:24] berco: Is it just a matter of joining that group? [13:26] lag: I think so [13:26] ndec, lets ask linaro if they want to work on a fix, else we can indeed build with -marm [13:26] lag: honnestly I haven't tried yet [13:26] Given the proximity to release, let's just use -marm [13:26] I can't join [13:27] You need to have a Google account [13:28] lag: yes you always need a google account to subscribe google groups I believe. [13:28] lag: I believe so. I just tried with my google account and I'm now a member of the group [13:29] lag: you can create a new google account with an existing email address. in that case it would give you a google account without gmail. [13:52] robclark:gm i saw some talk related to EDID ? [13:52] hi mythripk.. [13:53] yeah.. but mpoitier doesn't seem to be around atm.. [13:53] hmm , I should be able to get the code with seperate edid.c by this weekend [13:53] same thing we were talking about the other day, about how to support EDID for DVI/other drivers.. [13:54] ok, very cool [13:54] ya with your patch for DVI as well , i have the old regular code for EEDID [13:54] ahh, hi mpoirier [13:55] speaking of the devil :) [13:55] indeed [13:55] :) [13:55] finally mpoirier and mythripk in same channel at same time ;-) [13:55] we should remove europe ... that gets the timezones closer together :) [13:56] heheh, I'm not sure if it works that way.. [13:56] ogra: but I like Europe... [13:56] great for vacation. [13:56] mpoirier: mythripk had mentioned: "hmm , I should be able to get the code with seperate edid.c by this weekend" [13:56] lol [13:56] robclark: cool - on what processor ? [13:56] mythripk: hm, also interested on that :-) [13:57] robclark: rsalveti is heading that project now. [13:57] hmm k then let me send the code for review once im done [13:57] mythripk: cool [13:57] would you like some heads up ? [13:58] mythripk: yes please. [13:58] mythripk: what you're planing to do for improving the edid code on omap4? [13:58] the edid parsing [13:58] mpoirier: I guess this would be on omap4 kernel, but we should start trying to apply some of the patches on both to align omap3 and omap4 code.. [13:58] rsalveti: ^^^^ [13:59] robclark: yep, that's what I was looking for [13:59] trying to integrate at least the parsing code [13:59] create a seperate edid.c file which will handle all the edid and eedid code [13:59] yup [13:59] rsalveti: I can assist if need be. [13:59] and trying to use the common kernel api for it [13:59] mpoirier: cool [14:00] hmm ive seen some changes on omap3 done by srinivas i could send out those patches... [14:00] rsalveti: just keep in mind, in some use cases you might have hdmi display, but no framebuffer, only v4l2 device.. [14:00] yup , it is independent of v4l2 or fb and tied to hdmi.c [14:01] rsalverti, rob and mpoirier do you have any specific suggestions... [14:02] robclark: true, but it shouldn't be tied with fb [14:03] mythripk: just one... ideally somehow the edid parsing code could return a list/array of supported timings. Because eventually we want omapfb to populate modedb table with all supported modes [14:04] mythripk: you are miles ahead of me on the topic - I'll let you run with it. [14:05] robclark:hmm , i could add that but problem is there could be duplicates and problem with number of entries.. [14:05] becaue the 8 timing blocks timing data and the SVD block preferred timing data will overlap [14:06] and for DVI the standard timing data also should be populated... [14:09] mythripk: probably most important is the # of distinct resolutions.. if you have multiple supported timings that are same resolution, maybe it doesn't matter so much which you pick [14:10] the use case is just letting userspace pick from available supported resolutions [14:11] hmm ok then let me create a list and if the timing is valid , i shall populate all the values onto it... [14:12] mythripk: I guess it shouldn't hurt, tho, if you populate the list with multiple timings that are same resolution.. I guess either way would work [14:14] robclark: yup not parsing for a duplicate , i shall populate if valid ... only thing i need to do is convert Short video descriptor to resolution string.. [14:15] mythripk: I think it is ok to be a list/array/iterator of struct omap_video_timings [14:18] ya but SVD info will only give CEA code so need to populate it into a timing [14:18] k then time to head for my bus , i shall send the edid.c by this friday or so... good day [14:18] mythripk: I think you just need to loop thru the table of all timings, and see if it matches anything that we support? [14:18] ok, c-ya later [14:20] yes ... all_timings[code] will do ... [14:22] lag, ogra@panda:~$ dmesg|grep -i under [14:22] [ 424.812652] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX [14:22] [73202.197601] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX [14:22] got it twice since yesterday it seems [14:22] That's the one! [14:28] ogra: Which bootloaders are we using? [14:28] ogra: I fixed this before by using the correct ones [14:28] lag, most recent linaro package [14:28] Do you have back log on here? [14:29] this channel you mean ? [14:29] sure [14:29] robclark> lag: do you have x-loader w/ DDR timings tweaks and 1gb support? [14:29] without that, I don't think DSS gets enough memory bandwidth to feed a 1920x1080 hdmi monitor.. [14:29] yes, we have that [14:30] x-loader is ours btw ... only u-boot comes from linaro [14:36] lag, http://irclogs.ubuntu.com/2010/09/14/#ubuntu-arm.html is also available, in case you ever need backscroll and nobody here has it. [14:39] persia: Bookmarked, thanks [14:39] lag, that's just today's: you might want to bookmark something further up in the hierarchy :) [14:39] persia: I did ;) [14:39] * lag is not just a pretty face :) [14:40] Is there a searchable version? [14:43] I don't know of one currently maintained, other than using site: restrictions in popular search engines. [15:02] mpoirier_: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_07//exports/OMAP35x_Graphics_SDK_setuplinux_3_01_00_07.bin [15:02] this is the original SDK "tarball" [15:02] heh [15:02] rsalveti: let me take a look. [15:02] with the latest version you can just wget it [15:02] but it's huge, let me send you just the kernel source [15:02] 500MB [15:03] this is just in case you want to check where I got them [15:03] rsalveti: is this about the GPled ? [15:03] mpoirier: https://code.edge.launchpad.net/~rsalveti/+junk/omap3-sgx [15:03] mpoirier: only the kernel part is gpl [15:04] mpoirier_: this is a package I created using m-a to test [15:04] using the same kernel sources, you can check my branch and see the GFX_Linux_KM directory [15:05] this is the directory they put the source of their kernel modules [15:05] what exactly are we doing ? [15:06] mpoirier_: the idea of getting this source is to support the powervr sgx acceleration [15:06] mpoirier_, adding a 3D driver [15:06] to have opengles support [15:06] ok, nice to know. [15:09] * persia idly wonders if the GPL module is extensible to also support other powervr sgx hardware [15:10] \ [15:12] for omap 4 it's probably a different code/module [15:12] but not sure, never saw it [15:14] mpoirier_: http://paste.ubuntu.com/493659/ [15:15] the build log, in case you need it [15:15] to check how I'm currently building [15:17] mpoirier_: rcn-ee also did some work on it, when integrating the sgx into his kernel, but adding at staging [15:17] http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.36-devel/files/head:/patches/sgx/ [15:17] at http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.36-devel/annotate/head:/patch.sh#L126 you can see what patches are applied [15:18] rsalveti: this is all very interesting. [15:18] I'll start roaming through this stuff... [15:19] mpoirier_: cool [15:19] cool [15:19] remember that this is just for omap 3 [15:20] indeed [15:35] -etoomanyogras [15:36] heh [15:36] still missing ogra_n900 :-) [15:51] ogra/rsalveti... the boot time for the 10.10 daily images is about 10 mins on ES2.0 panda's is that what you are seeing on your end? [15:52] jayabharath: for first boot (installer)? [15:52] or any other normal boot? [15:52] First boot [15:52] rsalveti: on first boot [15:52] * jayabharath thinks that it's trying to format SD card or something [15:52] take a few to get up and running [15:52] hm, the very first boot is the sd resizing [15:53] it shouldn't take that long [15:53] but it depends on your sd card size, I believe [15:53] and the sd card speed [15:53] 4GB is what we are using... [15:53] 4gb class 4 should take 2, 3 minutes [15:53] at least this is what I get here [15:53] GrueMaster: did you tested latest omap 4 image already? [15:54] rsalveti: do you get errors sometime when booting? [15:55] orbarron|nb: no errors, just resize the sd card, reboot, oem-installer (around 10 min) and then the usual netbook interface [15:55] Just downloading todays. Yesterdays worked fine. [15:55] the only messages I'm getting is regarding sound [15:55] hmm [15:55] there's a bug that sometimes the first boot identifies a broken partition [15:55] broken filesystem [15:55] ok [15:57] * orbarron|nb downloads today's image [15:57] rsalveti: can you point me to the bug# [15:57] looking for it [15:59] hm, it sees that's a different issue, and with a quite old image: bug 613591 [15:59] Launchpad bug 613591 in jasper-initramfs (Ubuntu) "Jasper sometimes fails to resize root partition on omap4 (affects: 1) (heat: 104)" [Undecided,New] https://launchpad.net/bugs/613591 [16:00] * rsalveti also downloading latest image to test [16:00] thanks ubot2/ rsalveti [16:04] argh, getting a lot of smsc95xx 1-2.1:1.0: usb0: kevent 2 may have been dropped at my xM [16:20] sebjan: ASoC [16:21] lag: ASoC ? [16:22] sebjan: ASoC [16:22] :) [16:22] "asoc: no valid backend routes for PCM: SDP4430 Media" [16:23] lag: did you try to use the config files I sent earlier today? [16:24] Nope [16:24] Where do they need to go? [16:24] Oh, I've just seen what you've written [16:24] Give me a second [16:27] sebjan: Still nothing [16:27] But I am using the 6 layer board? [16:28] lag: I did not test myself with 6 layers but I have heard of issues with it. I tested on 8 layers. [16:29] Who knows more about these issues? [16:33] orbarron|nb: resize went very fast, one minute or so [16:33] 4gb class 4 [16:35] sebjan: How did you test? Application/file type? [16:36] lag: do you have access to a 8 layers? [16:36] sebjan: Unfortunately not [16:37] lag: you may ask on #pandaboard if some hw differences could explain a difference... [16:38] sebjan: Done [16:39] ogra: Can you make me a member of Ubuntu armel porters? [16:39] lag, done [16:40] ta [16:52] E: genext2fs: not enough memory for filesystem ??? [16:53] how much memory does this thing actually need? [16:54] Neko, exactly the size of the desired filesystem size [16:54] like real memory? [16:54] yes [16:54] holy crap [16:54] well, you can add swap [16:54] but that will be very very slow [16:55] i'D recommend not using the --no-root option unless you need to [16:55] ouch, that's crazy! [16:55] then it will just use a loop mounted image [16:55] mopdenacker, it is [16:55] but thats the way genext2fs is designed [16:55] my concern is that my /tmp is tiny [16:55] it allocates the whole image size in ram before copying contents [16:56] I thought rootstock respected TMPDIR but it always makes the image in /tmp [16:57] Could they do an mmap() on the output file instead of allocating RAM? This should be equivalent... [16:58] I'm just gonna hack this so BUILDDIR has a template... [16:58] mopdenacker, well, that no-root "feature" was only added for corner cases where people build on a big server but have no root access [16:58] Thought they may not know how big the output is gonna be... [16:58] the size is a parameter genext2fs expects [16:58] so it knows [16:59] its just very old software written at a time where you wouldnt have had the idea to roll gigabyte big images [17:00] Neko, file a bug, that it should use TMPDIR [17:00] I thought this was already a bug [17:00] 532342 [17:00] bug 532342# [17:00] Launchpad bug 532342 in rootstock (Ubuntu) "rootstock-gtk does not allow to specify the target rootfs tarball file path (affects: 1) (heat: 19)" [Medium,Fix released] https://launchpad.net/bugs/532342 [17:00] rootstock-gtk [17:00] hmm [17:00] my mistake but it's the same idea :D [17:01] well, rootstock-gtk surely respects it [17:01] the gui doesn't have enough options for me :/ [17:01] for a start, it doesn't have maverick in the distros list :D [17:01] else it wouldnt be fix-released [17:01] but please file a bug for the cmd [17:01] or reopen it :-) [17:02] well, its fixed in the gui [17:02] okay it will have to wait until I have actually done what I wanted to do with it but I have a post-it note reminding me now [17:02] i dont get how i fixed it there without fixing it in the cli though [17:04] * rsalveti lunch [17:05] just need to change it to BUILDDIR=$(mktemp -d ${TMPDIR}/tmp.XXXXXXXX) or so right? [17:05] that's working here [17:05] erm, no [17:05] mktemp will use TPMDIR by default [17:06] maybe mktemp doesn't do local shell variables? [17:06] I have to really export it or something? [17:06] ah, there is the bug :P [17:06] -t interpret TEMPLATE as a single file name component, relative to a directory: $TMPDIR, if set [17:06] man mktemp [17:06] just add -t [17:07] mktemp -d -t ? [17:07] yep [17:07] do I still need to file a bug? :D [17:07] and file a bug so we dont forget to add it to the code [17:07] doing it now [17:09] Neko: bug and/or a patch [17:09] :-) [17:09] relly strange ... looking at #linaro i really dont get how they have so many probs with omap3 [17:10] uhhhh mktemp -d -t did not fix it [17:10] it still made one in /tmp [17:11] how did you set TMPDIR ? [17:11] TMPDIR="/build/rootstock/tmp" [17:11] then I run rootstock in the next line of the script [17:12] should I be putting it in front of the script? I'm not entirely sure how or why bash mangles these things.. [17:12] yep that fixed it [17:13] TMPDIR=whereveer rootstock blah blah blah works [17:13] TMPDIR=whatplace [17:13] rootstock blah blah does not :D [17:13] it's funny because when you bash -ex it, the output is identical [17:14] bug 638190# [17:14] Launchpad bug 638190 in rootstock (Ubuntu) "rootstock cmdline does not respect TMPDIR (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/638190 [17:16] ogra, what are all these omap3 probs they have? D [17:16] oh shit I have a ubquity bug as well [17:16] Neko, you ned to export TMPDIR if you dont use it on the same line [17:17] simple shell rule ;) [17:17] guys did you notice that when oem-config creates a user it does not put it in the audio group? [17:17] from the installer (or rootstock even it seems) you get audio, but as soon as you oem-config in a new user, that guy gets no boot sound [17:17] there is no audio group in ubuntu [17:18] since ... like ... three releases or so [17:18] its all handled via policykit and pulse [17:19] I just had to fix it in my first maverick rootfs.. users and groups advanced, add to the audio group? [17:20] if rootstock added users to the sudio group in lucid thats definitely a bug [17:20] (none we'll fix now though :) ) [17:20] *audio group [17:22] maybe I am just overthinking it and mistaking the karmic demo image with the one I am working on :/ [17:22] I did think it weird that the sd card from fsl did not have a user with rights to audio [17:23] but my first xfce on maverick.. no audio.. ohhh I remember.. [17:23] somehow it had no audio devices [17:23] same symptom different problem [17:23] ah, you have one of the babbage boards with the preinstalled SD card images they hacked together ? [17:23]