[00:22] rsalveti: Where is this script for omap4 audio? [00:22] It isn't in bug 628217. [00:22] Launchpad bug 628217 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "No audio output from analog ports on panda (omap4) (affects: 1) (heat: 252)" [High,Confirmed] https://launchpad.net/bugs/628217 [00:23] GrueMaster: amixer.sh? [00:24] I guess. I keep hearing about a script to make audio work on the panda analog ports. [00:24] if rsalveti doesn't beat me to it, I'll fwd in a couple min [00:30] GrueMaster: http://paste.ubuntu.com/498061/ [00:30] run amixer.sh -a [00:32] thanks. [00:33] np [00:33] evening everyone [00:38] robclark: Still no audio. Ran sudo sh amixer.sh -a. Rebooted. Now nothing shows up in gnome volume control. [00:39] am I missing a driver? [00:39] GrueMaster: oh, ok.. maybe still the updated default.pa is needed? [00:39] hang on.. [00:39] This is a base image [00:40] GrueMaster: http://paste.ubuntu.com/498064/ is /etc/pulse/default.pa.. and one more coming [00:41] GrueMaster: http://paste.ubuntu.com/498068/ is daemon.conf [00:42] Ok. Will test then add these to the bug report. [00:42] there is some TI package, I think, that configures everything.. [00:42] and still I think open point about how to do it without overwriting system files.. but that is a known issue I suppose [00:43] Well, having these attached to the bug report will give the respective developers something to work with. [00:43] yup [00:47] audio problems too? [00:47] lol [00:47] they are comming [00:47] Evening GrueMaster :D [00:47] hello, and welcome back. [00:48] there is lot of ongoing work for ASoC.. which is making audio a bit painful right now [00:48] but should make things better for the future [00:49] yea, I've seen a flood of traffic on alsa-devel mailing list. [00:50] well, i see that i have some serious bugs on the audio setup on igepv2 [00:50] but seems to be the same problem with the beagle [00:53] rlameiro: On beagle, there are a few steps you can take in alsamixer to get audio working. Mainly unmute DAC2 Analog, HeadsetL Mixer AudioL2 and HeadsetR Mixer AudioR2, and increase volume for Headset and DAC2 Analog. [00:53] i did that on my igep [00:54] Does "speaker-test -c 2 -t wav" produce audio with those settings? [00:54] but even like that, the driver seems very buggy, as it cant handle big "WORKLOAD" [00:55] GrueMaster: never tried it out with those settings but it should [00:55] my problem is runnig puredata on it === DanaG1 is now known as DanaG [01:07] GrueMaster, robclark: the daemon.conf changes should not be needed. default.pa is (unless either we find a way to recognise the chip for berco's conf fragment, or the kernel gets fixed) [01:07] ahh, ok [01:26] Hrm. Actually, might be able to do something with udev. [01:26] * persia reads more docs === bjf is now known as bjf[afk] [01:50] Gah. death by alsa. After copying the default.pa and running the amixer.sh script, I am now getting kernel segfaults in alsa. [01:55] \o/ [01:55] * GrueMaster bangs head in silence. [01:55] So it's obviously a kernel bug. The kernel isn't supposed to segfault, regardless of what we do with userspace :) [01:56] I know. [01:56] Bug 644828 [01:56] Launchpad bug 644828 in linux-ti-omap4 (Ubuntu) "BUG: scheduling while atomic: alsa-source/2058/0x00000002 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/644828 [01:57] I think we are going to continue seeing these atomic issues in SOC systems until Cortex A9 is out in force and developers can fix their code. [01:57] Until now, no SOC was multicore, and some of the SOC specific code got a little free with the atomic stuff. [01:59] It's kind of the same growing pains that plagued x86 before SMP code was completed, just not as severe due to the lack of specific devices. [02:31] persia: I can verify that with the changes to default.pa and running amixer.sh from ti, I can now playback music in rhythmbox on panda. Not bad. [02:32] amixer.sh makes up for the fact that 1) the kernel doesn't actually know what to do with it and 2) doesn't even provide enough information to userspace to use a userspace config file. [02:33] default.pa is because 1) the kernel doesn't actually know what to do with it and 2) there currently exist no udev rules to explain (although this may be impacted by the same 2) as for amixer.sh: this remains to be determined) [02:34] Unfortunately, because of the 2) for amixer.sh, we are forced to fix this in the kernel somehow, as the userspace config trick won't work (unless we expect every single user to manually run amixer.sh) [02:35] pulse is differently complicated, but because of how udev works, it may be possible to have a special "panda-pulse-enable" package that handles that. [02:35] (and. absolutely worst cast, that hack package could run amixer.sh in postinst or something) [02:36] What I have found is that I have had to run amixer.sh after each reboot. [02:36] Even running it sudo doesn't save state properly. [02:37] Ugh. That's too painful for words. [02:37] Right. Kernel patch! [02:37] GrueMaster: I noticed same issue.. it used to work (saving settings on shutdown) with older internal fs that I had [02:37] but now I have to re-run script too :-( [02:39] well, it is after 6:30pm here. I could be doing this while drinking a beer. brb [02:58] Bother. Making pulse's module-udev-detect work requires properly poplating sysfs. [02:59] Could someone with a panda check /sys/class/sound/card.../pcmC...../pcm_class and tell me what it contains? [03:00] generic for all. [03:00] berco, /lib/udev/rules.d/78-sound-card.rules might be interesting to you (let's hope it isn't) [03:00] That's not helpful :( [03:01] Yeah, I think we just don't have enough information in userspace to detect that we want to do special stuff right now :( [03:03] Anything else I can do for you tonight? If not I'm calling it a day. 12 hours is enough. [03:03] persia: http://paste.ubuntu.com/498132/ [03:03] GrueMaster, Have a good night. [03:04] robclark, Yep. That just doesn't give us the information we want to be able to automatically populate something equivalent to http://paste.ubuntu.com/498064/ [03:05] specifically the "load-module module-alsa-{sink,source} device=..." lines [03:15] hi all, i have IGEP board unfortunately i saved wrong uboot parameter on it,now i am not able to boot from flash,sdcard as well not getting prompt on minicom [03:17] You probably have to perform some sort of reset on uboot. Check the docs for your specific board for low-level recovery instructions. [03:18] For example, some boards allow you to hold down some special button to boot from an alternate bootloader [03:19] persia, thanks but this board doesnot have any type of button as input [03:19] there is no recovery mode inside flash [03:20] No idea then. If you can't boot anything, and have no input/output (serial or console), I'm not sure if we can help much. [03:21] I really think you'd do better with the IGEP distributors (although I may be mistaken, and there are other folk here who have similar boards) [03:21] persia,ok [03:24] ajay, it may require the use of a hardware debugger [03:24] jtag [03:25] davidm, i have onle serial port console that is minuicm [03:25] minicom [03:26] ajay, if your board is: http://www.igep-platform.com/index.php?option=com_content&view=article&id=46&Itemid=55 [03:26] Then it has holes for a JTAG connector and that with special instructions will allow you to reflash the boot system [03:28] will IGEP boot off of MMC before NAND? [03:28] (or are there some DIP switch or jumpers to make that so) [03:28] robbiew, yes it tryies to boot from mmc first [03:28] then flash [03:29] then you should be able to put a good bootloader on an MMC card and recover that way [03:30] i did that as well for this i am getting white screen in LCD and no message over minicom [03:31] hmm, is that different behavior than booting without MMC card? [03:31] if so, then you know MMC comes first.. [03:32] then it is "just" a matter of getting a correctly formatted MMC card with good MLO and u-boot.bin.. [03:32] (there are scripts floating around to correctly format the MMC card under linux..) === Termana_ is now known as Termana === amitk-afk is now known as amitk [07:58] have you had a similar problem? http://paste.ubuntu.com/498254/ [08:07] I haven't seen that reported previously. [08:07] Please file a bug against qemu-kvm-extras-static (assuming you generated that on an Ubuntu system) [08:15] yes I've generated that using rootstock [08:22] Was that error produced as part of a rootstock build? === hrw|gone is now known as hrw [08:31] morning === kmargar is now known as markos_ [09:22] dmart_, fyi http://forums.computers.toshiba-europe.com/forums/thread.jspa?threadID=56355&start=30&tstart=0 [09:22] dmart_, so general bootloader access is there it seems, but nobody figured out the details [09:22] hi ogra [09:25] I'm always working with the boot process... I'm very frustrated with the new upstart mechanism (only few times all works fine, other times no: http://paste.ubuntu.com/498292/). [09:26] I don't think upstart is your issue there. [09:26] with this asyncronous method seems that some daemons wait something else but I don't understand when and what [09:27] persia... I think so, because some times all the boot process goes ok, sometimes no [09:28] and the problem is always similar to the one I reported in the pastebin [09:32] when the problem occurrs, all devices in /dev have a wrong datetime (01-01-1970) and ownership (root:root) [09:32] thats with ubuntu kernel ? [09:33] and does your system have an rtc battery and/or a network connection ? [09:34] the rtc is taken from another processor (a secure processor) [09:34] so it's good [09:35] the problem seems related to the devices generated by udev during the the initrd and the devices in the real filesystem [09:35] but I'm using the same initrd of the ubuntu [09:40] http://paste.ubuntu.com/498300/ [09:40] it seems that udev fails to be killed in the initrd?? [09:43] udev is supposed to be carried over from initrd, how did you generate the initrd assuming you use a different kernel [09:43] also do your kernel config options match with the ubuntu ones [09:44] if your devices are all tagged 1970 then your rtc part in the kernel that sets it on kernel bringup doesnt work (default in ubuntu) [09:45] I copied the initrd from the rootstock using this kernel: http://rcn-ee.net/deb/lucid/v2.6.35.4-l4/linux-image-2.6.35.4-l4_1.0lucid_armel.deb [09:45] ubuntu sets the rtc dircetly at unpackaing the kernel, if that doesnt work it falls back to ntpdate ... if *that* doesnt work you can still use the fixrtc cmdline option that sets the clock to last mount time of the disk [09:46] you should recreate the initrd if you use a different kernel [09:46] but I don't use any modules... [09:46] so the initrd should be the same except that [09:46] * ogra wonders why people always assume initrd is only for using modules [09:47] i heard that three times this week [09:47] I have read all scripts inside the initrd [09:47] it wont break but will gain you unexpected results [09:47] ogra, leftovers from embedded development models [09:47] and they should work with my configuration [09:47] like for example udev misbehaving with broken RTC :) [09:48] what HW is that exactly ? [09:48] furibondox, The key bit is not the scripts *in* the initrd, but rather the scripts used to genreate the scripts in the initrd which hardcode certain things depending on the kernel. [09:48] a standard beagle ? [09:49] no [09:49] it's not a standard beagleboard [09:49] it's a custom board [09:49] with omap 3530 [09:49] but you are trying to use a kernel that was compilde from a beagleboard defconfig ? [09:49] no [09:49] we use our kernel [09:49] well, the above one surely is [09:49] rcn-ee kernels are all beagle kernels afaik [09:50] I've only used the kernel I said you above in order to generate the initrd with the rootstock [09:50] ah [09:50] only for that [09:50] how much ram do you have on your board ? [09:50] 256MB [09:50] the plymouth error is likely the ureadahead OOM [09:50] yeah, that would fit [09:51] currently uredahead needs more than 256M else it will OOM and tear down plymouth with it [09:51] (you should actually see OOM messages for both in dmesg) [09:52] yesterday i tried also to disable ureadahead and plymounth but the problems remained [09:52] hi, while booting omap4 sdp i am getting this error .."init: ureadahead main process (487) terminated with status 5" ... any idea what status 5 suggests ?? [09:52] you cant disable plamouth [09:52] ogra: yes I saw ;-) [09:52] avinashhm, that you are using an SD card which it cant sacn [09:53] avinashhm, or any other flash device [09:53] avinashhm, that message is fine, its only info, not an error [09:54] ogra, its not related to network ... ?? it hangs after this .. i do nt get the prompt .... [09:54] furibondox, try removing ureadahead [09:54] ok [09:54] I have removed all nw options from make menuconfig ... [09:54] furibondox, which prompt on which console ? [09:55] just disable in the /etc/init/ureadahead or aptitude purge ureadahead ? [09:55] i.e. if you expect something on serial, did you make sure serial was enabled during rootstock with the --serial option ? [09:55] apt-get purgs [09:55] *purge [09:55] ok [09:55] (why do people always use aptiture is beyond me) [09:55] yes I use --serial ttyS2 [09:56] k [09:56] and thats also the console you are looking at ? [09:57] yes [09:57] ogra: Hi! For a BB xM with possible memory corruptions issues, is "mem=256M" a reliable workaround? [09:57] again... my kernel command line is this: rw console=ttyS2,115200e8 vram=5M omapfb.vram=2560K,2560K root=/dev/mtdblock7 rootfstype=yaffs2 lcdType=QVGA mpurate=600 omap_vout.vid1_static_vrfb_alloc=y mem=227M [09:57] alf_, yes, according to some testers [09:58] * ogra never had these RAM probs on his XM so i cant tell for sure [09:58] ogra: Great, thanks. Hopefully this will make my BB xM experience more deterministic :) [09:58] heh [09:59] i think ricardo uses that option on his XM too [09:59] ok now (w/o ureadahead) I've only this error in the boot.log [09:59] init: procps main process (3090) terminated with status 139 [10:00] thats an issue with your kernel config [10:01] yes, I'm investigate on this... [10:02] * ogra recommends pulling the ubuntu kernel deb and looking at the config file inside [10:03] enabling devtmpfs is also helpful [10:03] and there are a good bunch of other options i guess [10:04] ogra, the next statement after the "init: ureadahead main process (487) terminated with status 5" is "Last login: " ... does this need any n/w support ?? [10:04] "Last login: " ?? [10:05] that looks like you have some kind of autologin going on [10:05] its tells ... Last login time ... and other things right ?? [10:05] that line comes from motd iirc [10:05] yeah ... ubuntu @ ubuntu is logged by default ... [10:06] n/w = network ? [10:06] yeah ... network ... :-) .. sorry for confusion. [10:07] network is only needed if you dont have an rtc battery or dont use the fixrtc cmdline option ... to avoid fsck on boot if your last mount time is worng [10:07] but apparently you dont get an fsck so it all seems fine to me [10:09] i am on AC supply ... so no rtc battery ... and i don't have fixrtc in my bootargs .. may be this is causing the erro r ... [10:09] which error ? [10:09] * ogra doesnt see an error in any of your questions above [10:09] not error .. the hang .... it hangs after the print "init: ureadahead main process (487) terminated with status 5" ... [10:10] i thought it gives you an autologin [10:10] yeah ... it give autologon normally ...but when i disable network in menuconfig, it hangs [10:11] do you disable the NIC or all network support ? [10:11] indeed, as any linux system ubuntu needs a loopback device [10:11] so you should have basic networking enabled [10:12] Networking support ---> Networking options ---> TCP/IP networking .... whats NIC ?? and loopback ??? [10:12] ugh, why do you play with these options if you dont know what you do ? [10:13] NIC = network interface card [10:13] (your network card driver) [10:13] and loopback is the lo interface lostening for localhost connections on the virtual 127.0.0.1 address [10:13] *listening [10:14] there are some stability issues ... like system crashes @ rt_worker_func once in an hour or 2 ... so this funciton was tracked to some network file ... route.c ... so we wanted to disalbe that ... [10:14] some apps expect loopback networking to be available to properly run [10:15] ogra, so no way to boot ubuntu, with network disabled ??? [10:15] well, i dont know [10:15] but i know that some apps look for loopback [10:15] X wont start without it iirc [10:16] not sure about the low level, we never disable TCP/IP in ubuntu kernels [10:16] so i cant really tell what would happen then :) [10:17] thanks for hlep ogra ... :) ...let me give some more time on this ... and see what happens ..:-) [10:17] heh, ok === amitk is now known as amitk-afk === dmart_ is now known as dmart [12:30] persia, did you work with dyfet on the hdf issues ? where is that at ? [12:32] dyfet: ping? [12:33] * dmart guesses it may still be too early === amitk-afk is now known as amitk [12:34] or to late (in care of persia) [12:34] *case [12:34] dmart, btw, did you see my ping this morning ? [12:35] ogra: hmm, guess not. [12:35] dmart, http://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=218590𵗞 someone found access to the bootloader on the toshiba [12:35] ogra: (very faintly) pong [12:35] heh [12:35] ooo [12:35] so it seems to be just a matter of time now :) [12:36] * ogra already bricked one, so i'm waiting for others to do the hard work until someone figures out how to change the boot options [12:36] ogra, A little, but doko just -marm'd it, which makes the issue not visible. I believe dyfet was working on a test case for the underlying toolchain bug exposed in h5detect. [12:37] dmart, ^^^ [12:37] dmart, If you want to investigate, remove -marm, rebuild, and then look at the detection macros in h5detect. [12:37] persia, there was discussion about bug #635199 in #linaro (why are you not in there ? :) ) [12:37] Launchpad bug 635199 in hdf5 (Ubuntu) (and 1 other project) "[armel] the ./H5detect test segfaults when built for armv7 (affects: 1) (heat: 315)" [High,Confirmed] https://launchpad.net/bugs/635199 [12:37] The code does some things that end up being very ugly for any architecture that can handle more than one instruction set :) [12:38] * persia doesn't currently have attention to contribute to linaro [12:38] we have a team wide agreement [12:38] that everyone will be in both channels [12:38] persia: well, it's ubuntu too :) [12:39] Yao Qi's comment is correct, and matches what dyfet was telling me. [12:40] I should have some spare attention soon, and will be there more :) [12:45] Hmmm, the .diff.gz is almost twice as big as .orig.tar.gz for hdf5 :O [12:45] that's a bit scary [12:46] persia: yes, it doesn't look like a toolchain issue [12:47] I'm also wondering whether the kernel does something wrong with respect to alignment fixups. [12:47] (in addition to reporting them as SIGILL...) [12:47] That's a deeper question than I can answer: best wait for dyfet. [12:48] sure [12:48] no problem [12:48] h5detect is a good way to exercise alignment issues though :) [12:48] :) [12:49] wow software-center is really a myth [12:50] i wonder if the design team is aware that they overengineerd a bit here :) [12:50] how do you mean [12:50] more than less /var/lib/apt/lists/*Packages ? [12:50] well, i'm just testing a few things in it [12:51] and i dont find it very intuitive [12:51] i.e. trying to install all of OO.o i indeed click on the metapackage [12:51] which only gets me an "update now" button (that in the backend seems to run apt-get update) [12:52] you actually have to click on something like "openoffice writer" and then select the metapackage under "addon packages" [12:52] hmmm, that sounds weird... surely installing the metapackage that ought to suck in everything? [12:52] yes, it does, but only if you pick one of the sublevel packages and check a box [12:53] hmmm [12:54] I would have thought "install it all" would be a sensible default for inexperienced users [12:54] heh, yeah [12:54] i'm probably to experienced to understand it though [12:54] who knows :) [12:54] * dmart shrugs [12:55] ah, seems to actually be a bug :) [12:55] phew [13:20] ogra: hi! we finally found a problem in the u-boot currently beeing used (we were searching into MLO, but the issue was u-boot). Basically, u-boot overrides the pin-mux settings done in MLO, and miss some recent pin-mux updates. Who shall I speak to for defining the best way to fix this issue and get it integrated? sakoman? [13:23] sebjan, 1st a bug against u-boot-linaro 2nd yes, sakoman and 3rd we need to talk to slangasek and jcrigby to include the fixes in the package [13:35] ok, thanks [13:36] sakoman: we have this issue with the linaro u-boot used on omap4: bug 645167 [13:36] Launchpad bug 645167 in u-boot-linaro "omap4: u-boot overrides pin-muxing settings from x-loader (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/645167 [13:39] eek [13:40] you filed it in the upstream project :) [13:41] * ogra triages properly [13:44] that's ok [13:44] as long as it indeed affects the git repo :-) [13:46] lool, well, both, git and the package :) [13:46] i do care more about the package in maverick though :) [13:52] ogra: hi... any chance we could upgrade systemtap to 1.3 for 10.10 or this is way too late? it's in universe. [13:53] lool: ^^^^ [13:53] ndec, what does maverick have atm ? [13:53] we can surely try [13:53] ogra: 1.2 [13:53] * ogra hopes 1.3 is in debian [13:54] it gets tricky if it isnt, should be easy if it is [13:54] ogra: the 1.3 release notes mention they add support for .35, 1.2 is supposed to work up to .34... i am surprised that was not catched since 10.10 is on .35 [13:54] ndec: Given that systemtap is not seeded, it would seem possible [13:55] ndec: We could take it from Debian experimental [13:55] ndec: Did you try the 1.3 as packaged? [13:55] ndec: if you could copy the 1.3 source into some non-virtual PPA and confirm the source built under maverick produces working binaries, that would help [13:55] lool, oh, it is in experimental ? awesome [13:56] lool: no... we just realized that 1.2 does not work on omap4 with .35. right now I am still unsure if it's because of systemtap of because of our scripts. [13:56] that makes it easy [13:56] ndec: Would be nice if you could track this in a bug and report results of your testing of 1.3 as packaged [13:57] ++ [13:57] lool: ok. will open a bug, and we will do testing today or tomorrow ... so it's still possible to get something in 10.10... wouah.. I thought it was too late. [14:02] ndec: TBH new upstream releases are not the kind of things we're looking for at this point of time, but if you say systemtap is unusable with maverick kernels, it's a good reason to include it; <201009171327.17913.ubuntu@kitterman.com> has the detailed timeline for universe packages not on any media [14:27] ndec, i would have set the bug to critical, but then i end up in discussions with lool again about bug status :) "high"+milestone means its very important to have it fixed befoire release, critical would mean it affects everyone using ubuntu (which is not true) [14:28] mpoirier, yo [14:28] ogra: wazup ! [14:28] mpoirier, seems there is another bug with the IEGP2 that affects networking [14:28] mpoirier: hi... did you get your new wild animal? [14:29] and it seems to be fixed already for linaro's kernel [14:29] ndec: yes, thaming it right now. [14:29] just saw the bug [14:29] mpoirier, and it seems linaro has a fix for it ... but i have no idea how it would affect other omap3 arches ... see bug 618734 [14:29] Launchpad bug 618734 in linux-linaro (Ubuntu Maverick) (and 2 other projects) "[omap/igep] No eth0 with Linaro kernel (affects: 1) (heat: 106)" [High,Fix released] https://launchpad.net/bugs/618734 [14:29] ogra: hold on. [14:29] (i guess the main question here is why doesnt it work as a module though) [14:35] ogra: yep, doesn't sound like a correct fix for me [14:35] ++ [14:35] but seems to be a workaround if it doesnt affect other oamp3 subarches [14:35] yup [14:35] and i'm not sure about the latter [14:36] ogra: do we have one igepv2 around in our team? [14:36] nope, only linaro has them [14:36] seems lool has one [14:36] got it [14:36] right and some other folks in the linaro team [14:38] jo-erlend: maybe you could also help us testing this issue [14:38] jo-erlend: you said at the other bug that you don't have your eth0 working [14:39] rsalveti, right. I have both wlan and wired on my board, but none of them is working. [14:39] for wireless the cause is probably missing firmware [14:40] for wired it seems that a workaround is to move the config to built-in [14:40] still need to understand why this fixed the issue [14:40] what does that mean? [14:41] ogra: sorry for the delay - took me a while to find a wrothy tree. [14:41] ogra: It may help with some arch but affect others. [14:41] yeah, thats what i feared [14:42] ogra: I'd like to have an explanation for what the real effect of turning off CONFIG_FIXED_PHY has. [14:42] ogra: i.e, why it's fixing the problem on some arch and not others. [14:42] ask on the bug, i just stumbled over the fix in linaro (well, lool pointed me to it) [14:43] ogra: looks like a work around to me. [14:43] after i had seen the request in the other bug you filed a merge request for [14:43] rsalveti, "move the config to built-in"? [14:43] yes, its surely just a workaround [14:44] jo-erlend: currently the kernel is generating a module for your ethernet adapter [14:44] the workaround is to move to built-in [14:44] I have good news - armel cross compiler 4.5 landed in ubuntu (gcc-4.4 is on a way) [14:44] hey you didnt post that to #ubuntu-motu (but in every other dev channel) [14:45] rsalveti, ok.. I have no idea how to do that though. :) [14:45] ogra: I am not on ubuntu-motu [14:45] 'd [14:45] but all universe developers are [14:45] ;) [14:46] jo-erlend: it's easy, we're just discussing if we're able to have this change to our kernel [14:46] but first we need to understand why it's needed [14:47] oh, ok. Can you tell me how to do it? :) [14:48] jo-erlend: you'll need to recompile the kernel, not that hard to do it, but takes a while [14:48] especially on omap3 [14:48] if you want, I can easily generate a new uImage for you [14:49] rsalveti, that'd be nice. Thanks. [14:49] based on the kernel package I sent you [14:49] perfect. [14:49] ndec, lol, you commented on the wrong bug :) [14:49] * ogra was wondering which steve you are talking to in the systemtap bug [15:00] ogra, sebjan: I will prepare a u-boot patch for the panda pinmux corrections === bjf[afk] is now known as bjf [15:00] sakoman, yeah, i saw the bug comment, thanks a loit [15:00] *lot [15:00] sakoman: thanks! [15:00] I was told that omap4 wasn't a priority, so I've kept all omap4 stuff on the back burner [15:01] huh ? [15:01] morning/afternoon/evening all [15:01] its our highes prio in ubuntu [15:01] really? [15:01] *highest [15:01] ogra: from a linaro perpective [15:01] omap4 is the fuzz :D [15:01] we're not linaro here :) [15:01] <- ubuntu.arm [15:01] understood, but my direction comes from linaro ;-) [15:01] bah, we should also pay you then :P [15:02] haha :-) [15:02] works for me [15:02] ogra: patch is basically ready, but there is one pad I need to research a bit more [15:02] ok [15:03] the panda x-load sets a few pins more than once [15:03] and not the same each time :-) [15:03] we'll need to get it into the package too which will add some delay [15:03] so I need to look at the schematic and see if that is just a screwup or might be intentional [15:03] sakoman: cool, thanks for working on it :-) [15:03] ++ [15:04] yeah [15:04] you might notice that I have a few other omap patches in my omap4-dev branch [15:04] they are still being tested and may be tweaked a bit [15:04] useful for us ? [15:04] some of them [15:05] (if we need an upload anyway i would indeed like them in the package) [15:05] oh, and note that we use linaros u-boot in ubuntu :) [15:05] yep, to have all these new patches we would need it first to go to linaro's tree [15:06] then a new release and then a package update [15:06] I was just giving a "heads up" that new omap4 stuff was pending [15:06] ogra: can I remove a comment from launchpad... [15:06] sakoman: cool, will take a look at the tree :-) [15:06]