#ubuntu-arm 2009-06-01 <KB1JWQ> There a place to grab an ARM binary of GCC? <KB1JWQ> Or am I misunderstanding how this works? <persia> KB1JWQ, There is a place to grab such a binary, but that's not usually how we do things. <persia> For instance, I believe https://launchpad.net/ubuntu/jaunty/armel/gcc-4.3/4.3.3-5ubuntu4 contains the download for the gcc used in jaunty. <persia> But the preferred solution is to boot into a jaunty environment, and run `apt-get install gcc` if it's not already present (it likely is). <KB1JWQ> persia: Thanks! #ubuntu-arm 2009-06-02 <MrZorg2> Hi <MrZorg2> I have Ubuntu with lxde window manager installed on my gumstix Overo Air computer <MrZorg2> Is there no way to put a c compiler on it? <MrZorg2> I've tried alot of things <persia> MrZorg2, Have you tried `apt-get install gcc` ? <MrZorg2> It doesn't have wiresless-tools installed, which means I can't use iwconfig <MrZorg2> to get connected <MrZorg2> any other way to get connected? <persia> MrZorg2, Lots of ways, but it depends on lots of things. Does it have USB? Do you have a USB wired ethernet device? Does it have serial? Do you have serial protocol software installed (e.g. ppp)? <persia> Do you have access to external media? If so, you could download the packages, and copy them manually (yes, this will be a painful process). <MrZorg2> I downloaded packages and put them on a thumbdrive <MrZorg2> none of them would install <persia> How did you try to install them? <MrZorg2> every one of them complained that there was no c compiler <MrZorg2> I tried putting the binaries of gcc-toolchain on it, but the binaries wouldn't execute <MrZorg2> ./configure, install, make, etc.. the usual <persia> Ah. Don't do that. <MrZorg2> make's not installed either <MrZorg2> what should I do? <persia> Download the binary packages. Install them with dpkg -i ${file} <MrZorg2> okay <MrZorg2> cool, maybe I can get the GNU Arm toolchain to work <persia> Should work by default. It was used to build the entire release. <MrZorg2> I'll give it a try, brb <MrZorg2> every file that's in the bin folder of gnuarm? <MrZorg2> hmm <MrZorg2> dpkg: error processing arm-elf-gcc (--install): subprocess dpkg-deb --control returned error exit status 2 Errors were encountered while processing: arm-elf-gcc <persia> Um, no. <MrZorg2> oh, the binary packages, not the binary files <persia> You want the .deb files for the packages that contain the toolchain. Basically, the dependencies of the build-essential package. <persia> Right. <persia> We tried to do the hard part already :) <MrZorg2> Sorry.. More brb <MrZorg2> I don't think they offer .deb packages of gnuarm toolchain, get something else? <MrZorg2> nm <persia> I thought we did. What do you mean by the gnuarm toolchain? <persia> gcc, etc? <MrZorg2> http://www.gnuarm.com/ <MrZorg2> it has a bunch of stuff <persia> Oh, no. That's not offered, although the components (e.g. binutils, gcc, newlib, etc.) are. <persia> e.g. https://launchpad.net/ubuntu/jaunty/armel/libnewlib0/1.17.0-0ubuntu4 <persia> Although I find http://archive.ubuntu.com/ubuntu/pool/main/n/newlib/ easier to navigate sometimes. <MrZorg2> what order should I install these in? <persia> That's trickier. <persia> I'd probably start with build-essential, and then start pulling the packages based on the complaints about missing dependencies. <MrZorg2> If I can't find ubuntu debs I need, can I use ones I find other places, like debian's site? <persia> There's no guarantee of binary compatibility between Ubuntu and anywhere else, so that's a bit dangerous. <persia> But I know you shouldn't need any packages not in Ubuntu for the basic build toolchain. <persia> If you need an esoteric library, and it's not in Ubuntu, you can probably pull the debian-format source from somewhere else and build it (run `debuild` in the unpacked package directory) to get a compatible package. <MrZorg2> arrrgh <persia> ? <MrZorg2> none of the deb packages for wireless-tools will work <persia> How don't they work? <MrZorg2> package architecture doesn't match system (armel) <MrZorg2> i just found another one <persia> where are you looking? <persia> http://launchpadlibrarian.net/19753609/wireless-tools_29-1.1ubuntu2_armel.deb is probably right. <persia> The path to get there is as follows: <persia> Start from https://launchpad.net/ubuntu/+source/wireless-tools <persia> click 29-1.1ubuntu2 (as the version for the Jaunty release) <persia> click "jaunty armel" in the "Builds" portal on the upper left. <persia> click "wireless-tools 29-1.1ubuntu2" in the Resulting Binaries portal on the upper left <MrZorg2> when i searched for wireless-tools on the ubuntu site the search result was for the releaser's website.. so I assumed it wasn't there on the ubuntu site <MrZorg2> thanks <persia> Download the file listed under "Downloadable files" <persia> I don't have a lot of faith in those searches :) <persia> packages.ubuntu.com might be useful though. * MrZorg2 holds breath <MrZorg2> aww <MrZorg2> got some dependenciies to install first <persia> Yeah. Until you get a net connection up, you'll be playing that game for a bit. <MrZorg2> heh <persia> There's a couple other ways to do it that promise automation, but this is the one I tend to use. <MrZorg2> it tried to install though.. that's progress, for me <persia> I'm not sure how to document this properly. We tend to think of armel as just another architecture, not really any different from i386 or powerpc or sparc, except in terms of the instructions. <persia> But I think most people tend to think it needs special tools: there's a lot like yourself that come by looking to do it differently. <persia> Do you have any suggestions? <MrZorg2> sorry, was afk persia <NCommander> persia, he could try apt-moving an amel alternate CD; might be less painfl <NCommander> *painful <persia> NCommander, Or just copy the pool from an alternate and install build-essential from that. Good idea. Care to outline the procedure? <NCommander> persia, not really, I never using apt-move, or a file repo before <NCommander> s/file/local/g <persia> Hrm. Well then. <NCommander> persia, I would think you would have used apt-move before, you've said things about it before :-) <NCommander> also <NCommander> maybe debootstrap --variant=buildd --arch armel --foreign --make-tarball, and then decompress the result in the gumstix's root directory <NCommander> (and then afterwords do dpkg -i --force-all /var/cache/apt/archives/*.deb to make it properly reinstall the base system, or something like that) <persia> Won't that unpack the packages? <persia> And some base system is already installed. <NCommander> -i? <NCommander> -I is install <NCommander> -x is extract <NCommander> er, -i is install <NCommander> It's how I got my babbages setup with a toolchain before we had ogra's handy script <NCommander> actually <persia> RIght, but you weren't working from a preinstalled system. <NCommander> debootstrap --download-only --arch armel --variant buildd --foreign <NCommander> Then copy all the debs, and reinstall to get the necessary dev packages :-) <NCommander> (I figure thats easier than picking through dependencies by hand) <persia> Well, depends. For short stacks, dependency chasing isn't so bad. <persia> That's why there's a pool on the LiveCDs: to permit one to use that to get basic networking up. <NCommander> The toolchain stack with C and C++ compiler was long enough to make me shiver when I had to do it <persia> Except much of it is usually installed by default, which should reduce it considerably. <MrZorg2> Now I have iwconfig :D <MrZorg2> but no eth0 * MrZorg2 plays detective <MrZorg2> I'm assuming this would install a driver for the gumstix's wireless <MrZorg2> but that would make my life easier <persia> I don't think Ubuntu has a kernel for the gumstix: you'll probably have to get the driver from there. <persia> Also, check if you have a wlan0 <MrZorg2> i checked the interfaces file, only lo <persia> and ifconfig -a also reports nothing? <persia> Because /etc/network/interfaces only contains lo by default, regardless of available hardware. <MrZorg2> ifconfig only brings up lo <MrZorg2> hmm <MrZorg2> It doesn't detect the wireless at all <persia> Right. That's a kernel thing. Check dmesg to verify, and go hunt for modules from whereever your kernel originates. <MrZorg2> not in dmesg <persia> Right. If there's nothing in dmesg, it's likely your kernel didn't autodiscover it. You might be able to force load by modprobing some module, but I have no idea what's available there. <persia> Some day we'll have proper kernel support for all boards in the archive, but that day remains in the hazy future. <MrZorg2> it's funny, before I installed ubuntu I was using what came on the gumstix (OE) and could connect to the internet <persia> So, which kernel did you install when you installed Ubuntu? <MrZorg2> 2.6.28-omap1 <persia> and which kernel were you using when you were running OE ? <MrZorg2> Not sure <MrZorg2> if I pop the sd card out, I could probably tell <persia> Well, that's the bit to track down. I suspect there's a change there that matters. <MrZorg2> ok <MrZorg2> thanks for all your help, by the way <persia> No problem. That's part of the reason for this channel. <MrZorg2> do you think I should update the kernel? <persia> I have no useful advice for your kernel state. I know that Ubuntu doesn't supply a kernel that works on that device. <persia> As a result, you'll need to get a kernel somewhere else, either from someone else, or by building it yourself. <persia> So, if you're having a kernel driver issue, I'd recommend taking that up with your kernel supplier. <persia> Or with your device supplier :) <MrZorg2> I don't really have a kernel supplier.. I followed the directions on this page http://johnwoconnor.blogspot.com/2009/04/installing-ubuntu-on-gumstix-overo.html to install Ubuntu on my microsd card <MrZorg2> when you say "kernel supplier" I get this mental image of some guy talking on the phone saying,"We just got in a big shipment of kernels. I'll make you a deal." <persia> So your kernel was downloaded from http://www.gumstix.net/overo-gm-images/v0.91/uImage-overo-v0.91.bin ? <MrZorg2> yeah <persia> heh :) Well yes. That is what I mean, except that the phone call in this case happens to be a blog post. <persia> In that case, gumstix.net would have supplied your kernel. <persia> So you'd want to use the gumstix fora to investigate the issue. <MrZorg2> aha <persia> I'm not telling you to go somewhere else because I don't want to help, but only because I can't help, as I don't know anything about that kernel. <persia> Actually, there's a comment about getting wireless to work on that post. Something about copying the /lib/modules/ stuff right before the last step. <persia> http://overobuntu.svn.sourceforge.net/viewvc/overobuntu/bin/2.6.28-lib/modules.tar.gz?view=tar may or may not be what you want, and may or may not be trustworthy. #ubuntu-arm 2009-06-04 <Martyn> Morning all <Martyn> does anyone here have experience bringing up linux on a Cortex-A9 (RealView)? <Meizirkki> where could i get Crtex-A9 <Meizirkki> ? <Meizirkki> +o <armin76> Meizirkki: on a realview board? :D <Martyn> realview "board" that is <Martyn> It's a simulation, running under the ARM FastModel <Martyn> I have access to a Cortex-A9 that was implemented on an FPGA .. but the bloody thing is slow as mud (70Mhz) <lool> Martyn: not too surprizing :) * Martyn can't remember, for the life of me, what the correct patch to printk.c is for the beagleboard <Martyn> I know the community kernel sources won't boot out-of-box without a patch .. but I can't find it #ubuntu-arm 2009-06-05 <Martyn> Morning .. what is this OMAP printk() patch I keep seeing people talk about on lists related to the beagleboard? #ubuntu-arm 2009-06-07 <glguy> Are there ever any updates to the arm ubuntu port? It seems like apt-get update, apt-get upgrade never does anything for me #ubuntu-arm 2009-06-08 <Martyn> Hurray! Freescale /finally/ announced the i.mx51 netbooks this weekend <Martyn> Now we can babble about the Pegatron and Inventec devices all we want :) <Martyn> Unfortunately, they decided to only show it with Android. *grr* <Martyn> That netbook would totally have looked awesome w/ Ubuntu <palin> Hi all! Does anyone know when the arm base netbooks are coming out? I have search but can not find a date. <palin> link anything? <palin> ok then ty #ubuntu-arm 2009-06-09 <pan1nx> Can anyone enlight me about which ARM architecture is our ubuntu-arm compilation/build packages done for? <persia> amitk, Are you sure about +NEON as a base requirement, rather than simply some optimisations (like vfp for jaunty)? <amitk> persia: it is going to be an optimisation for ffmpeg and related libraries, I guess. <persia> amitk, That makes more sense to me. I didn't think a lot of stuff had NEON yet. <NCommander> Does anyone have hardware that can use +NEON? <amitk> beagle? <pan1nx> https://wiki.ubuntu.com/Specs/ARMLibraryOptimization <pan1nx> shouldn't we mention the NEON there then? <pan1nx> so far it lists: Ubuntu ARM includes support for ARMv5t+ instruction sets, with optimisations available for ARMv6, ARMv7, and VFP routines where appropriate. <persia> pan1nx, No. That was a jaunty spec. <persia> (and then it got stuck, and now it's kinda in limbo) <persia> The issue is, in part, that it's *hard* to get that right: the differences between generations seem to be larger for ARM. <pan1nx> I tried to find some blueprints on this topic and failed <persia> The blueprints system tends to be a bit hard to navigate, unfortunately. <pan1nx> LOL <pan1nx> I guess this discussion should be moved to #launchpad <pan1nx> but do you have one from the last UDS on this topic? <persia> Well, they're well aware of it. <persia> I didn't follow ARM that closely in Barcelona. You might see if the schedule is still craighoward@example.net, and if so, use that to guess which might be the right spec. <pan1nx> persia, looked there but still couldn't find a clear spec about the build <persia> pan1nx, There may not be such a clear spec. There's a few factors involved. <pan1nx> the closest blueprint i could find was https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-karmic-arm-cloud-builds <persia> Firstly, that the toolchain packages would have most of the details exposed inherently, and changes to the toolchain don't usually get specifications (because they happen so early in the cycle). <persia> Secondly, that most sorts of runtime-code-selection optimisations need to be done on a per-package basis, and so often will end up happening independently (and often in Debian, rather than in Ubuntu alone). <persia> Thirdly, Specs are being drafted currently, for inclusion in karmic, and it may be that if there is a spec, it's not done yet. <pan1nx> ok <pan1nx> good to know... <pan1nx> I will follow this closely <pan1nx> :D as usual :D <persia> pan1nx, Really, download the source of the toolchain, and check that. It's your best guide. <pan1nx> persia, where do I download that toolchain? <pan1nx> so far I found the best doc to be this one: <pan1nx> https://wiki.ubuntu.com/MobileAndEmbedded/ARM-EL-port <persia> pan1nx, apt-get source <persia> pan1nx, It's the Ubuntu toolchain, so, for instance, if you want to look at gcc, run `apt-get source gcc` <persia> Well, actually, it's a bit more complicated. <persia> For gcc, you'll want the "gcc-4.4" package. <persia> And you'll want to make sure you have karmic deb src lines in your /etc/apt/sources.list <pan1nx> ok <pan1nx> thanks persia #ubuntu-arm 2009-06-10 <armin76> Martyn: pegatron inventec :) <Martyn> armin76 : Oh hell yea <Martyn> armin76 : I have a pegatron netbook on the way to the office. <Martyn> armin76 : I have to wait to get my hands on the inventec one though. :( :( <Martyn> and on the PXA FPGA based Cortex-A9 from ARM <armin76> gimme one :D <Martyn> (which runs at a pokey 70mhz .. but at least is clock-cycle-accurate) <Martyn> no. I had to sign >two< NDA's to get the damned pegatron <armin76> yes! <Martyn> It's all prerelease hardware too .. so I'm sure it's buggy as all hell (like the Babbage -wasn't-) <Martyn> *mrrpf* <Martyn> In any case, I've nearly finished adjusting 9.04 for Beagle in a form that might be releaseable <Martyn> what I'd like is an armv6 recompile of the the whole tree though <Martyn> power consumption is LUDICRIOUSLY high with everything compiled v5 <armin76> use gentoo :) <persia> I hear that karmic will be ARMv6 compiled, which may help (but isn't now) <Martyn> we'll never convince anyone that 'ubuntu is better than Android' if we can't get a better optimized ARM dist working on the pegatron <Martyn> my boss has us doing oprofile() and power work now <Martyn> and the news with oprofile() is bad .. it spends far too little time in the idle_pm state <ogra> you can run android apps on ubuntu <persia> Surely that's not just from the compiler flags. <ogra> doesnt that make it classes better already ? :) <Martyn> not if your netbook will only run for 2 hours <suihkulokki> Martyn: umm.. and you think _that_ will get fixed by fiddlying compiler flags? <Martyn> suihkulokki : with proper flags in place? Yes. when you use idle_pm rather than kernel_idle, fully a /third/ of the calls turn into the lower power idle call <persia> suihkulokki, I hear that there was a 5% improvement on the Atom processors from flags: it might get an extra 6 minutes :) <Martyn> suihkulokki : It's one of the few times that putting in v6 support is a good thing <Martyn> persia : This is our beloved ARM .. atom's just don't "get" real power management <ogra> you mean 5% will make up 12min then ? <persia> ogra, 120 X 0.05 = 6 <Martyn> suihkulokki, persia : I'd be glad to show you the oprofile() work and power reductions once the power is complete... <persia> Martyn, Ah. I see. <Martyn> power study is complete rather <ogra> persia, ( 120 X 0.05 )^ARM = 12 <ogra> ;) <persia> Well, no. If there's that big a difference between idle_pm vs. kernel_idle, then it could be lots more. <Martyn> So, this is more like getting 3 hours instead of 2, without doing any hard work... <ogra> to be honest i have to see any improvements on power first ... as long as they put the same peripherial stuff around arm as you have on ATOM i really dont see where the saving factor will be <Martyn> I think the best thing to do is wait till we finish the study, and then read the paper and see the differences as measured in our lab... <Martyn> ogra : The difference is that ARM processors really do power down lots of pieces around the core when you engage the power management features <ogra> yeah yeah <Martyn> ATOM's dont :) <ogra> you have the babbage1 <Martyn> or I should say, they don't do it properly. <Martyn> Yeah. <Martyn> i.mx51 is a dissapointment <Martyn> I'm getting better power numbers out of the OMAP3 than I am from the i.mx51 <ogra> if the "pieces around" are all connected through unmanageable USB, it doesnt really help <persia> Yes, but USB *can* be managed, if it's the right part. <ogra> right, and babbage2 improves here <persia> Just a matter of good systems integration (mind you, there exists manageable USB for Atom too, although my Atom devices all leave USB powered on all the time (even when sleeping). <Martyn> ogra : Have you gotten the babbage2 yet? <ogra> yup <ogra> sits on my desk <Martyn> ogra : I'm skipping babbage2 in favor of the real pegatron hardware ATM <Martyn> (i.e. actual netbook) <ogra> well, that should be identical <Martyn> so I'm told. <ogra> i have the guts of the netbook too <ogra> but didnt even boot it yet <Martyn> ogra : How's the stability of the peripherals? especially ethernet? <Martyn> mine doesn't arrive until next Monday <ogra> seems ok, i ran the B2 for the last week or so without issues <ogra> though we dont have a kernel yet, i'm still using the shipped one <ogra> ubuntu kernel will be ready by alpha3 <Martyn> excellent <Martyn> I will be submitting patches for Cortex-A9 into the mainline kernel in the next couple weeks <Martyn> mostly surrounding getting SMP up and going. There are issues in using WFINE in the bootloader to hold off the other cores <Martyn> I'd like to move that responsibility totally into the kernel, and not have this bootloader state engine dependency <ogra> cool <Martyn> okay, catch you all on the flipside... I'm headed to the office <Martyn> back <Martyn> Okay, I talked to Boss-Man and made noises about getting our hands on a babbage2 <Martyn> no point on having me hack on hardware different than is available to Canonical, right? <persia> Martyn, Well, if you find that there's some gross incompatibility with other hardware, that becomes interesting, for certain classes of other hardware. <persia> Or at least, increases the user base. There's lots of people doing interesting things with Jaunty who have "unsupported" hardware. <ogra> well, the pegatron should be identical, i think the B2 was produced in a very limited amount <Martyn> limited, but ARM partners should have 'em <Martyn> b1 was also quite limited <Martyn> enough that if I accidentally break or tear the debug dongle cable, I'm screwed :) <cbrake> I get cat: /etc/timezone: No such file or directory when running build-arm-rootfs <cbrake> what is the best solution? <Martyn> Grrr... getting Babbage to boot from flash image is not fun #ubuntu-arm 2009-06-11 <ogra> cbrake, looks like your host system is missing proper timezone configuration (the script tries to determine your TZ from /etc/timezone of the host) <ogra> cbrake, as a quick fix run: sudo dpkg-reconfigure tzdata ... before you run the script <cbrake> ogra: yup, that worked -- thanks <cbrake> is there a standard way for making modifications to an embedded Ubuntu rootfs? <cbrake> I need to add some files for serial console, and set up the default networking <ogra> untar it, make your changes, tar it again ;) <cbrake> obviously, I can hack these files into the tarball, but wondering how support for various macnhines is done <ogra> as long as its config changes that will work just fine <persia> cbrake, As much as possible, we attempt to make the system able to handle all machines. <persia> So, for instance, the kernel and udev should be populating the devices you need, and you should be able to pass kernel command-line options for the serial console. <persia> Networking is a bit trickier: mac-based DHCP is a handy way to go. <cbrake> persia: I can get kernel messages out the serial port with kernel command line, but it does not start a getty on the serial port unless I do https://help.ubuntu.com/community/SerialConsoleHowto <ogra> yeah <persia> Hrm. <ogra> the rootfs build script only rolls a rootfs and adds a set of defaults ubiquity would add otherwise <persia> I wonder if there's a sane model for having that enableable on boot. Might be handy for server folk as well. <ogra> there isnt without creating the file in event.d <ogra> i could add a switch to the script, but that still leaves the serial options <ogra> i dont want to crowd the script with to many options <ogra> i.e. serial speed etc that should be set in the ttyS0 file <persia> Oh, right. <persia> I was sorta-kinda-hoping there would be some way to feed it without hardcoding, for general deployment. <ogra> but i surely can add a switch that at least creates it with a bunch of defaults <cbrake> I'm coming from the Openembedded world where the concept of machine support is very prominant, so trying to get re-aligned ... <ogra> yeah, ubuntu is rather focusing on "as broad as possible" support <persia> cbrake, Yeah, it's a different way of craighoward@example.net. We tend to focus on having a (mostly) general solution, rather than lots of machine-specific versions. <ogra> which indeed leaves off a lot of optimization <ogra> but gets nearly anyone the option to run it <ogra> (as long as your arch matches the minimal reqs ... i.e. ARMv5 in jaunty, ARMv6+ in karmic etc) <cbrake> interesting, so ARMv5 is only for jaunty <ogra> yeah, karmioc will do v6 ... likely vfp and NEON <cbrake> my default installs are running at 380MB -- is there any way to trim that down? <ogra> well, its not OE :) <cbrake> nod :-) <ogra> you can cut down by ripping out packages indeed <cbrake> so is that typically done by apt-get remove after the system is booted? <cbrake> or is there a way to remove packages when generating the rootfs? <ogra> no <ogra> after booting <cbrake> ok, thanks for all the help <ogra> unless you build a qemu image first, trim that, loop mount it and tar it up <ogra> the prob is that you cant just chroot into the rootfs ... you need a vm <cbrake> yes, qemu is pretty useful for that vs the target machnine <ogra> but the script has an option to build a qemu only image <persia> Well, unless you're building the rootfs on an armel system :) <ogra> which you then can boot in qemu and trim <ogra> oh, indeed <ogra> if you have powerful arm HW thats indeed the quicker option <persia> well, you might have to go through the rootfs game to bootstrap, but once there... <ogra> indeed ... you wouldnt use the script at all then <persia> Why not? Wouldn't the script speed the bootstrap? <ogra> it would still run qemu <persia> Well, yeah, but you have to do the initial boot somehow, unless debootstrap just works on the BSP. <ogra> oh, right <Martyn> re <Martyn> ogra : have you ever had this error pop up? (gcc 4.2) LD init/built-in.o <Martyn> LD .tmp_vmlinux1 <Martyn> `.cpuexit.text' referenced in section `.ARM.exidx.cpuexit.text' of arch/arm/mach-realview/built-in.o: defined in discarded section `.cpuexit.text' of arch/arm/mach-realview/built-in.o <ogra> nope <persia> Martyn, You mentioned yesterday that you found a power issue with idle_pm vs. kernel_idle. I just wanted to poke you to file a bug about that (as I hear the kernel *should* do the right thing with kernel_idle) <Martyn> persia : As soon as we're done with the tests (Fri) I'll do so. <persia> That soon? Excellent! Thanks. <Martyn> persia : More things have been discovered since yesterday, that may be errata in the i.mx51 and RealView_Cortex_A9 <persia> I always like it when it's a hardware problem :) <Martyn> it's a very high priority now <Martyn> well, it's more than a hardware problem. If its a fundamental design issue in the SoC, it's something my company will have to carefully watch for as we create ours. <Martyn> power domain issues are so.. fucking.. finicky <Martyn> ogra : Thoughts on booting SMP -- right now, I'm having a whale of a time getting the Cortex-A9MP kernel to go SMP, because for some reason ARM expects the bootloader (u-boot in this case) to hold the non-main cores in WFI (I use WFINE) <Martyn> ogra : however, the other cores never get the software interrupt they need to get going . and even THEN .. the WFI resumes right where it left off .. in the bootloader. <Martyn> I think it's the kernel itself that should hold the other processors back in WFI .. right? <Martyn> so that when it restarts the PC's of the other cores are pointed at kernel code .. not bootloader code. <ogra> hmm, amitk might be able to tell <Martyn> *nod8 <Martyn> My boss made nosies at ARM about getting us a babbage2 <Martyn> ogra : Question though .. in order to unify the Ubuntu/ARM universe, are we standardising around RedBoot? <Martyn> or was RedBoot just convenient for the Babbage? <Martyn> OR .. are we shifting to UEFI? #ubuntu-arm 2009-06-12 * ethanbot2 waves to ethana2 <persia> Somehow I doubt that worked the way it was intended. <lool> ogra: For the record, we wont expect NEON in karmic+, only ARMv6 and VFP v3; our toolchain doesn't output NEON by default anyway <Martyn> re <Martyn> lool : *nod* <Martyn> lool : I'm looking to see what it would take to compile karmic w/ full NEON and v7 optimizations <Martyn> akin to building the i686 port <lool> Martyn: why NEON? <lool> Martyn: karmic will likely move to v6 + vfp v3 <lool> There are some advantages to v7 over v6, but not really in a way which we'd use <lool> Martyn: NEON isn't picked up by the fsf toolchain yet AFAIK, it might be by the codesourcery one; perhaps you want to rebuild some specific NEON using apps with NEON enabled? But I don't see much value in using NEON righ tnow <Martyn> CodeSourcery supports it <Martyn> lool : Not for ubuntu "we" but for smooth-stone "we" I need as much optimized performance as I can get out of our new SoC <Martyn> And it's a quad-core v7 w/ a huge L2 <Martyn> Similar to what you're going to see out of pegatron and company once the A9MP's start rolling out <lool> Martyn: ok, but what's going to use your NEON instructions? <lool> Do you plan using a custom toolchain which generates more NEON code? <Martyn> lool : Yep. <Martyn> lool : Or more specifically, the customers that will be making systems from this architecture will need it #ubuntu-arm 2009-06-16 <nat2610> hey, I'm curious, how do you compile everything for arm. IO <nat2610> I'm looking at doing some cross compilation and generating an application that I'm working on, on my i386 linux and I'd like to generate an arm binrary <nat2610> I'm stock on the system library, for instance, I link libobjc.so.2 to my app but ld if I use arm-none-linux-gnueabi-gcc, ld complain that it can't find that lib since the one my system have is compiled for i386 <nat2610> but I know I have it on my arm system with ubuntu <nat2610> hmmm let me try to say that again <playya> nat2610, ubuntu prefers native builds <playya> you need a arm5 device to compile it there <nat2610> playya, so I can't do any cross compiling at all ? I saw some stuff like http://www.freedesktop.org/wiki/Software/sbox2 but I don't really know who uses that (I was hopping ubuntu would be ;) ) <nat2610> playya, I forgot to add, I have a arm5 device but it's really slow so I'm trying to build everything on my pc i386 and just copy over the binraries generated <armin76> nat2610: ubuntu is about using pre-built binaries :) <[g2]> nat2610: depending on what you are trying to cross-compile, you may want setup a full environment, or just run the arm-rootfs in qemu and cross-compile from within a native environment <kblin> hi folks <kblin> I'm running jaunty on a beagle board using one of ogra's kernels, and it seems like there's something weird going on with /proc <kblin> specifically, /proc/<pid>/maps and /proc/<pid>/smaps are empty <kblin> any idea what could be causing this? <Martyn> kblin : An incomplete implementation <Martyn> kblin : find one of the OMAP3 git trees, and you'll have to build a custom kernel <kblin> ok, I'll have to look into that then <Martyn> There is a good 2.6.29 (and now .30) kernel that compiles well. Don't use the tree that has the alternate video driver (ubuntu doesn't know how to drive it, and you'll end up with just a text console) <kblin> hey, I can fix the ip6tables modules while at that :) <kblin> Martyn: it's a headless ubuntu-server box, I don't mind :) <Martyn> oh! <Martyn> Well, then... <kblin> I'm trying to turn it into a file server, active directory domain controller <Martyn> you're going to find that IO performance on the beagle is ATROCIOUS <Martyn> Seriously poo-poo <kblin> yeah, I know <Martyn> I am using USB->SATA on a Beagle C3, and frankly I just want to throw it at a wall most days <Martyn> Then again, I'm getting /really/ used to working with the power of the new Cortex-A8 processors, and even Cortex A9 in the software FastModel simulators <kblin> especially as it seems like networking flakes out on my revB if I use a 2.0 USB hdd <Martyn> There's nothing like having 2, even 4 cores to really make things go zoom <Martyn> Yes <Martyn> there's a power issue on the RevB <Martyn> don't even bother with the B <kblin> well, that's what I got here.. <kblin> btw, power issue? would that matter on a powered hub? <kblin> anyway, this is more or less a proof of concept to show off at the storage developer's conference <Martyn> kblin : no, it's a matter of the on-board 100mw <Martyn> kblin : For some reason, the USB OTG hub tends to 'brown out' for no good reason <kblin> ok, weird :) <Martyn> which causes the hub to go into a bad state <Martyn> the host controller, rather <Martyn> yeah, feh :) <Martyn> C2/C3 doesn't suffer from the issue <Martyn> and has a PROPER port on it <kblin> that matches what I see in dmesg <kblin> well, crud :) <kblin> I guess if I really want to do this with a decent performance, I should be using a system with on-board ethernet anyway :) <Martyn> this is similar to the problem my company is trying to solve. Yep. <Martyn> kblin : There will be (soon) some boards based on the OMAP3 and i.mx51 that are similar to the beagle <Martyn> with more onboard devices <Martyn> there are also beagle-clones that /do/ have ethernet * kblin nods <Martyn> one even has a USB->SATA bridge <kblin> as I said, this one is a proof of concept <kblin> I'm sure if someone wants to turn this into a product, they'll bring the embedded know-how to build a system with the correct specs <kblin> I just want to go to a storage conference showing off that opensource can run an active directory domain controller with 2 Watts <broonie> You want to redo the old ARM demo and arrange to power it with the waste heat from a PC. :) <kblin> hehe <kblin> I'm not sure if a stirling engine-type generator won't look too much like a bomb on X-ray :) <suihkulokki> kblin: if you want decent headless network server, you should look at something like the sheevaplug <kblin> suihkulokki: yeah, planning to <kblin> suihkulokki: I'm currently looking for a way to get shipping to be less than 70% of the unit costs #ubuntu-arm 2009-06-17 <ttx> Hey guys, I have an armel build failure at: https://launchpad.net/ubuntu/+source/wesnoth/1:1.6.2-1ubuntu1/+build/1079861 <ttx> Boils down to "configure: error: C compiler cannot create executables" <ttx> Any hint on how I could debug that ? <kblin> no c compiler installed? <ttx> kblin: that's on an armel buildd so I suppose there is build-essential installed :) <persia> Maybe related to the recent binutils upload? I heard a rumour that there were increased build failures on all non-x86 hardware. <kblin> good point, I see the line where gcc 4 is installed <kblin> doesn't the ubuntu build system do something like "cat config.log" if configure fails? <ttx> kblin: unfortunately, not :) <persia> Adding cat config.log would be something someone could do in debian/rules to debug something. <kblin> because that's where I'd start <ttx> persia/kblin: I'll see if the rumour confirms itself and if not, do some debian/rules instrumentation in my PPA <ttx> thanks <persia> ttx, If your PPA has non-x86 :) <persia> Otherwise, I'd recommend looking for some hardware or virtualisation environment. <kblin> qemu-arm works ok.. <persia> (it shouldn't take that long to get to ./configure, even in low memory-limited qemu-system-arm) <ttx> ok, I'll look into that. <kblin> if you get past the random installer hangs <kblin> though I didn't try 9.10 there <ttx> looking at the buildd logs at https://launchpad.net/builders/nageia/+history it might just make sense to retry the build. <ttx> all builds are currently failing <kblin> ouch <kblin> I agree, given that all of those fail a couple of minutes into the build, with configure: error: C compiler cannot create executables :) <lool> ogra: build-arm-rootfs is a huge success; I keep reading about it in various places; I wish it would become a real project though: source code control, new features, bug reports and the like <ogra> its in the works <lool> ogra: Could you make that happen? I'm happy to contribute if it's in some shared place <ogra> i'm currently pondering how to integrate oem-config properly <ogra> https://blueprints.launchpad.net/ubuntu/+spec/mobile-arm-karmic-offline-installer-gui :) <ogra> i want to get over the script in the qemu instance and use proper tools ... <ogra> i'll put a branch up today <ogra> and prepare a package before end of the week <lool> Ok, cool <lool> ogra: e.g. craighoward@example.net <lool> ogra: With time, I'm starting to think we could use an ubuntu-arm@ ML, and perhaps a LP team <lool> We have a release out of the door, will support more SoCs and get more enthusiasts over time which use Ubuntu as a base <ogra> yeah, fully agreed <ogra> i'm getting chased down by a guy on ubuntu-users@ about his arm probs since weeks, he alone would have filled such a list since UDS :) <ogra> lool, there you go https://launchpad.net/ubuntu-arm-roofs-builder ... i'll create a maintainer team (or hand it to a newly created LP ubuntu-arm team) later <ogra> https://launchpad.net/ubuntu-arm-roofs-builder/trunk will have it with the next publisher run (i already pushed) <lool> ogra: Hmm consider naming things without ARM * ogra sees lool answered savita on ubuntu-devel ... <lool> ogra: only to one of the two questions <ogra> he is the guy i try to educate on ubuntu-users i mentioned above <ogra> yes, i answered all of his questions several times already <ogra> he asks them over and over and doesnt understand <lool> That sucks <ogra> yeah <ogra> well, thats the nature of ubuntu-users@ .... i asked him several times to come here, but he didnt find his way yet <ogra> in a one to one IRC conversation i'm sure he would get his imx31 system up and running fast <lool> ogra: Back to ubuntu-arm-roofs-builder, I think the approach would work very well with other use cases such as mips or even i386, so it would be nice to not use arm in the name :) * lool lunch & <ogra> well, its initially written for armel only :) <ogra> i can rename it if qemu grows support for other arches we support with it <ogra> (usb-imagewriter supports SD cards too, but i wouldnt rename it to be just imagewriter (to generic) or usb-and-sd-imagewriter (to long)) :) <playya> sometimes its better to post in on a ML. then the recipient can read it again and again <lool> ogra: qemu-system-<tab> :) <lool> ogra: The thing is that it's going to be hard to rename later when it's referenced, and it's not hard to make it generic <ogra> lool, any suggestions ? <ogra> playya, well, he asks the same question within five mails he sends within 15min at that speed IRC is more convenient <ogra> grmbl, indeed you can change everything but the url of the LP project <lool> ogra: Well rootfs-builder, or some cool project name <lool> argo! <ogra> so should i register a new project ? <lool> ogra: I think you can rename it <ogra> argo? <ogra> i can rename everything but the initial url i picked <playya> assisted rootfs gold obtainer <lool> ogra: Yeah, just a code name, and as you started it, agro sounded good :) <ogra> heh <playya> can some of you poke the bzr guys to implement git import, please. <ogra> pfft git <lool> Another Rootfs Growing Oddball <lool> playya: That's done? <ogra> lool, i can change everything in the details page, but not the project url, so i need to create a new one or leave the url but change the rest <lool> ogra: Really? <ogra> yeah <playya> lool, i can't pull git sources into LP <ogra> https://launchpad.net/ubuntu-arm-roofs-builder/+edit doesnt offer to change "ubuntu-arm-roofs-builder" <playya> and i want to have several projects. not only branches *hides* <ogra> playya, no, you need to convert the git tree to something sane (i.e. bzr) and then you can push <lool> playya: I think you can now <lool> ogra: I think it's a separate action, like rename project <lool> ogra: Otherwise, you can simply file a question to ask for the change <playya> ok. I'll test it when i finished the debian dirs for the core stuff <lool> https://answers.launchpad.net/launchpad/+question/8299 example * ogra checks <lool> Crap, I can't easily find a project I own <lool> Ulteo PC Virtualization Seminars: ?550 for the whole day <lool> 550 EUR! <ogra> fun <ogra> how about "jarb" <ogra> (just a rootfs builder" :) <playya> or just another ... <ogra> jaurb probably, since its written for ubuntu only (yet) <lool> ogra: Well argo had the advantage of being ogra in reverse ;-) <ogra> yeah, but no meaning at all :) <lool> I like jarb <playya> is anyone working on a graphical image builder? <lool> Simple, short, to the point, catchy <ogra> jarb is an abbreviation :) <lool> I hope it's not an insult in some language <ogra> playya, i am :) https://blueprints.launchpad.net/ubuntu/+spec/mobile-arm-karmic-offline-installer-gui <lool> playya: See, that's the kind of things we could do if we had some common project <lool> I personally thought it would rock to have it in python, or integrated in uvb, but this is all rather futuristic ;) <ogra> yeah, and really a lot crappy overhead <playya> vala vala vala <ogra> i want a gui to select the options and then it should launch oem-config from inside qemu <ogra> and i dont want to rewrite it in python :) * ogra considers calling it kxvlpm03582 ... thats surely not an insult in any language :) <ogra> and as good to pronounce as the renamed screen-profile project :) <ogra> which gets me an idea ... persia any nice japanese suggestion for naming ubuntu-arm-roofs-builder ? <ogra> (japanese seems to be the current hype) <playya> call it anata wa rootf builder <playya> if i remember my japanese course correctly <ogra> awrb ? <dpb> awrb sounds like something written in ruby <ogra> awrb.sh :) <lool> argh no, not .sh! <ogra> argh ... "arm rootfs generation helper" <ogra> ;) <ogra> or s/arm/another/ ... as you like <persia> ogra, æ ¹ä½ (but I'm not sure how to pronounce it) <ogra> is there an utf8 able equivalent i can use for LP ? * persia tries a couple things <persia> nesaku probably isn't horridly wrong. <ogra> sounds good <ogra> what does it mean exactly ? <persia> Meaning is roughly "The harvesting of the source/basis" or "root build" <ogra> perfect <ogra> lool, ^^^^^ <persia> Copy it to http://www.csse.monash.edu.au/~jwb/cgi-bin/wwwjdic.cgi?1B for a closer gloss. <persia> it's not a normal compound, just one I cobbled up (so not an actual Japanese word or anything) <persia> ogra, Do let me know if you're seriously considering it: I'll ask in #ubuntu-jp <ogra> well, sounds better than all former suggestions yet <ogra> lool seems asleep though ... or has no opinion ... <persia> asleep at this hour? <ogra> heh <lool> a) I'm not asleep, just deep in a context and avoiding switches :-) b) I'm getting a headache c) I disable beeping anyway! <lool> ogra: A non-feature-bound term is fine by me! <ogra> so lets go with "nesaku" <lool> As long as you don't name the project ogra's-arm-and-ubuntu-only-shell-rootfs-tarball-builder, it's going to work <ogra> nah, that would be to short <ogra> but probably nesaku.sh ? * ogra hides <lool> Nice try <ogra> :) <persia> ogra, Let me see if anyone in jp is still awake, to avoid making a silly mistake. <persia> ogra, #ubuntu-jp folk say not to use that name. It creates a reminder of farmers in olden times. I have no good suggestions. <lool> ogra: nesaku-(not-the-old-farmers) <persia> heh. No. <ogra> heh #ubuntu-arm 2009-06-18 <cars> Hi, I'm looking for a Korean IME for my netbook. <persia> cars, For application-level discussion, I'd recommend #ubuntu-mobile, but does lanugage-selector not let you enable the default IME? <vanexx> hey does anyone used web cam on a ARM board? <vanexx> I pluged in my UVCVIDEO web cam, dmesg and lsusb says its a logitech orbit AF and that all is ok, but the problem is that cat /dev/video0 produces "no such device", whenever i connect the webcam it makes a directroy under /dev/.udev/names/video ... any idea on whast going on? <lool> vanexx: You could crank up the udev debug level to find out <lool> /etc/udev/udev.conf <vanexx> lool so if i dont get the cam in /dev/video0 there is some problem right? <lool> vanexx: I'm not 100% sure whether cat is a good test <lool> vanexx: You might want to use some v4l2 program <ogra_> arent there some cams that are not using /dev/video anymore ? <lool> vanexx: Actually cat is a bad test, I just tried on my webcam and it doesn't work but the webcam works * lool moves himself to #ubuntu-meeting <vanexx> lool test a ls <vanexx> ls /dev/vido0 <vanexx> u may got garbage chars right? <lool> You mean /dev/video0 <lool> ls wont get you any garbage, no <lool> vanexx: Just use vlc or cheese <vanexx> vlc? <lool> vanexx: apt-get install vlc, then "vlc v4l2://" <lool> It's a media player <vanexx> omg i am idiot <vanexx> it works <vanexx> but.. it even not worked with ffmpeg <vanexx> i tried ffmpeg -i /dev/video0 <vanexx> and the same ting... hmm <vanexx> thks for all loooooooooooooooooooool * ogra_ doubts lool highlights on that :) <lool> Fortunately not :) <vanexx> does anyone outputing web cam stream in AARM? #ubuntu-arm 2009-06-19 <suihkulokki> <shunobies> Hello all I have a quick question probably like most. Does anyone know how to get Quick Synergy to work? <shunobies> I have attempted to set it up several times now and have not luck <shunobies> Hello all <vanexx> Can anyone suggest me a goos ARM board with usb host? cheap pls.. :) <lool> vanexx: beagleboard is probably the nicest you can get for now <lool> it's v7 and has advanced modern hardware <vanexx> yeah but is there any seller here in europe? <vanexx> i know it is 149 $ <vanexx> but shpping cost is 80 <vanexx> hmm hey what about this.. http://plugcomputer.org/ it is cool <lool> You can group orders; don't think there's a reseller in Europe <lool> vanexx: The sheevaplug is cute and nice and cheap, but keep in mind it's ARMv5 and has no VFP <lool> You can run Jaunty or Debian on it, but soon you wont be able to run karmic <vanexx> I am crosscompiling UVCVIDEO to an arm board with linux 2.6.14, uvcvideo needs to be compiled with version > 2.6.14. <vanexx> So its ok, I crosscompile it with 2.6.28 in my PC with no problems, the problem is: when I try to insmod the compiled uvcvideo.ko into the ARM kernel i got errors of the type <vanexx> "undefined symbol X", thats normal because those symbols (symbols from v4l2 etc) are not in 2.6.14 os version, so is there way for compiling <vanexx> uvcvideo specifyng that all refrences must be static instead of dynamic? <gaspa> vanexx: you need to compile the module with the kernel you really use. <gaspa> if uvcvideo needs a kernel > 2.6.14, then it needs that version to run too. <vanexx> but.. i cant change the os in the ARM board <vanexx> it is 2.6.14 and cannont be changed.. <vanexx> I do believe it is possible without compiling with the version I really use.. it is only a matter of compiling statically <gaspa> no, it's not. <vanexx> I mean gaspa, the only diff between 2.6.14 and 2.6.15 for example are new functions and symbols <gaspa> why can't the kernel be changed? it's on a ROM? <gaspa> "only" ? <gaspa> :P <vanexx> so if u export those symbols to ur static compilantion... <vanexx> well no really only but, yes for that matter <ogra> you will at least need the headers for that kernel <vanexx> gaspa no its on a flasy and yes it can be changed but i have no support from the vendor to do it <ogra> (the *configured* headers, which means you need the source) <vanexx> ogra yes... thats true <gaspa> ogra: "(01:42:26 PM) vanexx: I am crosscompiling UVCVIDEO to an arm board with linux 2.6.14, uvcvideo needs to be compiled with version > 2.6.14." <ogra> yep, i saw that <vanexx> thats what i want: use the kernel headers but when compiling the resulting module must have all their references static <ogra> backport it then :) <ogra> or forwardport the missing functions <gaspa> i think backporting is what you need to do. <vanexx> how can I do it? <ogra> with a lot of coding :) <gaspa> change the code of uvcvideo to match the interface of 2.6.14... <ogra> and there is no guarantee it will work <ogra> (which you will only find out in the end) <vanexx> and what if I dont change the OS in the ARM but in /lib i put libraries from the 2.6.28 for ex? <vanexx> using busyboc for ex <vanexx> busybox <gaspa> vanexx: no, userspace library doesn't craighoward@example.net. uvcvideo is a kernel module, and so, must be compiled against the "same" kernel that will run it. * bizkut i am back #ubuntu-arm 2009-06-21 <yeik> hey can anyone suggest me a good arm board? #ubuntu-arm 2009-06-22 <bandwidthcrunch> Hi friends, I have a omap3430 based hardware and i want to compile ubuntu for the armv7 architecture. Any pointers on how to go about the same ? <Martyn> You don' thave to <Martyn> Canonical is working on it, it's just going to take a bit <Martyn> Are you also working with Cortex-A9 hardware? <Martyn> or just Cortex-A8? <bandwidthcrunch> cortex-a8 <Martyn> Right, 3430 ... du <Martyn> duh ratehr :) I'm tired, it's 2:11am for me <bandwidthcrunch> ohh <bandwidthcrunch> catch some sleep <Martyn> not quite yet <Martyn> I'm in the middle of debugging a multicore ARM kernel <bandwidthcrunch> omap4 ? <Martyn> I'm not at a place where I can checkpoint .. still doing the instruction trace <Martyn> Cortex-A9 <Martyn> but not omap4 SoC <Martyn> I'm using the realview-eb fastmodel <bandwidthcrunch> is canonical
{'channel': 'ubuntu-arm', 'month': 6}