=== ogra_ac_ is now known as ogra_ac [02:13] rsalveti: Still hanging around? [02:14] GrueMaster: yup [02:18] Interesting info on our audio issues. Quick update: Dove & panda are new hardware for this cycle, hence new bugs. Beagle, however, works with lucid, fails with maverick. [02:18] GrueMaster: but new kernel for beagle, that could explain [02:19] new everything. New kernel, new alsa, new pulseaudio... [02:19] Lots of variables. [02:19] true [02:20] And I have eliminated the kernel for the most part, as I can run speaker-test just fine. [02:20] hm, ok [02:21] Oh, and btw, our own David Henningsson has created an alsamixertest script that should help in figuring out what needs to be in alsa.conf. [02:22] https://launchpad.net/~diwic/+archive/maverick [02:22] I haven't tested it yet, but I have built it for armel. [02:23] Requires a loopback cable (hp<>mic), and all mine are currently tied up. [02:23] hm, cool [02:24] if you want to test that with panda, I sent you an email with latest deb, that has probably everything we need from the kernel side [02:24] At any rate, it has been a long day of testing. I'm going to backup this fresh lucid image on my beagle, then kill it with an upgrade. [02:24] setting up the card name and everything [02:24] Yea, I saw the email Also planned on doing that before I call it quits. [02:25] cool === bjf is now known as bjf[afk] === sumitsemwal is now known as sumits [06:27] berco: can you share with us the file /usr/share/alsa/cards/SDP4430.conf? want to test with latest audio patch series [06:28] I'm already getting SDP4430 - SDP4430 from /proc/asound/cards === amitk-afk is now known as amitk [07:23] ... Can anyone assist me in setting up an ARM toolchain for ubuntu x86 [07:26] Xase, What are you seeking to accomplish? [07:26] Xase: with maverick you just need to isntall the correct packages [07:26] To build the android Kernel for an arm device. [07:27] /bin/sh: arm-eabi-gcc: not found [07:27] I have Maverick. [07:27] What packages? [07:27] gcc-4.5-arm-linux-gnueabi for example [07:27] ... [07:27] Xase, Which release are you running? [07:27] just give apt-cache search arm-linux [07:27] Well that would explain that's why I couldn't find it. [07:27] Lol [07:27] you should see the cross packages [07:27] I had no idea that's what apt-cache did. [07:28] Man... I wish there was a "ubuntu-phone" I could be running instead. [07:28] Or if MeeGo was a little more... well going. [07:28] :D [07:28] Xase, It's called "Kubuntu-Mobile" [07:29] No effin way >_> [07:29] Mostly gets tested on the n900s [07:29] ... I almost bought one of those. [07:29] But needs a few hacks, because the n900 kernel isn't open, etc. [07:29] Also works for i386 phones (but actually doesn't have the driver for the baseband chip in my x86 phone) [07:29] the kernel is open [07:30] ... there are x86 phones? [07:30] rsalveti, Not according to the kubuntu-mobile guys 12 hours ago. Are you sure? [07:30] Now you're just blowing my mind. [07:30] Xase, Yes, but this isn't the best channel to discuss them :) [07:30] persia: well, afaik yes [07:30] Of course not. [07:30] But now I must google explosively. [07:30] you could try upstream + additional patches from the stock kernel [07:30] rsalveti, Maybe some closed drivers or something? I dunno: there's a special procedure. [07:30] you can grab the kernel sources from it [07:31] generally you should just take care of the battery and watchdog stuff [07:31] to avoid random resets [07:31] Hmm [07:31] still reports: /bin/sh: arm-eabi-gcc: not found [07:31] rsalveti, You might want to touch base with rbelem and ian_brasil: they'd love to have a less complicated procedure :) [07:31] Xase, Which release are you running? [07:32] Maverick. [07:32] Xase: after installing the correct packages you should see arm-linux-gnueabi-gcc [07:32] persia: sure, I worked with them directly at indt already, will try to ping them later [07:32] And if your build file needs arm-eabi-gcc, you'll have to modify the build file. [07:32] to understand what's going on :-) [07:32] /bin/sh: arm-eabi-gcc: not found [07:32] rsalveti, I thought you'd find them familiar names :) [07:33] ln -s arm-linux-gnueabi-gcc arm-eabi-gcc ? [07:33] * rsalveti listening a cool mp3 from temple of the dog at his omap 4 board [07:33] with latest patches [07:33] Wouldn't just a symbolic link be fine? [07:33] but still manual work on alsa side [07:33] Xase: question is, why? [07:33] your build script is the wrong guy here [07:33] ... so I don't have to keep modifying stuff. [07:34] I didn't create the build script. [07:34] Blame Google. [07:34] well, you can then create a link and mess with your system :-) [07:34] but I guess that at least this part is expected from you to change it [07:34] it's the cross-compiler [07:36] So you'd instead recommend just modifying the build script? [07:37] yup [07:37] cooloney: I think I found a possible culprit for the mem issue [07:38] cooloney: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=644bab98ce980246e6b945962fec9a733a48c325;hp=adaf930e8ae3eaca5d8eda744dfce96caf71447e [07:38] cooloney: at http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4-1gb I added the previous patches and this latest one on top [07:38] Darn that's inexplicably complicated at the moment. [07:38] Lemme find my CTRL+F [07:38] cooloney: you can find the deb file at http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-2.6.35.3+_2.6.35.3+-87_armel.deb if you want to test it [07:38] rsalveti: got it, awesome man [07:39] I'm running the 5th build atm, no issues [07:39] without highmem [07:39] if I use highmem I'll always get this problem [07:39] rsalveti: yeah, let me try it. 2G:2G split right [07:39] cooloney: we were missing one errata for pl310 [07:40] cooloney: then I found that at the upstream l-o we already got a patch that selects the errata by default [07:40] just did the same thing [07:41] bah arm-eabi-gcc isn't specified in either Kbuild or Makefile >_> [07:41] rsalveti: so even we enable this errata for pl310, we still needs 2G:2G split and npitre's patch, right? [07:41] without highmem [07:41] cooloney: yup [07:41] rsalveti: thanks, got it [07:41] cooloney: that could be at least one workaround to use 1gb [07:41] while we try to debug the highmem issue [07:41] but would prefer to test highmem with upstream [07:41] rsalveti: yeah, just in time, a workaround to us 1G for our release [07:42] but even getting the mmc fix, couldn't get it recognized with upstream kernel [07:42] rsalveti: yeah, i tried patches in l-o list for mmc of es2.0 board, but the same as you [07:42] arm-linux-gnueabi-menuconfig? [07:43] nm [07:43] I'm reading wrong. [07:43] cooloney: description of the errata: http://paste.ubuntu.com/503055/ [07:43] so wrong. [07:43] Just do yourself a favor and put me on the ignore list. [07:44] cooloney: so it seems this could be our culprit, just need more testing [07:44] will let it building during the night and check it tomorrow [07:44] but so far so good [07:45] 2cpus, with l2, 2g:2g and 1gb support [07:45] BAH [07:46] ... [07:46] Wow. [07:47] I guess this is goodbye guys. [07:47] I just rm'd the arm asm [07:47] from the project file [07:47] rsalveti: great, man, [07:48] rsalveti: i will post your patches with npitre's again [07:48] Sweet. Nevermind. [07:48] I need sleep. [07:49] cooloney: with highmem I can easily get Unhandled fault: imprecise external abort [07:49] ... [07:49] so probably another issue [07:49] cooloney: cool, just let do some more testing and then we can post it [07:49] Too tired 2:49 AM... something about supporting nothing but the Calgary with this source >_> [07:49] *lets [07:51] rsalveti: without highmem, it looks like l2 controller pl310 is the root cause. So this errata is necessary. [07:52] rsalveti: i agree with highmem, it is different from pl310 errata issue. [07:53] cooloney: yeah [07:53] there's also some more l2x0 patches going upstream: http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk [07:54] and sram fixes at http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap_for_2.6.37 [07:54] rsalveti: yeah, i reviewed that before. those l2x patches are for kexec implementation on omap4 [07:55] and it follows Thomas Gleixner's generic one [07:55] yep [07:57] kexec is awfully nice :) [07:58] persia: heh, need more testing and backport some patches to enable that. [07:59] maybe with 2.6.37 on N :-) [07:59] No worries. I think I need two more cycles before we depend on it :) [07:59] ... gaddangit [08:00] I've messed up my source. [08:01] Gotta read the config a bit more clearly >_> [08:05] Well see, because I couldn't get it to compile I had modified a ton of crap, so now using the plain source... it compiles out of box. [08:05] Thanks #ubuntu-arm [08:06] Xase, So it's working for you now? [08:07] Kind of... [08:07] Still getting this "message" [08:07] arch/arm/mach-msm/board-mot.h:125: error: #error Calgary is the only HW supported by this release [08:07] And that's after using the source directly from the Calgary source page. [08:08] I have no clue what it means though so... shrug. [08:08] And you're targeting a Calgary device? [08:08] Anyways... anything I can do to help Ubuntu-arm out. [08:08] Yes Persia. [08:08] Also known as the Motorola Devour. [08:08] * persia suspects some subtle machine definition in the cross-compiler somewhere. [08:09] Should... I speficy TARGET=Calgary ? [08:09] * persia has no information about the source being compiled. [08:09] I'm new to any sort of compiling outside of software... [08:09] If that's a sensible option, try it. [08:09] It's the source for the Calgary Device. [08:10] Note that you'll probably get better advice about the specific compilation steps from a Calgary-specific resource (wiki, forum, channel, mailing list, etc.). We mostly focus on running Ubuntu native on ARM. [08:10] (with a wink and nod at limited cross-compilation) [08:11] TARGET_PRODUCT=calgary makes sense =/ [08:11] Yeah. [08:11] Kind of figured. [08:11] If there was anything for the Calgary. [08:11] It's an end-of-lifed device. [08:11] But I am better off asking in Android perhaps ;) [08:12] Again, is there anything I can do to help test/debug ARM Ubuntu? [08:21] Xase, If you happen to have hardware that can run it (e.g. Netwalker, Efika MX, Beagleboard, IGEPv2, Efika SmartBook, etc.) and want to help test and fix bugs, that would be great. [08:22] =( I will try [08:22] I might be able to attain something [08:22] If you don't have any of that, but have other ARMv7+VFP capable armel hardware with a working (recent) linux kernel, please try our userspace. [09:34] rsalveti: sorry, I didn't see your post earlier [09:35] rsalveti: I just attached the file to bug #637947 [09:35] Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/637947 [09:35] rsalveti: do you have all you need kernel wise? [09:53] ogra: you about to help merge? :-) [10:24] If I want to make a maverick target image, which version of rootstock should I use? [10:25] sveinse, theoretically, anything ought work to some degree, but 0.1.99.4 would be most likely to have the best support. [10:26] thanks === amitk is now known as amitk-afk === amitk-afk is now known as amitk === rgreening_ is now known as rgreening [12:54] Hi. Can somebody point to the oo.org build time problem ? === berco1 is now known as berco|laptop [13:57] * dcordes drops a pin [13:58] * ogra shades his ears from the noise [14:00] ^^ [14:08] I see a disruption of the force in 09-29 image [14:09] it won't start oemconfig althoug I have the semephore set [14:09] hmm, has been tested a lot though (since it's the RC candidate) [14:09] what arch ? omap or omap4 ? [14:21] ogra: I picked the omap4 and applied the few changes as usual [14:21] "the few changes" ? [14:22] it's not much really [14:22] I install my kernel modules [14:22] add few networking scripts [14:22] and do [14:22] 'touch /var/lib/oem-config/run' [14:22] usually after that, I start the rootfs and it will run oemconfig [14:23] no problems [14:23] yeah, it surely does for us [14:23] It might be corruption then. I see some error message: [14:24] Use of uninitialized value $item in hash element at /usr/share/perl5/Debconf/Format/822.pm [14:25] yeah, smells like [14:25] need to get to the library and download the new image @ 3,3MB/s againm [15:03] berco: thanks [15:04] berco: got the file from latest proposed tree with tons of sound patches [15:04] *kernel [15:14] rsalveti: i am going to post out our highmem issue workaround patch including your pl310 errata one. [15:14] rsalveti: do you think we need more test [15:15] cooloney: well, just saw that I'm going to the 10th build here [15:15] no issues [15:15] so it seems better [15:15] cooloney: were you able to test? [15:15] i just tested using usb, didn't test yet with mmc [15:16] but you can propose it, np, it's a fix anyway that we're not using atm [15:17] rsalveti: yeah, i tested it on my mmc, just 1 build, it passed. [15:17] rsalveti: ok, let me post it firstly [15:17] cool [15:20] rsalveti: you know, it is quite slow for me to connect with ports.ubuntu.com [15:20] rsalveti: drive me crazy [15:20] rsalveti: i will test audio fixing tomorrow. [15:22] yeah, can imagine [15:24] rsalveti: thx for the testing, it seems like that you're never sleep [15:26] cooloney: I try to :-) [15:26] cooloney: I saw you changed my patch to change just the config file [15:26] while it works for us, as we build just one flavor, I decided to change the Kconfig because this was the same change that went upstream === bjf[afk] is now known as bjf [15:27] that would fix the issue for all ARCH_OMAP4 boards [15:28] but I'm ok with your patch, just to let you know why I changed the Kconfig :-) === ogra_ac_ is now known as ogra_ac [16:07] * rsalveti lunch [16:46] hmmm... [16:46] * robclark somehow manages to murder an mmc card with fdisk.. [16:49] btdt. [16:49] I usually end up doing a complete nuke at that point. dd if=/dev/zero of=/dev/ [16:50] no... I no longer even get a device file for the card [16:53] ouch [16:53] May need to reboot. [16:54] Also, I discovered on one of my cards that one of the plastic guides on the side near the contacts had bent covering the contact. Breaking it off fixed it. [16:56] ogra_ac: For the release notes: upgrading beagle from lucid->maverick can run of of free space if USB drive is 4G or less. Haven't tried yet on larger. [16:56] mind to talk to skaet and add it to the wiki ` [16:56] ? [16:57] I'll drop a not on #u-release. [16:57] note even. === hrw is now known as hrw|gone [17:25] ogra_ac: ping [17:27] prpplague, i'm here [17:27] ogra_ac: hey, we were discussing possibly using a usb->sata on the bamboo board [17:27] ogra_ac: any thoughts on that? [17:28] you will be easily maxing out the USB with that i guess [17:28] the babbage imx51 board has such a setup, not really an advantage over a simple external USB disk [17:29] well the EHCI through put it pretty stable [17:29] ogra_ac: are they using OHCI or EHCI ? [17:29] ehci [17:29] ~24MB/sec reported by hdparm [17:29] ahh [17:31] and i doubt you can get much more through USb [17:32] so i guess just attaching SATA to the USB bus wont really gain much over a cheapo external USB disk directly attached to USB [17:32] yea that is kinda of why i didn't consider it [17:32] other than size of storage [17:32] i thought there was a way to attach it differently ? [17:32] It would be nice for convenience, but won't enhance performance. [17:32] gpio? [17:33] ogra_ac: it is possible to do PATA via the GPMC, and then use a PATA->SATA bridge [17:34] prpplague: maybe even PATA is fine.. I think they still sell those [17:34] ah [17:34] ;-) [17:34] GPMC, right [17:34] Hmm. PATA<>CF would be interesting. [17:34] yeah, even PATA would rock [17:34] GrueMaster: PATA to CF is pretty easy [17:35] the only thing that would have to be done is a kernel driver to "work the gpmc" like a PATA interface [17:35] Yes I know. I have 3 running systems that way. Fileserver, firewall, and serial-console monitor. [17:35] prpplague: well get crackin! ;-P [17:36] GPMC->PATA would probably drive two hd's, wouldn't it? A master and slave.. [17:36] robclark: gotta finish current project first [17:36] Pfft. Multitask. [17:36] :P [17:36] robclark: not sure i have enough chipselect signals to do two [17:37] hmm.. [17:40] prpplague: I guess I don't need both LED's.. depopulate one, some blue wire, and use that gpio as an extra CS? [17:41] robclark: negative [17:41] robclark: the controls need to be tied to the gpmc controller [17:41] robclark: the gpmc has it's on chipselects and such to control memory read/writes [17:56] ARGH !!!! [17:56] who designed the pandaboard.org page !!!!! [17:57] * ogra_ac just linked the logo in a blog post ... [17:57] at least i thought i link the logo [17:57] sigh [17:57] the whole page is a jpeg [17:57] Heh. [17:57] what an insanity !! [17:59] ogra_ac: hehe [17:59] they asked already to change to at least a png [18:01] that wont make it smaller though ... i just bloated planet.ubuntu.com with it [18:02] I don't know what you guys are talking about... pandaboard.org looks fine in lynx ;-) [18:02] * robclark ducks [18:03] LOL [18:03] HA [18:03] ogra_ac: maybe orbarron could send you a more appropriately sized logo? [18:04] robclark, well, its fine now [18:04] i'll just live with the embarrasement [18:09] Can rootstock be used to build debian root fle systems? [18:11] gourneau, i dont think anyone tested that ever [18:12] ogra_ac: any ac100 kernel news ? [18:12] Maybe it will be me then, I want to use Ubuntu. How are the seed images defined? [18:13] dcordes, see planet.ubuntu.com [18:13] (no, no kernel news, but fully working images [18:13] ) [18:14] ogra_ac: ah well didn't see any user space problems .. [18:14] dcordes, plenty [18:15] the SoC doesn't support neon right ? [18:15] right [18:17] what userspace related problems do you see ? [18:17] did you create a meta bug ? [18:17] android kernel [18:17] no [18:17] i dont think you will see any official support for the device any time soon [18:17] haha sometimes you make me laugh [18:18] feel free to create one though [18:18] I am looking to make things work, not if they will magically fix. [18:18] dcordes, thne tak to phh in #ac100 :) [18:18] I know the bum [18:18] *then talk [18:19] he has done a lot of low level stuff [18:19] and is still doing [18:19] without kernel source ? [18:19] well, there kind of is kernel source [18:20] its not as if there wouldnt be public branches of tegra eclair [18:20] now you got me all confused [18:20] the kernel supports modules ;) [18:20] you cant change the core indeed [18:21] Does anyone know of a good Ubuntu tablet about 7 inches, with a host USB port. The smartq v7 is the best I can find. [18:28] gourneau: htc hd2 but you need to supply external power for the usb and the display is not 7 inches [18:29] and you can run ubuntu natively ? [18:35] orga_ac: pandaboard.org is a temp site for now... plz forgive the jpeg [18:36] ogra_ac: yes [18:36] ogra_ac: http://vimeo.com/14630263 [18:36] orbarron, i dont care about jpeg, i care about that i right clicked the logo and pasted ion my blog post ... now my post has the whole site in it [18:36] ogra_ac: with full snappyness [18:37] lol bluepaste :> [18:37] ogra_ac: Do any of our initramfs scripts touch nand on beagle? I keep getting nand i/o errors on mtdblock0. [18:38] GrueMaster, nope [18:38] But only after upgrading lucid to maverick (which replaces the kernel in nand). [18:38] GrueMaster, not in maverick [18:38] Very odd. [18:38] That's what I thought. [18:38] oh, upgrade is different [18:38] that still uses nand indeed [18:38] No, this is running a preinstalled image. [18:39] Is there any known breakage in 27th omap4 preinstalled image ? [18:39] But I only get the error if the maverick kernel is also in nand. [18:39] dcordes: Use the 29th. It will be the official RC. [18:40] GrueMaster: ok I downloaded it already but had some strange problem [18:41] sounds like it must be on my end if you consider it for RC [18:41] somebody interested in adding HTC HD2 maverick RC infomration in planet ? [18:42] then we have covered the full embedded family [18:42] smartbook, dev board and cell phone [19:11] nevermind :) [19:16] grrrrr [19:16] someone needs to spank the icon designers [19:18] hi all , i have igep board but in minicom i am getting message as �� [19:18] no boot prompt [19:19] devilhorns: Are you referring to bug 651391? [19:19] Launchpad bug 651391 in gnome-control-center (Ubuntu) "Changing desktop font changed entire theme appearance in une-efl (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/651391 [19:19] GrueMaster, no, gimme a sec, I will show you my "gripe" :) [19:19] ajay: probably missing x-loader and u-boot [19:20] but green light is glowing on that board [19:20] GrueMaster, ok, keep in mind when you look @ this, that my code does everything properly (in that it centers the icons) [19:20] http://home.comcast.net/~devilhorns/files/unity_efl.png [19:20] GrueMaster, but, look @ the button [19:21] and looking @ the icon itself, you can see "the problem" [19:21] Yep. Icons aren't centered in their frame. Bad. [19:22] yep :) [19:22] now what kinda moron makes icons like that ... *sigh* [19:22] rsalveti, is this happens due to any null modem cable error as well? [19:22] There's probably a patent if they did. [19:22] ajay: could be, but generally you get tons of weird characters when getting garbage [19:22] a patent for centering icons ? I highly doubt that :) [19:23] ajay: are you open it with 115200? [19:23] yes [19:23] Never know with software patents. [19:23] hw and sw flow control is off [19:23] generally I never use minicom, just screen /dev/ttyUSB0 115200 is enough for me [19:23] GrueMaster, well, if that is the case, then every designer on the planet is in trouble :) I mean really, how Doesn't center images ? :) [19:23] but could be cable issues also [19:23] maybe wrong pins [19:24] heh [19:24] rsalveti, i have checked i am using cross cable [19:24] null modem [19:24] IDC10 DB9 also as mentioned in websites [19:26] rsalveti, for screen /dev/ttyUSB3 115200 also i am getting just blank screen [19:26] ajay: any garbage? [19:26] nothinmg [19:26] if i write then it is getting garbage [19:27] rsalveti, if i write same thing is getting printed [19:27] hm [19:28] just for enter key getting printed at start � [19:28] GrueMaster, btw [19:28] is it cable problem? [19:28] or uboot xloader got corrupted [19:28] that bug is not in une-efl ... it's a control-center (appearance properties) problem [19:28] That's what I thought when I filed it. [19:29] ajay: could be, but it it was corrupted you should not get any echo from uart [19:29]