[00:19] https://bugs.launchpad.net/bugs/487979 [00:19] jerone-mobile: Error: This bug is private [00:19] ubot4, wrong channel [00:19] Factoid 'wrong channel' not found [00:19] ubot4, sorry about that [00:19] jerone-mobile: Error: I am only a bot, please don't think I'm intelligent :) === asac_ is now known as asac === bjf is now known as bjf-afk [01:39] hello [01:39] any one know ETM 3.2? [01:45] any one know ETM 3.2? [01:50] hi [01:54] hi [01:54] any one know ETM 3.2? [01:55] any one know ETM 3.2? [01:57] any one know ETM 3.2? [02:00] Ramiz: Repeating your question over and over will not give you a quicker answer [02:00] no i am so sorry [02:01] i repeted cuz i did not sure if it sent or not cuz i am not login [02:01] sorry [02:01] i am wating [02:01] ah. What's ETM anyway? [02:01] Embedded Trace Macrocell [02:08] ok, figured it was but was but wanted to make sure. I'm guessing most people here aren't working with tools that low level [02:08] you might be better off asking in a group related to the specific SoC you're trying to debug [02:09] where i can find this on irc u think? [02:13] depends. what chip are you working on? [02:13] it is arm11 cutome one [02:13] it is like omap [02:14] custom? so your own soc? [02:14] it is not mine === Q_Continuum is now known as Q_Contixicated [11:32] ogra, asac: I see https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-multiarch-execution-environment just got a work item: research possibility of integrating the build-arm-chroot script [11:32] functionallity directly into debootstrap (2 days): TODO [11:32] Isn't that what I just did? [11:34] lool, well, sending that patch to colin, getting it approved upstream etc ... see the spec now, we postponed it [11:35] Is it research or is it implementation then? [11:35] if we keep binfmt as well as the build-arm-chroot script for now the world wont end [11:35] well, actually both, i could have formulated it better [11:36] This work item doesn't mention the static versus shared bit [11:36] the work items are kind of void as we pushed it back for lucid [11:36] lets just keep it as is... if one gets to create the code beyond a proof of concept it gets implemented ... i consider it nice to have [11:36] if you want to fill stuff in in the spec go ahead [11:36] s/it gets implemented/and it gets implemented/ [11:36] I've put down my research; did you guys check it out? [11:37] I was surprized not to hear back from any of you two [11:37] i read it, yes [11:37] ogra: right. thats what "Low" means. if someone gets to it fine. otherwise no problem [11:37] s/put/written [11:38] lool: will read it later today. needed to work full-time on spec stuff esterday ;) [11:39] lool, if you feel like implementing what you found, feel free (i'm not really happy with the idea to fiddle with binfmt on the fly, but as long as it doesnt stop working i dont care) [11:39] What would really rock is doing it with multiarch, but it's not clear it will happen this cycle [11:39] right [11:39] ogra: Well I'm not happy with relying on the host setup instead :-) [11:39] until then i'm happy to keep it as is [11:39] right, i know [11:40] Frankly where the binfmt stuff happens is just a technical detail; I hate the requirement that the chroot pathname needs to match the host pathname though [11:40] as i said, as long as the functionallity persists i dont really care, if you have spare cycles to implement it your way, feel free [11:40] Moving binfmt to this script is the only thing I didn't research -- as noted -- I dont know whether it's container friendly [11:41] It's probably though to do it in the chroot without a special helper: you can't run anything in the chroot without the wrapper and you need to setup the wrapper from withing the chroot for the container stuff to work :-/ [11:41] i think the container stuff happens at another level ... i wouldnt see why it shouldnt work [11:42] the kernels binfmt module just reacts on the magic number ... i dont think it cares if that happens in a container or not [11:43] as long as the wrapper is found at least [11:43] * suihkulokki has a way to execute arm binaries in a chroot using a dynamically linked qemu-arm without binfmt_misc [11:43] suihkulokki: I can do that for a single binary as well, but not one that forks [11:44] including forks [11:44] suihkulokki: Oh scratchbox2? [11:44] lool, anyway, if you find a way thats as easy as buiold-arm-chroot for the user, feel free to go ahead and implement it [11:44] well, sb2 can do that too [11:44] suihkulokki: Would love to hear your way then [11:44] my way is just much more lightweight [11:44] suihkulokki: I've documented what I tried in https://wiki.ubuntu.com/Specs/Mobile/QemuStaticExecutionEnv/Research [11:44] what i dont want is that the user needs to type in a chain of commands and options to create a chroot [11:45] ogra: That can always be reduced to a script :-) [11:45] as i said, feel free :) [11:45] ogra: My worries with the proposals I heard at UDS were: specific to Ubuntu, package proliferation [11:45] i will only put time into it if i actually have a lazy day before FF ... [11:45] which is unlikely [11:45] I hope to show my way next weekend latest [11:46] suihkulokki: Well you said too much now; mind sharing the high-level idea? [11:46] suihkulokki: Did you patch qemu to spawn itself on forks? [11:46] or exec rather [11:48] basicly a LD_PRELOAD a library that executes qemu on exec if the binary to be executed is not host arch [11:48] Ok; I thought of something similar by patching qemu's syscall emulation of the exec() syscall [11:49] Your approach is probably more self-contained and might also allow calling into a host binary more easily [11:49] Hmm not sure actually [11:50] LD_PRELOAD has to be inherited by all childs; it fails with env -i and the new childs will look for the preload data in the chroot [11:50] But still more self contained [11:50] ld.so.preload maybe? [11:50] and will fail for static binaries.. [11:51] dpb, look, the ld_preload only affects qemu, not the binaries running inside qemu so it doesn't matter if the muck the env or are static [11:52] s/look/lool/ [11:54] suihkulokki: Oh so it's a ld_preload trick to change qemu's behavior for exec(); ok that's exactly what I thought of except I envisionned that in the qemu code itself [11:54] That would work very well I think; good idea [11:59] lool: yeah. if some hardcoding is acceptable it would be easy to do the same modifying qemu's exec [12:00] suihkulokki: Is hardcoding really necessary? can't qemu-arm exec() into itself with enough info to proceed to the target binary? [12:00] suihkulokki: ah, right. I'm tired. :) [12:00] (I didn't look at the qemu syscall emulation itself at all, so feel free to call that impossible or very hard!) [12:20] asac: glib > we want to get rid of swp uses for v7 in any case, a short term stop gap would be to change the build flags of glib to build in arm mode; that would at least avoid failing a gazillion of builds, images etc. [12:21] lool: right. we dont want arm mode ... unles we cant find a patch quickly ;) [12:21] Well I'm only suggesting that as a stopgap [12:22] glib impacts a lot of packages [12:22] Of course we want thumb2 [12:22] lool, do you know swp will fail with -Wa,-mimplicit-it=thumb ? [12:22] lool: right. i just hope we can have a patch really quick ;) [12:22] (this afternoon) [12:22] I think it's not available in t2 mode [12:22] otherwise i agree we hsould upload with -marm [12:22] hrm [12:23] Which would seem logical since v7 introduced thumb2 AND new stuff to get rid of swp [12:24] http://paste.ubuntu.com/333081/ [12:24] thats the code [12:26] SWP instruction [12:26] is not supported in Thumb2 mode at all [12:26] i know [12:26] As confirmed from the Slide 5 notes in https://wiki.ubuntu.com/Mobile/ARMv7AndThumb [12:26] ;) [12:26] You were asking whether implicit-it=arm would help, it will not [12:26] I just double checked [12:27] its also here: https://wiki.ubuntu.com/ARM/Thumb2 [12:27] lool: right. thats what i suspected [12:27] or here https://wiki.ubuntu.com/Mobile/ARMv7AndThumb [12:27] Well since ogra was about to fire a build with implicit-it=, I figured it was worth mentionning that it wouldn't help [12:27] Anyway, /me hops to pressing stuff [12:28] well, i'm still writing on a spec [12:28] __sync_val_compare_and_swap [12:28] i wouldnt have fired it off right away :) [12:47] is there a good resource to track armel build failures? [13:08] ubuntuwire [13:08] http://qa.ubuntuwire.com/ftbfs/ [13:28] th [13:28] x === bjf-afk is now known as bjf [16:40] that's the failing qt4-x11 code http://paste.ubuntu.com/333247/ [16:40] The #else [16:41] ../../corelib/io/qfsfileengine_unix.cpp:1309: error: unrecognizable insn: [16:41] (insn 636 635 218 23 ../../corelib/io/qfsfileengine_unix.cpp:1286 (set (reg:SI 9 r9 [+4 ]) [16:41] set reg sounds like assembler to me, surely not like C++ === dyfet` is now known as dyfet === ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | is there gym excersizes to make ARMs faster? | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 [17:29] Hm, what's the reason for using softfp? I thought all supported platforms today had proper implementations? [17:29] oh, nevermind. that's just the abi [17:35] asac, do you need -Wa,-mimplicit-it=thumb or is -mthumb good enough? [17:43] fta, https://wiki.ubuntu.com/ARM/Thumb2 [17:43] i dont think -mthumb is enough [17:44] i get /tmp/ccRUIN1V.s:131: Error: thumb conditional instruction should be in IT block -- `moveq ip,#8' [17:44] but as it happens after 19h+ of build, i prefer to ask ;) [17:45] i should probably setup a crosscompile env [17:48] no, that gets painful [17:48] since you need to cross build all the deps first [17:49] crossbuilding is fine for packages with only a few deps ... i wouldnt build something with lots of deps in a cross way [18:27] ogra, upstream provides this recipe: http://code.google.com/p/chromium/wiki/LinuxChromiumArm [18:27] looks possible but could be easier :P [18:31] well, as long as you are sure the cross toolchain they provide uses the same options, that might work [18:32] ogra: our cross toolchain is not sysrooted [18:34] zumbi, well, does it default to the options documented on https://wiki.ubuntu.com/ARM/Thumb2 ? [18:34] ogra, no, i do not think so [18:34] right, thats what i suspected [18:35] so it doesnt help much unless you hack around it in debian/rules since fta wants to fix build errors happening on the buildds [18:36] btw, which cross tool do you use? lool PPA? [18:36] none [18:36] * ogra is highly anti cross :) i build on real HW [18:37] ogra: do you native build kernels for new bootstraps? [18:37] for small packages i use the ubuntu qemu-arm-static package [18:38] oh, for test kernels i sometimes use codesourcery ... [18:38] yes, qemu is nice and helpful, also cross building [18:38] but most of the time i simply use my dove board :) [18:39] which is fine and if you have the time and the power, it is best practice :-) [18:39] but cross building does only cut down buildtime in half or so ... and i usually dont touch kernels [18:39] ogra: you can not native build a uclibc based device (no space) [18:40] we dont use uclibc in our ubuntu images [18:40] all devices we support have at least 800MHz and 512MB [18:40] and usually a SATA port [18:40] ricer board [18:40] yes, in those cases, cross building is not needed [18:41] but, i can not native build on my lynksys [18:41] armin76, still envious, eh ? [18:41] zumbi, well, i did native builds on my nslu2 ... but i agree its no fun [18:41] armin76, just wait for the next gen sheeva plug :) [18:42] boo [18:42] ogra: why do i have to wait?! [18:42] it will be dove based [18:42] at least thats what roumours said :) [18:42] armin76: still you have not got an armv7? [18:43] zumbi: nope [18:43] zumbi: ogra doesn't wanna share *g* [18:43] armin76: get a beagleboard :) [18:44] or if you are rich, get a babbage board [18:45] ogra: cross building is needed when you have to maintain a distro which runs on 4MB devices up to several GB [18:45] indeed [18:45] luckily ubuntu went beyond that :) [18:45] also uclibc would enter in thecocktail [18:45] zumbi: or compiling qt and not waste several days on it :P [18:46] qt-embedded ? [18:46] ogra: i could get your babbage *g* [18:46] Stskeeps, https://launchpad.net/ubuntu/+source/qt4-x11/4.5.3really4.5.2-0ubuntu1/+build/1292073 22h :) not even a day [18:48] armin76, sure, i could sell it to you :) it being used i would even go down with the price by $50 ... so it would only be $700 :P [18:48] afaik freescale sells them now [18:52] genesi are shipping their pegatron smarttop rebranded device too (with u-boot as firmware) [18:53] right, but you could only use ubuntu userspace with it [18:53] there is no pegatron kernel [18:53] and its stuck on 2.6.28 ... [18:53] yeah i know. nice gpl compliance there. [18:53] heh [18:54] lucid will use uboot on the babbage too ... [18:56] * ogra calls it a day [18:56] yikes, 800 bucks from arrow [18:56] * zumbi wonders if any of you know mpc8548 ppc processors [18:57] zumbi: plenty of people on #mklinux do [19:00] ojn: yes, i just went there === Q_Contixicated is now known as Q_Continuum [21:14] ogra, i'm confused by the "-Wa,-mimplicit-it=thumb is not implemented as of gcc-4.4 4.4.2-3ubuntu1".. does it mean that passing it is useless as won't work, or that it's just not yet the default? [21:14] +it