/srv/irclogs.ubuntu.com/2011/02/11/#ubuntu-arm.txt

=== XorA is now known as XorA|gone
rsalvetiGrueMaster: can you also try to update to the latest kernel?00:06
rsalvetithe rc4 based one should be available already00:06
GrueMasterI didn't see it in the pool yet, but I'll check launchpad.00:07
rsalvetihttps://launchpad.net/ubuntu/+source/linux/2.6.38-3.30/+buildjob/225283600:08
GrueMasterYea, finished 16 minutes ago.  That's why.00:10
GrueMasterHeh.00:10
rsalvetihehe00:10
persiaHrm?  Says finished 7 hours ago for me.00:11
GrueMasterhttps://launchpad.net/ubuntu/+source/linux-meta/2.6.38.3.17/+buildjob/225507700:11
GrueMasterThat's what is currently published (or in the que).00:12
persiaAh.  That's probably still stuck in the publisher.00:12
persiaBut it finished enough before the hour that it ought be in this run, rather than waiting until the next run.00:12
GrueMasterRight, but last I was told, the publishing run starts at ~:05 and finishes at :40.00:13
* npitre sees a pending interrupt for himself here00:13
GrueMasterSo I only have to wait another 30 minutes.00:13
persianpitre, I've been trying to package an imx51 kernel tree with sascha's tree + patches from rtp + ubuntu sauce.  lool advised me you were the gatekeeper for linux-linaro-imx51, and I should send you patches and use your package.00:14
persianpitre, Since the last upload is 2.6.37, I'll try to sort out what patches I have that are relevant to the efika boards, and prepare a tree for your review.00:15
npitrepersia: no problem00:15
persianpitre, For reference, rtp's work is a quilt patchset at git://git.rtp-net.org/efika.git00:16
npitrepersia: what is rtp?00:16
persianpitre, Arnaud Patard00:17
npitrepersia: fyi, the linaro tree should move to 2.6.38-rc5 once released00:17
persianpitre, Excellent.  If your 2.6.37 boots on the hardware, I'll postpone sending you patches until after the move.  If not, I may send you a few in advance.00:18
npitrepersia: OK, as lool hinted I'm not that good at tracking irc so feel free to send me an email if you have something you want included in the linaro kernel00:19
persianpitre, Absolutely :)  I'm not that good at tracking email: thanks for having the initial discussion with me here.00:20
npitrepersia: you may try to ping me on irc, but sometimes this might take hours before I notice00:21
persianpitre, I'll send you email once I have something substantive.  For now, I'm waiting on a test report for the Efika MX with your kernel.00:22
npitrepersia: OK00:22
rsalveticooloney: hey, are you back already?01:08
cooloneyrsalveti: yeah, man01:11
cooloneyrsalveti: how's going?01:11
rsalveticooloney: good, and you?01:11
rsalvetirefreshed?01:11
cooloneyrsalveti: heh, actually a little bit tired01:12
cooloneyrsalveti: any news?01:12
rsalveticooloney: well, weekend ahead :-)01:12
rsalveticooloney: well, some :-)01:12
rsalvetiwe got a ti-omap4-dev branch01:12
rsalvetias you probably know already01:12
rsalveticooloney: one thing I'd like to ask you is if you can test and merge the DVI patches for panda01:13
rsalvetifor 2.6.3801:13
rsalvetiso we can have a working display with this kernel01:13
rsalvetias my panda has a broken dvi, can't test atm01:13
rsalvetilook at l-o for [PATCH] OMAP4: PandaBoard: Adding DVI support01:13
cooloneyrsalveti: sure, i will do it today01:14
cooloneyi got that HDMI-DVI cable01:14
rsalveticooloney: cool01:15
cooloneyrsalveti: is this one?01:15
rsalvetibut even the hdmi cable should work01:15
cooloney[PATCH] OMAP4: PandaBoard: Adding DVI support01:15
rsalveticooloney: yup01:15
rsalvetircn-ee said it worked fine for him01:15
rsalvetiso it should just work01:15
rsalvetiif it's the case, try sending it to this branch01:15
cooloneyit's from Raghuveer Murthy <raghuveer.murthy@ti.com>01:15
rsalvetiti-omap4-dev01:15
rsalveticooloney: yup, that's the one01:15
cooloneyOK, i got it01:16
cooloneyso will we get .38 patches soon?01:16
rsalveticooloney: not directly from serbjan, probably from linaro01:17
rsalvetior something like that01:18
cooloneyrsalveti: right, i know Andy Green is working with sebjan on that01:18
rsalvetiyeah01:18
cooloneyrsalveti: thx a lot for this info.01:19
cooloneyi will test that DVI patch and try to push to ti-omap4-dev01:19
* cooloney just update his machine, needs reboot, brb01:21
=== davidm_ is now known as Guest68895
cooloneyrsalveti: does our ti-omap-dev branch kernel supports graphic, since i wanna test that DVI patch.02:18
persiaIt should.02:18
rsalveticooloney: probably02:18
rsalveticooloney: you just need to check if you have all the dependencies, like described at the patch02:19
cooloneyrsalveti: i think it is based on 2.6.38-rc kernel which miss some graphic support.02:19
rsalvetibut as we're basically using the same one as master (rc4), and rcn-ee said it worked fine for him, I expect this patch to be enough to get the display working02:19
cooloneyrsalveti: OK, I will try it soon02:20
rcn-eersalveti, did you get the display working on the panda with 2.6.38-rc4?04:17
persiarcn-ee, backscroll reports that rsalveti is having issues with the DVI port : cooloney had volunteered to look at the relevant patch.04:18
rcn-eeah, interesting..  Could be something with the  monitors i have here..04:20
persiaNo, it's something with rsalveti's hardware04:21
persiaquoting "as my panda has a broken dvi, can't test atm"04:22
persiaUnless you had a HW hack to fix that?04:22
cooloneyrcn-ee: yeah, i am working on that04:22
rcn-eeah i see, (working my back in the scroll log.. )04:22
cooloneyrcn-ee: so mainline 2.6.38-rc4 kernel does support graphic things on Panda?04:22
rcn-eemainline + plus the patches posted on wednesday..04:23
rcn-eecooloney, these work on my panda a1.. http://dev.omapzoom.org/?p=anand/linux-omap-usb.git;a=shortlog;h=refs/heads/display-patches-for-v2.6.38-rc4  and they don't seem to break my c4 beagle board with the same uImage04:24
cooloneyrcn-ee: right, i pull the branch from Anand's display-patches-for-v2.6.38-rc404:24
cooloneyrcn-ee: yeah, exactly04:24
cooloneyrcn-ee: what's kind of root fs you are testing for this?04:24
rcn-eethe one thing i haven't tested is the edid stuff, so i did a "1024x768" value on the bootargs...  on that boot test, maverick...04:25
lilstevieis anyone here good at fbdev :p04:31
persialilstevie, Try asking the question you'd ask if someone said "yes".  Someone might not consider themselves good, but may know the answer to your specific question.04:36
lilstevieheh well I have no idea what is wrong04:36
lilsteviethe screen blinks the backlight on and off04:36
persiaWhat board?  Which image?04:38
lilstevierootstock made image04:41
lilstevieand not a usual board :p04:41
lilsteviegalaxy tab04:41
persiaHeh, that makes it tricky :)04:43
persiaI'm not even sure what question would be useful to ask next (I know I don't know the solution to your problem, but I can usually get a bit further in the script :) )04:44
lilstevieheh04:46
lilstevieI do have logs04:46
lilstevieand interactivity over ssh04:46
cooloneyrcn-ee: sorry, i was dropped04:50
rcn-eenp cooloney, i believe i tested it on maverick, (defined the video x/y in the bootargs, didn't do edid).. but it might have been lucid/squeeze, i was testing other userspace things at the time..04:52
cooloneyrcn-ee: great, i am testing it with our natty userspace and wanna apply those patches to our ubuntu 2.6.38 based kernel04:53
rcn-eeis this for the ppa one mentioned on the ubuntu-kernel list earlyier this week?04:53
cooloneyrcn-ee: from Anand Gadiyar's branch, i found 35+ patches on top of 2.6.38-rc404:54
cooloneyrcn-ee: yeah, it is our ti-omap4-dev branch which is 2.6.38 based branch04:55
cooloneyi think for ti-omap4 stuff, it is almost the same as mainline04:55
rcn-eethat's pretty strange, shouldn't have been that much..04:56
rcn-eei know there's 4-5 omap specfic ones that were merged in the rc3-rc4 so that wouldn't add up either..04:56
rcn-ee(crap wrong patchset... it's 35..)04:57
cooloneyrcn-ee: from Raghuveer Murthy's description in DVI patch, it is only depends on 6 patches04:57
cooloneyrcn-ee: but i think pure 2.6.38-rc4 does not include DSS patches which is required for graphic on OMAP4 like panda04:58
rcn-eeyeah, 2.6.38-rc4 only has the omap4 ehci/musb bits, nothing really else.. those 35 on top of that were enough for my dvi port to correctly work on the panda...05:00
cooloneyrcn-ee: so how did you test that DVI patch? apply those 6+1 patches on 2.6.38-rc4 kernel?05:04
rcn-eei applied the 35 on top of my current 2.6.38-rc4 tree.. https://github.com/RobertCNelson/2.6.38-devel/blob/master/patch.sh#L16005:05
cooloneyrcn-ee: ok, cool, man05:11
rcn-eeyeah, rereading it on the linux-omap archive, Murthy does mention the other 6 patches, but it looks like Anand Gadiyar merged those 6 depencies into the group of 35..05:12
=== davidm_ is now known as Guest12115
sebjanrsalveti, cooloney: I already have a branch with the DVI patches working08:05
cooloneysebjan: thanks a lot08:06
cooloneysebjan: i'm just trying the DVI branch from Raghuveer Murthy08:06
cooloneywanna apply those 35 patches in Anand Gadiyar's branch, but it failed on our ti-omap4-dev branch08:07
cooloneysome conflict08:07
sebjancooloney: I did not try yet to apply them on the ti-omap4-dev branch, I currently work on mainline (.38-rc4)08:10
cooloneysebjan: yeah, i know some conflicts there, will try to solve them08:11
cooloneyand prepare a branch to test08:11
cooloneysebjan: but i am not sure about those patches from Anand Gadiyar's branch, will they be merged into mainline?08:11
cooloneyit's about 35 patches08:12
sebjancooloney: they are reviewed on LO, but not sure about their status08:13
cooloneysebjan: ok, so how about your patches?08:13
cooloneyDVI patches?08:13
sebjancooloney: let me clean and retest my branch and I send it to you (but tis shall be very similar to Anand's one)08:14
cooloneysebjan: great, I will try Anand's soon after i solve those conflicts08:14
sebjancooloney: here is my git / tag: git://github.com/sebjan/linux-2.6.git topic-wlan-iv1-2.6.38-rc4 (https://github.com/sebjan/linux-2.6/tree/topic-wlan-iv1-2.6.38-rc4)08:17
sebjanI have DVI working (from DVI connector P1)08:18
sebjanand can choose the screen definition with these bootargs for ex: omapfb.mode=dvi:1024x768MR-24@60 omapdss.def_disp=dvi08:19
=== zumbi|eislusft is now known as zumbi
NishanthMenonslnr, hi10:30
slnrhi10:30
NishanthMenonslnr, can you share the issue with gst-launch with mp3 decoder and filesink with ndec10:30
NishanthMenonndec, ping10:30
slnrgst-launch filesrc location=test.mp3 ! mad ! filesink location=test.pcm10:31
slnrthis is working fine10:31
slnrgst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm10:31
slnrthis is not working10:31
NishanthMenonslnr, this is for OMAP4 rt?10:31
slnryes10:31
NishanthMenonslnr, one more place to ping is #gst_ti10:32
slnrthanks10:32
NishanthMenonslnr, np10:32
slnrwe will try to join that channel10:32
NishanthMenonndec, know anything about this pipe failing with ubuntu?10:32
persiaslnr, You have the omx packages installed, right?  (just for confirmation)10:32
NishanthMenonpersia, good Q -> slnr try gst-inspect | grep omx_mp3dec10:33
slnrit is there10:33
NishanthMenonslnr, does fakesink work?10:33
slnryes10:33
* NishanthMenon out of cookies :( defers to ubuntu experts10:34
slnryes10:34
slnrwe will try this and let you know10:34
NishanthMenonslnr, ?? did you mean, you are now going to try gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink ?10:35
slnryes we tried10:35
slnrwith fakesink10:35
cooloneysebjan: do you have the kernel config file for dvi patches testing?10:35
slnrit works properly10:35
NishanthMenonslnr, k.. /me out of ideas here..10:36
slnrone sec10:36
slnrwe will cross check this pipeline once10:36
NishanthMenonand alsasink works?10:36
sebjancooloney: yes, I have 2: one is minimal, and the other is an Ubuntu-like one. They are located into arch/arm/configs/omap4_panda_* (the 'full' one is an Ubuntu like)10:36
slnrwith alsasink it is working10:37
slnrwe just checked fakesink10:37
slnrit fails10:37
persiafakesink fails and alsasink works?10:37
sebjancooloney: the minimal one also boots with an Ubuntu FS (issue was: not devtmps + .38 issue with omap2plus and ARMv7 SMP)10:37
cooloneysebjan: is it in the github?10:37
slnryes10:37
slnrpersia: yes10:38
sebjancooloney: yes shall be. let me cross-check10:38
persiaslnr, That's unexpected.  If fakesink fails, nothing ought to work, or something is very odd.10:38
slnrok10:38
NishanthMenonslnr, can you post the log on pastebin.mozilla.org and provide us a link of what you see with gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink10:39
slnrpersia: gst-launch filesrc location=test.mp3 ! omx_mp3dec !  fakesink/filesink fails10:39
sebjancooloney: confirmed, they are in my branch on github10:39
persiaOr paste.ubuntu.com :)  Lots of choices.10:39
slnrpersia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works10:39
persiaThen it's beyond what I know about gstreamer.  I've always believed that fakesink was a no-op.10:40
NishanthMenonslnr, might help us to see the log. dont post the log straight here, instead post it to the paste.ubuntu.com and provide us the link10:40
slnrNM: ok10:40
slnrsure10:40
NishanthMenonpersia, i agree, I'd think of it as cat file>/dev/null fails and /dev/dsp works! hmm.. mebbe some weird handshaking requirements?10:41
persiaHeh, yeah, that's my thought.  But there are plenty of people more knowledgeable about gstreamer than I (although at this time of day, it may be a long wait until they are awake)10:42
slnrNM: we are capturing the log and we will provide the link on pastbin in few mins10:42
NishanthMenonslnr, thx.. mebbe you should check with #gstreamer as well in addition to #gst_ti.. u'd get a bunch of gstreamer experts there10:42
slnrNM: ok10:43
* NishanthMenon suspects it might have something to do with ti gstreamer omx implementation10:43
NishanthMenonsome caps negotiation or something "implicitly expected by ducati"..10:43
NishanthMenonsebjan, know who can help?10:44
* NishanthMenon hopes france folks not away on lunch yet ;)10:44
sebjanNishanthMenon: not yet :)10:44
NishanthMenonsebjan, :D gstreamer issue pretty much needing someone knowing gstreamer and omx_ti :( know anyone lurking arnd?10:45
cooloneysebjan: i think we need enable the graphic driver for the DVI testing10:45
cooloneysebjan: but it is disabled in your config10:45
ndecNishanthMenon: hi10:47
slnrNM: http://pastebin.mozilla.org/104710810:47
NishanthMenonndec, good afternoon :)10:47
ndecNishanthMenon: sorry was in meeting.. what's the problem?10:47
ndecNishanthMenon: well, technically it's not noon yet ;-)10:47
ndecNishanthMenon: where are u?10:47
NishanthMenonndec, slnr has this problem with gstreamer10:47
slnrNM: you can see the logs10:47
NishanthMenonndec, blore atm10:47
NishanthMenonslnr, yep10:48
NishanthMenonndec, can you glance at the log from slnr? looks like swapping the sink to fakesink instead of alsasink fails10:48
ndecNishanthMenon: slnr: for audio MP3 we do not support OMX anymore. that was only on OMAP310:48
NishanthMenonndec, how come alsasink works then?10:49
slnrNM: we have run a video pipeline and10:50
ndecNishanthMenon: ok.. too much backlog. can you summarize which pipeline fail?10:50
NishanthMenonand looking at the log, it seems to go to GstOmxH264Dec:omxh264dec0!10:50
slnrwe have pasted the logs10:50
NishanthMenonslnr, do u have any mp3 logs?10:50
NishanthMenonnot mp4 logs10:50
ndecslnr: for gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm10:50
slnrndec: we will test mp3 too and paste10:51
NishanthMenonslnr, the log you pasted is for video h264_dec!10:51
ndecslnr: this is not expected to work. in fact we should removed the omx_mp3dec element for OMAP4 since it's not supported. on OMAP4 audio is thourhg ffmpeg, mad, libaac only10:51
slnrndec: ok10:51
NishanthMenonslnr, have you really tested it?10:51
ndecfor the video pipeline using omx_h264dec element and fakesink, I think it's failing because the sink is expected to be 'tiler aware' which fakesink isn't10:52
slnrndec: can you analyse the video log10:52
ndecslnr: does the video pipeline work with v4l2sink?10:52
slnrNM: the log we capture fir video is now10:52
slnryes10:52
NishanthMenonndec, so no go for filesink or fakesink? sad..10:52
slnrndec: yes10:52
sebjancooloney: right, I just see Idid not upgrade the 'full' config with the display... The minimal one is up to date. Check the last commit for the relevant changes (otherwise, the minimal config can boot on a Ubuntu FS)10:52
NishanthMenonslnr, yeah.. wondering how you claimed mp3 worked before10:52
NishanthMenonquote "<slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works"10:53
slnrNM: that was one ex10:53
slnrNM: our colleague quoted as saying10:53
NishanthMenonk, looks like it is wrong info10:53
slnrNM: we were looking to video mainly10:53
NishanthMenonndec, any chance of looping video output to a file?10:53
NishanthMenonsome tileraware component that can route data to file/fakesink?10:54
slnri am unable to route video output to fakesink/filesink10:55
NishanthMenonslnr, if you notice what ndec said, your sink should be tile aware. obviously file/fakesink is not and hence it fails10:55
NishanthMenonv4l2sink is probably aware and should work10:55
* NishanthMenon wonders if there is something to route the video data to a file, helps for debugging usually - e.g. ssim comparison etc.10:56
slnrNM: yes v4l2sink works, how to make filesink tile aware?10:57
cooloneysebjan: https://github.com/sebjan/linux-2.6/blob/topic-wlan-iv1-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig also disabled DSS drivers10:57
ndecNishanthMenon: to do this you need to copy the tiler buffer in a regular buffer, robclark would know more about this, he did it in gst-ducati. so with gst-ducati you can have a filesink. the plugin will check for the capabilities of the sink, and will do the necessaru10:57
ndec/necessaru/necessary/10:57
NishanthMenonndec, ok.. looks like a few more hrs before robclark appears10:57
ndecNishanthMenon: so for ex, with gst-ducati you can do video transcoding which you can't do with OMX ;-)10:58
NishanthMenonndec, thx for the tip ;) I get the message - "more limitations of OMX" yet again :P10:58
NishanthMenonndec, do you package gst-ducati with ubuntu?10:58
slnrNM: can this be downloaded from the net??10:59
sebjancooloney: please look at my iv2 tag: https://github.com/sebjan/linux-2.6/tree/topic-dvi-iv2-2.6.38-rc410:59
sebjancooloney: DSS and DPI are activated here: https://github.com/sebjan/linux-2.6/blob/topic-dvi-iv2-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig11:00
NishanthMenonndec, dunno.. u need to catch robclark when he comes online11:00
NishanthMenons/ndec/slnr11:00
slnrNM: so my pipeline will look like omx_h264dec ! gst-ducati ! filesink location=test.yuv11:02
slnrNM: is this assumption correct??11:02
cooloneysebjan: thanks a lot, i looked at iv1 tag11:02
sebjancooloney: np11:03
cooloneysebjan: so generally, it needs to enable DPI and Generic panel, right?11:03
NishanthMenonslnr, i dont think it will be gst-ducati.. it probably will have different component name - ask robclark11:03
sebjancooloney: yes11:03
persiajanimo, So, the nature of omap4 only specifies booting from MMC: it doesn't specify whether that is SD or eMMC or what.  As a result, depending on the final retail design, it's perfectly conceivable that you'd end up writing internal flash when writing to MMC on some device.11:04
slnrNM:  Thanks for the information11:04
janimopersia, well I am not sure what else can be done to make this safer, short of not implementing the spec, but I am open to suggestions :)11:05
persiajanimo, But if you're special-casing only development boards, and won't be doing anything for retail devices, it's probably safe (and most developers like to be able to use newer bootloaders anyway)11:05
janimopersia, I don't know anytihng about retails devices. You mean future tables and ARM based OEM sutff?11:05
=== slnr is now known as SLNRPremkiran
janimoIf so they are tweaked by OEM anyway to prevent all kinds of snafu I hope11:06
persiajanimo, Doesn't have to be future, if you consider OMAP311:06
persiaAnd if you presume that some OSV will tweak the OS, you are presuming nobody will want to run Ubuntu regularly, which I think is an unfortunate presumption.11:06
janimopersia, rsalveti and ogra know more about the rationale and potential drawbacks than I do11:07
=== SLNRPremkiran is now known as premkiran
janimopersia, I am not presuming but this is what I understood from the stories regarding OEM customization of Ubuntu11:07
janimothat almost all are not quite vanilla images11:07
persiajanimo, I'm not suggesting you don't implement: just asking for care to make sure it only affects the development boards.  Retail shoppers don't tend to be as adept at recovering from bricked devices.11:07
janimopersia, sure11:08
janimothat is why probabaly the spec stated it should not be automatic11:09
persiaMost likely :)11:09
alf__Hi! Any idea if Ubuntu can be run on Archos 101 tablets? It can supposedly run Angstrom, so I guess in the worst case someone can use the kernel from that.11:12
persiaalf__, Which processor do they use?11:14
alf__persia: They only say "ARM Cortex A8 at 1 GHz with DSP"11:15
persiaalf__, Should work fine.  Needs investigation to ensure you can get a working kernel, but userspace ought have no issues.11:15
janimopersia, in the meantime if you have suggestions about how to best solve the notification part of this BP I'd appreciate it. So far I was told about update-motd, jockey and debconf notes11:16
persiaWhat's the BP URL?11:17
janimohttps://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update11:17
alf__persia: aha, some more investigation reveals it is OMAP 3630, so it should be fine11:17
persiaAnd here I was hoping that was about porting coreboot :(11:17
janimopersia, do you think that woudl make sense for these boards?11:18
persiajanimo, Reading the spec makes me feel a lot more comfortable in general.11:18
persiaLooks like we use the normal package update mechanism to update files, but never actually change the boot process.11:18
janimoright11:18
persiaAnd then there is a tool that allows the user to install new boot files, if they like.11:19
janimoalthough the installation of packages was questioned by ogra recently11:19
janimobut then I am not sure if getting them is not much more hassle11:19
janimoI'd rather apt&co would take care of that part11:19
persiaI like packages.  We know how to deal with packages.  That we don't actually deploy the delivered code is not so important.11:19
janimopersia, I agree11:20
persiaI'd suggest using the update-notifier mechanism to suggest to the user that they run the update tool.11:20
persiaAnd maybe jockey to select the correct bootloader package to track, which would trigger the tool11:20
persia(if the bootloaders all stuff things in /usr/share/bootloaders/... and the package in question has a trigger on the directory, and that trigger enables update-notifier, etc.11:21
persiaBecause for a beagle A2, it would be nice to update the bootloader, but for the Archos 101 above, it's probably risky, at best, while we otherwise probably support the hardware reasonably.11:22
cooloneysebjan: that's great, i saw our Natty Unity graphic via DVI port now11:22
cooloneysebjan: i applied the patches on top of our ti-omap4-dev branch11:22
janimopersia, do the above work just as well in headless mode?11:22
persiatriggers do.  I don't know about update-notifier.  You might want to have the trigger leverage both update-notifier and update-motd to handle both cases.11:23
persiaNothing is going to handle remote X terminals well, but that's significantly less common than ssh sessions, console logins, or GUI environments.11:24
ograpersia, the prob is that we cant seed it ... i'm not against packages11:35
persiaI'd be against seeding as well :)  Thanks for the clarification.11:35
ograi dont care how we get the binaries as long as we do get them in the right place with a single command11:36
ograif there are packages involved or if someone just dpkg -x'es them to /tmp, i totally dont care11:36
janimoogra, what about sort-of seeding via livecd-rootfs?11:36
ografine with me as well11:37
janimoogra, as wgetting and figuring out version and generally doing apt's job is not too useful11:37
janimogreat11:37
ograapt-get -d <packagename>11:37
ogra;)11:37
persiaI'd prefer jockey to livecd-rootfs11:37
ograno wget needed11:37
persiaJust because, if things go as I hope, we'll see a wider variety of devices capable of using a common image.11:38
ograjockey doesnt really fell like it would fit the task11:38
ogra*feel11:38
janimopersia,  have no idea how jockey can be used here, do you have some pointers?11:38
janimodoes it not already know about packages being available?11:38
ograjockeys backend probably has checks and stuff11:39
ograbut i wouldnt use the frontend here11:39
persiajockey has a means to determine what hardware is present, and then encourage the installation of specific packages that help.11:40
ograiirc it talks about third party drivers and enabling additional HW in its UI11:40
persiaBut, as ogra points out, it's probably only good to use the backend to get the data packages: the front-end is too inviting for the easily confused, and too annoying for the bare-metal types.11:40
ograwe do neither here11:40
kishhi.. i have a minimal maverick filesystem that works with arm.. it does not have dpkg.. and i want to install additional debian packages..11:43
persiaInstall dpkg :)11:44
kishonly if i know how i can install it..11:44
* ogra wonders how you can have an ubuntu rootfs without dpkg in the first place11:44
persiaHrm.  That gets tricky.  Do you know that your userspace is entirely compatible with Ubuntu?  If so, which release?11:44
persiaogra, Careful manual hacking of the rootfs post-construction.11:45
ograheh, but very careful with much effort11:45
persiakish, Do you have ar and tar available?  Alternately, do you have filesystem access to the rootfs from another device.11:46
persiaogra, Yes: the sort performed by the most annoying class of OSV11:46
kishyes.. i have tar ball available.. i access the rootfs from OMAP3430 using nfs..11:46
persiaNOTE: the following is disrecommended, dangerous, and incomplete11:47
kishyeah.. fine..11:48
persiaI'd probably unpack the armel dpkg .deb (make sure you have the Pre-Depends working first), and install the files manually.11:48
persiaThe run the preinst and postinst manually.11:48
persiaNote that dpkg may not work as expected when this is complete, as /var/lib/dpkg is likely not properly populated.11:49
persiaMind you, the above is risky, and not in any way sure to achieve your goal.11:49
persiaIn most cases, if you have the ability to replace the rootfs, you'd do better creating a new one from scratch.11:50
kishi got that rootfs from someone else.. well then I'd probably try to create a new rootfs..11:51
persiaEasiest is probably to use the release image.  If that doesn't work, some people are happy with rootstock.11:51
lilsteviehow the hell do you get an ubuntu, or any debian variant for that manner without dpkg 0.o12:03
premkiranHi12:06
premkiranDid anyone try arecord on ubuntu on OMAP4 blaze board12:06
persia!ohmy | lilstevie12:06
ubot2lilstevie: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.12:06
premkiranWe observe that the arecord on ubuntu is not working for blaze12:07
persialilstevie, Consider that someone could create a rootfs, and then delete individual files.12:07
premkiranNM: we see arecord has a problem with ubuntu on blaze12:11
=== premkiran is now known as slnr
slnrhi NM12:58
slnrNishanthMEnon: we were discussing about the issue of http://pastebin.mozilla.org/104710813:03
RBTrob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! filesink location=test.yuv13:25
RBTthis pipeline fails13:25
RBTrob: unable to dump in yuv file13:25
persiaRBT, Is this different than the issue with not supporting untiling buffers identified before?13:26
=== davidm_ is now known as Guest85609
RBTpersia/rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! v4l2sink13:27
slnrpersia: me and RBT are together13:27
RBTthis pipeline works fine on blaze13:27
persiaI thought ndec said this was expected behaviour.  If it's a bug, then it's worth reporting a bug, but if it's expected, then use gst-ducati13:28
slnrpersia: we installed gst-ducati13:28
slnrpersia: we do not have pointers of how to fix the pipeline with gst-ducati13:29
persiaDoesn't that have a different gstreamer bit than omx_h264dec ?13:29
persiaI'd think you'd want ducatih264dec13:30
persiaBut i'm just guessing, really.13:30
persia(based on http://bloggingthemonkey.blogspot.com/2010/11/announcing-libdce-and-gst-ducati.html )13:30
slnrpersia: did not get13:30
persiaIf you want to use a different decoder, you need to change the gstreamer pipeline.  Just installing a different package gives you the capability to use a different decoder, but doesn't actually use it.13:31
slnrpersia: yes we understand13:32
slnrpersia: so you say we can replace the omx_h264dec with ducati plugin and check ??13:32
RBTpersia: we are looking for both playback and capture. for eg gst-launch omx_camera mode=1 exposure=1 awb=1 nsf=1 device=secondary output-buffers=2 name=cam cam.src ! "video/x-raw-yuv-strided, format=(fourcc)NV12, width=864, height=480, framerate=15/1" ! ffmpegcolorspace ! omx_h264enc input-buffers=3 output-buffers=2 bitrate=4000000 profile=1 level=2048 ! qtmux ! filesink location=/home/blaze/test_13:32
RBT1.mov13:32
persiaThat's what I'd do if I was having that problem, but I'm just guessing.  I have no deep knowledge about the issue.13:33
ndecRBT: capture? our public ducati firmware does not support capture and encode.13:33
slnr# looking into capabilities of ducati plugin13:33
persiaRBT, From the backscroll, I have the impression that if you're working on an OMAP4 platform, you want to use the ducati* plugins, rather than the omx_* plugins.  Change your pipeline.13:33
persiaAh, if no capture, then no capture :)13:34
kishhi.. i use a minimal maverick filesystem on OMAP3. whenever i execute any command I get an illegal instruction error..14:17
persiakish, Are you sure you're using an armel filesystem with armel packages?14:21
kishyes.. the same file system works well in omap4..14:21
persiaVery odd.14:22
vstehlekish: does your kernel support thumb2 ?14:32
kishi see "# CONFIG_THUMB2_KERNEL is not set" and CONFIG_AEABI=y" in my .config14:39
vstehlekish, not sure if 'CONFIG_THUMB2_KERNEL' means "kernel supports thumb2 user space" or "kernel compiled in thumb2 (experimental)"14:40
kishok i'll give a try..14:40
loolvstehle: I don't think there's a tunable to disable Thumb 2; I think this is to build your kenrel as a Thumb 2 binary14:40
vstehlelool: I think you can disable support for thumb214:41
vstehleLxr says thumb2_kernel means kernel compiled in thumb2. kish, this is not this one14:42
vstehlehttp://lxr.linux.no/#linux+v2.6.35/arch/arm/Kconfig#L119414:42
kisherr.. crashed when i set CONFIG_THUMB2_KERNEL14:42
loolCONFIG_THUMB2_KERNEL is definitely to have a kernel using thumb itself14:42
apwogra, is ubuntu-mobile@lists still valid ?14:42
* apw notes that is where he is sending natty upload notificaions to ...14:43
ograapw, nope14:43
loolvstehle: I don't see the option to disable thumb in arch/arm/Kconfig14:43
apwdo you get those?  i am not getting an error14:43
vstehlelool, yeah me neither. I should have mistaken with NEON, sorry.14:43
ograapw, not sure, they might get /dev/null'ed14:44
apwogra, now that has to be the silliest idea ever14:44
ograi dont get any mails from that list anymore14:44
ograto be honest i have no idea whats IS policy of shutting down a list14:45
sebjanlool, vstehle, kish: are you looking for CONFIG_ARM_THUMBEE?14:51
vstehlenope. Thumb214:52
vstehle(thumbee is more "java")14:52
dmartvstehle: did you solve your problem?15:14
vstehledmart, you mean kish's problem ? :)15:15
* dmart scrolls back15:15
dmartvstehle: ummm, yeah15:15
dmartlooks like he's gone anyhow15:16
=== TheUni is now known as Guest3491
=== NCommander is now known as Guest28688
rsalvetijanimo: how did your x-loader/u-boot update testing go?15:38
rsalvetijanimo: did it work fine? or did it break?15:38
janimorsalveti, well it seesm copying works, but not all the time. It may not be the copy itslef but rather the version of the firmware?15:38
janimoshould versions of x-loader and u-boot be independent?15:39
janimotried xloader 1.41 and would not start (Xloader hung)15:39
ograthey are not aligned atm15:39
rsalvetijanimo: but what version did you use?15:39
janimobut I am testing15:39
rsalvetinot aligned15:39
janimodefaults from natty and those from an angrstrom page15:39
rsalvetibecause if you get it quite frequently, then it'll be good to change the tool to recreate the first partition15:39
janimook not aligned but can they be incompatible? like uboot require a minimum version of xloader?15:40
janimorsalveti, indeed, let's see how testing goes15:40
rsalvetijanimo: well, it should be fine if you test the maverick's x-loader/u-boot with natty's one15:40
janimook15:40
rsalvetijanimo: and also, you set the create the wiki page to done, but it's still a work in progress15:41
janimowell it is created15:41
rsalveti:-)15:41
janimoit reflects the current status :)15:41
rsalvetiyeah, not the best word used there15:41
janimothe rest is bugfixing/polish.15:42
janimoI just need to figure out which of the many proposed notification solutions is the simplest and most effective15:42
janimowithout having to explicitly differnetiate between gui and headless if at all possible15:43
rsalvetiyeah, true15:43
alf__rsalveti: (sorry to repeat this, I am not sure if it got through because of the netsplit)16:31
alf__rsalveti: Any luck with clutter and the shaders?16:31
rsalvetialf__: http://bazaar.launchpad.net/~rsalveti/clutter/gles/view/head:/debian/patches/defining-correct-shader-precision-gles.patch16:33
rsalvetithen it worked fine16:33
alf__rsalveti: so the precision is needed in the vertex shader, too... interesting16:34
rsalvetiyup, otherwise it still break16:35
alf__rsalveti: the question is whose fault this is? Is sgx not following the standard?16:35
rsalvetiyeah, I'd say yes, but still need more debugging16:35
rsalvetiwill also try with latest sgx drop as soon I get it working with natty16:36
rsalvetithis version I'm using is not supported anymore16:36
alf__rsalveti: From the standard: The vertex language has the following predeclared globally scoped default precision statements:16:37
alf__precision highp float;16:37
alf__...16:38
alf__The fragment language doesn't have that16:38
alf__The fragment language has no default precision qualifier for floating point types16:39
rsalvetialf__: well, this is clearly not the case for sgx16:39
rsalvetiat least the patch is not going to break others16:39
rsalvetibut should be fixed inside sgx16:39
rsalvetialf__: as soon I can test the new pvr driver I'll report that to imagination16:40
alf__rsalveti: what puzzles me is that glmark2 should fail, too, (because it doesn't declare float precision in vertex shaders)16:41
rsalvetialf__: probably16:41
rsalvetidid you test that with omap 4?16:41
alf__rsalveti: but last time I tried it it worked (on the SDP)16:42
rsalvetihm16:42
=== guerby_ is now known as guerby
=== davidm_ is now known as Guest25169
loolpersia: I wrote u-boot-linaro-efikamx and an uImage created with mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n Linux from linux-linaro-mx51, and could boot up to a kernel panic looking for rootfs21:00
loolpersia: seems to work fine on efikamx; I see USB EHCI, consoles, MMC... and obviously serial21:01
=== ogra is now known as Guest95972
persialool, Thanks for checking that.  I'm filled with new confidence.  After the 2.6.38-rc5 release, I'll identify specific patches to add to improve things.22:42
LopiDoes anyone have any recommendations for virtual keyboards?22:47
LopiI made a custom keyboard layout for matchbox-keyboard and it works decent22:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!