| rlameiro | ok | 00:00 |
|---|---|---|
| rlameiro | i will do that in a moment, girl needs atention... | 00:00 |
| persia | rlameiro, So you want to add to the massive case statement near where it says "OMAP3 Beagle Board" an entry for your machine, which calls check_subarch "omap" | 00:00 |
| persia | rcn-ee, That alone isn't enough: one should also add something around line 668 | 00:01 |
| rcn-ee | oh right... | 00:02 |
| rcn-ee | http://pastebin.com/JUD5ZQpJ ;) | 00:03 |
| GrueMaster | http://paste.ubuntu.com/498807/ | 00:05 |
| rcn-ee | i almost think for maverick +1 maybe the nand usage in that omap_flash_kernel could be dropped and just default to mmc? | 00:05 |
| GrueMaster | rcn-ee: Heh. Same idea. | 00:05 |
| persia | Either one. Now get someone to test it, and get it attached to a bug :) | 00:06 |
| rcn-ee | if rlameiro system is still up, he could manually patch it.. and then try running it. .;) | 00:06 |
| persia | rcn-ee, My personal preference is to boot from NAND, and have MMC available for secondary boots for testing, etc. Mind you, I use USB storage anyway. | 00:07 |
| rlameiro | rcn-ee: i came back | 00:07 |
| rcn-ee | yeah, it's nice for your own embedded systems, we got tons of rma's with incorrect nand on the beagles. ;) | 00:07 |
| rlameiro | going to open second ssh and edit it with nano | 00:07 |
| persia | rcn-ee, Oughtn't one be able to just boot off MMC and recreate NAND to work around that? | 00:08 |
| persia | rlameiro, Rather than using nano, could you use patch? | 00:08 |
| rlameiro | where do i found my partitions | 00:08 |
| rlameiro | persia: well i can try, but i am not experienced | 00:08 |
| persia | `cd /usr/sbin; sudo patch < /tmp/flash-kernel-patch;` | 00:08 |
| persia | Just download one of the patches before you do that. | 00:09 |
| rlameiro | so i edit a different version and then patch it? | 00:09 |
| rcn-ee | yeap... that's exactly how i fixed most of the returns and sent back to the customers. ;) | 00:09 |
| rlameiro | so only this patch? | 00:10 |
| persia | rlameiro, You shouldn't have to edit anything at all. | 00:10 |
| rlameiro | http://paste.ubuntu.com/498807/ | 00:10 |
| rcn-ee | yeap, that one is good.. | 00:10 |
| rlameiro | /usr/sbin/flash-kernel: 671: Syntax error: word unexpected (expecting ")") | 00:13 |
| GrueMaster | Oops. Add a | before \ on line 25 of patch. | 00:14 |
| rlameiro | missing a pipe lol | 00:14 |
| rcn-ee | actually 671, needs a space.. like; "OMAP3 Beagle Board" | "IGEP v2 board") | 00:14 |
| rcn-ee | btw, has anyone tried using rootstock on maverick x86 to build a maverick dist with any xfce4 based packages? it worked this afternoon for me, so maybe the old qemu bug has fixed it self? | 00:16 |
| rlameiro | why the "\"? its to tell that the line continues? | 00:16 |
| GrueMaster | yes. Makes it more readable. | 00:16 |
| rlameiro | so it stays "|\" or "| \" ? | 00:17 |
| GrueMaster | second option | 00:17 |
| GrueMaster | space is good. | 00:17 |
| rlameiro | Reversed (or previously applied) patch detected! Assume -R? [n] -R | 00:19 |
| rlameiro | Apply anyway? [n] y | 00:19 |
| rlameiro | Hunk #1 FAILED at 149. | 00:19 |
| rlameiro | Hunk #2 FAILED at 319. | 00:19 |
| rlameiro | Hunk #3 FAILED at 665. | 00:19 |
| rlameiro | 3 out of 3 hunks FAILED -- saving rejects to file flash-kernel.rej | 00:19 |
| rlameiro | do i need to make a diff? | 00:19 |
| GrueMaster | No. Did you try to edit the patch and apply it to a clean flash-kernel? | 00:19 |
| rlameiro | nope | 00:20 |
| rlameiro | to the alreday patched one | 00:20 |
| GrueMaster | Ok. edit the flash-kernel script directly. Fix line 670. | 00:20 |
| GrueMaster | You can only apply a patch once. | 00:21 |
| rlameiro | is there a way to revert a patch? | 00:21 |
| rcn-ee | -R (with same patch) | 00:22 |
| rlameiro | ok | 00:22 |
| GrueMaster | sudo patch -R < <patchfile> | 00:22 |
| rlameiro | U-Boot partition not found, using Nand. | 00:26 |
| rlameiro | The Kernel doesn't fit in flash. | 00:26 |
| rlameiro | so i need to add the partition to the file? | 00:26 |
| rcn-ee | assuming it's mmc add UBOOT_PART=/dev/mmcblk0p1 to /etc/flash-kernel.conf | 00:27 |
| GrueMaster | Yes. create /etc/flash-kernel.conf with two lines: | 00:27 |
| GrueMaster | UBOOT_PART=<partiotion for uImage & uInitrd> | 00:27 |
| GrueMaster | root=<root partition> | 00:27 |
| rcn-ee | GrueMaster, looking thru flash-kernel, what uses root=? | 00:28 |
| rcn-ee | or is the boot.scr creater script pulling that.. | 00:29 |
| GrueMaster | might be. | 00:29 |
| GrueMaster | It could also be a hold over. | 00:29 |
| rcn-ee | it's new in my book, that's why i wondering.. ;) | 00:30 |
| GrueMaster | flash-kernel is something I think was pulled from Debian. | 00:30 |
| rlameiro | so what do i put on the root? | 00:31 |
| rcn-ee | yeap i remember it well specially when it first came into lucid... (quit touching my flash..) | 00:31 |
| rlameiro | /dev/mmcblk0p2? | 00:31 |
| rcn-ee | yeah, that looks good.. | 00:31 |
| rlameiro | fingers cross | 00:32 |
| rlameiro | lol | 00:32 |
| rlameiro | same error | 00:32 |
| rlameiro | do i need to reboot? | 00:32 |
| rcn-ee | no... | 00:32 |
| rcn-ee | is it the same line? | 00:32 |
| rlameiro | where? on the flash-kernel.conf? | 00:32 |
| rlameiro | no separated files | 00:33 |
| rcn-ee | line 671/2 | 00:33 |
| rlameiro | rcn-ee: its like this | 00:35 |
| rlameiro | rcn-ee: i just made into one line and the output is the same | 00:37 |
| rcn-ee | i actually think it's line 671... make sure there is spaces: "OMAP3 Beagle Board" | "IGEP v2 board" | 00:37 |
| rlameiro | yes ther is | 00:38 |
| rlameiro | check this line | 00:38 |
| rlameiro | omap_flash_kernel() { | 00:39 |
| rlameiro | if [ -n "${UBOOT_PART}" ]; then | 00:39 |
| rlameiro | echo "Using u-boot partition: ${UBOOT_PART}" >&2 | 00:39 |
| rlameiro | do i need to pass it as an argument ? | 00:39 |
| rcn-ee | it pulls that from /etc/flash-kernel.conf | 00:39 |
| rlameiro | like flash-kernel -n /dev/mmcblk0p1? | 00:40 |
| rlameiro | where? i dont see where does it loads the variable | 00:40 |
| rcn-ee | flash-kernel runs ". /etc/flash-kernel.conf" the variable gets loaded... | 00:40 |
| rcn-ee | line 290/295 | 00:41 |
| rcn-ee | config="/etc/flash-kernel.conf" | 00:41 |
| rlameiro | lol | 00:42 |
| rlameiro | i was actually editing kernel-info.conmf | 00:42 |
| rlameiro | lol | 00:42 |
| rlameiro | kernel-img | 00:42 |
| rlameiro | yay | 00:43 |
| rlameiro | rcn-ee: so now reboot? | 00:44 |
| rcn-ee | maybe? did it print out everything okay, and is a new uImage in /boot/(mmc1) | 00:44 |
| rlameiro | well it booted | 00:47 |
| rlameiro | but now i dont have network | 00:47 |
| rlameiro | yep uname-a confirms | 00:48 |
| rcn-ee | those should have loaded.. i think ubuntu se them as built -in... | 00:48 |
| GrueMaster | Sorry, flash-kernel doesn't change that. | 00:48 |
| GrueMaster | :P | 00:48 |
| rlameiro | its the linaro kernel 2.6.35.1005-linaro-omap | 00:48 |
| rlameiro | GrueMaster: but the kernel does :D | 00:49 |
| rlameiro | cant do lspci also | 00:50 |
| GrueMaster | At any rate, if you can file a bug on launchpad.net against flash-kernel, I'll attach my (updated) patch and we can roll it in. | 00:50 |
| rcn-ee | found my notes.. the igepv2 needs the smsc911x as built-in... | 00:50 |
| rlameiro | o mannnnnn | 00:50 |
| rlameiro | so i need to reverse this? | 00:50 |
| GrueMaster | No. (not flash kernel at least). | 00:51 |
| rlameiro | yeah | 00:51 |
| rcn-ee | something about u-boot setting up the pins and ussing it, therefor it can't be used setup as a module? | 00:51 |
| rlameiro | but my kernell | 00:51 |
| GrueMaster | But if you file a bug on it, I can get my patch rolled into the package. | 00:51 |
| rcn-ee | rlameiro, you were using my kernel before right? | 00:51 |
| rlameiro | pcilib cannot open /proc/bus/pci | 00:51 |
| rlameiro | yes rcn-ee | 00:51 |
| rlameiro | GrueMaster: i would like to do so, no network on the device :D | 00:52 |
| rcn-ee | first check in your /mm1 there might bee a "uImage_old/bak" "uInitrd_old/bak" | 00:52 |
| rlameiro | rcn-ee: flash-kernel said it make a backup | 00:53 |
| GrueMaster | flash-kernel should have moved them to uI*.bak | 00:53 |
| rlameiro | i also made a backup before doing this :D | 00:53 |
| rcn-ee | 2nd you can bypass flash-kernel with adding "FLASH_KERNEL_SKIP=yes" to /etc/flash-kernel.conf (untill upstream has the kernel fix) | 00:53 |
| GrueMaster | Or alternatively, you can type "flash-kernel <kernel version>" (i.e. flash-kernel 2.6.35-22-omap) | 00:54 |
| rlameiro | what is the command to rename on the cli? | 00:55 |
| GrueMaster | That will move whatever test kernel you are using onto the uboot partition (as long as the kernel is installed in /boot). | 00:55 |
| rcn-ee | i just 'mv' to rename... | 00:55 |
| GrueMaster | Use mv <old> <new> | 00:55 |
| rlameiro | ok | 00:55 |
| rlameiro | i think it should be the other way around | 00:58 |
| rlameiro | it boot the same kernel | 00:58 |
| rlameiro | and maybe i lost the bak... | 00:58 |
| rcn-ee | if you did mv uImage uImage.bak you did.. | 00:58 |
| rcn-ee | does your wifi work? | 00:59 |
| rlameiro | no | 00:59 |
| rlameiro | i did first the back | 00:59 |
| rlameiro | but it actually asked something about permissions | 00:59 |
| rlameiro | i just press enter | 00:59 |
| rlameiro | my wifi doesnt work, i need to instal the libertas drivers | 00:59 |
| rlameiro | well, maybe using sudo mv helps... duh!!! | 01:01 |
| rlameiro | so GrueMaster i file the bug and you post the patch? | 01:02 |
| GrueMaster | Yes, please. | 01:03 |
| rlameiro | lp #645659 | 01:06 |
| ubot2 | Launchpad bug 645659 in flash-kernel (Ubuntu) "flash-kernel doesn't work with the IGEPv2 board (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645659 | 01:06 |
| rlameiro | do you need some of my files? | 01:07 |
| rlameiro | i can send them to you GrueMaster | 01:07 |
| rlameiro | dropbox :D | 01:07 |
| rcn-ee | "cat /proc/cpuinfo" should be enough.. | 01:07 |
| GrueMaster | Nope, this is enough. Now to work my magic. | 01:07 |
| GrueMaster | Yes, add /proc/cpuinfo to the comments. | 01:08 |
| GrueMaster | Then I can assign it to ogra. Might even attach the patch before he notices. :P | 01:09 |
| rlameiro | you should attach it | 01:10 |
| NCommander | persia: not if you cast up to double. I should have made that clear :-/ | 01:10 |
| rlameiro | GrueMaster: why wit for ogra ? | 01:11 |
| GrueMaster | testing the annoyance factor. Guess I'll play nice. :P | 01:11 |
| GrueMaster | Patch attached. If you could now comment that the patch was tested ok, we should be done here. | 01:12 |
| rlameiro | GrueMaster: the patch has an error | 01:14 |
| rlameiro | it misses 2 spaces around a "|" | 01:14 |
| GrueMaster | This is the fixed one. I tested it already. | 01:14 |
| rlameiro | case "$machine" in | 01:14 |
| rlameiro | -"OMAP3 Beagle Board") | 01:14 |
| rlameiro | +"OMAP3 Beagle Board"|"IGEP v2 board") | 01:14 |
| rlameiro | I changed it on mine | 01:15 |
| rlameiro | maybe they arent needed, it was rcn-ee idea | 01:15 |
| GrueMaster | Hmm. Will check. | 01:15 |
| persia | NCommander, In terms of code clarity, for all architectures, why would you want to do that? Isn't it cleaner to rely on system qreal to be as expected? | 01:15 |
| === bjf[afk] is now known as bjf | ||
| GrueMaster | rlameiro: Ok, fixed (again). | 01:17 |
| rlameiro | rcn-ee: so what is needed to put the kernel working with my hardware? | 01:17 |
| rlameiro | i cant debug some audio issues withou network | 01:17 |
| rlameiro | and i cant file bugs against the kernel/alsa against your kernel... | 01:18 |
| GrueMaster | persia: I have received a new XM board. It works and audio is currently in the same state as the beagle. | 01:18 |
| * rlameiro looks at a nice paradox.... | 01:18 | |
| rcn-ee | rlameiro, according to my notes, i had to move CONFIG_SMC911x=m to y and CONFIG_SMSC911X=m to y.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/revision/90 (and haven't changed that config since..) | 01:19 |
| rlameiro | GrueMaster: http://launchpadlibrarian.net/56291674/IGEP-add.patch | 01:19 |
| rlameiro | it appended the second patch to the other | 01:20 |
| GrueMaster | rlameiro: You can always file a bug using apport-cli --save=<PATH> and it will save the bug report to disk for transferring to another system. Then you can sneaker-net it to your desktop/laptop. | 01:20 |
| rlameiro | GrueMaster: not that, i want my ssh | 01:20 |
| rlameiro | and also test some configs with GUI over ssh -X | 01:20 |
| GrueMaster | grr. | 01:20 |
| rlameiro | no network, no gain | 01:20 |
| rlameiro | rcn-ee: so its dependent on the kernel team? | 01:22 |
| GrueMaster | keyboard issues. Accidently hit >> instead of > when creating the patch file. | 01:22 |
| GrueMaster | phat phingers. | 01:22 |
| rlameiro | hihi | 01:23 |
| rlameiro | fixed now | 01:23 |
| rlameiro | i checked it | 01:23 |
| GrueMaster | Well, prepare for a lot of lp-spam. Sorry about that. | 01:23 |
| rcn-ee | yeap, they'll need a bug, i'd ping lag or mpoirier to help get it pushed.. | 01:24 |
| rlameiro | its on a different mail :D | 01:24 |
| rlameiro | rcn-ee: so i need to file another bug? | 01:24 |
| rlameiro | lol | 01:24 |
| rcn-ee | yeap.. ;) that's why i have my external tree, i don't really wait for anyone.. | 01:25 |
| rlameiro | well, i guess i can do the flash-kernel, file the bug withh apport-cli and then reveret the kernel | 01:26 |
| persia | GrueMaster, Thanks for the confirmation, as unfortunate as the result is. | 01:27 |
| GrueMaster | persia: The only bit is the kernel tweaking for enabling the right channels. | 01:27 |
| rcn-ee | and one more board down.. ;) so who wants to do the devkit8000, it needs some dss2 fixes.. | 01:27 |
| GrueMaster | I mean unmuting. | 01:27 |
| persia | rlameiro, Which kernel are you using? Have you tried both linux-omap and linux-linaro-omap? | 01:27 |
| rlameiro | just linaro | 01:27 |
| rlameiro | should i try the not linaro one? | 01:28 |
| persia | GrueMaster, Should be easy. Up for writing a patch? :) | 01:28 |
| persia | rlameiro, Since there are two kernels that ought boot on your board, if you try both, you'll know if one works better than the other for you :) | 01:28 |
| GrueMaster | Not tonight. I have a headache. :P | 01:28 |
| GrueMaster | Is this a kernel patch for alsa? | 01:28 |
| persia | rcn-ee, In terms of moving from a module to a built-in, shouldn't udev be loading the modules at boot? I know there's an issue with some storage modules, but those aside. | 01:29 |
| persia | GrueMaster, Would be ASoC, but ends up passing through the ALSA tree. | 01:29 |
| rcn-ee | persia, i can't find the link... but i believe it has something to do with u-boot setting up and tieing to the device.. so once the kernel loads... well's it's kinda already setup... | 01:30 |
| GrueMaster | Hrm. will have to look at the code. | 01:30 |
| persia | rcn-ee, If you're pushing enough patches to the kernel, you could ask for commit access, rather than maintaining an external tree :p | 01:30 |
| persia | rcn-ee, Ah, Ugh. That's an annoying situation :( My concern is that we might not want it built-in for some omap kernels: can you think of a case where we might not need it? | 01:30 |
| rcn-ee | well right now only two little ones are mine, the rest are other beagle users and that big TI sgx thing which i don't have copyright. ;) | 01:31 |
| persia | Having copyright isn't important, if you have license to redistribute. If you don't have license to redistribute, please don't :) | 01:31 |
| rcn-ee | (and we are in the omap merge for 2.6.37 i'm submitting those tomorrow..) | 01:31 |
| rcn-ee | persia, well what i meant, they are GPL 2.. it's just they are TI's so there is no point in my pushing.. | 01:32 |
| persia | Depends on to where you push :) If you were trying to maintain a perfect Ubuntu kernel, you might find it useful to push to Ubuntu. For pushing to linux-omap proper, indeed, better to just encourage the authors to push there. | 01:33 |
| rcn-ee | well the important bits i do ping the ubuntu guys. ;) some of it is expermental and too risky for ubuntu.. (like dspbridge stuff that just went into 2.6.36) | 01:34 |
| rlameiro | persia`404 error W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.35-22-omap_2.6.35-22.32_armel.deb | 01:36 |
| rlameiro | 404 Not Found | 01:36 |
| rlameiro | cant test it | 01:36 |
| persia | http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.35-22-omap_2.6.35-22.33_armel.deb replaces it. | 01:40 |
| persia | Run apt-get update :p | 01:40 |
| rlameiro | well toolate | 01:43 |
| rlameiro | filing for the linaro one :D | 01:43 |
| rlameiro | how do i see the kernel PID? | 01:43 |
| persia | kernel doesn't have a PID. | 01:48 |
| rlameiro | even 0? | 01:48 |
| persia | PID 1 is init, which is usually upstart. | 01:49 |
| persia | I think 0 is undefined, but I don't really understand the specifics. | 01:49 |
| rlameiro | ok | 01:49 |
| rlameiro | always learning :D | 01:49 |
| persia | Yep :) | 01:51 |
| * GrueMaster heads out for a bit. | 01:54 | |
| rlameiro | rcn-ee: lp #645684 | 02:00 |
| ubot2 | Launchpad bug 645684 in linux-linaro (Ubuntu) "linux-linaro kernel, doesnt boot with support for the LAN interface (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645684 | 02:00 |
| rlameiro | another bug :D | 02:00 |
| rlameiro | looking now for the linux-omap one :D | 02:01 |
| rsalveti | rlameiro: this bug is a duplicate of 618734 | 02:18 |
| rsalveti | bug 618734 | 02:18 |
| ubot2 | Launchpad bug 618734 in linux-linaro (Ubuntu Maverick) (and 2 other projects) "[omap/igep] No eth0 with Linaro kernel (affects: 2) (dups: 1) (heat: 108)" [High,Fix released] https://launchpad.net/bugs/618734 | 02:18 |
| rsalveti | this should be fixed with latest linaro's kernel | 02:18 |
| rlameiro | ok, linux omap is going to have another | 02:19 |
| rlameiro | or should i not report this? | 02:19 |
| persia | rsalveti, Except rlameiro just tested with the latest linaro kernel, and it didn't work... | 02:21 |
| rsalveti | persia: not the latest | 02:21 |
| persia | rlameiro, Probably not worth having two bugs: you can mark that bug "Also affects" if you can reproduce in the other kernel. | 02:21 |
| persia | rsalveti, The "latest" isn't in the repos? | 02:21 |
| rsalveti | 2.6.35-1006.11 should be the latest, not 2.6.35-1005.10 | 02:21 |
| persia | rlameiro, Would you try .11 :) | 02:21 |
| rlameiro | well, maybe i should do an update before installing that | 02:22 |
| rlameiro | yes i will | 02:22 |
| rsalveti | well, the bug was closed by Launchpad Janitor, so I think the deb should be at our repo | 02:22 |
| rlameiro | but the last linux omap is not working either | 02:22 |
| rlameiro | and this I am sure is the last | 02:22 |
| rsalveti | rcn-ee: for me is weird that changing CONFIG_SMC911x=m to y and CONFIG_SMSC911X=m to y fixes the problem | 02:22 |
| rsalveti | it should work the same way as module and built-in | 02:22 |
| persia | Well, unless uboot does odd things. | 02:24 |
| rsalveti | probably a kernel bug | 02:24 |
| persia | But, yeah, the kernel has a bug, and ought be able to do bring-up whether u-boot did or not. | 02:24 |
| persia | Most certainly a kernel bug. | 02:24 |
| rlameiro | rcn-ee's kernel brings the interface up | 02:24 |
| rsalveti | because the config is set as built-in | 02:25 |
| persia | rlameiro, No it doesn't: it assumes it's up. | 02:25 |
| rsalveti | but I first wanted to understand it better before submitting a patch | 02:25 |
| persia | rsalveti, You're going to end up buying an IGEPv2 :) | 02:25 |
| rsalveti | persia: I'm just sending an email requesting one :-) | 02:26 |
| rlameiro | with linaro and linux-omap kernel, lspci brings up an error | 02:26 |
| rsalveti | and thanks for the flash-kernel patch :-) | 02:26 |
| rlameiro | i didnt made the patch :D | 02:28 |
| rlameiro | it was rcn-ee GrueMaster and persia | 02:28 |
| rlameiro | i just tested it realtime... almost | 02:28 |
| * persia didn't do it :p | 02:29 | |
| rlameiro | lp #645689 | 02:29 |
| ubot2 | Launchpad bug 645689 in linux (Ubuntu) "linux-omap cant bring up eth0 on igepv2 board, no network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645689 | 02:29 |
| rlameiro | well, no a break before testing the last linaro kernel | 02:30 |
| persia | OK. That should be a duplicate to 618734, which should have both limux-linaro and linux-omap tasks. | 02:30 |
| rlameiro | the kernel source is the same ? | 02:31 |
| rlameiro | mine has more info :D | 02:32 |
| rlameiro | rsalveti: sorry, but the latest version is linux-image-2.6.35-1005-linaro-omap | 02:35 |
| rlameiro | .10 not .11 | 02:35 |
| rsalveti | hm, that's weird, we should be able to find 2.6.35-1006.11 | 02:36 |
| rsalveti | let me find the sources from launchpad | 02:36 |
| rlameiro | the .11 is not supported by canonical | 02:36 |
| rlameiro | it is there, but not supported | 02:37 |
| rsalveti | 1006.11 | 02:37 |
| rlameiro | yeap | 02:37 |
| rlameiro | well, i will ty it anyway | 02:37 |
| rlameiro | try | 02:37 |
| persia | It's supported by Ubuntu, and by Linaro, so it ought be safe. | 02:37 |
| rsalveti | https://edge.launchpad.net/ubuntu/maverick/armel/linux-image-2.6.35-1006-linaro-omap/2.6.35-1006.12 | 02:38 |
| rlameiro | lol | 02:38 |
| persia | .12 already. heh | 02:38 |
| rlameiro | now it appears as supported | 02:38 |
| rsalveti | http://launchpadlibrarian.net/56232546/linux-image-2.6.35-1006-linaro-omap_2.6.35-1006.12_armel.deb | 02:38 |
| rlameiro | forget it... problably some synaptic stuff | 02:38 |
| rlameiro | yep | 02:38 |
| rlameiro | rsalveti: sorry about crapy feedback... synaptics deceived me.... | 02:40 |
| rlameiro | :( | 02:40 |
| persia | Take care with terminology :) | 02:40 |
| rlameiro | rsalveti: one thing i did found interestinf is the size of the images compared to the image of rcn-ee's kernel | 02:42 |
| rsalveti | config definitions | 02:42 |
| rlameiro | images from ubuntu where quite smaller | 02:42 |
| rlameiro | ok, it works on the new one | 02:47 |
| rlameiro | at least networking | 02:47 |
| rsalveti | cool | 02:47 |
| rsalveti | for display fixes they are still waiting the kernel team to review and apply | 02:48 |
| rlameiro | rsalveti: do i need to confirm its working? installing it from the repo? | 02:51 |
| rsalveti | rlameiro: if you want to test, I have a deb for you | 02:51 |
| rlameiro | i tested it :D | 02:52 |
| rlameiro | its working | 02:52 |
| rlameiro | network, didnt tried display, dont have hdmi tv here | 02:52 |
| rsalveti | http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-43_armel.deb should have the display fixes | 02:52 |
| rsalveti | http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v4 is this kernel with the config changes | 02:52 |
| rsalveti | so if you install my deb and use this uImage, you should be able to have network and display working | 02:53 |
| rlameiro | well, for now i dont need display | 02:53 |
| rsalveti | so you're fine already with linaro's kernel :-) | 02:53 |
| rlameiro | i dont have an WM so its ok for me, what i want is audio working :D | 02:53 |
| rsalveti | then it's another issue | 02:53 |
| rlameiro | yes I know, one at a time | 02:54 |
| rsalveti | :-) | 02:54 |
| rlameiro | rsalveti: lp 645689 | 02:57 |
| ubot2 | Launchpad bug 645689 in linux (Ubuntu) "linux-omap cant bring up eth0 on igepv2 board, no network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645689 | 02:57 |
| rsalveti | nice | 03:01 |
| rsalveti | I'd just like to understand it better, like why using it as module doesn't work | 03:02 |
| persia | From what rcn-ee said earlier, I had the impression that uboot is doing bring-up on the device, and hands it off already configured. | 03:04 |
| persia | So by building it in, it's easy to notice it's there. | 03:04 |
| persia | My (blind) guess is that there isn't an entry in the module detection routine, so there's no coldplug event, so udev doesn't know to load the module. | 03:05 |
| persia | That said, I suspect there also aren't the necessary module mappings so that udev would be able to load the right module on detection. | 03:05 |
| rlameiro | well, igep is configured to have the device ready for netboot | 03:06 |
| rlameiro | maybe it stays configured | 03:06 |
| rsalveti | hm, ok, but then driver needs to be initialized correctly | 03:07 |
| persia | Separately, if the code isn't written to be hotplug-compatible, modload isn't going to be able to bring it up from scratch (even with coldplug), because the module initialisation routines will be missing the right bits. | 03:07 |
| rsalveti | we have platform data for it at the board file, and the kernel should be able to request the module | 03:07 |
| persia | rsalveti, Yep. Precisely. Cleaning up the initialisation and reporting should enable coldplug. Once coldplug works, hotplug is trivial. | 03:07 |
| rsalveti | still prefer to debug it further than changing the config file | 03:08 |
| rsalveti | but, have no board ( | 03:08 |
| rsalveti | :-( | 03:08 |
| rcn-ee | rlameiro, the size difference might be from all the omap4 stuff i have enabled to.. The sgx and dspbridge modules do add a little extra | 03:08 |
| rlameiro | hmm | 03:08 |
| persia | rsalveti, Isn't there a way to pass a boot option to get extra debug information in dmesg from coldplug initialisation? Would that be enough to understand the nature of the issue? | 03:09 |
| rsalveti | not sure, would first check if we have everything write at the board file | 03:12 |
| rsalveti | that's where the platform_data is stored | 03:12 |
| rsalveti | and afaik the ethernet chip is deployed with the usb hub | 03:13 |
| rsalveti | like we have for xM | 03:13 |
| rsalveti | hm, LAN9221i is just an ethernet controller | 03:22 |
| rsalveti | rlameiro: where do you get your u-boot? | 03:23 |
| rlameiro | stock | 03:24 |
| rsalveti | rlameiro: do you have the source's link? | 03:25 |
| rlameiro | do you want the version? | 03:25 |
| rlameiro | rsalveti: you need to register at their site | 03:26 |
| rlameiro | http://www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55 | 03:26 |
| rlameiro | there should be a link on the left menu where you can go to support or downloads section | 03:26 |
| rlameiro | there are all the sources that igep use | 03:26 |
| rlameiro | kernels, modules etc | 03:26 |
| rsalveti | hm, ok, thanks | 03:28 |
| rlameiro | even if i give you the direct link, you will need to be registered... | 03:28 |
| rlameiro | sorry | 03:29 |
| rsalveti | argh, still need to wait for the administrator to approve my account | 03:30 |
| rsalveti | cooloney: hey, morning! :-) | 03:47 |
| rsalveti | maybe you can help me | 03:47 |
| rsalveti | I believe that the smsc911x module is not automatically loaded simply because this is a platform_driver | 03:48 |
| rsalveti | it's not connected to any pci or usb | 03:48 |
| rsalveti | what we have at the board file is the platform_data, that's correct registered for igepv2 | 03:49 |
| rsalveti | but I don't think we have an automatic way to find and load the proper modules while booting the kernel | 03:49 |
| rsalveti | that's why it works since boot when you have it as built-in | 03:50 |
| rsalveti | then we have a platform_driver_register that matches with a platform_data, the hardware is then initialized correctly | 03:50 |
| rsalveti | rlameiro: persia: ^ | 03:51 |
| rsalveti | so loading the module should do the same, so it's expected to work | 03:51 |
| rlameiro | well, so the solution is the driver to be builtin? | 03:51 |
| rsalveti | but then we have another issue currently with ubuntu's kernel | 03:51 |
| rlameiro | how do you load a module without detecting it? | 03:52 |
| rsalveti | that amitk pointed me: http://www.spinics.net/lists/netdev/msg140340.html | 03:52 |
| rsalveti | and that's why we have to remove CONFIG_FIXED_PHY | 03:52 |
| rsalveti | so, removing CONFIG_FIXED_PHY and loading the kernel by hand should be enough to have the ethernet chip working | 03:52 |
| rsalveti | rlameiro: scripts, but should be avoid | 03:52 |
| rsalveti | I could be wrong, but I don't know a way to detect the platform devices | 03:53 |
| rsalveti | all upstream config files put it as built-in | 03:53 |
| cooloney | rsalveti: built-in FIXED_PHY? | 03:54 |
| rsalveti | cooloney: currently we have it, and as a side effect we can't make smsc911x to work | 03:54 |
| rsalveti | cooloney: http://www.spinics.net/lists/netdev/msg140340.html | 03:55 |
| cooloney | rsalveti: yeah, i removed the FIXED_PHY in fsl-imx51 ubuntu kernel before | 03:55 |
| rsalveti | cooloney: a question, is there a way to auto detect the platform devices and trigger user space events so udev could load the proper modules? | 03:55 |
| cooloney | due to the conflict | 03:55 |
| rsalveti | or in this case we should always put it as built-in | 03:55 |
| rsalveti | cooloney: cool, we're missing this currently | 03:56 |
| rsalveti | will request the linaro's patch to be applied to our tree | 03:56 |
| cooloney | rsalveti: i think for our hardware which contains smsc911x needs to built-in smsc911x driver and remove that FIXED_PHY | 03:58 |
| rsalveti | cooloney: cool, also think the same | 03:59 |
| rsalveti | so I it seems I finally have a proper answer for the issue :-) | 03:59 |
| rsalveti | thanks | 03:59 |
| rsalveti | will submit the patch | 03:59 |
| cooloney | rsalveti: cool, man. that's conflict wasted me some time before | 04:00 |
| rsalveti | can imagine, hard to find | 04:01 |
| cooloney | rsalveti: i still lost in the mem=1G highmem issue | 04:03 |
| cooloney | rsalveti: no clue for that | 04:03 |
| rsalveti | comradekingu: me neither | 04:03 |
| rsalveti | ouch, sorry | 04:03 |
| rsalveti | cooloney: ^ | 04:03 |
| rsalveti | npitre fixed some highmem issues in the past, maybe he could give us some directions | 04:05 |
| rlameiro | I have a doubt | 04:05 |
| rlameiro | what is the Alsa drivers used on omap? | 04:05 |
| rlameiro | the normal ones that run on my laptop? or the striped down ones? | 04:06 |
| cooloney | rsalveti: cool. npitre is master. i need to talk with him | 04:07 |
| npitre | I'm here btw ;-) | 04:08 |
| npitre | although I WOULDN'T QUALIFY MYSELF AS "MASTER" | 04:08 |
| npitre | (especially when hitting capslock by mistake) | 04:09 |
| rsalveti | hey | 04:11 |
| rsalveti | npitre: we're currently facing a weird bug with highmem on omap4, if we use 1gb the memory some times gets corrupted | 04:11 |
| rsalveti | and then the system turns unstable | 04:12 |
| rsalveti | we'd like to test upstream, but can't atm as the mmc support is broken | 04:12 |
| npitre | rsalveti: what kernel version are you using? | 04:12 |
| rsalveti | npitre: one provided by TI, based on 2.6.35: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=shortlog;h=refs/heads/for-ubuntu-2.6.35 | 04:13 |
| rsalveti | that's why we'd like to try upstream, to avoid all other patches | 04:14 |
| npitre | all the highmem fixes I know about are included in 2.6.35 | 04:15 |
| npitre | can you boot it with only one CPU? | 04:17 |
| rsalveti | yep, while looking at 2.6.36 we just noticed one patch that could help: http://lkml.org/lkml/2010/9/7/390 | 04:18 |
| rsalveti | we can, and we tried it already, but still faced the issue | 04:18 |
| npitre | the other thing to try out is to use mem=512m vmalloc=1g in the kernel cmdline string | 04:18 |
| rsalveti | with this patch applied things seems to be better, but still breaks | 04:18 |
| rsalveti | hm, ok | 04:18 |
| npitre | OK that patch might help if the hardware ends up needing bounce buffers (mine didn't) | 04:21 |
| cooloney | npitre: hey, man how's going | 04:21 |
| npitre | rsalveti: those kernel cmdnline arguments will force 512 mb OF ram ,AND FORCE ALMOST ALL OF IT INTO HIGHMEM, WHICH SHOULD BE A GOOD TEST | 04:22 |
| npitre | cooloney: GOOD GOOD | 04:22 |
| cooloney | npitre and rsalveti, i think we might need some simple testcase to catch this subtle issue | 04:23 |
| npitre | arch damn capslock | 04:23 |
| cooloney | npitre: np, heh | 04:23 |
| rsalveti | npitre: nice, will test it here | 04:23 |
| cooloney | npitre: ok, i will try that cmdline | 04:23 |
| cooloney | rsalveti: cool | 04:23 |
| rsalveti | cooloney: currently the best test I have is to try to compile the kernel | 04:23 |
| rsalveti | it breaks in one or two minutes | 04:24 |
| rsalveti | with internal compiler error | 04:24 |
| cooloney | rsalveti: yeah, i also got that, if i built kernel in a ssh console, i will got Bad Mode oops in my serial console | 04:25 |
| cooloney | Unhandled abort | 04:25 |
| rsalveti | yep, that's the error | 04:25 |
| cooloney | right, but this test is quite complex. do you guys know any other highmem test SW? | 04:26 |
| rsalveti | maybe something to stress the memory | 04:27 |
| rsalveti | but it usually takes quite a while before giving any error | 04:27 |
| npitre | what if highmem is turned off? does this still fail? | 04:28 |
| rsalveti | when setting mem to 716 (460 + 256) with or without highmem we don't face this issue | 04:29 |
| npitre | what is the storage device used? | 04:29 |
| npitre | does it use DMA? | 04:29 |
| rsalveti | the hole is a fixed memory region for decode I guess | 04:29 |
| cooloney | npitre: if we don't use mem=1G, there is no such issue | 04:29 |
| rsalveti | mmc and usb | 04:30 |
| cooloney | yeah, mmc and usb | 04:30 |
| cooloney | i tried booting from mmc and rootfs on mmc | 04:30 |
| cooloney | but built kernel on NFS or USB | 04:30 |
| npitre | does it happen if you use only mmc or usb at once? | 04:30 |
| cooloney | got this compiler error every time when mem=1G | 04:30 |
| rsalveti | yep, I'm using only USB | 04:31 |
| rsalveti | never tested with full mmc, but I believe cooloney tested it already | 04:31 |
| cooloney | rsalveti: i think npitre is asking whether we can booting and building kernel only on mmc | 04:31 |
| cooloney | rsalveti: oh, no, i just test build kernel on usb and nfs | 04:32 |
| cooloney | let me try it | 04:32 |
| cooloney | need a big mmc card | 04:32 |
| rsalveti | try just on mmc, but I believe people from TI tried it already | 04:32 |
| npitre | what I want to know is wether the problem occurs if you use only USB, or only MMC, or only NFS, etc. | 04:32 |
| cooloney | npitre: ok, i got it | 04:32 |
| rsalveti | ok, got it | 04:32 |
| cooloney | rsalveti: can we boot from usb? | 04:33 |
| rsalveti | cooloney: do you have a big sd card with you? | 04:33 |
| cooloney | i don't think so | 04:33 |
| cooloney | rsalveti: i got one 8G SD card | 04:33 |
| rsalveti | not directly, I just use the mmc to load the kernel from u-boot | 04:33 |
| rsalveti | my rootfs is in a usb disk | 04:33 |
| cooloney | rsalveti: ok cool | 04:33 |
| rsalveti | then I don't use mmc anymore | 04:33 |
| cooloney | so could you try that USB only test? | 04:33 |
| cooloney | i will try mmc only test | 04:34 |
| npitre | another thing to test is CONFIG_VMSPLIT_2G | 04:34 |
| rsalveti | cooloney: yep, this is my usual build environment, and I always face this issue when using 1g | 04:34 |
| cooloney | npitre: good point. | 04:35 |
| cooloney | rsalveti: ok, let me prepare the 8G SD card | 04:36 |
| npitre | another test: just add a flush_dcache_all() at the beginning of dma_cache_maint_page() and see if that makes the issue go away | 04:39 |
| npitre | note this is not a fix just a test | 04:40 |
| rsalveti | hm, nice test | 04:40 |
| npitre | time to go to bed ... just drop me an email with your findings and I might have another clue | 04:41 |
| cooloney | npitre, have a nice dream | 04:41 |
| rsalveti | npitre: nice, thanks a lot! | 04:41 |
| cooloney | we can inception your dream and tell you the result | 04:41 |
| rsalveti | :-) | 04:41 |
| cooloney | npitre: if you watched the movie inception. | 04:41 |
| cooloney | heh | 04:42 |
| npitre | I'm rather heavy on TumbleOnThatDamnCapsLockKey tonight | 04:43 |
| npitre | that's usually a sign that I should go to bed | 04:43 |
| rsalveti | just pull it off, who needs caps lock | 04:43 |
| rsalveti | :-) | 04:43 |
| rsalveti | cooloney: going to bed now, please let me know if you have any success on this highmem testing | 06:07 |
| rsalveti | interested at the flush_dcache_all testing | 06:07 |
| rsalveti | can continue tomorrow | 06:07 |
| GrueMaster | Bed? It's only 2am there. | 06:08 |
| GrueMaster | Pfft. | 06:08 |
| * rsalveti getting old | 06:08 | |
| GrueMaster | heh. | 06:09 |
| GrueMaster | Old is when you forget where you left your coffee mug, while drinking it. | 06:10 |
| rsalveti | hm, happens all the time with me | 06:10 |
| rsalveti | dammit | 06:10 |
| GrueMaster | Yea, but mine is a 20oz silver & black keg. | 06:12 |
| rsalveti | haha :-) | 06:16 |
| rsalveti | well, time to go, see ya | 06:16 |
| GrueMaster | Night | 06:17 |
| GrueMaster | persia: about? | 06:41 |
| * GrueMaster crawls to bed. Will pick up in the morning. | 07:05 | |
| === hrw|gone is now known as hrw | ||
| hrw | morning | 07:10 |
| persia | GrueMaster, Sorry to have missed you. Sleep well. | 07:30 |
| avinashhm | hi, .. any one knows configuration to control or switch governors ... any sysfs entry ??? | 07:36 |
| hrw | avinashhm: cd /sys/devices/system/cpu/cpufreq/ and check there | 07:41 |
| avinashhm | hrw, i am obseving .. it switchs from performance --> ondemand after some time .. during boot ... any script to do this configuration ... | 07:42 |
| avinashhm | i observe the samething isn't there in busybox ... it always stays at performance .. so was curios , is it some script doing this ?? | 07:44 |
| hrw | probably yes | 07:45 |
| avinashhm | hrw, thanks ... | 07:49 |
| hrw | I would do grep ondemand /etc -r | 07:50 |
| avinashhm | hrw, i will try this .... | 07:51 |
| avinashhm | hrw, .. found bunch of things ... etc/init.d/ondemand ... | 07:52 |
| avinashhm | , ... now i wan't configure similar things for my busybox here .. let me try ... thanks again hrw | 07:54 |
| ShreeRang | i am working on an ARM based device and when working on the mozilla web browser i am facing a problem... | 08:48 |
| ShreeRang | there are number of scroll bars appearing on the screen... | 08:48 |
| ShreeRang | i have taken screen shots of the same... | 08:48 |
| ShreeRang | please have a look at them at the following link | 08:49 |
| ShreeRang | http://picasaweb.google.co.in/patwardhan.shreerang/ARMBasedMozilla?authkey=Gv1sRgCLeMjMPZha67kAE# | 08:49 |
| persia | Which release of Ubuntu are you running? | 08:49 |
| ShreeRang | has anyone of u faced a similar problem? | 08:49 |
| ShreeRang | i m using a customized ubuntu | 08:51 |
| persia | Customised from which release? Also, customised how? | 08:51 |
| ShreeRang | ubuntu 9.10 | 08:53 |
| ShreeRang | by using rootstock | 08:53 |
| persia | I'd recommend trying with 10.04. I think I remember that problem in the past, but I believe it to be solved. | 08:54 |
| hrw | 9.10? | 08:54 |
| persia | hrw, karmic | 08:54 |
| hrw | ShreeRang: which cpu you are using? | 08:54 |
| ShreeRang | OMAP 3503 | 08:54 |
| hrw | ShreeRang: try 10.04 then | 08:55 |
| ShreeRang | ok... | 08:55 |
| ShreeRang | dats an option... | 08:55 |
| ShreeRang | anything else that i can do? | 08:55 |
| persia | You might try one of the firefox backports from the mozillateam PPAs, but you'd have to compile it locally. | 08:56 |
| * persia wonders if anyone has tried Ubuntu on the Mini6410 | 08:56 | |
| hrw | persia: 6410 is armv6 - right? | 08:57 |
| ShreeRang | fine...il try dat n update... | 08:57 |
| persia | hrw, Is it? My quick search misinformed me then. I'll believe you (and I see 9.10 images of it about) | 08:57 |
| hrw | persia: according to samsung datasheet it is arm1176jzf-s | 09:10 |
| hrw | so arm11vfp3 | 09:10 |
| persia | So no support. Thanks for double-checking. | 09:26 |
| === ogra_ac2 is now known as ogra_ac | ||
| ogra | NCommander, getting along with gconf ? | 10:54 |
| === zyga is now known as zyga-airport | ||
| === JamieBen1ett is now known as JamieBennett | ||
| ogra | ndec, around ? | 11:17 |
| ndec | ogra: yep. | 11:18 |
| ogra | ndec, i will soon need a list with binary package names to install from the ppa | 11:19 |
| ogra | with the next software-center upload the feature will be fully enabled | 11:20 |
| ndec | ogra: argh... | 11:20 |
| ndec | ogra: can this be just a meta package, something like ubuntu-omap4? then I can manage my dependencies in this pkg? | 11:20 |
| persia | Yes. | 11:20 |
| ndec | persia: is this 'yes' for me? | 11:21 |
| ogra | ndec, indeed ... what we need is one postinst snippet that removes the .desktop file in one of your packages | 11:21 |
| ogra | but persia is right, easiest will be a metapackage | 11:21 |
| persia | ndec, Yes :) | 11:21 |
| ndec | persia: ;-) | 11:21 |
| ogra | (and the sprecific postinst bit in there) | 11:21 |
| persia | ogra, Might be easier to remove the .desktop file from the source, rather than adding it and removing it. | 11:22 |
| ogra | persia, from the source ? | 11:22 |
| persia | Yep. | 11:22 |
| ogra | its not in any package ... | 11:22 |
| ogra | and it cant be | 11:22 |
| persia | Then from where does it come? | 11:22 |
| persia | No file shouldn't have a package | 11:23 |
| ogra | jasper (or if we ever use live images it would have to come from casper) | 11:23 |
| persia | (yes, there are exceptions, but they are each special for their own, specific, special reasons, and *NONE* of them are .desktop files) | 11:23 |
| persia | Why? | 11:23 |
| persia | app-install-data-tippa would be such a better place to put it ... | 11:23 |
| ogra | because it has to be dynamically created during first boot/install time unless we want to have even more subarch specific images | 11:24 |
| persia | No. Just have jasper purge app-install-data-tippa if it's not the right subarch | 11:24 |
| ogra | hrm | 11:25 |
| persia | Unowned files are bad. | 11:25 |
| ogra | not for such hacks as PPA enablement for specific subarches | 11:25 |
| persia | Yes. | 11:25 |
| persia | they are always bad. | 11:25 |
| persia | hacks are bad, but bad hacks are extra bad. | 11:25 |
| persia | Please avoid extra badness :) | 11:25 |
| ogra | i dont really want to jump through all the hoops of paperwork that would involve | 11:26 |
| ogra | especially since everything is implemented and works now | 11:26 |
| persia | Please talk about the architecture with me beforehand next time :p | 11:26 |
| persia | Also, please file a bug to fix this already immediately post-maverick :) | 11:26 |
| ogra | sure, we can change all that when we rewrite jasper | 11:26 |
| persia | You told me not to do that this cycle back around FF :) | 11:26 |
| ndec | ogra: persia: is ubuntu-omap4 a good name? what else would you propose? | 11:27 |
| persia | But yeah, that's an OK time. | 11:27 |
| ogra | for now jasper will dynamically create the apturl file for omap3 or 4 | 11:27 |
| ogra | ndec, ubuntu-omap4-addons ? | 11:27 |
| persia | ndec, I'd probably use ubuntu-panda-extras | 11:27 |
| ogra | i dont think its panda specific | 11:27 |
| persia | ogra, "addons" has a special semantic value, and should be avoided. | 11:27 |
| ndec | persia: no, i don't want panda since it works on other OMAP4 platforms too | 11:27 |
| ogra | will be for blaze too | 11:27 |
| persia | ndec, If you're *sure* it's going to be good for all omap4, then "ubuntu-omap4-extras" | 11:28 |
| ogra | well, then ubuntu-omap4-extras | 11:28 |
| ogra | persia, well, for all *existing* omap4 platforms at least :) | 11:28 |
| ndec | some of them are restricted by the way... since I have put some debconf to get clickwrap (like sun java)? | 11:28 |
| ogra | thats fine | 11:29 |
| ogra | ndec, i also need a text for the "eula" (its not really an eula, but it is shown by sw-center if you want to enable the PPA | 11:29 |
| ogra | ) | 11:29 |
| ndec | well in fact there could be a few bits specific to board. e.g. wlan chip is not the same on panda and blaze. so we could either install both packages, or make different meta packages. I prefer first option. | 11:30 |
| ogra | you can try it on todays image to see what i mean | 11:30 |
| ogra | (currently it shows some broken html text) | 11:30 |
| * ogra prefers both too | 11:30 | |
| persia | ndec, Would it be possible to have one package that does runtime autodetection to make one or the other work, or has parallel auto-enabled configuration? | 11:30 |
| ndec | ogra: so it's a welcome message, right? something like ' you are reading to enable an OMAP PPA and enter a whole new world of improved user experience' ;-) | 11:30 |
| persia | Doing it that way will also reduce long-term merge pain. | 11:31 |
| ogra | ndec, well, you could also put all eula txts there if you wanted to :) | 11:31 |
| persia | let's have a less marketing-friendly message there :p | 11:31 |
| ogra | ndec, but that would duplicate the eula stuff i guess | 11:31 |
| ndec | especially because EULA are different for our various packages, we don't have 1 EULA overall | 11:31 |
| ogra | since they are required to be in the packages too (a user can always enable the ppa without sw-center) | 11:32 |
| ogra | ndec, yeah, you could put all of them in ... would be ugly but be possible ... though as i said you will need them in the packages too because you can always manually switch the PPA on on cmdline | 11:32 |
| ndec | persia: ideally I should be able to install ti-wlan-127x (panda) and ti-wlan-128x (blaze) package. and have the same root FS work on both. is that okay? | 11:32 |
| ogra | so a 2welcome text" would likely be best | 11:33 |
| ogra | >The Ubuntu 10.10 TI OMAP4 channel contains applications that are made | 11:33 |
| ogra | available for Ubuntu by TI to improve the user experience and hardware | 11:33 |
| ogra | support on OMAP4 hardware | 11:33 |
| ogra | thats the current text | 11:33 |
| ndec | ogra: yes a user can install packages without using the desktop icon... that's an argument against removing the icon in the ubuntu-omap4-extra, no? | 11:34 |
| ogra | (i just made that up quickly to have some placeholder text) | 11:34 |
| ndec | so, now we need to translate the message too ;-) | 11:34 |
| ogra | ndec, no, the icon should be removed as soon as the meta is installed | 11:34 |
| ogra | shriek ! | 11:34 |
| ogra | i didnt think of translations ! | 11:34 |
| ogra | sigh | 11:34 |
| ndec | ogra: can you make the initial ubuntu-omap4-extras package with the postinst and push it in PPA? I will push updates when we are ready. | 11:35 |
| persia | Well, we can hit three languages quick-like: the rest will be slower. | 11:35 |
| ndec | ogra: i don't care about translation! | 11:36 |
| ogra | persia, my prob is that i in no case want to add gettext to jasper | 11:36 |
| ogra | that will massively bloat it | 11:36 |
| * persia mumbles about architectural integrity and pretends everyone reads English for the next few months | 11:36 | |
| ogra | well, lets call it a wart we will carry in maverick and do better in natty | 11:37 |
| ndec | persia: I think the website where one can order pandaboard will be in english... so we can assume that if someone buys a panda, he understands english ;-) | 11:37 |
| persia | When we ignore all prior work and write jasper correctly :) | 11:37 |
| persia | I promise I won't be out-of-touch for 10-12 weeks in a row for the next cycle :) | 11:38 |
| ogra | well, then we wont have the PPA stuff in it anymore anyway | 11:38 |
| ogra | we should switch to packages as you said above | 11:38 |
| ogra | and they can then easily be gettextized | 11:38 |
| * persia goes off to do less computationally intensive things | 11:38 | |
| ogra | my prob in maverik is that the cool sw-center stuff only came late ... i threw away all the hacky oemä-config stuff i had done for PPA enablement just last week | 11:39 |
| ogra | in favor of the new apturl feature | 11:39 |
| ogra | ndec, what about the discussed split for single features (-omap4-wireless, -omap4-graphics ... etc) should we use these as deps in the toplevel metapackage ? | 11:41 |
| ogra | or was that for a different PPA anyway ? | 11:41 |
| ogra | (i mean the stuff chris wanted) | 11:41 |
| === amitk is now known as amitk-afk | ||
| jo-erlend_nb | rsalveti, I have wired networking! :) | 12:16 |
| jo-erlend_nb | now for wireless, I only need to install libertas-firmware? | 12:17 |
| jo-erlend_nb | except... I can't find it. I find it in apt-cache on my laptop, but not on the igep board. | 12:19 |
| jo-erlend_nb | oh, it's in multiverse. | 12:20 |
| ogra | ndec, do you think your lawyers would sue me for that ? http://people.canonical.com/~ogra/ti-ppa.svg | 12:37 |
| ogra | (th elogo is from wikipedia) | 12:39 |
| ogra | *the logo | 12:39 |
| persia | ogra, Take care: you'd need a license to use the logo. Make ndec upload it :) | 12:40 |
| ogra | persia, yeah, he shoudl just use it as team logo :) | 12:40 |
| ogra | then i can "officially" pull it from LP | 12:40 |
| persia | Unfortunately, trademark law requires that every case be prosecuted, or the trademark is lost. | 12:40 |
| persia | (at least in some jurisdictions) | 12:40 |
| persia | For example, Bayer is the only company that can sell "Aspirin" in some countries, but in others anyone can sell under that name, because of insufficient defense. | 12:41 |
| ogra | yep | 12:42 |
| jo-erlend_nb | this is looking good! Everything seems to be working nicely on my igepv2 board now, though there are things I haven't had time to test yet. | 13:00 |
| === amitk-afk is now known as amitk | ||
| jo-erlend_nb | I have a 16GB memory card which I'm installing on now. The image was written to it at 3MB/s. How long should the first boot take, with resizing partitions, etc? | 13:38 |
| persia | Maybe 10 minutes. | 13:40 |
| persia | But depends on the hardware inside the card as well, really. | 13:40 |
| jo-erlend_nb | ok. Does this happen before the welcome screen appears? | 13:40 |
| persia | Yes. | 13:41 |
| persia | Depending on your configuration, you may get text to console, which may end up on serial or display, during the rebuild. | 13:41 |
| jo-erlend_nb | it went too quickly for me to notice, apparently. :) | 13:42 |
| persia | That's a good thing :) | 13:42 |
| jo-erlend_nb | the difference between those to memory card was rather significant. Using the first one, a normal boot took about 3-4 minutes. Using the other one, it took less than a minute. | 13:43 |
| persia | That's the internal hardware differences. | 13:43 |
| persia | You will probably notice the system feeling "snappier" as well, as you use it, if you run off that SD. | 13:44 |
| jo-erlend_nb | looking forward to testing it. :) | 13:44 |
| jo-erlend_nb | persia, I'm not sure I'd use the phrase "snappy", but it's far less sluggish. :) | 13:56 |
| jo-erlend_nb | makes me want to try using a usb harddisk, just to see how fast it is when the storage isn't such a bottleneck. | 13:57 |
| persia | "snappier" == "less sluggish". | 13:57 |
| jo-erlend_nb | hehe, yes, except for the slightly different connotations :) | 13:58 |
| lag | Hi mpoirier | 13:58 |
| mpoirier | lag: hey good morning ! | 13:58 |
| lag | Evening :) | 13:59 |
| lag | How are you progressing with sound? | 13:59 |
| mpoirier | lag: hold on. | 14:00 |
| mpoirier | lag: i spent a lot of time in sdp4430.c and twl6040.c | 14:01 |
| lag | Okay | 14:01 |
| mpoirier | lag: the "dai" (digital audio interface) are key. | 14:01 |
| lag | So what do you plan to do? | 14:01 |
| mpoirier | lag: still unknown. | 14:02 |
| * persia idly notes that the userspace solution turns out not to work with current kernel reporting | 14:02 | |
| mpoirier | lag: now that I know how the system works, I'll start looking in other files for a possible solution. | 14:03 |
| lag | persia: How do you mean? | 14:03 |
| * ogra_ac was wondering too | 14:03 | |
| mpoirier | lag: twl6040.c was written by TI guys, I'll get in touch with them. | 14:03 |
| persia | lag, berco put together an alsa configuration fragment that would do what running amixer.sh would do, but ALSA isn't even reporting the card type, so there's no way to load the config fragment. | 14:04 |
| mpoirier | lag: ultimately we can do it at the card level, once all the DAIs are registered, but it won't be upstrem'able. | 14:04 |
| persia | We also looked at how pulse's module-udev-detect works, and all the values it pulls from /sys/... end up as "unknown", so it can't assign things. | 14:04 |
| persia | mpoirier, Why won't it be upstreamable? | 14:05 |
| lag | mpoirier: If it's not upstreamable, then it's the wrong way to do it | 14:05 |
| * persia agrees | 14:05 | |
| === njpatel_ is now known as njpatel | ||
| mpoirier | lag: make no mistake, I don't like it. | 14:06 |
| * ogra_ac just notes that the majority of omap4 patches we use isnt upstreamable currently | 14:06 | |
| persia | ogra, That's different. | 14:06 |
| ogra_ac | how ? | 14:06 |
| ogra_ac | we use a hackish un-upstreamable kernel in maverick | 14:07 |
| lag | Ugly! | 14:07 |
| ogra_ac | which will be fixed later | 14:07 |
| ogra_ac | so i personally would mind a hackish fix in the sound driver | 14:07 |
| ogra_ac | *wouldnt | 14:07 |
| lag | mpoirier: What makes you think dai is key? | 14:07 |
| persia | ogra, just hardcoding the DAIs is unlikely to result in anything compatible for both Blaze and panda: reports indicate they require slightly different handling. | 14:08 |
| ogra_ac | its still better than hacking around in userspace with weird scripts | 14:08 |
| persia | We *can't* hack around in userspace: we tried that. | 14:08 |
| mpoirier | persia: *if* i hack it, it would be on a board level, not system wide. | 14:08 |
| ogra_ac | we obviously can when using the ugly amixer script | 14:08 |
| persia | Mind you, it may be possible to use a less-critical hack in the kernel side to enable userspace hacking, but... | 14:08 |
| lag | ogra_ac: How is it better | 14:08 |
| lag | ? | 14:08 |
| persia | mpoirier, Oh, with the machine drivers? How is that not upstreamable? | 14:08 |
| ogra_ac | lag, one change in one place instead of three changes in three places | 14:09 |
| lag | I'd say it was less hacky to do it in user space | 14:09 |
| lag | It's what amixer was designed for | 14:09 |
| persia | ogra, Ah, yeah, the amixer script. That doesn't have sufficient elegance to even be called "hack" in my book. | 14:09 |
| lag | ogra_ac: We only need the script | 14:09 |
| ogra_ac | lag, plus the fact that we break all ubuntu policies with it | 14:09 |
| lag | Just to turn the thing up! | 14:09 |
| ogra_ac | and packaging | 14:09 |
| persia | lag, No. the scipt is unusable. | 14:09 |
| persia | lag, *if* the kernel reported the card, we could set mixer policy with userspace config. | 14:10 |
| lag | Then that's what we need to do | 14:10 |
| lag | Not hack the volume in userspace | 14:10 |
| lag | Wrong: kernel | 14:10 |
| lag | s/userspace/kernel | 14:11 |
| rsalveti | jo-erlend_nb: nice to know, sent both fixes to the kernel team, let's see when they will get applied | 14:11 |
| persia | Minimal kernel work would mean passing CARDINFO so we can use a userspace hack for ALSA, and passing something in /sys/... so that udev would be able to identify headset, speakers, etc. | 14:11 |
| persia | Better kernel work would be to correctly identify and name the device, and pass the correct naming to userspace policy. | 14:11 |
| mpoirier | main problem right now it a misconnection between front and backend DAIs | 14:12 |
| persia | Best kernel work would be to correctly identify and name the device, and perform correct basic initialisation on the device (turn on the useful amps, turn off the useless ones, etc.) | 14:12 |
| mpoirier | userspace tries to open a stream but can't 'cause kernel returns an error. | 14:12 |
| mpoirier | running the scripts fixes the connection between DAIs, hence returning a proper stream to sink to. | 14:13 |
| persia | The key bit is that with the current design of ALSA (and yes, there are discussions to move more to userspace), the kernel is responsible for identification, initialisation, and initial configuration. | 14:13 |
| berco | persia: mpoirier: I have a kernel change for audio that I need to test | 14:14 |
| mpoirier | Getting the DAIs connected properly (on a per card basis) will fix our problems. | 14:14 |
| lag | Do we have a working example of how it 'should' work? | 14:14 |
| ogra_ac | lag, intel HDA i think | 14:14 |
| persia | berco, Excellent! What does it do? | 14:14 |
| persia | Intel HDA is another pile of pain | 14:14 |
| lag | 'good example' | 14:14 |
| ogra_ac | all other soundcards ? | 14:15 |
| lag | And they work in the same way? | 14:15 |
| persia | I don't know of one. I'd really suggest asking in #alsa-soc | 14:15 |
| lag | Report all relevant information to userspace? | 14:15 |
| persia | ogra, Most soundcards don't use the SoC layer, making them poor examples. | 14:15 |
| lag | Good plan | 14:16 |
| ogra_ac | ah, right | 14:16 |
| berco | persia: it adds long name support in soc | 14:16 |
| persia | berco, Cool! Great find. | 14:16 |
| persia | mpoirier, Could you take a look at that? | 14:16 |
| mpoirier | persia: sure but what does "long name support" do ? | 14:16 |
| berco | persia: trying to get a new kernel with that change in place for testing | 14:16 |
| ogra_ac | size matters ? | 14:17 |
| ogra_ac | even with sound ? | 14:17 |
| persia | Should be reporting of the card name, so that CARDINFO lets us use userspace policy config hacks. | 14:17 |
| persia | berco, mpoirier can probably spin you one fairly quickly, if you can point at the patch. | 14:17 |
| mpoirier | berco: yes, send me the patch and I'll test this. | 14:17 |
| mpoirier | berco: within 30 minutes that is... | 14:18 |
| hrw | check how twl4030 does it? | 14:18 |
| persia | mpoirier, The userspace config stuff isn't packaged, so you'll want to come back for instructions on how to test :) | 14:18 |
| hrw | most omap3 uses twl4030 but has it connected in zyllion ways | 14:18 |
| persia | hrw, twl4030 reports CARDINFO, sets amps and volumes, and reports the right parameters to udev? | 14:19 |
| ogra_ac | hrw, which obviously breaks it on Xm | 14:19 |
| persia | hrw, Ah, yeah, not an ideal example: this is why we don't have working sound on beagle C4/XM | 14:19 |
| persia | (well, it kinda works, sorta, on beagle) | 14:19 |
| ogra_ac | i think C4 works | 14:19 |
| hrw | persia: no idea. I used few omap3 devices with sound. n900/beagleboard b7+c3/bug2 | 14:19 |
| persia | kinda, sorta, if you don't do anything tricky | 14:19 |
| persia | hrw, Making it seem like it works on any of those is trivial: fiddle with alsamixer for 5 minutes, and never think about it again. | 14:20 |
| mpoirier | hrw: yes, twl4030 was in my list of things to look at today. | 14:20 |
| persia | The trick is having it work perfectly in an autodetected manner on first install. | 14:20 |
| ogra_ac | for me "works" = i hear a login sound :P | 14:20 |
| persia | ogra, On first boot. | 14:20 |
| ogra_ac | sure | 14:20 |
| persia | GrueMaster was reporting issues with that for both C4 and XM, I thought. I may be misremembering. | 14:21 |
| hrw | persia: for me "alsactl restore" with prepared asound.conf is fine | 14:21 |
| ogra_ac | hrw, thats so broken | 14:21 |
| ogra_ac | "prepared asound.conf" ... | 14:21 |
| hrw | ogra_ac: kernel people tends to move more and more to userspace anyway | 14:22 |
| persia | hrw, That means "not working" to me. | 14:23 |
| persia | And moving more to userspace is fine, but it needs to be done right (and that discussion is ongoing in ALSA upstream). | 14:23 |
| persia | Just expecting endusers to magically know how to write a config file isn't acceptable user experience. | 14:24 |
| === ogra_ac2 is now known as ogra_ac | ||
| hrw | make alsa-config package which will keep asound.conf-boardname + script which will check /proc/cpuinfo? | 14:25 |
| ogra_ac | ugh | 14:25 |
| persia | We have something like that already. | 14:26 |
| persia | It is part of alsa-utils, which you have installed already. | 14:26 |
| persia | But it depends on the kernel reporting *which* card is installed. When the kernel doesn't tell userspace which card is in use, userspace can't do anything at all. | 14:26 |
| berco | mpoirier: I'm attaching that patch to the bug 637947 | 14:26 |
| ubot2 | Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947 | 14:26 |
| lag | What EXACTLY does userspace need from the kernel (do you need from me) | 14:26 |
| persia | And /proc/cpuinfo is exceedingly unlikely to accurately report the audio interface | 14:26 |
| berco | mpoirier: just a min | 14:26 |
| mpoirier | berco: fantastic | 14:27 |
| lag | persia: It must be reported | 14:27 |
| lag | persia: How does ALSA know what to change? | 14:27 |
| persia | berco, Could you expand on what was preventing the custom config from loading? | 14:27 |
| jo-erlend_nb | rsalveti, you're confident they'll make it in time for maverick? | 14:29 |
| rsalveti | jo-erlend_nb: not sure for the release, let's see | 14:29 |
| jo-erlend_nb | rsalveti, I did a clean install of todays preinstall on a new memory card, using the new kernel so I could see the process on my screen. It still doesn't setup the filesystems properly. | 14:29 |
| rsalveti | if not release, at least as an update | 14:30 |
| rsalveti | hm, what do you get on your screen | 14:30 |
| rsalveti | ? | 14:30 |
| berco | mpoirier: #17 and #18 in the bug 637947 log activity | 14:30 |
| ubot2 | Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947 | 14:30 |
| jo-erlend_nb | well, everything works nicely, except the rootfs isn't resized. I don't know if bootfs is cleaned with each reboot yet. I'll know that in a little while. | 14:30 |
| mpoirier | berco: cool, hold on, checking. | 14:31 |
| rsalveti | jo-erlend_nb: ok, would be good to see the messages from the first boot, you should be able to see if it's resizing it or not | 14:31 |
| berco | persia: from my understanding in the /proc/asound/cards we only reported "- SDP4430" instead of something like "OMAP4 - SDP4430" | 14:31 |
| berco | persia: hence, alsa was not looking for any .conf file | 14:32 |
| persia | Aha, so longname should be enough then, right? | 14:32 |
| berco | persia: if you have this omap4 field or whatever, you can just name your .conf file the same as this field i.e OMAP4.conf and it would get loaded by alsa | 14:32 |
| mpoirier | berco: I'll apply and test - this should be very quick. | 14:33 |
| berco | persia: my understanding from the audio guy, is that this fix should be enough, right | 14:33 |
| berco | mpoirier: thanks, let me know | 14:33 |
| jo-erlend_nb | rsalveti, it went very quickly. I didn't see anything special. Then the welcome screen appeared. I filled out all the details, and it worked for a while, then it rebooted. | 14:33 |
| persia | berco, If lrg told you that's what it takes, I'm pretty sure it's correct :) | 14:33 |
| berco | mpoirier: I used iwatch to verify my .conf was loaded by alsa. At least we can make sure after this change a .conf file get read and then make this .conf file look good :) | 14:34 |
| berco | the .conf should contain all our amixer settings | 14:34 |
| persia | Right, which then just leaves pulse | 14:35 |
| * persia goes and looks at source again | 14:35 | |
| rsalveti | jo-erlend_nb: after booting try searching for /var/log/jasper.log | 14:35 |
| jo-erlend_nb | rsalveti, I did see a message that Jasper was being removed. | 14:37 |
| rsalveti | jo-erlend_nb: but the log should still be there at least | 14:37 |
| ogra_ac | whats the prob ? | 14:38 |
| jo-erlend_nb | rsalveti, let me install an irc client on it, then it's easier to paste. | 14:38 |
| rsalveti | cool | 14:39 |
| jo-erlend_nb | it does say it's resizing partitions, at the top of the log file. | 14:39 |
| persia | For pulse, the immediately obvious missing bit is missing values for /sys/class/sound/card.../pcmC.../pcm_class | 14:40 |
| jo-erlend_nb | oh. And I have no sound. | 14:40 |
| persia | But to get a real answer, best to have someone with the hardware to load module-udev-detect with debugging on to track down what's missing. | 14:40 |
| rsalveti | jo-erlend_nb: anything else? | 14:41 |
| jo-erlend_nb | rsalveti, bluetooth doesn't seem to be recognized. | 14:41 |
| persia | That's concerning. Anything in dmesg at all? | 14:41 |
| jo-erlend_nb | rsalveti, but I haven't installed that deb you sent me yet, so perhaps that's causing some problems? I'll do that when I fix the filesystem issues. I have about 50MB free space now. :) | 14:43 |
| rsalveti | jo-erlend_nb: sure, np | 14:48 |
| rsalveti | with default uImage and uInitrd you should be able to run the resize without issues | 14:48 |
| jo-erlend_nb | rsalveti, you mean I should just do it manually? | 14:49 |
| jo-erlend_igep | rsalveti, http://paste.ubuntu.com/499149/ | 14:51 |
| rsalveti | jo-erlend_nb: no, I mean that I believe it should just work | 14:51 |
| jo-erlend_igep | that's the jasper log. | 14:51 |
| ogra_ac | aha | 14:52 |
| rsalveti | first issue with jasper, it expects MLO | 14:52 |
| ogra_ac | right | 14:52 |
| lool | ogra_ac: hey, I see you committed directly to lp:ubuntu/flash-kernel and not to lp:~ubuntu-core-dev/flash-kernel/ubuntu; do you mind if I completely kill the latter now? | 14:52 |
| ogra_ac | and the script is running with set -e | 14:52 |
| rsalveti | so yes, jasper is not running the resize | 14:53 |
| rsalveti | hm, that'd explain | 14:53 |
| lool | ogra_ac: I can help you merge rebase remaining branches based on lp:~ubuntu-core-dev/flash-kernel/ubuntu to lp:ubuntu/flash-kernel if you like | 14:53 |
| ogra_ac | loolgo ahead i committed there because i dont want two branches | 14:53 |
| ogra_ac | just kill the old one | 14:53 |
| jo-erlend_igep | rsalveti, can I just do it myself while the board is running? | 14:53 |
| lool | ogra_ac: Done; thanks | 14:54 |
| jo-erlend_igep | I mean while rootfs is mounted. | 14:54 |
| ogra_ac | i'll do the rebases locally for my personal branches ... if others have probs i'll point them to you though ;) | 14:54 |
| rsalveti | jo-erlend_igep: nops, you need to unmount it first | 14:54 |
| rsalveti | it works during boot because of uInitrd, that loads a shell in memory | 14:55 |
| ogra_ac | no, resize2fs should be able to do an online resize while mounted | 14:55 |
| rsalveti | even while mounted? | 14:55 |
| rsalveti | never tried | 14:55 |
| lool | That's ok; it's basically a matter of updating .bzr/branch/branch.conf to point at the new parent, which can be done when pulling or pushing with --remember | 14:55 |
| ogra_ac | but yu miss the bits from jasper_growroot that run afterwards | 14:55 |
| ogra_ac | loolyeah | 14:55 |
| ogra_ac | rsalveti yeah, but the fs needs to be clean | 14:56 |
| jo-erlend_nb | it keeps deleting everything on my boot partition. How do I fix that? | 14:56 |
| rsalveti | I'd say that jasper is running on every boot, as you didn't generate another uInitrd | 14:57 |
| ogra_ac2 | sigh ... tegra wlan ... sigh | 14:58 |
| === ogra_ac2 is now known as ogra_ac | ||
| ogra_ac | whats the content of your boot partition ? | 14:59 |
| ogra_ac | can you pastebin the ls output somewhere | 14:59 |
| jo-erlend_nb | I have boot.ini, uImage and uInitrd. | 15:04 |
| ogra_ac | create an empty file caled MLO | 15:04 |
| ogra_ac | *called | 15:04 |
| ogra_ac | are you sure the IGEP2 cant read a boot.scr ? | 15:05 |
| jo-erlend_nb | I'm currently resizing the rootfs. I'll try that afterwards. | 15:05 |
| ogra_ac | thats tricky to add | 15:05 |
| jo-erlend_nb | ogra_ac, seems so. | 15:05 |
| ogra | lool, i know you use IGEP2 in linaro, how do you handle the fact that it requires a boot.ini instead of a boot.scr by default ? | 15:18 |
| ogra | do you just replace u-boot in NAND ? | 15:18 |
| * ogra cant imagine that flash-kernel every worked in that scenario | 15:20 | |
| ogra | *ever | 15:20 |
| jo-erlend_nb | rsalveti, can you give me the url to that deb you uploaded? I seem to have misplaced it. :) | 15:20 |
| rsalveti | ogra: maybe u-boot upstream uses boot.scr | 15:20 |
| ogra | rsalveti, well, i would expect jo-erlend to use the in NAND one | 15:21 |
| ogra | and linaro too actually | 15:21 |
| ogra | if that requires .ini while its weird, flash-kernel and jasper wont be able to handle that | 15:22 |
| GrueMaster | Morning. | 15:22 |
| ogra | GrueMaster, morning ... did you have any success with the omap image from yesterday ? | 15:23 |
| ogra | (does it still boot with the new u-boot) | 15:23 |
| GrueMaster | mpoirier: I was looking at the alsa SOC source yesterday for beagle and had an epiphany. By looking at soc/omap/omap3pandora.c and comparing it to omap3beagle.c, I think I have an idea of how to make it work. | 15:24 |
| GrueMaster | ogra: yes, everything works the same (from what I can tel). | 15:24 |
| ogra | \o/ | 15:24 |
| ogra | awesome | 15:24 |
| GrueMaster | back to audio. Pandora is an opensource handheld using similar hardware to beagle. But they actually only enable the pins on the codec that are connected in the system. Beagleboard just maps the entire codec in the dai. | 15:26 |
| GrueMaster | I think we can use the pandora as a roadmap to make beagle work properly. | 15:27 |
| GrueMaster | No need to look at the twl4030 code, except to get proper channel names for the omap3beagle.c | 15:27 |
| mpoirier | berco: got results for you. | 15:27 |
| mpoirier | berco: 'cat /proc/asound/cards' indeed reports "TI OMAP4 SDP4430 Board" | 15:28 |
| ogra | GrueMaster, pandora ? i thought that was still vaporware ... did they ever actually release something ? | 15:30 |
| GrueMaster | Yes. They are actually shipping. | 15:30 |
| berco | mpoirier: cool | 15:30 |
| mpoirier | GrueMaster: I'll get back to you. | 15:30 |
| ogra | wow | 15:30 |
| mpoirier | berco: we are not out of the woods | 15:31 |
| * ogra remembers them announcing it in 2007 or so | 15:31 | |
| berco | mpoirier: is that the only string? | 15:31 |
| mpoirier | berco: hummm... good question. you get a kernel message and a user space returned messages. | 15:32 |
| ogra | on the daily image it currently reports SDP4430 too fwiw | 15:32 |
| mpoirier | berco: I'll use a pastebin - hold on. | 15:32 |
| ogra | (not TI OMAP4 in front nor Board in the end though) | 15:32 |
| jo-erlend_nb | are imap4 boards already available? | 15:33 |
| mpoirier | berco: http://paste.ubuntu.com/499164/ | 15:33 |
| ogra | jo-erlend_nb, no | 15:33 |
| ogra | but soon | 15:33 |
| berco | mpoirier: looks better. however asoc string should be replaced to something else to my thinking | 15:34 |
| mpoirier | berco: we have a bigger problem - let me explain. | 15:35 |
| mpoirier | I did 3 longs days of soul searching in sdp4030.c and twl6040.c. Know how things get initialized. | 15:35 |
| mpoirier | berco: to about 90 % i'd say. With what you wrote in the scripts, I think you can bridge the last 10% for me. | 15:36 |
| mpoirier | so, when the kernel boots all the DAIs are associated to the SDP4030 card. | 15:37 |
| mpoirier | things stay still until a user log in. | 15:37 |
| mpoirier | when logging in, 'snd_soc_pcm_open' in soc-core.c gets called. | 15:38 |
| mpoirier | this is where things go south... | 15:38 |
| * berco is still listening | 15:39 | |
| mpoirier | in there, 'snd_soc_get_backend_dais' is called, which is where I've isolated the problem to. | 15:39 |
| mpoirier | I've enable debugging and get the following output: (let me use a pastebin). | 15:40 |
| mpoirier | berco: http://paste.ubuntu.com/499170/ | 15:41 |
| mpoirier | berco, over and over again, which tells me someone in userspace is trying to get information from the card . | 15:42 |
| === hrw is now known as hrw|gone | ||
| mpoirier | berco, when running the scripts DAIs get resolved and the messages go away (I'll use another pastebin). | 15:43 |
| berco | mpoirier: hold on a second please | 15:43 |
| mpoirier | ok | 15:43 |
| rsalveti | jo-erlend_nb: sorry, got distracted: http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-43_armel.deb | 15:44 |
| jo-erlend_nb | thanks. | 15:44 |
| berco | mpoirier: ok, just explaining my colleague what we discussed so far as he has a better audio background than me :) | 15:46 |
| berco | mpoirier: everything makes sense in your findings | 15:46 |
| mpoirier | berco: That's the 10% i get lost and would welcome help from people in the know. | 15:47 |
| berco | mpoirier: now, our understanding is that you have a string "AsoC - SDP4430" reported by "cat /proc/asound/cards" | 15:47 |
| mpoirier | berco: absolutely | 15:47 |
| mpoirier | berco: hold on actually. | 15:48 |
| berco | mpoirier: and we should write a "/usr/share/alsa/cards/asoc.conf" file that would include all our amixer script settings | 15:48 |
| mpoirier | berco: this is new to me. let me check. | 15:48 |
| mpoirier | berco: let me guess, I should find a "SDP4430.conf " in there ? | 15:49 |
| berco | mpoirier: I did the test on my PC which as an HDA-Intel audio card | 15:49 |
| berco | This HDA-Intel string is reported in /proc/asound/cards on my PC and I can see the HDA-Intel.conf gets read | 15:50 |
| berco | mpoirier: no SDP4430.conf is for me a wrong name | 15:50 |
| berco | mpoirier: the file name should correspond to the first half of the string before the hyphen character | 15:51 |
| berco | mpoirier: "AsoC - SDP4430" | 15:51 |
| berco | mpoirier: I can see in the patch that "AsoC" is the card->snd_card_driver name | 15:52 |
| jo-erlend_nb | rsalveti, after I installed libertas-firmware, I can see wireless networks in nm-applet. However, I can't seem to connect to my AP. I'm using wpa2+. Do you know any reason why that wouldn't work? | 15:52 |
| berco | mpoirier: not a good name but for testing it should be enough | 15:52 |
| rsalveti | jo-erlend_nb: hm, don't know, could be a firmware/driver limitation | 15:53 |
| mpoirier | berco: let's go back to http://paste.ubuntu.com/499164/ | 15:53 |
| berco | mpoirier: do you have mean to share the kernel? And can work on the script file if you want | 15:53 |
| berco | mpoirier: ok | 15:54 |
| mpoirier | berco: the first line comes from the kernel. | 15:54 |
| mpoirier | the second is in user space. | 15:54 |
| berco | mpoirier: yes | 15:54 |
| berco | mpoirier: all is kernel. AsoC is a generic framework for audio driver. Probably why they chose that name. | 15:55 |
| mpoirier | berco: if I follow you properly, it's not reading "ASoc" but "TI OMAP4 SDP4430 Board" | 15:55 |
| berco | mpoirier: this driver can manage several sound cards from several companies | 15:55 |
| berco | mpoirier: ? | 15:56 |
| berco | mpoirier: what is reading "TI ... ? | 15:56 |
| mpoirier | berco: brain bug on my side. | 15:56 |
| berco | mpoirier: I think it's alsa in user space which is calling the snd_xxx functions... | 15:57 |
| mpoirier | I was under the impression the content of /proc/asound/cards was "TI OMAP4 SDP4430" only. | 15:57 |
| mpoirier | and 0 [SDP4430 ]: ASoC - SDP4430 was a debug messages coming from the query request. | 15:57 |
| mpoirier | it is not the case. | 15:57 |
| berco | mpoirier: ok :) I see. No everything comes from it | 15:58 |
| mpoirier | berco: let's resume. | 15:58 |
| mpoirier | therefore, we should find ASoC.conf under /usr/share/alsa/cards ? | 15:58 |
| berco | mpoirier: now, I understand why we disconnected :) | 15:59 |
| berco | mpoirier: absolutely | 15:59 |
| berco | mpoirier: that's my understanding | 15:59 |
| mpoirier | berco: I have a feeling this fine should contains settings that are related to my second pastebin. Am I correct ? | 16:00 |
| mpoirier | s/fine/file | 16:00 |
| berco | mpoirier: exactly. This .conf file should contain the amixer settings and that should provide valid audio path to alsa and get rid of your second pastebin error message | 16:01 |
| berco | mpoirier: now, an other funny part is the format of this .conf file :) | 16:02 |
| berco | mpoirier: I need to fix my cross compile environment to build my own kernel and help you with this testing | 16:03 |
| mpoirier | berco: I can accept and test any patches you can give me. | 16:03 |
| mpoirier | berco: my turn around is very quick - everything is setup on my side. | 16:04 |
| lool | ogra: We currently copy the boot.scr into the boot.ini when writing the image | 16:04 |
| mpoirier | berco: it depends on how tedious you think the process will be. | 16:04 |
| ogra | lool, but not with flash-kernel | 16:04 |
| berco | mpoirier: thanks a lot for your help. I should be able to get back to you tomorrow | 16:04 |
| ogra | i.e. when updating the kernel | 16:05 |
| lool | ogra: I didn't think flash-kernel had to touch it in our case | 16:05 |
| ogra | ah | 16:05 |
| ogra | well, we use a /boot/boot.script file as input so we regenerate it on every flash-kernel run | 16:06 |
| lrg | mpoirier, berco: fwiw, this file + driver patch is still work in progress. Should be a newer fix tomorrow. | 16:06 |
| ogra | (since we hide the actual vfat partition) | 16:06 |
| berco | lrg: are you also preparing this .conf file? | 16:07 |
| lrg | berco: yes, the audio team is working on this. | 16:07 |
| === amitk is now known as amitk-afk | ||
| mpoirier | GrueMaster: I will start looking in omap3-beagle.c and omap3-pandora.c . | 17:17 |
| GrueMaster | What I was going to say was that the omap3beagle maps the entire codec in the dai, whereas the omap3pandora only maps the used channels. The omap3evm should map the entire codec as it is an evaluation board. Beagle is not. | 17:18 |
| GrueMaster | But if ASOC is heading towards a userspace conf file format, that may be the better solution. | 17:19 |
| GrueMaster | I only spent about an hour looking at the code. But we should be able to get a solution fairly quickly. | 17:20 |
| === ogra_ac2 is now known as ogra_ac | ||
| GrueMaster | Something happened to the dove image. It no longer has a partition table in today's image. Very odd. | 18:30 |
| GrueMaster | ogra, NCommander: ^^^ | 18:31 |
| ogra_cmpc | GrueMaster, a partition table ? | 18:45 |
| ogra_cmpc | in a *dove* image ? | 18:45 |
| GrueMaster | Yes. It should have 1 partition, vfat. | 18:45 |
| ogra_cmpc | right but no table | 18:45 |
| GrueMaster | If you have a partition, you have a partition table. | 18:46 |
| GrueMaster | Otherwise the raw device is one big filessytem. | 18:46 |
| GrueMaster | I.e. /dev/sdh vs /dev/sdh1 | 18:46 |
| ogra_cmpc | ogra@antimony:~/branches/debian-cd$ bzr pull | 18:46 |
| ogra_cmpc | No revisions to pull. | 18:46 |
| ogra_cmpc | ... | 18:47 |
| ogra_cmpc | no changes | 18:47 |
| ogra_cmpc | i dont think we ever partitioned dove | 18:47 |
| GrueMaster | After running dd if=maverick-netbook-armel+dove.img of=/dev/sdh bs=4M, I should see /dev/sdh1. I do not with todays image. | 18:48 |
| ogra_cmpc | parted -s "$IMAGE" mklabel msdos | 18:48 |
| ogra_cmpc | hmm, we apparently do | 18:49 |
| ogra_cmpc | well, there are no code changes at all | 18:52 |
| ogra_cmpc | GrueMaster, are you 100% sure thats only with todays image ? | 18:52 |
| ogra_cmpc | i.e. yesterdays was for sure ok | 18:53 |
| GrueMaster | As soon as I am done flashing today's omap image for my beagle, I will double check yesterdays. | 18:53 |
| ogra_cmpc | k | 18:53 |
| GrueMaster | I know for a fact that 20100920 was good. No build on 20100921. | 18:53 |
| ogra_cmpc | i know antimony was upgraded to lucid but thats a few days ago | 18:53 |
| GrueMaster | Should have been done earlier in the cycle. | 18:54 |
| ogra_cmpc | yes ... | 18:54 |
| ogra_cmpc | but now its there | 18:54 |
| ogra_cmpc | checking the partitioning code, its identical for omap, omap4 and dove | 18:54 |
| ogra_cmpc | so it cant be a newer parted or some such | 18:55 |
| GrueMaster | Gah, flashing images to SD takes forever. | 18:55 |
| ogra_cmpc | yeah :( | 18:55 |
| GrueMaster | And if I try to flash to two USB devices at the same time, my Core2Quad becomes quite unstable. | 18:56 |
| GrueMaster | Even though they are on separate USB busses. | 18:56 |
| ogra_cmpc | file a bug ... kernel issue | 18:56 |
| ogra_cmpc | or HW | 18:56 |
| GrueMaster | No, I think it is hardware related. Wife's computer has the same issue, and she runs that "other" OS. | 18:57 |
| ogra_cmpc | its the CPU ! | 18:57 |
| GrueMaster | Pffft. | 18:57 |
| ogra_cmpc | wrong vendor ! | 18:57 |
| GrueMaster | I do need to nuke & pave it though. Running i386 install. Should run x86_64. | 18:59 |
| Neko_ | ogra, see ubiquity bug, making real progress on this :] | 19:11 |
| Neko_ | there is an upstart bug that means it won't "stop" an already running thing, so gdm and ubiquity-dm will just fight it out because it will refuse to quit running gdm just because ubiquity is running | 19:12 |
| Neko_ | but, I could connect to wireless from in oem-config GUI and apart from how ugly as sin it is, it worked great until it nuked trying to do a symlink :D | 19:12 |
| ogra_cmpc | Neko_, well, we use iit daily on our images and never hit such bugs | 19:13 |
| ogra_cmpc | i personally also find it quite beautiful | 19:13 |
| ogra_cmpc | Neko_, you are using maverick, right ? | 19:13 |
| Neko_ | yes :) | 19:14 |
| Neko_ | I think part of it is we're using a fat partition for /boot | 19:14 |
| ogra_cmpc | did you ever consider just using the readily produced images ? | 19:15 |
| Neko_ | what are you using for disks on your systems? | 19:15 |
| Neko_ | what readily produced images | 19:15 |
| ogra_cmpc | the dailies we build | 19:15 |
| Neko_ | there are the dailies for dove etc. but they're installers | 19:15 |
| Neko_ | we can't hack in our kernel to those | 19:15 |
| Neko_ | gimme a URL so I can see what you're talking about? :/ | 19:16 |
| GrueMaster | Neko_: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ | 19:16 |
| ogra_cmpc | http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ | 19:16 |
| Neko_ | ugh .img? | 19:16 |
| ogra_cmpc | Neko_, you need to generate the inird with the rootfs on the second partition but beyond that it shouldnt be difficult to add another kernel | 19:17 |
| Neko_ | what's the 16MB of difference between the two, just kernel stuff? | 19:17 |
| ogra_cmpc | (initrd is essential) | 19:17 |
| ogra_cmpc | yes | 19:17 |
| Neko_ | I mean given the choice they're identical in terms of packages | 19:17 |
| Neko_ | and it's UNE right | 19:17 |
| GrueMaster | yes | 19:17 |
| ogra_cmpc | right | 19:18 |
| Neko_ | but we don't want UNE. | 19:18 |
| Neko_ | UNE is too touchscreeny and weird | 19:18 |
| * ogra_cmpc uses it on a 24" 1920x1280 screen on omap4 ... i dont find it touchscreeny | 19:19 | |
| Neko_ | the scrollbar is backwards like a touchscreen "drag" would be | 19:19 |
| Neko_ | you drag it up and it scrolls down | 19:19 |
| ogra_cmpc | no | 19:19 |
| ogra_cmpc | that was a bug that was fixed long ago | 19:19 |
| Neko_ | have you ever considered that people might just want a normal gnome desktop? ;_; | 19:19 |
| ogra_cmpc | the image ships a normal gnome desktop too | 19:20 |
| GrueMaster | It is there as well. You can select it at the gdm login. | 19:20 |
| Neko_ | ... oem-config first though right? :) | 19:20 |
| ogra_cmpc | jasper first | 19:20 |
| ogra_cmpc | then oem-config | 19:20 |
| Neko_ | whats jasper and what is it doing for me | 19:20 |
| ogra_cmpc | then netbook UI | 19:20 |
| ogra_cmpc | it does the initial system setup | 19:21 |
| ogra_cmpc | growing the rootfs to teh full size of the SD ... | 19:21 |
| ogra_cmpc | system setup ... | 19:21 |
| Neko_ | oh fuck that I am going to loop mount the image and make a tarball | 19:21 |
| ogra_cmpc | optimization for SD card | 19:21 |
| Neko_ | the thing is going to be on a 16GB SSD | 19:21 |
| ogra_cmpc | jasper lives in the inird | 19:21 |
| Neko_ | which we don't have :D so... good | 19:22 |
| ogra_cmpc | (thats why i said initrd is essential on these images) | 19:22 |
| ogra_cmpc | well, its easy to roll one | 19:22 |
| Neko_ | you'd think.. | 19:22 |
| ogra_cmpc | install your kernel package in the rootfs and just run update-initramfs | 19:22 |
| Neko_ | we don't haaave a kernel package | 19:23 |
| ogra_cmpc | tr8ivial | 19:23 |
| ogra_cmpc | ugh | 19:23 |
| ogra_cmpc | how do you apply security updates ? | 19:23 |
| Neko_ | for some reason the kernel stuff is all reliant on some weirdo 2.6.33+ stuff | 19:23 |
| ogra_cmpc | oh | 19:23 |
| Neko_ | markos is having trouble getting our 2.6.31 to build using the correct packaging | 19:23 |
| ogra_cmpc | well, then i see why you have upstart probs | 19:23 |
| GrueMaster | ogra_cmpc: Issue with today's omap4 image. Running oem-config, something has used up my entire 7.2G of root partition. May be related to encrypted home dir. | 19:23 |
| Neko_ | oh no, do not blame this on the kernel:D | 19:23 |
| Neko_ | upstart has absolutely no reliance on any feature of the kernel in that manner | 19:24 |
| ogra_cmpc | Neko_, upstart relies on a 2.6.35 kernel | 19:24 |
| Neko_ | in what way | 19:24 |
| ogra_cmpc | ask Keybuk in #ubuntu-devel | 19:24 |
| ogra_cmpc | upstart and udev in ubuntu are always tied to the kernel | 19:24 |
| Neko_ | is this something that got hastily put in after you dropped mx51 support or has it always been that way? | 19:25 |
| ogra_cmpc | there are surely more userspace tools that expect certain kernel features | 19:25 |
| ogra_cmpc | it has always been that way | 19:25 |
| Neko_ | christ.... | 19:25 |
| ogra_cmpc | in some releases more in some less | 19:25 |
| ogra_cmpc | ask our kernelteam how much they suffered from backporting changes to the imx kernels :) | 19:26 |
| Neko_ | oh we had the same troubles here believe me | 19:26 |
| Neko_ | Freescale keep promising a 2.6.35 | 19:27 |
| ogra_cmpc | i bet they still do | 19:27 |
| Neko_ | the last we heard was "we can get you a snapshot maybe october 15th" | 19:27 |
| Neko_ | then they said "no shapshot just wait for the bsp" | 19:27 |
| Neko_ | that's probably november 30th | 19:27 |
| Neko_ | we are pushing it to higher management | 19:27 |
| ogra_cmpc | yeah ... enjoy the wait | 19:27 |
| ogra_cmpc | get some icecream meanwhile :P | 19:27 |
| GrueMaster | Nah. It would melt too fast. | 19:28 |
| ogra_cmpc | no, you eat it and get more :) | 19:28 |
| Neko_ | they really really want Maverick because they just realised Karmic blows donkey cock.. we explained they had better back us up and then they said "but we have no roadmap we thought you would do it all" | 19:28 |
| Neko_ | it's really a mess.. Linaro are too focused on mainline, we need BSPs | 19:28 |
| ogra_cmpc | well, letting BSPs die is linaros mission | 19:28 |
| ogra_cmpc | and a good one imho | 19:29 |
| Neko_ | it's a 5 year mission | 19:29 |
| ogra_cmpc | in any case, if your oem-config issues are upstart related i'd take a look at the kernel | 19:30 |
| Neko_ | to boldly go where no man has gone before | 19:30 |
| Neko_ | no doubt, like every other ship that isn't the Enterprise, it will end up as a debris field | 19:30 |
| ogra_cmpc | the more people help, the shorter the timefarme will get | 19:30 |
| GrueMaster | ogra_cmpc: For some reason, my omap4 image swap file is 5.5G. Jasper log looks ok, so I doubt it has anything to do with it. | 19:34 |
| ogra_cmpc | GrueMaster, the swap file ? | 19:34 |
| * ogra_cmpc blames rsalveti | 19:34 | |
| ogra_cmpc | :P | 19:34 |
| GrueMaster | Why? Jasper looks ok. | 19:35 |
| ogra_cmpc | ogra@panda:~$ ls -lh /SWAP.swap | 19:35 |
| ogra_cmpc | -rw-r--r-- 1 root root 512M 2010-09-22 11:38 /SWAP.swap | 19:35 |
| ogra_cmpc | its exactly as big as it should be here | 19:35 |
| GrueMaster | ls -lh mnt/SWAP.swap | 19:36 |
| GrueMaster | -rw-r--r-- 1 root root 5.5G 2010-09-23 11:11 mnt/SWAP.swap | 19:36 |
| ogra_cmpc | woah | 19:36 |
| GrueMaster | Yea. bit on the plus side. | 19:37 |
| ogra_cmpc | i'll try to reproduce tomorrow | 19:37 |
| GrueMaster | I'll continue on it now. I think it has to do with encrypted home directory. What would I file this under if I reproduce it? | 19:37 |
| ogra_cmpc | hmm | 19:38 |
| ogra_cmpc | good question | 19:38 |
| GrueMaster | this is why I have a hard time filing some bugs. | 19:38 |
| GrueMaster | I can spend hours trying to find the right package. | 19:38 |
| ogra_cmpc | ecryptfs-utils probably | 19:38 |
| ogra_cmpc | or cryptsetup | 19:39 |
| ogra_cmpc | if you reliably can point to the encrypted home | 19:39 |
| GrueMaster | I'll pick one. It will be wrong, but let someone in triage figure it out. | 19:39 |
| GrueMaster | :P | 19:39 |
| ogra_cmpc | well, they are deps of ubiquity | 19:39 |
| ogra_cmpc | one of them is responsible for the homedir stuff | 19:40 |
| GrueMaster | First I will try on my 16G SD. If that gets bloated, I'll go from ther. | 19:40 |
| GrueMaster | there | 19:40 |
| ogra_cmpc | afaik vstehle uses encrypted home on all his test installs | 19:40 |
| ogra_cmpc | i havent heard from him since we enabled swap creation again | 19:41 |
| ogra_cmpc | which i'd see as a good sign | 19:41 |
| ogra_cmpc | i really wouldnt mind dropping swap on omap4 to be honest | 19:42 |
| GrueMaster | Could. It is not as critical as on beagle. | 19:42 |
| ogra_cmpc | well, even there only on C4 | 19:42 |
| GrueMaster | Might actually speed it up a bit due to SD I/O. | 19:42 |
| ogra_cmpc | only if it swaps :) | 19:43 |
| GrueMaster | And I meant beagle, not XM. | 19:43 |
| ogra_cmpc | heh | 19:43 |
| GrueMaster | And apparently mine did swap a little. | 19:43 |
| ogra_cmpc | well, it cant swap beyond the size we gave it | 19:44 |
| ogra_cmpc | its not some magically autogrowing file | 19:44 |
| GrueMaster | Yea, I'll keep that in mind when I look at the 5.5G file again. | 19:45 |
| ogra_cmpc | it can actually only have happened at creation time | 19:45 |
| GrueMaster | I looked at the jasper log and it looked ok. | 19:46 |
| ogra_cmpc | dd if=/dev/zero of=${DIR}/root/SWAP.swap bs=1048576 count=512 >>$LOGFILE 2>&1 | 19:46 |
| GrueMaster | The size reported in the log was nowhere close to this. | 19:46 |
| ogra_cmpc | i dont see how that would create a 5.5G file | 19:46 |
| ogra_cmpc | yes, but it cant just grow | 19:47 |
| GrueMaster | Theory vs Reality. I don't know either, but will look at the logs more as soon as I finish flashing the other SD. | 19:48 |
| GrueMaster | And XM is fine (although I didn't add encrypted home dir on it). | 19:49 |
| rsalveti | ouch, 5.5G of swap? | 19:49 |
| rsalveti | makes no sense | 19:49 |
| GrueMaster | Yea. I'm big, but not that big. | 19:49 |
| GrueMaster | Also, why am I seeing mtdblock 0 errors during jasper on beagle (not XM). | 19:50 |
| Neko_ | why don't you just use qualifiers for the dd arguments | 19:50 |
| Neko_ | bs=1M count=512 | 19:50 |
| ogra_cmpc | precision :) | 19:50 |
| GrueMaster | From the dmesg log: [ 7.045257] Adding 524284k swap on /SWAP.swap. Priority:-1 extents:137 across:2219040k SS | 19:53 |
| GrueMaster | Looks ok so far. | 19:53 |
| ogra_cmpc | yes | 19:54 |
| ogra_cmpc | do you see 5.5G on the running system too ? | 19:54 |
| ogra_cmpc | (with ls) | 19:55 |
| GrueMaster | Just booted it. oem-config now up. | 19:55 |
| ogra_cmpc | oem-config ? | 19:55 |
| GrueMaster | Yes. Fresh SD install. | 19:56 |
| ogra_cmpc | oh, i meant the one that had the 5.5G file | 19:56 |
| GrueMaster | I have two SD cards I use for panda. One I am looking at, the other is now booting to reproduce the issue. | 19:56 |
| GrueMaster | On the SD with 5.5G, oem-install failed with an out of space error. | 19:57 |
| GrueMaster | Stopped at that point to debug. | 19:57 |
| ogra_cmpc | ah | 19:58 |
| GrueMaster | From oem-config.log: debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: No space left on device | 19:58 |
| GrueMaster | Not sure what stage that is. | 19:58 |
| ogra_cmpc | relatively to the end | 19:58 |
| ogra_cmpc | but doesnt matter | 19:58 |
| ogra_cmpc | as long as the user can input stuff debconf is only read afaik | 19:59 |
| GrueMaster | Interesting. After creating the user, there is a message in oem-config that it is wiping swap space for security. | 19:59 |
| GrueMaster | That may be doing it. | 19:59 |
| ogra_cmpc | only the content though | 19:59 |
| ogra_cmpc | the file shouldnt grow | 19:59 |
| GrueMaster | depends on how it is trying to wipe it. If it is just doing "dd if=/dev/zero of=<SWAP Space>". | 20:00 |
| GrueMaster | Since we are using a file, it is very possible that this is what is happening. | 20:01 |
| ogra_cmpc | oh, that would be a possibiltty | 20:01 |
| GrueMaster | It is used to wiping a predefined partition. | 20:01 |
| ogra_cmpc | well, kees is busy talking in -devel | 20:01 |
| ogra_cmpc | he's the security expert | 20:01 |
| * ogra_cmpc gets dinner and will vanish until the call now | 20:02 | |
| kees | hola | 20:04 |
| rsalveti | hey | 20:04 |
| GrueMaster | So I am testing our daily images and found that when oem-install creates a new user with home dir encryption, our /SWAP.swp file ends up filling the entire SD card. | 20:05 |
| GrueMaster | How is ubiquity zeroing the swap space? | 20:05 |
| rsalveti | ouch, interesting bug | 20:05 |
| GrueMaster | rsalveti: It's my hidden talent. | 20:06 |
| rsalveti | so not caused by me :-) | 20:06 |
| rsalveti | GrueMaster: haha :-) | 20:06 |
| kees | GrueMaster: well, first of all, oem-install probably shouldn't enable home dir encryption, that's not the default in the other ISOs | 20:16 |
| kees | GrueMaster: secondly, it writes zeros to the entire partition, IIRC. | 20:16 |
| GrueMaster | It isn't? | 20:16 |
| GrueMaster | Seems to me, it is part of user creation, which on preinstalled images would be appropriate for oem-install. | 20:17 |
| GrueMaster | As to the zeroing the entire partition, I can see that. | 20:17 |
| DanaG | http://www.engadget.com/2010/09/23/marvell-unveils-1-5ghz-triple-core-application-processor-all-cu/#comments | 20:18 |
| DanaG | Spiffy. | 20:18 |
| mpoirier | GrueMaster: I just had a look at omap3beagle.c and omap3pandora.c | 20:40 |
| GrueMaster | ok. Cool. I've been swamped with swap issues. | 20:40 |
| mpoirier | the scheme set forth in omap3 land is interesting - one card definition per board. | 20:41 |
| GrueMaster | Yea, I think that may be the old way of doing it. I think they are trying to shift towards "expose all - config in userspace". | 20:42 |
| GrueMaster | Which would make the most sense. | 20:42 |
| mpoirier | if we were to continue this in omap4 land, sdp4430.c *could* become sdp4430panda.c | 20:42 |
| GrueMaster | Easier to add a config file on the fly than patch->build->test kernel. | 20:42 |
| GrueMaster | I think for now, we want the fastest solution. We can look for the best solution in Natty. | 20:43 |
| mpoirier | Well, hold on - this scheme solves only half the puzzle. | 20:44 |
| GrueMaster | What is the other half? Pulseaudio? | 20:44 |
| mpoirier | omap3 land was not as refined as omap4 and therefore cards had to put their cpu_dai in the snd_sod_dai_link definitions. | 20:45 |
| mpoirier | in omap4 they have replace the hard coded scheme by a naming convention. | 20:45 |
| mpoirier | which is exactly what is being done in twl6040.c with the end result being exactly the same. | 20:45 |
| mpoirier | that is, we haven't found a way to push front-end and back-end dai configuration to the kernel. | 20:46 |
| mpoirier | without scripts that is. | 20:46 |
| mpoirier | Right now the TI audio team is looking at fixing /proc/alsa/cards and giving us a proper ASoC.conf file, | 20:47 |
| mpoirier | which will solve the problem. | 20:47 |
| mpoirier | Patches are on the way. | 20:48 |
| GrueMaster | Ok. Is that omap4 or all? | 20:48 |
| mpoirier | First omap3. | 20:48 |
| mpoirier | sorry, omap4, first omap4. | 20:48 |
| GrueMaster | So for omap3, we could just tweak omap3beagle.c for now. | 20:49 |
| GrueMaster | And pick up the ASoC.conf in Natty. | 20:49 |
| mpoirier | hold on, I got an idea... | 20:49 |
| mpoirier | I'll get back to you shortly. | 20:50 |
| GrueMaster | I'll be here. | 20:51 |
| mpoirier | GrueMaster: I **think** I just bridged the gap. | 20:52 |
| mpoirier | do you have time to hear it ? | 20:53 |
| GrueMaster | Sure. | 20:53 |
| mpoirier | Do you have a running beagleboard in front of you ? | 20:53 |
| GrueMaster | beagle, XM, and two pandas. | 20:53 |
| mpoirier | are they all running ? | 20:54 |
| GrueMaster | pandas are finishing oem-install now. | 20:54 |
| GrueMaster | all are running otherwise. Fresh images as of this morning. | 20:54 |
| mpoirier | ok sure - in anycase you don't have the proper patch for omap4 so it won't matter. | 20:54 |
| mpoirier | It all starts from my little chat with berco this morning. | 20:55 |
| GrueMaster | right. | 20:55 |
| mpoirier | berco gave me a patch that output http://paste.ubuntu.com/499164/ in /proc/asound/cards | 20:56 |
| mpoirier | the "ASoC" is the important part here. | 20:57 |
| GrueMaster | ok | 20:57 |
| mpoirier | yes, bare with me, I have a lot of layers to peel. | 20:57 |
| DanaG | USB 3.0 ARM... sounds perfect for a NAS. | 20:58 |
| mpoirier | GrueMaster: just a sec. | 20:59 |
| mpoirier | GrueMaster: sorry, need to organize brain. | 21:02 |
| GrueMaster | Take your time. | 21:02 |
| mpoirier | GrueMaster: we know from omap3beagle.c and omap3pandora.c that sound card are named per board. | 21:03 |
| mpoirier | that is, omap3beagle.c defines the sound card for beagle and omap3pandora.c for pandora. | 21:03 |
| mpoirier | that information is exported in /proc/alsa/cards | 21:04 |
| mpoirier | from that information /usr/share/alsa/cards/ is search from the right card. | 21:05 |
| GrueMaster | Ok, following so far. | 21:05 |
| mpoirier | from my conversation with berco this morning, bridge between front and backend dais are made from those files. | 21:05 |
| lrg | mpoirier: google for alsa UCM | 21:06 |
| GrueMaster | It can be. It looks like omap3pandora is doing that internally though. | 21:06 |
| mpoirier | Irg: good you're on. | 21:06 |
| DanaG | Why does omap3beagle have so many extra pins (such as "handsfree" and "predrive") that aren't wired on the board? | 21:06 |
| DanaG | If it's per-board, couldn't they hide those? | 21:06 |
| rsalveti | probably copy paste | 21:06 |
| rsalveti | from other board | 21:07 |
| mpoirier | Irg: do you know exactly what field in the .conf file alsa is looking for ? | 21:07 |
| lrg | mpoirier: looking for what ? | 21:08 |
| === ian_brasil__ is now known as ian_brasil | ||
| GrueMaster | DanaG: It looks simpler than copy/paste. I would guess that it was just to expose the entire codec. | 21:08 |
| mpoirier | the patch that you wrote this morning write ASoC in /proc/alsa/cards | 21:09 |
| mpoirier | according to berco, alsa then looks for ASoC.conf under /usr/share/cards/ | 21:09 |
| lrg | that's changed to card name now | 21:09 |
| mpoirier | Irg: yes good idea. | 21:09 |
| lrg | fwiw, the alsa conf method is only a stopgap atm | 21:10 |
| lrg | UCM is the prefered solution | 21:10 |
| rlameiro | evening evryone | 21:10 |
| lrg | UCM is currently in the alsa-lib ucm branch | 21:10 |
| lrg | and will hopefully be in master soon | 21:10 |
| DanaG | What does UCM stand for? | 21:11 |
| lrg | Use Case Manager | 21:11 |
| mpoirier | Irg: I'll look at UCM as soon as we're done. | 21:11 |
| DanaG | ah. | 21:11 |
| mpoirier | Irg: for the next 7 days though, we need a way to configure our cards. | 21:11 |
| GrueMaster | lrg: It is still very wip. | 21:11 |
| lrg | it will be ready for in the next few weeks | 21:12 |
| mpoirier | Irg: and from what I gathered in the past couple of days, I *think* we have a clean solution. | 21:12 |
| GrueMaster | lrg: We have release on 10/10. | 21:12 |
| rlameiro | what is a Use case manager? | 21:12 |
| lrg | GrueMaster: I was thinking 4/11 | 21:13 |
| GrueMaster | Feature freeze was several months ago. | 21:13 |
| mpoirier | Irg: for 4/11, I can sure put it in. | 21:13 |
| GrueMaster | lrg: Definitely a possibility for 11.04 | 21:13 |
| lrg | GrueMaster: it will be part of alsa-lib by then (i.e. next alsa-lib release) | 21:13 |
| rlameiro | when is the final freeze? like no more stuff until launch? | 21:14 |
| GrueMaster | absolute zero is 10/6. | 21:14 |
| GrueMaster | Bug fixes with a lot of begging now. | 21:14 |
| rlameiro | lol | 21:15 |
| rlameiro | so i need to get starting on my USB audio intrface bug | 21:15 |
| GrueMaster | rlameiro: if you have a patch and want it fixed, do it quickly. Still, no guarantees it will make release. May have to go sru and be added to mav-updates. | 21:17 |
| mpoirier | Irg: back to my question: which part of /proc/alsa/cards is alsa looking for to seach configuration file under /usr/share/alsa/cards/ ? | 21:18 |
| rlameiro | I even dont know what is wrong... | 21:18 |
| rlameiro | I think i am betting for natty | 21:18 |
| rlameiro | :( | 21:18 |
| rlameiro | I am kinda disapointed with audio stuff on the Arm platform | 21:19 |
| GrueMaster | rlameiro: If you can reproduce it on x86, that would make things easier I think. usb-audio shouldn't change between arch's. | 21:19 |
| rlameiro | but changes | 21:19 |
| rlameiro | and as far as i know, there are diferent stuff on alsa, between arm/x86 | 21:19 |
| rlameiro | for instance ASoC | 21:19 |
| lrg | mpoirier: the driver name, so in this case SDP4430 (instead of ASoC) | 21:20 |
| GrueMaster | Besides the obvious. arm also doesn't support HD Audio. | 21:20 |
| rlameiro | why? to save power? | 21:20 |
| GrueMaster | rlameiro: HD Audio is build in to x86 motherboards. It is a different bus architecture. | 21:22 |
| GrueMaster | But usb is usb. | 21:23 |
| rlameiro | well, never like hd audio so for me is irrelevant | 21:23 |
| DanaG | HD Audio is a bus, just like AC97 is a bus, right? | 21:24 |
| DanaG | Like, some Creative cards have had an AC97 bus controller, and an AC97 codec somewhere. | 21:24 |
| GrueMaster | The point is that the usb audio driver on x86 is the same code for the usb audio driver on arm. | 21:24 |
| rlameiro | yeap usb should work on the 2 sides, unless the code is different or crippled for size concerns | 21:24 |
| DanaG | And C-Media has a vaporware USB-Audio thing that has an HD Audio bus controller. | 21:24 |
| GrueMaster | DanaG: In it's simplist form, yes. | 21:24 |
| mpoirier | Irg: my I suggest... | 21:25 |
| DanaG | I just wish somebody would make a freaking ExpressCard C-Media Oxygen (or such) card. | 21:25 |
| mpoirier | Irg: to call it something more card related... Something like SDP4430panda ? | 21:25 |
| mpoirier | that way, when another card is released, we could call it SDP4430another_card. | 21:26 |
| mpoirier | Irg: i'm replicating the scheme put forward in omap3beagle.c and omap3pandora.c | 21:26 |
| GrueMaster | I agree with mpoirier's idea. We should be able to whip it out in minutes, vs trying to figure out what an ASoC.conf file would need. | 21:26 |
| rlameiro | GrueMaster: for isntance, my usb audio has an alsa addon to quircks, in order for the device to have its full extended usage | 21:26 |
| DanaG | I hope that panda will become available soonish. | 21:26 |
| DanaG | My CM106 USB card is silent with default Windows USB-Audio drivers. | 21:27 |
| DanaG | And it only supports 7.1-channel -- no 5.1 or stereo! | 21:27 |
| mpoirier | Irg: I'm not an expert... I'm just thinking with what I learned lately... | 21:27 |
| rlameiro | GrueMaster: and i am not sure if this driver has it, altough midi does apear on alsamixer for my device | 21:27 |
| DanaG | In my case, the hardware really is buggy. | 21:27 |
| GrueMaster | Ok, not to be picky, but we really need to focus on asoc issues atm. We are getting too much chatter in the channel. | 21:28 |
| lrg | mpoirier: the name will be the same as the mach driver, and SDP4430 is just another development board like panda. Fwiw we may decide to create a separate mach driver for panda if it becomes necessary | 21:29 |
| lrg | so maybe omap4panda will be better | 21:30 |
| GrueMaster | Sounds reasonable to me. | 21:30 |
| rlameiro | where are the packages for arm? for download? | 21:30 |
| mpoirier | Irg: it would follow the omap3XYZ scheme already widly known | 21:30 |
| lrg | yes | 21:31 |
| GrueMaster | rlameiro: http://ports.ubuntu.com | 21:31 |
| rlameiro | thanks | 21:31 |
| rlameiro | sorry GrueMaster, but i cant find the sources for the kernel I have installed | 21:37 |
| GrueMaster | rlameiro: If you type "apt-cache show <package> it will tell you the name of the source package. It will be in pool/main/ somewhere. | 21:41 |
| GrueMaster | what kernel are you running? | 21:41 |
| rlameiro | linaro | 21:41 |
| rlameiro | well, I need to powerup my board then | 21:42 |
| GrueMaster | http://ports.ubuntu.com/pool/main/l/linux-linaro/ | 21:43 |
| GrueMaster | look there. | 21:43 |
| GrueMaster | You will want linux-linaro_2.6.35.orig.tar.gz, linux-linaro_2.6.35-1006.12.diff.gz and linux-linaro_2.6.35-1006.12.dsc | 21:44 |
| rlameiro | no source in ther, just binaries | 21:44 |
| GrueMaster | The first file is a compressed tarball of the main source tree. The second file is their current patchset. the third is used by debian build utilities. | 21:47 |
| GrueMaster | Hmmm. "NAME = Sheep on Meth". Interesting. | 21:49 |
| === ian_brasil_ is now known as ian_brasil | ||
| Neko_ | ogra, would you care to make a blueprint or something for "the perfect storm" of features on an arm system that would make your life easier re uboot configuration and system peripherals and suchlike? :D | 21:53 |
| GrueMaster | How about make-arm-poweron-self-programming-to-perfection? | 21:55 |
| Neko_ | :) | 21:55 |
| Neko_ | but I mean like "it would be nice if it booted ext4 native" or you know.. that kind of thing. | 21:56 |
| GrueMaster | Might increase the footprint of the silicon a bit though. | 21:56 |
| Neko_ | "has some other storage than f**king SD card" | 21:57 |
| Neko_ | :D | 21:57 |
| GrueMaster | Problem there is that the beagleXM and panda have no nand. | 21:59 |
| GrueMaster | So they boot from SD by default. | 21:59 |
| GrueMaster | It is in silicon (from what I understand). | 21:59 |
| mpoirier | Persia: anyone home ? | 22:04 |
| mpoirier | persia ^^^^^ | 22:04 |
| * persia reads some backscroll, hoping to develop context | 22:05 | |
| mpoirier | persia: no need... | 22:06 |
| persia | mpoirier, What? | 22:06 |
| mpoirier | you were talking about a "machine driver" at one point... | 22:06 |
| persia | yes. | 22:06 |
| mpoirier | would you have an example of its usage (any usage really) somewhere ? | 22:06 |
| persia | I have pointers to documentation, but no pointers to code. | 22:07 |
| mpoirier | documentation then... | 22:07 |
| DanaG | What's the difference between the Ubuntu and Linaro kernels? | 22:10 |
| persia | DanaG, All the kernels in the Ubuntu repos are Ubuntu kernels. | 22:13 |
| persia | Current kernels come from two upstreams (kernel.org mainline and linaro) | 22:14 |
| DanaG | Are there any significantly notable differences between the two? | 22:15 |
| DanaG | er, "significantly notable" is a bit redundant. | 22:15 |
| persia | mpoirier, /usr/share/doc/linux-doc/sound/alsa/soc/machine.txt | 22:15 |
| persia | DanaG, To the limit of my knowledge, Linaro is attempting to unify ARM trees, and so has a bunch of patches that may not yet be mainline from various sources plus a bunch of patches that help unify things. | 22:16 |
| persia | Additionally, Linaro has a whole bunch of folk working on enabling stuff, so likely carries those patches. | 22:17 |
| GrueMaster | persia: mpoirier: That would fall back on our earlier discussion re: omap3beagle.c, etc. | 22:17 |
| GrueMaster | persia: cliffnotes version of scrollback: I discovered last night that omap3pandora.c enables specific ports in the codec, whereas omap3beagle.c enables the entire codec. | 22:20 |
| persia | GrueMaster, Thanks! Yeah, something more targeted makes sense. That said, it may be that every port is wired to something on the beagle (although it would be nice if they had proper names) | 22:21 |
| GrueMaster | No, the beagle just enables every port on the codec, whether it is wired outside the chip or not. | 22:22 |
| persia | Did lrg's patches help with omap4? | 22:22 |
| GrueMaster | Not sure. For our immediate useage, probably not. It also requires hacking together an ASoC.conf in /usr/share/alsa/cards, which itsself is short lived. | 22:23 |
| persia | Why? | 22:23 |
| persia | Why not /usr/share/alsa/cards/KJH34987.conf (or whatever is appropriate for that specific board) | 22:24 |
| GrueMaster | But his patch does enable us to move forward to UCM | 22:24 |
| persia | Then we can use the reported card name to configure it. | 22:25 |
| persia | UCM? | 22:25 |
| GrueMaster | UCM Usage Case Manager. Will be in Natty. | 22:25 |
| GrueMaster | New to alsa-lib. | 22:25 |
| persia | Ah, OK. | 22:26 |
| GrueMaster | The idea is to make the driver open all controls and do the system config in userspace. | 22:26 |
| persia | I think berco already created the conf file to drop in /usr/share/alsa/cards so it's low-additional-effort to enable that, as much as it's not the right long-term solution. | 22:26 |
| GrueMaster | Not sure. | 22:27 |
| persia | And ASoC will be doing this also, not just regular ALSA? | 22:27 |
| GrueMaster | Won't help with omap3 though. | 22:27 |
| GrueMaster | This is all asoc I believe. | 22:27 |
| GrueMaster | The rest of alsa may adapt. | 22:27 |
| persia | Not having to quirk HDA would make lots of folk jump up and down in joy. | 22:28 |
| GrueMaster | I'd have to read the email threads in alsa-devel. I've seen it come up a few times recently in my mailbox. | 22:28 |
| persia | That said, I thought lots of folk were looking forward to devicetree to deal with some of this. | 22:28 |
| GrueMaster | Not sure how far out devicetree is, and atm it is PPC & arm specific. | 22:29 |
| persia | That's not so helpful :( | 22:29 |
| GrueMaster | It would require all arches to support devicetree. | 22:30 |
| persia | Indeed. | 22:30 |
| persia | Or, conversely, devicetree to support all arches | 22:30 |
| mpoirier | persia: currently omap3 (beagle, and I assume pandora) return "twl4030" in /proc/asound/cards | 22:36 |
| mpoirier | hence we'd need /usr/share/alsa/cards/twl4030.conf and we'd be set. | 22:36 |
| mpoirier | doesn't offer a solution to differentiate beagle, pandora, gumstix, igep... | 22:37 |
| rlameiro | only one question, what could be the reason that my board cant support this tipe of audio format S24_3LE? | 22:41 |
| DanaG | device-tree is also used for Microblaze. | 22:58 |
| DanaG | Though, last time I tried Microblaze, it was a "bag of hurt" (me using Jobs's words). | 22:58 |
| rlameiro | everytime I unplug something from the usb hub, the board stops recognizing when i plug something again | 23:16 |
| rlameiro | is there any way of "restarting" the usb detection system? | 23:17 |
| rlameiro | or what is called | 23:17 |
| rsalveti | vstehle: cool, thanks for the patch at bug 646368, this was the fix I was looking for yesterday | 23:36 |
| ubot2 | Launchpad bug 646368 in linux (Ubuntu) "smsc911x has no module alias, does not get auto-loaded on OMAP3 EVM (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/646368 | 23:36 |
| rsalveti | didn't know that just adding the module alias would make the kernel to request the proper module | 23:36 |
| ogra | heh | 23:37 |
| ogra | i was just about to point that out to you :) | 23:37 |
| ogra | perfect timing :) | 23:38 |
| * ogra goes to bed ... | 23:38 | |
| rsalveti | :-) | 23:39 |
| rsalveti | see ya | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
