| who_ | Is there anyone that can talk to me briefly about cross compiling on 9.10(x86) for 9.10(arm)? | 16:01 |
|---|---|---|
| who_ | Specifically, I want to know if there's an established toolchain/way to setup the codesourcery toolchain. | 16:02 |
| lool | who_: The codesourcery toolchain can be used as usual | 16:11 |
| who_ | lool: as usual doesn't mean a huge amount to me ;) it's not something I 'usually' do. | 16:11 |
| lool | who_: What's your overall goal? | 16:12 |
| who_ | I have an IGEP2 board (like a beagle). I have made myself a 9.10 rootfs, and I want to be able to compile some apps not in the repositories for it | 16:12 |
| lool | I would recommend you do native builds then | 16:13 |
| who_ | I don't want to have to compile on the hardware and I because of the 256mb mem requirment on qemu (as far as I can see) - it's pretty slow | 16:13 |
| lool | I wrote some patches to qemu to be able to use more than 512m | 16:13 |
| lool | It's usually enough | 16:14 |
| lool | Another route you might follow is using qemu syscall emulation to build under x86; this is very fast, much faster than qemu machine emulation | 16:14 |
| lool | In this latter case, you can have as much as your host, but probably limited to 4GB; didn't try it out | 16:14 |
| who_ | lool: that sounds more like what I'm looking for | 16:15 |
| who_ | lool: so I could, for example, point it at my rootfs and get it to link against that? | 16:15 |
| who_ | lool: the packages in the repositories: how are they built? | 16:16 |
| lool | We build natively, on real hardware | 16:17 |
| who_ | lool: out of interest, do the qemu patches need to be applied to qemu and to the kernel I want to use with qemu? and are they in some rcs somewhere? | 16:17 |
| lool | who_: You could point at your rootfs and link against that | 16:17 |
| who_ | lool: sounds excellent. | 16:17 |
| lool | If you want to use the patches, these are for machine emulation; they target the realview and versatile boards | 16:17 |
| lool | We actually some of the versatile ones to our Ubuntu versatile kernel | 16:18 |
| lool | But I didn't get that kernel to work yet | 16:18 |
| lool | We actually *applied | 16:18 |
| lool | But you don't need any patch for syscall emulation | 16:18 |
| who_ | lool: okay, I guess I'll try that route first | 16:19 |
| lool | The only thing to keep in mind is that it's a very unperfect emulation; stuff might or might not run and your software might detect host features which your target doesn't have | 16:19 |
| lool | But when it works it's the best option | 16:19 |
| who_ | lool: any reason you suggest that over codesourcery? | 16:19 |
| who_ | or, in fact, some other cross compilation system? | 16:19 |
| lool | If you're using karmic, just install the qemu-arm-static package, and copy /usr/bin/qemu-arm-static to your rootfs' /usr/bin, and you're done | 16:20 |
| lool | Cross compilation is harder to get to work with Debian/Ubuntu packages | 16:20 |
| who_ | lool: at first, I will probably be just compiling new code I'm writing or things I'm porting... | 16:21 |
| lool | It creates many issues of its own which you wont get without xcompilation, and the output is not identical to native compilation | 16:21 |
| lool | basically, cross-compilation adds a layer of complexity and uncertainty and degrades output slightly | 16:21 |
| who_ | lool: thanks. that makes sense. | 16:22 |
| who_ | so what _is_ qemu-arm-static? | 16:22 |
| lool | A package shipping a static binary of qemu-arm, that's the syscall emulation one | 16:23 |
| who_ | sorry, I mean, /usr/bin/qemu-arm-static - what is in that file an for what purpose do I need it on my rootfs? I assume it only needs to be there for when I'm running on the x86 machine, not that any applications compiled using syscall emulation actually require it to be there? | 16:31 |
| who_ | lool: also - can you tell me anything about this supposed xcompile toolchain? http://alone-in-the-light.zenvoid.org/2009/11/cross-toolchain-for-arm-ubuntu-910.html | 16:32 |
| lool | who_: It only needs to be there while you're using the rootfs on your x86 host; it's needed for binfmt | 16:34 |
| lool | who_: First time I see that link, no idea what's in there | 16:34 |
| who_ | lool: okie :) I'll have a bit of an explore myself. I'm in that stage where I don't yet quite know enough to assess these things/avoid naive mistakes :S. I'm sure I'll get there | 16:35 |
| lool | Try the simple instructions I mentionned earlier, it should get you started immediately | 16:37 |
| who_ | lool: you're referring to the instructions about copying qemu-arm-static to the rootfs and using qemu syscall emulation? That's what I think I'll try first. | 16:40 |
| lool | Yes | 16:41 |
| who_ | thanks very much for your help :) | 16:46 |
| who_ | some questions in passing. Are there arm builds for ppas? | 16:46 |
| who_ | and what hardware do you use for the compilation of the entire repositories!? | 16:46 |
| lool | who_: We don't have public armel PPAs; I'm not 100% sure about current hardware, but I think only Freescale i.MX51 based boards are in use ATM | 16:53 |
| who_ | lool: so I assume then most people using ubuntu-arm 'in anger' are compiling natively and/or using only things int he repositories? One thing I'd like to try on by board but don't really want to have to compile is Chrome (the browser) - know if there are any packages around? google doesn't seem to have helped me. | 17:02 |
| lool | who_: https://launchpad.net/ubuntu/+source/chromium | 17:03 |
| lool | ISTR it requires NEON though | 17:03 |
| who_ | that one's a game not a browser "Chromium is a top down fast paced high action scrolling space shooter which uses the SDL libs." | 17:04 |
| who_ | https://launchpad.net/ubuntu/+source/chromium-browser seems to be built for Lucid though... | 17:05 |
| who_ | when I get to my desk tomorrow I'll see if it depends on things I don't have... | 17:06 |
| lool | who_: Oh sorry | 17:08 |
| lool | who_: https://launchpad.net/ubuntu/+source/chromium-browser | 17:09 |
| lool | who_: But you can see it's built for x86, x86-64 and ARM | 17:09 |
| who_ | yea, I found that (see above), hopefully the lucid package will work on Karmic without too much trouble :S? | 17:10 |
| who_ | lool: otoh, it's not that important - just an experiment really. | 17:11 |
| armin76 | hahaha | 17:50 |
| armin76 | lool: so a game, uh? :D | 17:50 |
| === Guest57357 is now known as davidm | ||
| pdxspork | Hey, I have a couple questions if anyone is around and wants to humor me | 22:20 |
| pdxspork | I have a beagle board that I have used rootstock to build a 9.10 image for. Most stuff works pretty well but I need access to GPIOs and UART2 on the expansion connector, the later requiring changing the way the OMAP has the pins muxed. What is the best way to change the pin muxing? | 22:20 |
| pdxspork | It looks like my options are to recompile either uboot or the kernel, however it does not seem that the process for building an ARM kernel on my x86 machine is going to be too much fun. | 22:21 |
| pdxspork | Secondly, I get a "Permission denied" error when attempting to access the GPIOs (user LEDs to be specific) on the OMAP. Even as root. Is this a kernel issue or am I just doing something wrong? | 22:22 |
| lool | pdxspork: You could build the kernel natively; it might be painful once, but if you use ccache the next builds should be ok | 22:24 |
| lool | pdxspork: Otherwise, you could build within a qemu-syscall chroot or cross-compile | 22:25 |
| pdxspork | lool: Yeah, I'm looking towards using a cross-compile | 22:47 |
| pdxspork | I have a lot of x86 horsepower, no reason to wait an eon for the beagle to compile it when I've got a dual xeon box sitting here | 22:48 |
| lool | pdxspork: Cross-building the kernel is probably easiest then; just add it to you path and pass CROSS_COMPILE=your-compiler-binaries-prefix- to the build | 23:14 |
| lool | e.g. CROSS_COMPILE=arm-linux-gnueabi- | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!