=== asac_ is now known as asac
[02:43] <persia> So, I think I figured out how to make plymouth work on armel, at least for ATI or nVidia cards.
[02:44] <persia> But someone needs to write KMS drivers for more typical video adaptors if it's really going to work for most folk.
[02:54] <rcn-ee> hey persia what do you need? omap's have dss2 which went mainline in 2.6.33 which might work...
[02:55] <persia> rcn-ee: From what I'm told, I need a KMS driver, and then someone to write something likehttp://cgit.freedesktop.org/plymouth/commit/?id=f2048af97dcc862dbbb587a0cc2546ddbdbd2b0c that works with the KMS driver.
[02:56] <persia> And preferably something that can build and (kinda) work on all architectures, so we don't have to special-case it.
[02:56] <persia> Mind you, some cases won't get much testing (like I'm building libdrm-intel for armel right now)
[02:57] <persia> Note that the results of this will probably either require some customisation or more maturity of Ubuntu armel, just because with the current way arm kernels boot, only a couple dev boards get supported, which means very little chance of working drivers for fancy graphics chips.
[02:58] <rcn-ee> very true....  which reminds me, it would be nice if meta packages had 'arch' support, no need for ati/intel/nvidia stuff for armel...
[02:58] <persia> But getting the code written and into linux and plymouth makes it easy to get working once the hardware is there.
[02:58] <persia> Actually, metapackages *do* have per-arch support.
[02:58] <persia> But I disagree with your assertion.  I own an ARM device (sadly ARMv5) that has an ATI graphics accellerator.
[02:59] <persia> And I know there exist ones with nVidia chips.
[02:59] <rcn-ee> yeah, that's right the msm7200 has one..  (we almost started stocking that one..) and nvidia's tegra...
[03:01] <persia> Dunno if the current radeon and nouveau drivers work for those, but we may as well publish packages and maybe someone will find a bug and fix it :)
[03:01] <oyotat> Hello. Does anyone know if ubuntu-arm would run on a Gumstix Xscale? like a Gumstix Basix?
[03:02] <persia> oyotat: I can say that you'll probably need a custom kernel, at least.  Let me check the gumstix site.
[03:02] <rcn-ee> actually plymouth's framebuffer mode should work, i need to test that tomorrow.. (dss2 sets the resolution at boot)
[03:03] <persia> rcn-ee: I don't know if I will get the necessary bits into the archive by tomorrow, but in short: build libdrm-intel for armel, then build plymouth using that libdrm-intel1-dev.
[03:03] <oyotat> persia, thanks. one last question, anyone happen to know what's the difference between a marvell armada xscale like the pxa1xx versus the older intel xscale like pxa270?
[03:03] <persia> You end up with a currently-useless intel driver for plymouth, but it lets you test.
[03:05] <persia> oyotat: You should be able to run Jaunty on a verdex-based system with a custom kernel, and up through lucid on an overo-based system with a custom kernel.
[03:05] <persia> Dunno which is "Basix".
[03:06] <rcn-ee> oyotat, pxa270 i think are only armv4 based...
[03:06] <persia> I'm fairly sure they are ARMv5
[03:06] <persia> Because some of the pxa26x series were ARMv5
[03:06] <persia> But I could be mistaken.
[03:07] <rcn-ee> yeah they are armv5, + intel instructions... they were just weird...
[03:08] <persia> Well, one can ignore the instruction extensions to make something work :)  My collection of Zauri have been happily doing their thing for some time (although I find that, despite the better form-factor, I have replaced all my use cases with the Netwalker)
[03:09] <persia> Err, maybe I should have written "despite the inferior shape"
[03:09] <persia> (Zaurus case >> Netwalker case but Netwalker chips >> Zaurus chips)
[04:33] <Sarvatt> if anyone wants to try a newer pixman with more neon optimizations out -- http://sarvatt.com/downloads/armel/lucid/
=== bizkut-miau is now known as bizkut-redhat
=== suihkulo1ki is now known as suihkulokki
=== jamie is now known as JamieBennett
[12:56] <ogra> mumble
[12:56] <ogra> so i cant load boot.scr for no apparent reason :/
[13:09] <xreal> Hi there. Is it even possible to run Linux on a PNA with ARM-compatible CPU?
[13:10] <persia> xreal: What's a PNA?
[13:11] <ogra> picking nose appliance ?
[13:11] <xreal> persia: Personal Navigation Assistant
[13:12] <persia> xreal: Well, there's probably three factors you'd need to investigate.
[13:12] <xreal> persia: Okay, which ones?
[13:12] <persia> 1) Which instruction set is supported by the processor: if it's new enough, you may be able to run Ubuntu
[13:13] <xreal> persia: http://pdadb.net/index.php?m=cpu&id=a9g3&c=centrality_atlas_iii
[13:13] <persia> 2) Is there a way to boot an arbitrary kernel and run against an arbitrary filesystem : if the device is hackable, you may be able to run Ubuntu
[13:13] <xreal> Instructions: 	 ARMv5TEJ
[13:13] <persia> For that instruction set, you could only run Ubuntu 9.04.  Newer versions will not run.
[13:13] <xreal> persia: I've talked to the manufactor and he can offer me a "clean" device, without any software.
[13:14] <persia> 3) Can you build (or find) a kernel that supports Ubuntu 9.04 userspace that runs on the device.
[13:14] <xreal> persia: I think 4) will be: is the other hardware support, like graphics, touchscreen etc.
[13:14] <persia> 4) Are there sufficient drivers for the available input/output devices to make it worthwhile?
[13:14] <persia> Yep :)
[13:14] <persia> But the first three are the key ones.
[13:15] <xreal> I think, I will stay on WM5 and will code software for Windows Mobile.
[13:15] <persia> And 4) is kinda just personal style.  Some people would like to run Ubuntu on their toaster, even if the entire interface consists of a lever one pushes down, which pops up when the toast is done.
[13:15] <xreal> I wanted to use Linux on the device and code linux software ... but that's too hard to figure out.
[13:16] <ogra> that really depends on your toaster !
[13:16] <persia> ogra: Well, sure.  If you have a cool toaster, there might be a point.
[13:16] <ogra> i do !
[13:16] <xreal> I'm not that deep into linux...
[13:16]  * ogra got a cool toaster for chriatmas 
[13:16] <ogra> *christmas
[13:17] <persia> On the other hand, I've found that the smarter an appliance I have, the less likely I can use it successfully.  The processor on my rice cooker died, and now I can make rice reliably.
[13:17] <persia> Which one?
[13:17] <ogra> http://fs1.kauflux.de/slot/358/artimg/large/13226207_401557.jpg
[13:19] <persia> blinkenlights!
[13:19] <ogra> hehe
[13:20] <persia> So, did you install Ubuntu?
[13:20] <persia> Or does it come pre-installed?
[13:20] <ogra> nope, sadly not ... still working on an installation toast :)
[13:20] <ian_brasil> that sir is an impressive toaster
[13:20] <ogra> heh
[13:21] <persia> What due the dark spots beside the slots do?
[13:21] <ogra> they hover out the breadroll device
[13:22] <ogra> it slides out if you touch them
[13:22] <persia> So you can slow-roast stuff over the toaster?
[13:22] <ogra> right
[13:22] <persia> Wow!
[13:22] <ian_brasil> that rocks
[13:22] <ogra> it also has a freezer program to thaw frozen toast
[13:23] <persia> Does it auto-toast once the bread is defrosted?
[13:23] <ogra> yep
[13:23]  * persia should really put on an op hat and declare this off topic, but deep fascination wars with this instict
[13:23] <ogra> lol
[13:23] <persia> That's just a really nice toaster.
[13:24] <ogra> it is, was my only item on the whishlist this year :)
[13:35] <koczis> hi all, anyone interested in ARM/Cortex talk? - have a few questions... rather regarding hardware, but... , anyone?
[13:36] <persia> !ask | koczis
[13:36] <ubot4> koczis: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[13:39] <koczis> self-introducing and the subject may be handy - especially when group subject isn't really in sync...
[13:40] <koczis> I have questions about interrupt handling and interaction between Cortex Core and peripherals in STM32
[13:40] <koczis> the 1st is: do I have to clear pending flags early or lately
[13:40] <koczis> ?
[13:44] <persia> Hrm.  You might have to wait for some time to pass to get an answer to something that specific.
[13:44] <persia> Most of what we've been doing is taking code that compiled for ARMv4 and recompiling for newer versions, based on some toolchain changes.
[13:45] <persia> And I don't think I've seen anyone talk about using STM chips, although that doesn't mean nobody does.
[13:45] <persia> Depending on whether that was one of your more specific questions, or one of your less specific questions, it may be worth asking others, and hoping someone gets back to you about the first.
[13:46] <persia> But if that was one of your more general questions, you may find faster/better answers somewhere else (although I'd be happy to be proved wrong about that)
[13:49] <koczis> that was less specific  - cause in fact: 1. I didn't find a word about it in STM32 doc, 2. I have own experience with early/late clear behavior on other arch, 3. I tested it and it looks the late clearing has flaws that make it outcomes unpredictable
[13:50] <koczis> ...so I use only early clearing now
[13:50] <koczis> so the more specific question about same thing - how do you do it?
[14:46] <asac> lool:  * Bug:488267: ffmpeg: "should be built with -marm for lucid on armel"
[14:46] <asac> cant we just upload that?
[14:46] <asac> or is there more?
[14:46] <asac> bug 488267
[14:46] <ubot4> Launchpad bug 488267 in ffmpeg "ffmpeg should be built with -marm for lucid on armel" [Low,Fix committed] https://launchpad.net/bugs/488267
[14:46] <asac> bug 456659
[14:46] <ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659
[14:47] <asac> plars: isnt that fixed in latest kernel?
[14:47] <asac> cooloney: ?
[14:47] <asac> is that still "fix available" ... or should we move that back to "needs investigation" ?
[14:48] <asac> dmart: hi
[14:48] <dmart> Hi there
[14:48] <plars> asac: still fix available, I've been told that they have a fix for it, but I have not heard that it has gone in yet
[14:49] <asac> dmart: we have  * Bug:458537: linux-fsl-imx51: hibernate does not work
[14:49] <cooloney> asac: i prepared some kernel deb to do some test,
[14:49] <asac> someone said, that this bug doesnt make sense for arm
[14:49] <asac> is that a hardware restriction? or was that just none-sense
[14:49] <asac> cooloney: can you get plars that deb for verification? or post the url on the bug?
[14:49]  * asac sets the bug back to in progress
[14:50] <dmart> (Bug #458537)
[14:50] <ubot4> Launchpad bug 458537 in linux-fsl-imx51 "hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537
[14:51] <cooloney> asac: ok, cool, will update the status of the bug
[14:52] <dmart> Why doesn't the bog make sense for arm?
[14:52] <dmart> bug
[14:57] <lool> asac: 15:55 < lool> asac: The changes are ready in git since Wed; I've tried to  confirm twice with sirestart how he want to handle some other  intrusive changes which are in git (symbol versioning); once  that's clear I can prepare the upload from git
[15:11] <plars> cooloney: got it, will test shortly
[15:24] <cooloney> plars: thanks a lot. frankly, i am not sure whether this will fix the issue.
[15:24] <cooloney> plars: but i will dig into it after i return to Shanghai since my board is there
[15:24] <plars> cooloney: installing now, should be able to let you know shortly
[15:25] <cooloney> plars: great, so what is the symptom on your side of that suspend/resume issue
[15:25] <plars> cooloney: does this kernel also have things to possibly help with the suspend/resume?
[15:26] <cooloney> plars: yeah, might be, because i merged some patches from FSL latest BSP
[15:26] <plars> cooloney: on imx51, it seems to suspend (although I have some doubts as to whether it suspends completely), but will not resume
[15:26] <cooloney> plars: those patches are relatedt to suspend/resume
[15:27] <plars> if I connect to serial, I can see a message like "<PWR> key pressed" when I push the power button, but nothing happens
[15:27] <plars> cooloney: oh, you posted it on the hibernate bug
[15:29] <cooloney> plars: right, i posted both of them, since i applied 30+ patches from FSL latest BSP
[15:29] <plars> cooloney: will do
[15:29] <cooloney> plars: need your help to test, because I am traveling now. heh
[15:29] <cooloney> plars: thx a lot
[15:30] <plars> cooloney: It's what I do :)  Feel free to point me to stuff like that anytime
[15:32] <cooloney> plars: appreciate, oh, do you also have BB3 or just BB2?
[15:32] <plars> cooloney: I'm testing on bb3 at the moment
[15:33] <plars> cooloney: I have a 2.5, but it is in the box at the moment
[15:33] <cooloney> plars: cool, thanks a lot
[15:33] <plars> cooloney: suspend/resume appears to be unaffected by the new kernel, still broken
[15:34] <cooloney> plars: ok, got you,
[15:34] <cooloney> plars: i plan to ping fsl guys for help know
[15:38] <cooloney> plars: if we wanna to resume the suspended board, we press keyboard or the PWR key
[15:41] <asac> bug 505772
[15:41] <ubot4> Launchpad bug 505772 in linux-mvl-dove "system freezes sometimes after X is up for a while" [Critical,Confirmed] https://launchpad.net/bugs/505772
[15:41] <plars> cooloney: neither keyboard, nor power key seem to work.  Also, hibernate still seems to not be supported (not listed in /sys/power/state)
[15:42] <cooloney> plars: ok, thanks, will ping fsl guys soon
[15:42] <plars> asac: that one could be related to 504880, definitely still broken
[15:42] <plars> bug #504880
[15:42] <ubot4> Launchpad bug 504880 in linux-mvl-dove "[dove] possibility of thumb2 instructions invalidly being handled" [High,Confirmed] https://launchpad.net/bugs/504880
[15:42] <plars> cooloney: thanks, I'll update the bugs
[15:43] <cooloney> asac: yeah, i think ericm might know that freezing bug, right?
[15:45] <asac> bug 504880
[15:45] <ubot4> Launchpad bug 504880 in linux-mvl-dove "[dove] possibility of thumb2 instructions invalidly being handled" [High,Confirmed] https://launchpad.net/bugs/504880
[15:45] <asac> cooloney: yes. sorry. just posting here so i can copy that text to release team meeting report
[15:47] <asac> cooloney: plars: ogra: JamieBennett: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[15:47] <asac> please check if you want something to get added to summary
[15:48] <asac> and if i missed anything on the RC bug front
[15:48] <ogra> asac, uboot NIC issues ?
[15:48] <asac> ogra: bug?
[15:49] <plars> bug #507887
[15:49] <ubot4> Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,New] https://launchpad.net/bugs/507887
[15:49] <ogra> https://bugs.launchpad.net/ubuntu/+source/uboot-imx/+bug/507887
[15:49] <asac> give me id .. .ensure its targetted for lucid and milestoned
[15:49] <ubot4> Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,New]
[15:49] <plars> ha! I win :)
[15:49] <ogra> heh :)
[15:49] <asac> "better, strong faster ..." ;)
[15:49] <asac> plars: ogra: please remember to target such things for lucid ...
[15:49] <asac> done
[15:50] <ogra> oh, sorry, i milestoned it for A3 though
[15:50] <asac> yes, both is required
[15:50] <asac> also all that are targetted need to be milestoned (i failed in the past)
[15:51] <asac> and have an assignee
[15:51]  * asac checks bug list again to see if anything is missing
[15:52] <plars> asac: 462798 needs a target also, but is medium and I don't know when/if NCommander plans to work on.  NCommander is a3 reasonable for this?
[15:52] <NCommander> bug #462798
[15:52] <ubot4> Launchpad bug 462798 in ubiquity "selecting 'new partition table' confuses the partitioning" [Medium,Triaged] https://launchpad.net/bugs/462798
[15:52] <plars> sorry, asac, NCommander bug #462798
[15:53] <NCommander> plars, medium, alpha 3, I'm going to work with persia on this during the sprint if we can fix the dove issues
[15:53] <plars> great!
[15:53] <plars> will target
[15:53] <persia> Is that when we're doing it?  I've been wondering :)
[15:54] <asac> ogra: i will put that uboot net bug on your plate for now ...
[15:55] <asac> i will also try to help at least to verify
[15:55] <asac> but i need an assignee
[15:55] <asac> ;)
[15:55] <ogra> hrm, k
[15:56] <asac> ogra: feel free to reassign to someone else from the team ;)
[15:56] <ogra> heh
[15:57] <asac> ogra: bug 506761
[15:57] <ubot4> Launchpad bug 506761 in uboot-imx "lucid uboot hangs on fatload uImage on fsl TO2 TO2.5 and TO3" [Undecided,Confirmed] https://launchpad.net/bugs/506761
[15:57] <asac> isnt RC anymore
[15:57] <asac> or should we even close?
[15:58] <ogra> no, there is still something wonky
[15:58] <ogra> ext2load works flawless
[15:58] <ogra> while fatload doesnt
[15:59] <asac> right. but its not RC
[15:59] <asac> as we managed to work around
[15:59] <asac> or is the script loading bug also gone on ext2
[15:59] <asac> ?
[15:59] <plars> too bad we don't have something for the "fixed this week" category.  dmucs ftbfs was fixed iirc, but not exactly rc
[15:59] <asac> right
[15:59] <asac> well
[16:00] <asac> lool: i dont understand what i means if you say that ffmpeg is committed to git
[16:00] <asac> when does that come down to us?
[16:00] <asac> can we just upload it to ubuntu ?
[16:00] <ogra> asac, the script *only* loads on ext2
[16:00] <asac> ;)
[16:00] <asac> ogra: yeah. ok
[16:00] <ogra> i cant make it load on fat at all
[16:00] <ogra> BBG U-Boot > fatload mmc 0:2 0x90800000 boot.scr
[16:00] <ogra> reading boot.scr
[16:00] <ogra> ... hangs forever ...
[16:01] <asac> yeah
[16:01] <ogra> BBG U-Boot > ext2load mmc 0:2 0x90800000 boot.scr
[16:01] <ogra> Loading file "boot.scr" from mmc device 0:2 (xxa2)
[16:01] <ogra> 407 bytes read
[16:01] <ogra> BBG U-Boot >
[16:01] <asac> i will check fat code
[16:01] <ogra> works flawless
[16:01] <asac> we need to add debugging
[16:01] <asac> u-boot really needs better debugging facilities imo
[16:01] <asac> even the DEBUG flags are all broken
[16:01] <asac> ogra: i can reproduce it, so i can try to work on that if we cant go for ext2
[16:01] <ogra> well, i wouldnt be surprised if thats due to some vendor patches
[16:01] <ogra> we cant
[16:01] <ogra> ext2 needs root
[16:02] <ogra> we dont have root on the build machine
[16:02] <asac> sure
[16:02] <asac> i will check that
[16:02] <asac> thought e2progs work ... or does that need root too?
[16:02] <ogra> its to slow
[16:03] <ogra> NCommander tested it and said its unusable
[16:03] <asac> err e2tools
[16:03] <asac> ok. noted
[16:03] <NCommander> ogra, well, I never looked at optimizing it to reduce the number of e2tools calls
[16:04] <ogra> NCommander, but you said it takes hours to copy the files
[16:04] <ogra> even if you optimize that will be to slow
[16:04] <NCommander> ogra, no, it was about ~10-15 minutes per image
[16:04] <asac> sounds not that much
[16:04] <ogra> vs 1-2 min :)
[16:05] <ogra> thats a lot
[16:05] <asac> right. but its by far not a dramatic problem
[16:05] <asac> or how many image runs are we doing?
[16:05] <asac> one-per-image ... right?
[16:05] <asac> aka 2 ;)
[16:05] <asac> rather 4 (with alternates)
[16:05] <ogra> dont forget a live build already takes 90min
[16:06] <ogra> during alpha and release time thats already to much
[16:06] <ogra> (which is why we're still waiting for a second livefs builder to not have to deal with 3h buildtime)
[16:06] <asac> still. its acceptable imo
[16:07] <asac> at least as a backup
[16:07] <asac> i will try to fix fat and talk to uboot folks that did the fsl patches
[16:07] <asac> its really annoying how fat behaves ;)
[16:07] <ogra> you mean to fsl folks that did the uboot patches :)
[16:07] <asac> yes
[16:08] <asac> i will escalate that if i dont find the issue quickly
[16:09] <ogra> yeah
[16:10] <asac> ogra: so you already tried vfat?
[16:10] <asac> that felt like a good pointer
[16:10] <ogra> yes, but its already enabled in some common.h file
[16:10] <ogra> didnt change a thing, just spilled redefine wanrings
[16:11] <persia> The other massive benefit to FAT is that if we get it working, and get USB support working, we can do bootable USB flash solutions without requiring users to reformat their flash.
[16:12] <persia> (or FAT-on-SD, with the same benefits)
[16:12] <persia> Which means no needing to use dd (or wrappers).
[16:12] <cooloney> asac: just got email from fsl guys, they do not support hibernate, are we going to do that?
[16:13] <asac> cooloney: if they dont support it, we wont do it ... will remove it from RC bug list after meeting
[16:14] <cooloney> asac: got it, i think you are in the email loop i sent, let me update the status of the bug hibernate
[16:15] <asac> thanks
[16:15] <asac> cooloney: do you know if its a hardware limitation thing? or just because there is no code yet? (or is that in the mail i havent read yet)?
[16:18] <cooloney> asac: i just checked code quickly, i think there is no code for hibernate.
[16:19] <asac> ok. but doesnt that need hardware support too?
[16:21] <asac> ogra: can you link the uboot bug to the spec?
[16:21] <asac> thx
[16:21] <asac> slangasek will otherwise poke i guess
[16:22] <ogra> asac, both ?
[16:22] <ogra> (NIC and FAT)
[16:22] <asac> both
[16:23] <cooloney> asac: and from my experience, it seems no arm soc supports hibernate
[16:23] <ogra> donr
[16:23] <ogra> e
[16:23] <ogra> fun
[16:24] <ogra> now i can load boot.scr but uimage hangs
[16:26] <asac> cooloney: right
[16:26] <asac> thanks
[16:26] <asac> ogra: make the partition even bigger ;)
[16:26] <asac> or bad the file with zeros
[16:26] <ogra> nah, thats cant be it :P
[16:26] <asac> so its at least a full block :)
[16:26] <asac> who knows
[16:27] <asac> i saw code in uboot that said: "always full in full blocks"
[16:27] <asac> pull
[16:27] <ogra> boot.scr is 315 byte big and loads fine
[16:30] <ogra> doesnt load uinitrd either
[16:33] <lool> asac: You pinged me on this bug
[16:33] <lool> asac: 15:46 < asac> lool:  * Bug:488267: ffmpeg: "should be built with -marm for  lucid on armel"
[16:34] <lool> asac: I'm saying that I fixed this and it's pending upload; it's commited in the packaging git repo
[16:34] <asac> sure
[16:34] <asac> i understood that. just wasnt sure what that means
[16:34] <asac> but nevermind
[16:34] <lool> I dont understand where the ambiguity is
[16:34] <asac> e.g. is that git repo for debian
[16:34] <asac> will we wait until it migrates to testing
[16:35] <asac> etc.
[16:45] <lool> asac: It's a git repo for debian and ubuntu
[16:45] <lool> The changes aren't uploaded to Debian
[16:46] <lool> It's like regular Vcs-Git stuff; not sure what to say
[16:48] <asac> sure. git just felt like debian
[16:48] <asac> thats why i double check
[16:49] <ogra> debian isnt *that* bad, come on
[16:50] <lool> What's in Vcs-Git for ffmpeg and -extra is correct
[16:51] <lool> No way to encode the branch infor,mation though
[17:38] <asac> i dont mind debian, just the time delay if we go through debian first
[17:38] <asac> thats why i wanted to clarify it
[17:39] <asac> so all fine ;)
=== bizkut-miau is now known as bizkut-redhat
=== bizkut-miau is now known as bizkut-redhat
=== bizkut-miau is now known as bizkut-redhat
=== keesj_ is now known as keesj
[22:07] <lool> suihkulokki: You might be interested in kees patch for the ld-linux segfaults
[22:08] <lool> http://bugs.launchpad.net/bugs/452175
[22:08] <ubot4> Launchpad bug 452175 in linux "Random segfaults when using ld.so explicitly to start a program" [Medium,In progress]