#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 up at summit.ubuntu.com, 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 looking at things.  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 2010-06-14
<lag> cooloney: ping
<cooloney> lag: yeah,
<lag> cooloney: Good morning
<cooloney> lag: morning, man
<lag> Is the OMAP4 repo on our server yet?
<amitk> morning guys!
<lag> Morning Amitk
<amitk> I heard that we have a newly-rebased tree from TI?
<cooloney> lag: yeah, i just synced one from sebjan
<cooloney> and he is trying to unify the panda code into his tree
<lag> Great
<cooloney> i will pull from him after that and built for you guys for testing
<amitk> what version is the tree based on cooloney ?
<lag> What's it' called?
<cooloney> lag: do you have other omap4 hardware instead of panda?
<cooloney> amitk: oh it is based on TI 2.6.34 integration tree
<lag> No, just Panda
<hrw> morning
<lag> I'm guessing it would be called ubuntu/ubuntu-lucid-arm.git
<comradekingu> Gnome bytter ut F-spot med shotwell
<comradekingu> Wrong chan, sorry
<cooloney> lag: lucid-arm.git? no, the new branch is for maverick
<lag> I'm guessing it would be called ubuntu/ubuntu-maverick-arm.git
<lag> ;)
<amitk> why is it a separate tree and not a branch in the maverick git tree?
<lag> I understood that it's not ready to go into the main repo yet
<lag> I was chatting with cooloney and ogra about it the other day
<cooloney> lag: http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-ubuntu-2.6.34
<cooloney> that is a temp branch in my repo
<lag> Okay
<lag> And after?
<cooloney> after it is ready, i will push it out for review and merge into maverick
<cooloney> amitk ^^
<amitk> ok
<lag> cooloney: ping
<cooloney> lag: could you please try the kernel from http://people.canonical.com/~roc/kernel/omap4-2.6.34-panda/ on your panda?
<lag> Was it built from roc/ubuntu-maverick.git
<cooloney> lag: yeah, it is
<cooloney> lag: i cross built it locally
<lag> By locally, do you mean on 'your' machine?
<lag> I am building the same kernel currently on one of the build servers
<cooloney> lag: yes, on my machine, since i failed to use sbuild on tyler
<cooloney> lag: aha, cool, are you using sbuild?
<lag> No idea
<lag> Whatever's specified in the chroot
<lag> I guess so, as I received an sbuild error this morning when the permissions were messed up
<cooloney> lag: yeah, me2, so i switched to my local builder
<lag> Well once the maverick-armel issue is sorted apw will have it available again within 2 mins
<apw> lag its not that simple
<apw> but i am working on it
<lag> Is it not the same issue as the other build server?
<apw> lag no
<lag> You nailed that in moments few
<apw> as in the machine is now working for you, but not for him
<lag> Ok, sorry for giving false hope :)
<lag> Oh, that sucks
<lag> (for him)
<lag> :)
<apw> there is a collision due to two different chroot types, a normal one, and a union one for hard builds
<lag> I'll not pretend to know a great deal about chroot architecture. I thought they were just different directories each with their own TLD in
<apw> lag, nope they arn't quite.  well they are in the normal case which you use to build, and are union mount overalys in the case of the sbuild use case
<apw> and by default they use the same names and everything breaks
<apw> i think i have it sorted out though
<lag> Good stuff
<cooloney> apw: ok, let me try again.
<apw> cooloney, not fixed yet
<lag> !Good stuff
<apw> cooloney, i'll let you know when we are there
<ubot2> Factoid 'Good stuff' not found
<apw> lag, i am waitng on a new chroot building
<cooloney> apw: no, failed again. ok, no problem.
 * lag gigges - "stupid bot"
<apw> cooloney, yep i know
<apw> sbuild -d sbuild-maverick-armel PACKAGE*.dsc
<apw> cooloney, could you try again now, note the sbuild- prefix on the chroot name as above
<cooloney> apw: thanks a lot, man. it is running now
<cooloney> apw: i guess you created a new chroot named sbuild-maverick-armel?
<apw> cooloney, yes, as it needs to be a different form from the normal ones, in which changes are persistant
<apw> i've only make one on that machine and only for maverick
<apw> now i know it works i'll get with rtg to get them made across the board
<cooloney> apw: ok, very nice, thx.
<apw> cooloney, if you need a different release made let me know
<cooloney> apw: one more sbuild-lucid-armel is better.
<apw> cooloney, you need lucid yes ?
<cooloney> apw: yeah, i might use it for build ti-omap and fsl-imx51
<apw> cooloney, ok, its building now will let you know when its done
<cooloney> apw: currently, i focus on ti-omap4 for M
<apw> yp
<cooloney> apw: thanks a lot.
<apw> i suspect we'll make them all as they are pretty cheap
<cooloney> yeah, i think so, and are those schroot setup scripts in our kteam-tools?
<amitk> cooloney: lag: how are we doing on the bugs in omap support in lucid?
<amitk> can one of you take up the USB OTG bug
<amitk> ?
<lag> amitk: I am still quite tied up with a suspend-resume bug, but I can take a look for you if you like?
<amitk> lag: please do, assuming you have a beagleboard now
<lag> I do not :(
<amitk> does either mporier or cooloney have one?
<lag> Just my lonely panda - no wonder they're going extinct
<amitk> most zoos would love to get a panda :)
<lag> I couldn't tell you
<cooloney> amitk: i'd love to do that. but i don't have beagleboard and panda
<cooloney> amitk: what's the USB OTG bug?
<cooloney> i saw some fixing in 2.6.34 kernel
<amitk> cooloney: we need to find patches and fix configuration so the USB OTG works in Lucid
<cooloney> amitk: ok, any bug on LP? i do love to do that.
<lag> cooloney: That image works
<cooloney> lag: thanks for the testing.
<lag> But has a heart attack when a monitor is plugged in via HDMI
<cooloney> lag: do you think that is the first time you meet that?
<amitk> cooloney: lag: you should bookmark this page -> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/
<cooloney> no such thing in .33 kernel?
<cooloney> amitk: got it. thx
<lag> amit: I already have it, thanks
<lag> cooloney: bug592295
<lag> cooloney: bug 592295
<ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592295
<lag> cooloney: Are you still around?
<cwillu_at_work> cwillu@lucid-zippy:~$ sudo modprobe usbhid
<cwillu_at_work> [sudo] password for cwillu:
<cwillu_at_work> [  400.146759] usbhid: unknown relocation: 3
<cwillu_at_work> FATAL: Error inserting usbhid (/lib/modules/2.6.35-rc3-dl0/kernel/drivers/hid/usbhid/usbhid.ko): Invalid module format
<cwillu_at_work> that doesn't strike me as the sort of thing that should be possible :p
<rsavoye> does anyone know the url for gcc 4.4 in Maverick for ARM ?
<rsavoye> I dug around on launchpad, but only found lp:ubuntu/gcc-4.4
<cwillu_at_work> rsavoye, http://ports.ubuntu.com/ubuntu-ports/pool/universe/g/gcc-4.4/
<rsavoye> is there a bzr branch for it ?
<cwillu_at_work> apt-get source it, it'll tell you if there is
<cwillu_at_work> but yes, probably
<rsavoye> I wanted to check the level of ARM patches
<cwillu_at_work> okay, that's a week since rcn was last on, anybody want to come with me on a rescue mission? :p
<cwillu_at_work> https://launchpad.net/ubuntu/+source/gcc-4.4
<rsavoye> that looks like it, thanks
<zumbi> rsavoye: afaik, doko uses debian svn for gcc devel, svn.debian.org -- project: gcccvs
<rsavoye> I wanted to check the code sourcery patches for ARM, which aren't in the Debian sources
<rsavoye> there are some new patches in gcc trunk for Android I was going to migrate
<zumbi> rsavoye: http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/#_branches_sid_gcc-4.5_debian_patches_
<rsavoye> right, but this patch I don't believe is in debian at all
<zumbi> rsavoye: where are CS patches at?
<rsavoye> got me, but I heard there was one for ARM stuff
<zumbi> well, there are tons of fixes and patches for ARM
<rsavoye> as the CS sources haves fixes for 4.4 based on 4.6
<rsavoye> not a huge big deal, I was just doing some Android toolchain hacking and thought maybe I'd check
<zumbi> they backport 4.6 development into 4.4 (probably for next release)
<rsavoye> yes
<rsavoye> maybe it's not merged in yet
<zumbi> well, g'luck!
<rsavoye> Guess I'll stick to my build of 4.5 for now.
<wocao> where is the soucelist for  arm
<cwillu_at_work> wocao, how do you mean?
<amitk> sources.list?
<amitk> sauce list?
<amitk> :)
<ogra> yum
<ogra> sauce
<wocao> sourcelist for arm platform
<wocao> ?
<wocao> where i can fine
<wocao> where i can find
<ogra> in /etc/apt/
<cwillu_at_work> wocao, deb ports.ubuntu.com/ubuntu-ports lucid main universe
 * cwillu_at_work found rcn
<mpoirier_> lag: what was that ?
<lag> amitk: Ping
<lag> Ogra: Ping
<ogra__> lag, yep ?
<lag> If I'm fixing bugs for Panda, which tree should I be using?
<lag> Things seem a little scattered
<ogra> no idea, cooloney should have created one on the server
<lag> He has one for Maverick
<ogra> right
<lag> Hang on
<ogra> panda will be maverick
<lag> He has one for Maverick in his own area
<ogra> hmm
<lag> Will panda only be Maverick?
<ogra> then i dont know
<ogra> yes
<lag> I have a working Lucid kernel?
<Martyn> good morning
<ogra> lag, we wont add new kernels to lucid :)
<ogra> its released
<lag> Okay, but the Maverick one doesn't work on Panda yet?
<lag> Or does it?
<ogra> no idea
<ogra> afaik we dont have binaries yet
<Martyn> I've nearly finished the first set of ARM symbol de-dup patches.   I honestly had no idea how much work I had signed up for at UDS.  This is tough, tough work
<ogra> so i havent tested anything yet
<lag> Okay
<ogra> we got the branch on friday afaik
<lag> So I can't fix Panda bugs yet then, is that what you're saying?
<Martyn> I thought it would be easy to separate the functions out .. but it wasn't.
<Martyn> ogra : What's new?
<ogra> lag, do we do have bugs for omap4 yet ?
<ogra> since there is no package in the archive yet i doubt we do
<lag> I have filled one
<lag> But that was with the Lucid kernel!
 * lag head explodes 
<lag> 's*
<ogra> which was just a build of the plain TI omap4 upstream kernel
<ogra> we dont have the actual kernel yet we will use
<lag> Okay, I guess that clears things up
<lag> Phew!
<ogra> the lucid package you use was just a quick build of what was available to get the boards up at all
<lag> Got you
<ogra> the actual kernel package we will use has to be built by cooloney first, would probably be best to ask if you can help him with that
<ogra> since thats the current blocking factor
<lag> Okay, I'll have a word with him tomorrow
<ogra> what was your bug about ?
 * cwillu_at_work continues happily using his working rcn kernels :)
<ogra> clearly a kernel issue ?
<lag> HDMI
<lag> Yeah
<ogra> k
<lag> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/592295
<ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 6)" [Undecided,New]
<cwillu_at_work> now, if only I could get firefox to stop crashing when using webworkers
<Martyn> When did the Panda board support go into the kernel?
<ogra> Martyn, not yet
<Martyn> *nod*  The only thing I've seen so far was the proposed patch by David Anders, and it missed the patch window (just like the Smooth-Stone patch missed it)
<Martyn> Both then end up on hold until 2.6.36
<tumbleweed> I'm trying to replicate http://launchpadlibrarian.net/49300098/buildlog_ubuntu-maverick-armel.hdf5_1.8.4-patch1-2_FAILEDTOBUILD.txt.gz in qemu but it keeps segfaulting at the same point in the build processes
<tumbleweed> are qemu-system-arm segfaults the norm?
<ogra> tumbleweed, depneds what kernel you use
<tumbleweed> ogra: the versatile kernel in the repos doesn't work with my qemu
<tumbleweed> so I'm using the one from http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/
<ogra> thats the same kernel as the archive kernel
<ogra> but thats alright then, you shouldnt see segfaults
<tumbleweed> ogra: it doesn't seem to be. md5sums don't mathc
<tumbleweed> also 2.8M vs 3M
<ogra> well, debian-installer just pulls the binary out of the package
<ogra> when it builds the netinstall kernel
<tumbleweed> with a HEAD qemu and the archive kernel: http://paste.ubuntu.com/449748/
<ogra> oh
<ogra> you should mention that you dont use the ubuntu qemu
<tumbleweed> I was getting it with ubuntu qemu first, tried git after that
<tumbleweed> actually haven't tried ubuntu qemu with the archive kernel. does that
<ogra> vmlinuz-2.6.35-2-versatile ?????
<ogra> thats not a lucid kernel
<tumbleweed> ogra: maverick
<tumbleweed> aah, right
<ogra> right, thats untested yet :)
<ogra> theoretically it should work though
<ogra> there were no changes to the versatile branch to my knowledge
<ogra> apart from newer upstream
<tumbleweed> ok. I see no bugs. I'll file one
<ogra> great, thanks
<ogra> anyway, your build log seems to have a SIGILL
<ogra> could be a toolchain issue
<tumbleweed> yeah, I saw that. Tried to replicate, and got sidetracked by this
<ogra> since it happens during linking
<tumbleweed> I tihnk it cgot past that, though
<ogra> are you using a lucid rootfs in your vm image ?
<tumbleweed> maverick
<ogra> ah
<cwillu_at_work> what's the newest firefox build available for arm?
<cwillu_at_work> i.e., does anyone have 3.7 builds?
<ogra> i dont think so
<ogra> theer was no firefox upload to maverick yet
<ogra> so the latest in the archive must be the lucid version
<cwillu_at_work> :/
<cwillu_at_work> building firefox isn't fun :*(
<ogra> i dont know if there is any PPA with dailies of trunk
<ogra> asac would know such stuff
<asac> cwillu_at_work: ogra: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
<asac> not for armel ;)
<ogra> right, thats what i suspected
<asac> but firefox 3.7 is there ... which afaik is now branched ... so trunk might be missing temporarily
<cwillu_at_work> asac, I suppose I could apt-get source it myself :/
<asac> cwillu_at_work: yep
<asac> cwillu_at_work: is there any important reason why we should try a ffox 3.7 build?
<ogra> tahts great, you can tell us about build failures in advance then :)
<asac> if there is a good reason (like important bug fix landing for arm that needs landing), i spin that in a ppa
<cwillu_at_work> asac, I can crash a 3.6 build at will by running my app on it?
<cwillu_at_work> no idea if it's fixed yet, but it's annoying enough to duplicate that I really want it to get fixed by accident :p
<asac> cwillu_at_work: do you see that problem o intel too?
<cwillu_at_work> yep
<asac> then test it with that ppa
<ogra> and it worked on former releases i assume
<cwillu_at_work> asac, have been, so far so good
<asac> intel builds are avail there ;)
<cwillu_at_work> ogra, no, webworkers didn't exist previously
<ogra> ah
<cwillu_at_work> but they're a pretty big win performance wise in my case
<tumbleweed> ogra: gaaah. wrong terminal. ubuntu qemu boots the maverick kernel fine, sorry
<ogra> phew
 * ogra wipes the sweat off his forehead 
<ogra> tumbleweed, what i would try is to build the package in the same vm inside a lucid chroot, if thta succeeds its most likely a toolchain issue
<tumbleweed> brb supper
<ojn> Martyn: I didn't see patches for either go by on arm-kernel. Where were they posted? (panda and smooth-stone support)?
<tumbleweed> ogra: when I say "boots fine" I mean it says "booting the kernel" and then hangs at 100% CPU
 * gsnedders found the reason why the BeagleBoard he has wasn't working properly: the NAND is b0rked.
<cwillu_at_work> ogra, well, I seem to be stable given some code modifications on 3.6.6 from the nightlies
<cwillu_at_work> on x86
#ubuntu-arm 2010-06-15
<playya_> how much space is required to bootstrap ubuntu-minimal on ARM?
 * mozzwald is away: snore...
<EthanZ6174> how can i get a arm-ubuntu source list?
<EthanZ6174> i got so many 404 when i use the kind of normal ones..
<hrw> morning
<cooloney> amitk: around?
<amitk> cooloney: yes
<cooloney> amitk: i am looking at the OTG config issue you pointed out yesterday
<cooloney> from the git log, i think you revert the patch which enabling the OTG in the kernel
<cooloney> so why you revert that?
<cooloney> OTG driver doesn't work at all?
<amitk> cooloney: that config was causing OOPs, IIRC. So we need to see if some more patches are necessary
<cooloney> amitk: yeah, i guess so. so firstly we enable the OTG as the omap3 beagle board defconfig
<cooloney> and test and file another bug?
<cooloney> i think OTG should be built-in
<cooloney> oh, maybe the dmesg.txt from ogra_cmpc in the LP is from a kernel which built-in OTG stuff
<amitk> cooloney: if possible OTG should be a module so we can switch between different gadget drivers - audio, ethernet, gadgetfs, mass storage, etc.
<amitk> cooloney: actually, only the USB Gadget drivers need to be modular, the HW-specific driver can be compiled in
<amitk> cooloney: http://paste.ubuntu.com/449992/ is the diff for that should enable OTG
<amitk> s/for//
<cooloney> amitk: i agree, gadget upper level drivers should be modulars, and TI OTG controller driver should be built-in
<cooloney> amitk: after a study of the oops from the dmesg, i think we missed to built-in the OTG transceiver driver as well as OMAP OTG driver
<cooloney> amitk: let me try to build in them and post a kernel for testing
<lag> Good morning every-peeps
<amitk> morning lag
<lag> Hey amitk
<cooloney> lag and amitk morning. -:)
<lag> Morning cooloney, I'm just replying to your emails
<lag> cooloney: How far have you progressed with the Maverick - Panda kernel?
<cooloney> lag: I added some panda supported yesterday, and sebjan will review that. if that's ok, i will send out for review and pull
<cooloney> lag: for the bug #592295
<ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/592295
<cooloney> lag: is on .33 or .34?
<cooloney> and i think you may have some solution now
<lag> cooloney: 2.6.34-900-omap4
<lag> If you send me a .33 kernel, I can see if the problem is a lasting one
<lag> cooloney: I have seen your solution, but I think I have a neater one
<cooloney> lag: ok, got it, but in the LP post, you said it is 2.6.33-900-omap4
<cooloney> lag: ok, cool, i don't have the hardware. hehe
<lag> In which case, I have tested it on both
<lag> So it is .33 and .34
<lag> cooloney: Have you read your emails?
<cooloney> lag: oh, just got it.
<lag> ;)
<cooloney> for the .34 repo, git://kernel.ubuntu.com/roc/ubuntu-maverick.git ti-ubuntu-2.6.34
<cooloney> i think sebjan will do his work based on this branch
<lag> Does that boot?
<cooloney> hmmm, i think you told me it boots from you panda
<cooloney> hehe
<lag> If it's the same one you sent me yesterday it does
<cooloney> and after sebjan fixed his kernel cmdline, he boots that kernel on his panda too
<lag> However, I tried to build it and it didn't boot
<cooloney> lag: yeah, it is the same
<cooloney> lag: really?
<lag> Yeah, really
<cooloney> you built from the same tree, but does not boot?
<cooloney> oh, maybe you are trying the my old base
<cooloney> so which commit SHA is your base in you building tree
<lag> It's the one on kernel.ubuntu.com
<lag> Wait one
<cooloney> np
<lag> ea34fca089b7ab2986ff391f1fc036d4425e6995
<cooloney> oh, sorry, that is not including the panda support
<cooloney> pls just git fetch
<cooloney> and rebuild,
<lag> That was the latest when you went offline last night
<lag> :(
<lag> I thought it was something I was doing wrong!
<cooloney> lag: oh, sorry, hold on,
<cooloney> could you post your git log --oneline?
<lag> I've just fetched
<cooloney> ok,
<cooloney> that should be the same as my kernel source, i think
<cooloney> you are using sbuild or just crosscompile
<lag> cooloney: It's still at ea34fca089b7ab2986ff391f1fc036d4425e6995 UBUNTU: SAUCE: fix changelog for our target release - maverick
<lag> Even after a fetch
<cooloney> lag: yeah, i think you got the same kernel source as me
<lag> And that should work?
<cooloney> yeah, i built the kernel package from that.
<cooloney> and uploaded to you and sebjan
<cooloney> so is there any error message when you was booting your own built kernel?
<lag> Nope, I just don't receive any output
<cooloney> lag: hmmm, too bad, no idea about that. you changed the kernel cmdline or something?
<lag> Nope, I'm using the same one
<lag> When I do a diff on or images, they 'differ'
<lag> Is ea34fca089b7ab2986ff391f1fc036d4425e6995 your final commit?
<cooloney> yeah, i didn't change anything since that
<cooloney> lag: you are using sbuild or just cross compiling?
<lag> I'm just using schroot
<lag> I'm using the build scripts
<cooloney> lag: the kernel i uploaded yesterday is cross compiled
<lag> Okay
<lag> Let me try it again
<cooloney> ogra_cmpc and amitk, i updated bug #566645
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 70)" [High,Confirmed] https://launchpad.net/bugs/566645
<hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
<zumbi> hrw: congrats! can you try powerpc or mips/el?
<hrw> zumbi: thats dpkg-cross way
<zumbi> hrw: yes, but binary-*-cross.mk merged into binary-*.mk?
<hrw> zumbi: no, this is still on a list
<zumbi> oh! ok, also biarch cross compilers were broken for multilib and non-multilib builds, on lenny used to work fine
<zumbi> anyway, well done :)
<hrw> zumbi: gcc-4.5 cross work resulted in a set of fixes
<zumbi> in a couple weeks I hope to have some time available to help out
<hrw> zumbi: https://edge.launchpad.net/ubuntu/+spec/arm-m-cross-compilers has them linked
<zumbi> i remember you showing me a patch
<JameswStubbs> Hello, anyone here who can give some advice?
<lool> zumbi: We dont have mips/mipsel in Ubuntu and powerpc in not in the main priorities of Linaro, it's more a Debian thing, but that should just work -- problem is that the patches aren't in the Debian toolchain yet
<lool> JameswStubbs: don't ask to ask   ;-)
<hrw> lool: those patches are also not in ubuntu toolchain yet
<lool> hrw: Ok, did you apply any to build http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ?
<JameswStubbs> Ok then, basically I've built a Ubuntu minimal rootfs using rootstock and have it mounted in qemu with networking, I'm trying to install matchbox. I've installed xorg, and all the matchbox applications but I need GTK, Is there a way to do this without installing the full gnome enviroment?
<hrw> lool: 594534, 590696 were needed
<hrw> I have a build with also 593281 applied to get libgcc1-dbg
<hrw> libgcc1-dbg-armel-cross_4.5.0-5ubuntu1.lool1_all.deb
<JameswStubbs> Bump (Sorry for bumping)
<cwillu_at_work> JameswStubbs, um, then don't bump?
<cwillu_at_work> this isn't ubuntuforums
<lool> lool1 that's me!
<lool> hrw: ~hrw1 please  :-)
<lool> JameswStubbs: in theory you should just be able to apt-get install that
<lool> JameswStubbs: does it pull more than it should?
<lool> JameswStubbs: what specifically is pulled which shouldnt be?
<JameswStubbs> apt-get install what?
<lool> JameswStubbs: matchbox
<JameswStubbs> matchbox pulls everything it needs
<JameswStubbs> But it depends on GTK which is gnome's toolkit I think
<lool> JameswStubbs: You need Gtk+ for what, a custom application?
<JameswStubbs> Matchbox-session needs gtk
<zumbi> lool: then maybe sparc? -- I just wonder if biarch cross compilers are fixed. I saw you having some mails with doko about it, but he was wanting to fix it in the right way, while you wanted a quick hack for linaro
<cwillu_at_work> not seeing the problem
<lool> JameswStubbs: Gtk+ is the toolkit used in GNOME, but it's not the full GNOME environment
<cwillu_at_work> gtk isn't all of gnome
<lool> zumbi: This is incorrect
<JameswStubbs> So what do I need to enter into apt-get to get gtk?
<JameswStubbs> apt-get install gtk??
<lool> zumbi: Linaro is investing time in fixing it the right way, hrw is working on that, but it will take a while so I've asked him to produce intermediate builds the "old" way (regular Emdebian way) in the mean time
<lool> zumbi: there is no additional hack than the existing Emdebian binary-cross stuff
<lool> JameswStubbs: the matchbox-session package should depend on the libgtk package
<lool> JameswStubbs: So this should just all work
<lool> JameswStubbs: I fail to understand your actual problem   :-(
<hrw> lool: patch was yours
<hrw> lool: and I do not provide them outside of my hdd
<lool> hrw: You mean the build fixes?
<zumbi> lool: sure, but Emdebian way only works for armel (also sh4) but the rest of arches were broken
<JameswStubbs> I'd copy and paste it all but it's within 2 vm's :) , When I enter matchbox-session from the prompt, it says something like gtk: couldnt open
<lool> hrw: These are not additional hacks though, they just fix bugs in the current approach, do you agree?
<zumbi> lool: i agree
<hrw> lool: they are fixes, yes
<lool> zumbi: We didn't look into that, we don't have people blocking on cross-compilers for the arches you mention
<lool> zumbi: I would hope that everything will work once hrw is done, but we don't need to produce daily cross-compilers for sparc or powerpc in Linaro right now
<lool> zumbi: We do need to hand out some armel cross-compilers while hrw continue on the quest to clean cross-compilers builds
<lool> JameswStubbs: Ok, you need to be more specific though
<JameswStubbs> Ok I'll try
<zumbi> lool: while I understand you focus on armel (which is primary) I'll try to work on the rest of arches (at least test builds)
<lool> JameswStubbs: (IIUC, you installed only Ubuntu packages in your rootfs, but you see some error messages with gtk, can only comment if we know what the error is)
<lool> zumbi: As I said, I expect the *final* solution to work on other arches
<zumbi> `buildcross` could easily be used to test all cross compiler arches
<lool> zumbi: But I asked hrw to provide hand-built packages *right now* because we need them, we don't need them for other arches than armel
<zumbi> lool: i got it. thanks :)
<lool> Ok  :-)
<JameswStubbs> I've made a rootfs using rootstock. I've then opened it in qemu. I then installed xorg. I then installed matchbox. Now when I enter matchbox-session is returns: (matchbox-desktop:434) : Gtk-Warning **: cannot open display:
<lool> JameswStubbs: Do you run matchbox-session from within Xorg?
<JameswStubbs> Should I enter startx
<JameswStubbs> Then when I get the x shell then enter matchbox-session?
<lool> JameswStubbs: matchbox-session should be started from within a Xorg context, otherwise it doens't know which Xorg DISPLAY to connect to or which credential (XAUTHORITY) to use
<lool> JameswStubbs: I'm not sure what the proper way is to start matchbox-session on boot or to start Xorg + matchbox-session, perhaps startx will do the trick, perhaps you need to setup more things
<lool> JameswStubbs: One way to quickly test matchbox-session is to start Xorg with a xterm and then run matchbox-session from there, but that's certainly not what you would want in the end I guess
<JameswStubbs> I think I need to add match-box session to xinitrc
<lool> Yes, it is indeed possible you have to do that
<JameswStubbs> Hm, All I'm getting after adding matchbox-session to xinitrc is a blackscreen and a mouse, which I can't move.
<JameswStubbs> Any ideas lool?
<lool> JameswStubbs: Check the xinit man page, and/or read through /etc/X11/Xsession.d/* scripts and /etc/X11/Xsession
<lool> JameswStubbs: I don't have a recipe for you, as I didn't do this myself, but it should be easy to look into what the shell scripts are doing
<lool> JameswStubbs: I think one important thing is to have .xinitrc +x or something like that
<lool> and you need a shebang too if you do this obvisouly
<JameswStubbs> shebang? !#?
<lool> #!/bin/sh
<lool> JameswStubbs: I checked and if you look at startx, it will pass xinitrd to xinit which expects to be passed a client program
<lool> So if you pass it a text file, it wont work
<asac> ogra_cmpc: where is rcn? isnt he usually hanging out here?
<lool> asac: 16:10 < cwillu_at_work> okay, that's a week since rcn was last on, anybody want  to come with me on a rescue mission? :p
<lool> asac: 17:09  * cwillu_at_work found rcn
<cwillu_at_work> asac, he should be back today
<cwillu_at_work> took an unannounced vacation
<asac> ah ... one of the weak ones ;)
<armin76> he's running from you :D
<armin76> *away
<cwillu_at_work> I was wondering about that actually :p
<cwillu_at_work> omg
<cwillu_at_work> that's embarrasing
<cwillu_at_work> I've got a webapp I run in an undecorated fullscreen firefox window
<cwillu_at_work> been having horrible performance
<cwillu_at_work> firefox using 60-80% cpu, with the backend server using the other 20%
<cwillu_at_work> (backend has to poll a bunch of serial devices and push data to firefox)
<cwillu_at_work> figured it was just the overhead of updating things / the push system
<cwillu_at_work> finally got around to getting venkman on it
<cwillu_at_work> a completely unrelated piece of code was in a hard mutually recursive loop:  initializing a drop-down menu was triggering a request to get data, and the request handler was triggering an init of the drop-down
<cwillu_at_work> the embarrassing part is that I've been working under the false assumption for long enough to have actually shipped this to customers :p
<hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ contains now amd64 and i386 cross toolchains for armel target
<rsavoye> hrw: is there a branch for the source used to build your cross toolchain ?
<hrw> rsavoye: I used ubuntu sources
<hrw> will add README
<rsavoye> so no Code Sourcery patch yet ?
<hrw> not yet
<rsavoye> you hacked libstdc++ and libiberty to cross configure ?
<rsavoye> hrw: there is a nice patch in GCC trunk for Android you might want to add when you get to patching 4.4
<rsavoye> all it does is cleanup linking mostly
<hrw> rsavoye: url?
<rsavoye> the thread is at http://www.pubbs.net/201005/gcc/37284-patch-06-add-support-for-android.html
<rsavoye> it's based on my older Android patch, and adds bionic support in a nice generic way
<lool> hey rsavoye
<rsavoye> howdy
<lool> rsavoye: Might make sense for you folks to discuss this on #linaro, but here is fine too
<rsavoye> ah, didn't think of that, thanks
<rsavoye> I was just hacking on ARM toolchains this weekend for Gnash, so pipped up when I saw the link to debs
<fabrice_sp> Hi. Just as a follow up of last time I connected (About atlas build on arm): I'll upload atlas as someone has been able to build it in qemu
<fabrice_sp> in case it loops, who should I poke to kill it?
<tumbleweed> ogra: I'm still getting a fair number of qemu segfaults with lucid
#ubuntu-arm 2010-06-16
<cwillu_at_work> tumbleweed, qemu had fixed any of those?
<tumbleweed> cwillu_at_work: no, same problem with the current git head
<tumbleweed> I was trying to test a few FTBFS bugs, but it seems that qemu just isn't a workable solution for this
<cwillu_at_work> qemu-static-arm should work fine though
<cwillu_at_work> with the added bonus that you can use all of the cores of your desktop
<tumbleweed> hmm, I haven't tried that
<cwillu_at_work> I've hacked up my rootstock to work via chroot, works great
<cwillu_at_work> <3 asac or lool or whoever told me to try it
<tumbleweed> heh
<tumbleweed> any recommended way to do that? pbuilder integration would be awesome :P
<cwillu_at_work> just change runvm to chroot, calling installer directly
<cwillu_at_work> oh, and fix up the script to not do things like reboot, obviously
<cwillu_at_work> haven't done anything with pbuilder
<tumbleweed> ok, i'll have a shot in the morning (2 30 am)
<hrw> morning
<hrw> "ld: cannot find -lgcc_eh" - someone remembers that?
<lool> NCommander: around?
<lool> NCommander: May I ask you for recommendations for debconf?  I wonder whether it is of any importance which NY airport I land at
<lool> hrw: It might be the renames which are being done in the gcc packaging
<lool> hrw: upstream uses e.g. /usr/lib/foobar/4.4.4 and we use /4.4
<hrw> anyway found issue - rebuilding again
<sebjan> ogra: Hi! I think you have been doing some packaging for u-boot for omap4? Do you have some pointers to code or guidelines or advices to share?
<ogra> sebjan, u-boot-omap4 is the package, take a look
<sebjan> ogra: ok, thanks
<zumbi> hrw: did you need something? why do you CTCP ping me?
<zumbi>  hrw [~hrw@chello089078170228.chello.pl] requested CTCP TIME from zumbi
<zumbi> 11:39 [freenode] hrw [~hrw@chello089078170228.chello.pl] requested CTCP VERSION from zumbi
<hrw> zumbi: I requested time just to check timezone
<zumbi> hrw: sure, i am at .es (EU timezone, UTC+1)
<hrw> ~curse iconv tests in eglibc
<zumbi> in couple weeks i'll be at UTC
<zumbi> hrw: FYI, if you build eglibc with debian patches applied, it will fail on gcc-stage2 builds
<ukleinek> zumbi: how come your here and not in front of your TV?
<ukleinek> :-)
<zumbi> crtX defines __libc_alloca which it should not
 * ogra_cmpc was about to ask the same :)
<zumbi> ukleinek: what are you doing here? these ubuntu people has tricked you too :-)
<ogra_cmpc> GrueMaster, http://people.canonical.com/~ogra/jasper/ has a new test image
<zumbi> well, I am working (in front PC) and we can have small screen with the game :)
<hrw> zumbi: I passed gcc/stage2
<zumbi> hrw: great :)
<hrw> why core i7 are so expensive :(
<amitk> hrw: because they are fast?
<hrw> amitk: ;)
<hrw> amitk: too bad that move from my q6600 -> i7 would be nearly 1kâ¬
<hrw> hi prpplague
<prpplague> hrw: hey bud
<GrueMaster> ogra_cmpc: downloading now.  Should be ready by the time my coffee is ready.
<ogra_cmpc> GrueMaster, resizing works fine on two cards i tested, dont expect it to work after reboot yet (flash-kernel changes are still missing)
<GrueMaster> ogra_cmpc: Is there any documentation online for creating these images?  If so, I can manually build them here, as I have a local mirror of the repo.  It would also enable me to do some more specialized testing.
<ogra_cmpc> GrueMaster, you should be able to create the rootfs with livecd-rootfs
<GrueMaster> ok
<ogra_cmpc> i cana give you a script for the rest once you have it
<GrueMaster> I assume I will need a newer livecd-rootfs than Lucid?
<ogra_cmpc> latest from maverick
<GrueMaster> ogra_cmpc: ready for your script.
<ogra_cmpc> you need the u-boot-omap3 and x-loader-omap packages
<GrueMaster> ok
<ogra_cmpc> unpack them s0omewhere with dpkg -x
<ogra_cmpc> http://paste.ubuntu.com/450637/
<ogra_cmpc> adjust the paths in the script, it takes the path to the .ext3 file as arg
<ogra_cmpc> you need to run mkimage for the vmlinuz and initrd.img files livecd-rootfs spits out and point the script to the resulting uImage/initrd files
<GrueMaster> ok
<GrueMaster> ogra_cmpc: FYI: Today's image boots the .34 kernel, but only the 2.6.35-2 kernel & modules are on the root partition.
<ogra_cmpc> gar
<ogra_cmpc> i didnt re-roll the ext3
<ogra_cmpc> GrueMaster, did the resizing work this time for you ?
<GrueMaster> on this particular card, yes.  Will check it on other cards.  16G card, took ~15-20 minutes (I wasn't particularly watching).
<ogra_cmpc> i hope the time gets down a bit if we have a bigger image
<ogra_cmpc> so the gap gets smaller
<ogra_cmpc> it takes 6min on my 4G testcard
<GrueMaster> I'll try to do some timing tests this week, using my desktop USB SD card reader as a baseline.  I personally think it may be more I?O bound than platform bound.
<ogra_cmpc> well, essentially the FS should just get expanded and be filled with zeros
<GrueMaster> right.
<ogra_cmpc> probably the filling takes so much time
<ogra_cmpc> did you get any probs with the missing modules ?
<ogra_cmpc> oem-config worked for me (i did only check for that)
<GrueMaster> Only networking (so far).
<ogra_cmpc> ah, i didnt even test networking
<GrueMaster> OEM config seems to want to install additional packages.  I am assuming that is by design?
<GrueMaster> I.e. ubuntu-desktop, ubuntu-netbook, etc.
<ogra_cmpc> only if you make a selection in the task selector :)
<ogra_cmpc> just dont make one
<ogra_cmpc> for netbook the tasksel part will not be there
<GrueMaster> well, duh.  I just wanted to verify that the task selector should be coming up.
<GrueMaster> Ok.
<GrueMaster> did you see my note yesterday regarding jasper naming?
<ogra_cmpc> the console switching is also a bit weird, but that might be caused by plmouth crashing
<GrueMaster> also, jasper log is now reporting this error:
<GrueMaster> ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/mmcblk0p2 is
<GrueMaster> mounted.
<ogra_cmpc> hrm, that was supposed to be fixed
<ogra_cmpc> can you paste the jasper log somewhere ?
<GrueMaster> hard to do w/o network, but I can try.
<ogra_cmpc> jasper is supposed to have created an mtab file before running resize2fs
<ogra_cmpc> well, is there any hint that mtab coundnt be created in the log ?
<GrueMaster> It does.  Then deletes it before running tune2fs.  Maybe move the rm to the bottom?
<ogra_cmpc> hmm, the message comes from tune2fs ?
<ogra_cmpc> yeah, indeed, i'll move it to the bottom
<GrueMaster> is there an easy way to transfer text through the serial port?  I want to copy/paste the jasper.log for you, but would rather not retype it.
<ogra_cmpc> nah, all fine
<ogra_cmpc> forget about the log
<GrueMaster> ok
<ogra_cmpc> or cp it to the SD if you feel like
<ogra_cmpc> and then pull it off there before next test
<GrueMaster> Yea, I suppose I could sneaker-net it.
<GrueMaster> ah, that works.  Launch sudo getty /dev/ttyS2
<GrueMaster> It has been a long time (~8 years) since I messed with serial consoles.
<ogra_cmpc> heh
<cwillu_at_work> odd;  NetworkManager is trying to configure the ethernet (dhclient and so forth) on a zippy2, even though nothing is plugged in (and mii-tool agrees that there's nothing plugged in)
<ogra_cmpc> broken sysfs entry of the NIC ?
<cwillu_at_work> where should I look?
<ogra_cmpc> NM code and sysfs
<ogra_cmpc> i dont know from the top of my head what it looks for
<cwillu_at_work> don't see any difference in /sys/.../eth0/* when I unplug it
<cwillu_at_work> ah well
<cwillu_at_work> try again under 2.6.35 once that's working I guess :p
<GrueMaster> cwillu_at_work: /sys/.../eth0/link_mode maybe?
<cwillu_at_work> nope
<cwillu_at_work> I compared every file in there
<GrueMaster> Or it could come through as a uevent.
<cwillu_at_work> nope, nothing in udevadm monitor
<GrueMaster> Well, the driver may not be sending udev reports properly.  But I believe network manager is using udev.
<Martyn> Is there a reccomended install image for the Lange?
<GrueMaster> Martyn: I think it was Jaunty, but I'm not sure.
#ubuntu-arm 2010-06-17
<hrw> morning
<lag> Morning hrq
<lag> hrq*
<lag> Grrrrrrrrr
<lag> hrw*
<lag> :)
<lag> Stupid fancy keyboard!
<hrw> ;D
<cooloney> lag: can you boot the .34 panda kernel which was built by yourself?
<lag> Yes
<lag> :)
<lag> I have been playing with it
<cooloney> lag: excellent, man, good to hear that
<cooloney> lag: thx
<lag> cooloney: No problem
<lag> Do you have HW yet?
<cooloney> too bad, no
<cooloney> i don't have omap3 and omap4
<lag> Are you going to get HW soon?
<hrw> igep v2 should be good omap3 testboard. compared to beagleboard (c4/xm) it is available
<cooloney> hrw: igep v2 is from TI or other vendor?
<cooloney> lag: no, i think there is no OMAP4 HW for me
<cooloney> lag: and for omap3, no idea about that
<lag> That sucks
<hrw> other
<cooloney> lag: maybe i need to order some omap3 boards and ship to folks in US, and get the board during next sprint
<hrw> cooloney: spanish company
<cooloney> hrw: ok, let me search
<cooloney> hrw: thx
<lag> I think I'd find it difficult working on an architecture without HW
<lag> cooloney: Do you know if a console is configured on HDMI on the Panda board?
<cooloney> lag: oh, not sure about that, let me check
<hrw> cooloney: http://shop.igep.es/index.php?main_page=product_info&cPath=1&products_id=38&zenid=j4novjt0a4t4k1j0o2igoldhm6
<amitk> cooloney: we are trying to get some IGEPv2 boards for evalueation
<hrw> cooloney: 130â¬ for no wifi/bt, 145â¬ for wifi/bt
<amitk> they should work with our kernel, i've enabled it in the configs
<cooloney> hrw: nice, ehe
<cooloney> amitk: good to know that. hope i can get one of them to play with
<amitk> yeah, hope so too
<cooloney> lag: i am not sure about the HDMI console. so i believe you are using HDMI display with panda,
<lag> I want to
<cooloney> lag: can you see anything on it?
<cooloney> oh, you don't have
<lag> No, nothing
<lag> I do have
<cooloney> oh, how about change some kernel cmdline to add 'console=tty0' or similar
<lag> When I boot, I get 1,000's of these: omapdss DISPC error: SYNC_LOST_DIGIT
<lag> That was my follow-up question - Which console ...
<ukleinek> ericm|ubuntu: I start merging your and mine patches now, OK?  (You're not in #armlinux, so this is slightly off-topic)
<lag> I've been meaning to install a full desktop environment on my new SD card
<hrw> I wonder how many working pandas are outside of TI
<ericm|ubuntu> ukleinek, i'm ok
<cooloney> hrw: skip me, i don't have any
<cooloney> hrw: ehe
<lag> hrw: o/
<cooloney> lag: hmmm, actually, i have no idea about that.
<cooloney> sebjan: do you not this console tty0 should be the right one for HDMI console?
<cooloney> sebjan: i think lag is trying to output our UNR on it
<ndec> hrw: hi. not man panda outside of TI.. not many inside of TI anyways...
<ndec> lag: which kernel are you using?
<amitk> ndec: panda (the board) as endangered as panda (the animal) ?
<lag> 2.6.34-900-omap4
<lag> Maverick
<ndec> amitk: yep... we are trying to save the animal from disparation ;-)
<hrw> ndec: yep
<ndec> lag: do you have a HDMI screen or is it a DVI screen using the HDMI output of the board?
<lag> It's the real deal
<lag> HDMI->HDMI
<ndec> lag: ok. well this should work without any config change, assuming you have the right config in the kernel... but i have not tried on HDMI screen yet.
<lag> Hmmm
<lag> ndec: On which console?
<lag> tty*
<ndec> lag: don't know. i had tried HDMI->DVI screen several weeks ago with the UNE UI
<lag> I've just tested the monitor on my Revo running Karmic and it worked fine
<lag> The DVI port on the Panda has an HDMI socket, so I can't test that
<ndec> lag: I am using the HDMI port (closest to USB). with the HDMI to DVI cable. I think we have problems with the DVI port. that one shouldn't work either...
<lag> ndec: No, that doesn't work as far as I can tell
<lag> But neither does the HDMI
<lag> ndec: Have you seen this message: omapdss DISPC error: SYNC_LOST_DIGIT
<ndec> lag: yes... something wrong in DSS2/OMAP4
<armin76> i want one
<lag> Do you think it will be related to why I don't have HDMI?
<ukleinek> ericm|ubuntu: do you want to look into my patches 4 to 9 and comment/ack?
<ericm|ubuntu> ukleinek, OK
<ukleinek> ericm|ubuntu: well, my 7 = your 2
<ndec> lag: yes.
<armin76> ndec: can i get a panda? :D
<ndec> armin76: why do you always ask me the same questions ;-)
<armin76> last time it wasn't a question :P
<ndec> armin76: good point...
<ndec> armin76: let us know polish it first...
<armin76> i want to polish it too :)
<lool> hrw wants to polish it too!
<lool> and zyga!
<lool> (zyga and hrw are in Poland)
<hrw> Polish man meets English man and says: "I need to polish my English". English man replies: "No, your English is Polish enough".
<hrw> joke sounds better then looks
<ndec> hrw: nice...
<hrw> http://alt-tab.org/data/images/2010/06/angelamerkel.png
<zyga> lol :-)
<berco> anyone knows if it is possible to tell debuild to generate both a -dbg package a striped binary version? I know that I need to set DEB_BUILD_OPTIONS=noopt,nostrip for debug but this will provide me only the debug binary. I'd like to generate both in one command if possible
<lool> berco: Is this a package with -dbg packages in control?
<lool> berco: What you can do, and what Ubuntu does on all packages, is using pkg-create-dbgsym to achieve that
<lool> berco: You would build the package as usual, but the build will output -dbgsym packages along the other ones
<berco> lool: I have not changed the control file for this
<lool> berco: Just install the package and it should work (you might have to turn it on in /etc)
<berco> lool: I was looking more for the general rule to achieve this :)
<berco> lool: thanks. I will give it a try
 * armin76 steals lool's panda
<hrw> armin76: since when he has one? ;D
<armin76> he stole it too :D
<ogra> dyfet, how far are you with the gobject-introspection FTBFS ?
<ukleinek> npitre: ping
<ukleinek> npitre: do you care to answer to http://mid.gmane.org/20100611045507.GA10894@pengutronix.de
<ukleinek> ?
<berco> lool: ping
<lool> berco: pong
<lool> berco: Ideally, don't ping but just ask something so that I dont context switch twice  ;-)
<berco> lool: thx for the dbg, seems to work.
<lool> Cool
<berco> lool: I now face another issue
<berco> lool: I noticed in my source package some files lost the execution privilege
<berco> lool: any idea how to prevent this?
<lool> berco: Sorry, what source is this?
<berco> lool: package that contains source code (apt-get source <package name>
<lool> berco: Yes, which one?
<berco> lool: well not public yet, it's for omap4, this is the "tiler" package
<lool> berco: Ok; would be easier to suggest a fix for a public source package
<lool> berco: So which file is losing the +x bit exactly and at which point?
<berco> lool: code has never been package. it's available but not in deb format yet. Am working on it...
<lool> berco: There are two places where that can happen: in your source files, because of the source packaging format, or in the resulting .debs
<berco> lool: this is bootstrap.sh file
<lool> berco: are you saying that the +x is lost when you unpack the source package, or in the resulting .debs?
<berco> lool: I need to check. I just did an "apt-get source" and noticed it's lost
<lool> berco: Right, so while unpacking the source
<lool> berco: So this is expected in the default source package format
<lool> berco: you could of course change the source format, but there's something odd here
<lool> berco: Usually, bootstrap.sh is part of the "upstream" tarball, the .orig.tar.gz
<lool> berco: Files in this tarball wouldn't lose this bit
<lool> berco: What might have happened here is that you intended to ship this file in the tarball, but it got shipped as part of the packaging instead
<berco> lool: ok, so I need to check b'cos this file should be in my .orig.tar.gz
<lool> berco: You really want this file to be in the upstream tarball I guess
<lool> berco: Please do
<berco> lool: thanks, that would make sense. I will check
<lool> berco: Also, might be best to just ask the chan rather than me specifically -- will get you faster answers, spread the load, and also I dont actually work on omap4 stuff (yet?) but others here do
<berco> lool: ok. Sorry I'm new to the Linux world so learning all the habits and stuff
<lool> berco: This is fine; I hope you don't mind me telling you
<berco> lool: not at all, just noticed you knew quite well the pcakaging topci
<berco> :q
<berco> when packaging from the .orig.tar.gz, I created a patch to move files but those that have +x attribute will lose it in the .deb source package. Anyone knows how that can be fixed. I want to keep the +x on these file.
<berco> btw, I'm using cdbs-edit-patch for creating the patch
<lool> berco: Why do you move the files?  and why in a patch?
<berco> lool: git tree has the source code in a subfolder
<berco> lool: am not really allowed to change this and I created the orig.tar.gz with the simple "git archive" command
<lool> berco: You could either tell your package to build in a subfolder rather than build from the top, or you could release tarballs from the proper level?
<berco> lool: might be simpler in my case to build from the subfolder until the upstream maintainer modifies the git tree
<lool> berco: Without moving files in the git repo, could you strip a component when creating the tarball?
<lool> berco: Ok; if you're not upstream, then just go for the sub-folder build
<lool> berco: Set DEB_SRCDIR near the top of your rules if you're using cdbs
<berco> lool: yes, am using cdb
<lool> The default is ".", you could set it to subfolder or to $(CURDIR)/subfolder if you need an absolute pathname
<berco> lool: cdbs. I will try this, that sounds the most reasonable at this point
<in-game> anybody formilliar with the sharp netwalker?
<lag> in-game: What's up?
<GrueMaster> in-game: persia might be the one to ask, but he's on holiday.
<GrueMaster> I believe he has one, though.
<in-game> ahh ok
<in-game> sweet device but the ubuntu running is 9.04
<GrueMaster> yep.
<in-game> so i am searching for a  way to upgrade somehw
<in-game> now running lxdm to make it some faster
<amitk> in-game: unlikely you'll be able to upgrade
<GrueMaster> I don't think it supports 10.04.  Iirc, it was a hardware issue.
<amitk> the kernel hasn't been mainlined
<in-game> thought so
<in-game> pitty, the arm packages are some what lagging behind
<amitk> in-game: it is mostly kernel and any binary drivers if reqd.
<GrueMaster> There were some hardware changes between 9.04 & 10.04.  The newer kernels in 10.04 were never made to support the older hardware rev.
<npitre> ukleinek: sorry
<GrueMaster> If you are kernel savvy, you could probably forward port the changes though.
<amitk> in-game: the rest of the arm packages have been carried forward just fine
<in-game> ok, yeah i wanted to update lxdm because of the network xplore function
<GrueMaster> Unfortunately 9.04 packages are built for ARMv5 and 10.04 were built for ARMv7.  It would be like running x86_64 code on an Intel Pentium (P5).
<amitk> in-game: you could enable the lucid repo in /etc/apt/sources.list and only upgrade certain packages
<amitk> GrueMaster: the processor is a ARMv7
<GrueMaster> amitk: The processor may be, but the kernel doesn't have support for it.
<in-game> amitk tried that, but it deleted my x packages somehow
<in-game> tried it twice now
<amitk> GrueMaster: in-game does NOT want to upgrade the kernel, just the desktop. He can do that if the dependencies were carried over correctly
<amitk> in-game: it is quite possible that the new version of the desktop brings in a new version of X which ofcourse doesn't have new version of some display driver or similar. That could kill your X
<in-game> yups.
<in-game> so hm first uprade the x
<in-game> can add 10.04 to the repro and upgrade just without the kernel?
<amitk> in-game: are you trying a 9.04->10.04 upgrade direct?
<in-game> hmm
<in-game> yeps
<amitk> that is probably untested. Have you tried a 9.04->9.10 ?
<in-game> maye first 9.10
<in-game> not yet
<in-game> heh that is pretty good one :)
<NCommander> amitk: in-game: this is probably a bad idea. Netwalker kernel is very dated, and doesn't have proper thumb2 handling support which is required for lucid (you might get karmic to work)
<amitk> NCommander: that is what I just suggested ^^ :)
<in-game> yep :)
 * NCommander brain farts, and goes to hide in a corner
<in-game> no need for hiding, I tried it twice.... ><
<amitk> hehe
<in-game> Well lets try a update!
<in-game> thanks for the info people
<in-game> Speak to you later, if it works I will be back soon
<ojn> Lucid isn't built with neon enabled by default, right?
<cwillu_at_work> neon in what?
<cwillu_at_work> libpixman includes neon routines for instance
<cwillu_at_work> but as far as I know, gcc never outputs neon instructions automatically
<ojn> huh. that won't run on Dove then...
<slangasek> various packages include neon-optimized routines as alternatives but they're expected to work on non-neon systems too
<cwillu_at_work> I'll check, but I'd expect there to be guard clauses
<cwillu_at_work> exactly
<armin76> ojn: its not
<ojn> ok, thanks.
<armin76> ojn: last time i checked ubntu had an old version of pixman which didn't had the neon routines
<armin76> iirc pixman compiled automatically with neon, but it gets disabled/enabled at runtime
<armin76> ssvb: is the master here :D
<cwillu_at_work> armin76, pixman-0.16.4 has some neon fastpaths
<cwillu_at_work> I'm looking at apt-get source libpixman-1-0
<cwillu_at_work> doesn't have the more recent work done in january though
<armin76> cwillu_at_work: as i said, ssvb should know for sure :)
<cwillu_at_work> armin76, argument screens off authority :p
<armin76> iirc the neon stuff was reworked on >0.16 by ssvb itself :)
<cwillu_at_work> i.e., I'm looking at the source code :)
<lool> ojn, armin76, cwillu_at_work: lucid's and maverick's pixman have some NEON bits which are detected at runtime (via /proc/self/auxv)
#ubuntu-arm 2010-06-18
<Sarvatt> pixman in maverick is muuch faster on arm, I merged that as soon as I could :)
<kai> hi folks
<hrw> morning
<kai> is there much of a difference in assembler code between armv5 and the newer systems like the cortex (apart from the stuff the newer systems add)?
<kai> one of my co-workers is fiddling around with low-level kernel calls to get async file io going, and I'm wondering if I should get him an account on a shevaplug (faster, more ram) or on a beagle (newer cpu arch)
<lool> kai: Depends whether he's optimizing for v6 or v7?
<lool> kai: beagle's speed is decent, but I never tried the JTAG; sheeva is really great to JTAG-debug, so it might be relevant for him
<Lutin> lool: if it's a matter of getting things /going/ , v6 vs. v7 shouldn't matter much though
<lool> Lutin: the question is sheeva versus beagle, I agree with you that the described work is likely not architecture specific, but apparently it's about writing some assembler, so it could make a difference
<hrw> Lutin: v5 vs. v7
<lool> if you want to ship a v7 based product and you dont care that your code works on v5, you might be able to use some v6 or v7 assembly to speed things up
<hrw> sheeva has armv5
<kai> lool: I don't actually know what's involved
<kai> lool: this is about some really low-level IO stuff in the linux kernel, that's about the point where the explanation turned into chinese
<hrw> kai: sheeva + jtag access then would be easier and faster
<kai> hrw: ok, thanks :)
<hrw> sheeva cpu if much faster in integer then beagleboard
<hrw> and in kernel you can not use vfp or neon so no big speed up would be archived on bb
<hrw> shit. dpkg hang on my dekstop
<amitk> ogra_cmpc: what is the equivalent of qemu-arm-static in debian?
<lool> amitk: qemu-user-static
<amitk> lool: thanks
<lool> mpoirier: Heya
<mpoirier> good day.
<lool> mpoirier: linux-image-omap depends on linux-image-2.6.33-500-omap in maverick
<mpoirier> ?
<lool> mpoirier: Currently, linux outputs linux-image-2.6.35-4-omap
<lool> mpoirier: There are two set of omap kernels in maverick
<lool> mpoirier: One built from linux, and one built from linux-ti-omap
<mpoirier> humm....
<lool> apt-get install linux-omap or linux-image-omap should do something useful, but is broken right now
<mpoirier> Humm....
<lool> mpoirier: It's not clear to me whether you'll switch to a separate branch + source package for omap4 support, or whether it will still be linux source package?
<mpoirier> it is still undecided.
<lool> Humm....
<mpoirier> according to the trail of email in my inbox over the last couple of days
<lool> mpoirier: Is there any benefit for OMAP3 in running the OMAP branch from TI?
<lool> If you get a single binary kernel to work on OMAP3 + OMAP4 from the TI branch and it's strictly better than the mainline one, then I think the path is clear
<mpoirier> indeed.
<mpoirier> mainline should follow quickly though...
<amitk> lool: omap4 support will come out of separate source tree (it resides as a branch in the maverick kernel)
<amitk> tim added it yesterday
<lool> amitk: Yes, understood this bit; was it decided to use a single kernel for OMAP4 and OMAP3?  and is there any regression for OMAP3 from mainline to the TI branch?
<amitk> lool: there is not benefit is running omap3 with TI's code since TI's code is not upstream and hence will get refactored quite a bit before it all makes it to upstream.
<amitk> also, last I looked, TI's tree breaks OMAP3
<lool> Ok
<ogra> lool, bug 595949
<ubot2> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) (and 1 other project) "linux-meta-ti-omap depends on the wrong binary kernel in maverick (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/595949
<lool> ogra: Thanks; I didn't know whether linux-meta was also concerned or not
<hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ -  new structure, new versions
<sebjan> ogra: I just filed the bug 596004 regarding the UNE UI issue on Maverick
<ubot2> Launchpad bug 596004 in netbook-meta (Ubuntu) "with 2D UI (une-efl) selected, the gnome desktop toolbar is also visible and seems to be running (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/596004
<ogra_cmpc> sebjan, great, thanks, i'll take care of it
<lool> Wow, my beagle has a /dev/ramzswap0 for some reason
<lool> is compcache enabled on installed system as well?  i thought it was an install only thing
<markos_> lool: hi, I have some initial results on the hardfp/softfp performance
<markos_> tested on the iMX515 with karmic (ubuntu original vs my compiled with hardfp)
<markos_> I tested glxgears to see how it would affect fp performance (using fbdev X, no 2d/3D accel)
<markos_> so softfp gave me ~120 fps, while hardfp gives me 146 fps
<markos_> I know glxgears is not a proper 3D benchmark, but I'm not interested in 3D, rather fpu performance
<markos_> so...
<markos_> that's ~21% speed increase, dunno if it can be more, but it looks logical
<markos_> I'll post this asap with more info
<lool> markos_: markos_ That's interesting, thanks
<lool> markos_: what about the archive, did you manage to setup a source one?
<markos_> yeah it includes sources in the same url
<markos_> most of them at least
<markos_> I probably forgot to include sources for packages I built manually -not needing patching, just cyclic dependency probs,e tc
<lool> markos_: http://freevec.org/repository/dists/karmic/main/ has no source index?
<markos_> strange, I did reprepro includedsc
<markos_> lol
<markos_> that was on my local server, I have to rsync it
<markos_> sorry bout that :)
<markos_> I'll let you know when the rsync is over
<lool> markos_: thanks a lot
<lool> markos_: I'm away next week though, so I'll probably mirror the week afterwards
<markos_> i don't think it's going anywhere
<markos_> I mean I have no plans to move or remove it
<markos_> so...
<lool> Ok thanks
<markos_> the past days I've been working on setting up wanna-build...
<markos_> I have to say the documentation is *crap*
<markos_> I still haven't managed to even setup the db
<markos_> anyway, dinner time, later
<GrueMaster> ogra: ping.  Do you know when jasper will be in the repo?
<lool> markos_: An alternate wanna-build is being developed IIRC
<lool> markos_: pkern was doing a python rewrite as a gsoc I thnk
<lool> markos_: The documentation for the current version is the source I'm afraid
#ubuntu-arm 2010-06-19
<DanaG> http://armdevices.net/2010/06/03/ubuntu-10-4-on-marvell-armada-510/
<DanaG> hmm.
<DanaG> I see lack of compiz. :(
<ogra> GrueMaster, jasper is in the repo since beginning of the month
#ubuntu-arm 2010-06-20
<rsavoye> is there a PPA for lucid of the newly added Mesa OpenGL-ES package ?
<GrueMaster> ogra: Thanks, I see it now on ports.ubuntu.com.  It is in universe, which I haven't started mirroring yet (not sure if I want to mirror it).
<idlogin> Hi everyone my first time here :-) i've been picking up interest in arm for linux. a question. can something like this http://www.maplin.co.uk/Module.aspx?ModuleNo=385448 running WinCE 5 easily be converted to an ARM Linux machine?
#ubuntu-arm 2011-06-13
<MrCurious> persia: are you around?
<MrCurious> i think it was you who reccomended that i use the ubuntu opencv linraries (from apt-get) rather than building them myself.  do you know if for pandaboard, the ubuntu opencv libraries have any DSP or 3d optimizations in them
<Martyn> they do not, that I am aware of
<MrCurious> curses!
<MrCurious> wonder if anyone is working on hardware acceleration for opencv on pandaboard
<Martyn> Well, there isn't all that much in there to help with accel
<Martyn> It's not exactly like you can use CUDA on an omap 4400
<Martyn> openCL maybe?
<Martyn> that uses the SGX accel
<MrCurious> looks like opencl has not yet come to the pandaboard
<MrCurious> hmmm OpenCL implementation is in work at this time and from what I understand it
<MrCurious> will likely be made available in 2H11. Andrew is at Imagination Technologies
<MrCurious> ( the graphics IP vendor for OMAP4 SoC)  i.e, he has access to the inside
<MrCurious> implementation he he is able to do such posts.
<MrCurious> wonder what 2H11 means?
<MrCurious> 2nd quarter 2011
<MrCurious> http://withimagination.imgtec.com/news/powervr-sgx-cores-get-opencl-conformance/
<MrCurious> looking like you are right about opencl
<MrCurious> its just a question of can they be had
<persia> MrCurious, I don't know of anyone working on optimisation of OpenCV (except perhaps you).
<MrCurious> i am not working on, just inventorying what is available to me
<MrCurious> i am curious if anyone has a pandaboard and a web cam(running ubuntu or android) if they could check teh FPS they get with mplayer on /dev/video0
<MrCurious> would love to know if i have a less than optimum setup 3 web cams varying 8 FPS to 12 FPS
<persia> Looks like OpenCL isn't really well-supported right now.  There's a khronos-opencl-headers package, but it doesn't seem to be something that has dependencies.
<MrCurious> no library package for those headers?
<persia> Only the nVidia CUDA implementation
<MrCurious> and my guess is that is not meant for pandaboard
<persia> And from what I can tell, that's not being distributed as part of Ubuntu currently.
<persia> Heh, no.
<persia> The headers are from http://www.khronos.org/registry/cl/ , but from what I can tell, it needs N implementation libraries.
<persia> Meaning that there's probably lots of integration and interoperability work to be done as the implementations become available and packages are created.
<persia> For the pandaboard, you'll probably get the fastest throughput with video capture using gstreamer.
<persia> I believe TI has some optimised gstreamer input plugins in their PPA.
<persia> (although I may be mistaken: I haven't tried playing with video in)
<MrCurious> gstreamer... isnt that for working the DSP's?
<MrCurious> not something to speed up USB ports
<persia> gstreamer is an A/V programming framework: I believe that it helps deal with onboard processing once it's come over USB.
<persia> If you think 8-12 FPS is limited by USB, then it probably won't help.
<MrCurious> at this point i am unsure of where its bottlenecked. thats why i seek comparison with other users
<MrCurious> given that my disk was much much slower than gruemaster
<MrCurious> and mine was ssd vs his spinning disk
<MrCurious> panda has gstreamer support?
<persia> Everything has gstreamer support, but TI has some special gstreamer modules to make panda even faster at processing video.
<MrCurious> interesting
<MrCurious> lots of packages come back in a gstreamer search
<persia> Right, but the ones with the panda-specific optimisations are probably those in ppa:tiomap-dev/release
<persia> I *think* you want gst-ducati (but I'm not really sure)
<Martyn> Damnit, I can't get a hold of George in New Zealand
<persia> It's the end of the day there...
<Martyn> yes.. but the earthquake seems to have knocked out phones/cells again
<Martyn> there was a swarm, starting at 1pm (5.5) ending with a pretty solid 6.0 quake at 2:20pm .. it's been a little over two hours
<persia> I seem to have some (sporadic) traffic from .nz hitting my router: I presume the lines are up and congested.
<Martyn> .nz is big enough to be up away from Christchurch
<Martyn> can you tell if there is much (if any) traffic coming from there?
<persia> Nope.  I have insufficient knowledge of the relation between network topology and geography in that region.
<persia> I'm probably currently biased, but I'd presume that a series ending in 6.0 isn't likely to have been catastrophic, although that means nothing in terms of individuals.
<Martyn> Yep, and what's bad is that NZ has many, many buildings that just aren't up to earthquake codes
<Martyn> they happen, and lately frequently, but in the past not very often
<persia> That could make it much worse then.
<Martyn> Can .. of course since the big quake four months ago, there has been a call to up the quality of construction (and shore/replace current structures)
<Martyn> but it's only been four months
<persia> Code compliance requires a generation of buildings, which can be fairly long in places with heritage regulations.
<garagoth> Good morning
<garagoth> I have a problem with mu Natty on BB-xM
<garagoth> (again)
<garagoth> After reboot it does not bring up USB and network
<garagoth> also, bridgedriver (for DSP) seems to be missing...
<garagoth> any hints?
<GrueMaster> What rev beagleXM do you have?
<garagoth> C
<garagoth> it was working before reboot (except dsp)
<GrueMaster> Yep.  Known issue.  We have a new kernel for this.  Give me a sec and I'll paste the link up.
<garagoth> and kernel during startup correctly identifies my board (u-boot does not)
<garagoth> GrueMaster: Is this a second patch for Natty on xM rev B, C then?
<GrueMaster> Yes.
<garagoth> But it started up correctly when I rebooted after headless install... ?
<GrueMaster> https://wiki.ubuntu.com/ARM/OmapNetbook
<GrueMaster> The update is at the bottom of the wiki page.
<garagoth> I powered it off for weekend and it did not start.
<GrueMaster> Instructions are the same for headless.
<garagoth> GrueMaster: Is this the same updated image I applied at hm, thursday or friday, when I reported problems with headless install here?
<GrueMaster> Maybe.  I have lost track, as I had to fly to London for meetings.
<GrueMaster> I can look through the backscroll to check.
<garagoth> Because headless install was failing (no network), then applied your (and rsalveti) patch, went fine, reboot, still all fine... now not fine, after halt & poweroff
<GrueMaster> Odd.  Same kernel or did it revert?
<garagoth> The patch is exactly the same, md5 identical.
<garagoth> Hm, dunno.
<garagoth> Should be the same?
<garagoth> How can I check it?
<GrueMaster> Here is my md5sums:
<GrueMaster> 6b627ef6dbbca9b9f8212a512fcd9561  uImage
<GrueMaster> 1747c4ab2cc6a9d0710207f48666a91d  vmlinuz-2.6.38-8-omap
<GrueMaster> I don't have access to a beagleXM here, so I can't check the kernel signature.
<garagoth> my uImage is different
<garagoth> but I changed boot.script and executed flash-kernel
<GrueMaster> flash-kernel would have changed the timestamp, but nothing else as long as it is using the same vmlinuz.
<garagoth> Hmm!
<GrueMaster> Make sure /boot/vmlinuz links to the vmlinuz updated kernel.
<garagoth> it is.
<garagoth> and flsh-kernel generated uImage with md5 2fb0dd0f4061e4b5c0ff482639d69248
<GrueMaster> I don't know what to tell you off hand.  maybe rsalveti will have some ideas.
<garagoth> what is the kernel module responsible for usb on BB-xM ?
<GrueMaster> Not sure, but I know that it is built in.
<garagoth> ahm.
<garagoth> Then maybe you know something about missing bridgedriver module?
<GrueMaster> Not offhand.
<garagoth> Mm. Thanks.
<GrueMaster> Let me see if my beaglexm is still running at home.  If so, I can do a quick test of this kernel.
<garagoth> Sure.
<garagoth> Angstrom boots fine, so not a hardware issue...
<garagoth> GrueMaster: Also, u-Boot still reports Beagle unknown rev 0x02, while u-Boot from Angstrom displays Beagle xM. Kernel displays correctle as bb-xm rev C...
<garagoth> Grr. Why I always make a typo in correctly and usually in typo ...
<GrueMaster> Yes, I don't know if u-boot has been updated upstream yet.
<GrueMaster> Also, I can't get the kernel to work properly with networking either on my older XM, so definately a kernel issue.
<GrueMaster> rsalveti:  ^^^
<garagoth> rcn-ee: How is your work on 2.6.39 kernel for natty?
<jussi> Does anyone know about the driver for the HDMI expansion card on the freescale iMX53 quick start board? (ie. which driver it is)
<rcn-ee> garagoth, haven't been able to repeat it, tried a bunch of mmc cards, haven't been able to get the mmc -110 on the current image..
<garagoth> rcn-ee: Also, your latest 2.6.39.1-x1 kernel fails to bring up my USB devices & network interface...
<rcn-ee> are you using my u-boot?
<garagoth> I installed it on natty headless because 2.6.38-8 has same problem
<garagoth> rcn-ee: Not sure...
<rcn-ee> android people where running the same issue.. if you don't have a u-boot that knows about the xM C, for some reason the usb is dead..
<garagoth> Funny thing is...
<garagoth> that I installed headless natty (after installing patched 38-8 kernel), rebooted, all was fine... then I powered it off, waited 2 days, powered on and no USB
<rcn-ee> so either, something was setup that got lost between reboot's, or the kernel changed..
<garagoth> Kernel was the same...
<garagoth> But few reboots it was working. It stopped after power off
<garagoth> for few reboots*
<rcn-ee> humm strange.. well got to run to work, will be back in just a bit..
<garagoth> Mm.
<garagoth> Ok. More strange things
<garagoth> I booted Angstrom (it booted fine, all USB working), then reset (without powering off), swapped cards, booted ubuntu... and all is working again...
<garagoth> rcn-ee: Let me know when you will be back, I need to learn about your uBoot
<rcn-ee_at_work> garagoth, nothing special, i just build it from angstrom's..
<garagoth> Ok... how to install it? It is "special" as it works...
<rcn-ee_at_work> on your fat partition, just copy it as is. "uboot.bin" would upgrade it.. MLO/X-loader it's usualy a toss up 50/50 you'll need to redo the sd card..
<garagoth> what would it upgrade?
<garagoth> Maybe I will just copy MLO & u-boot.bin from Angstrom? Will it work, or your files have something better/Ubuntu specific?
<GrueMaster> I would hope that we all are using the same u-boot source tree, instead of one for ubuntu, one for Angstrom, etc.  Our released package may be dated, but we should be using the same upstream source.
<rcn-ee_at_work> they are 2011.02 with a few patches: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot/u-boot_git.bb?h=2011.03-maintenance#n28
<garagoth> rcn-ee: None of your u-boot.bin files correctly identified my board
<garagoth> while Angstrom u-boot.bin identifies it correctly.
<garagoth> I was checking inages from here: http://rcn-ee.net/deb/tools/beagleboard/
<rcn-ee_at_work> yeah, sorry those are pure mainline was using them to find a mmc card issue on an old Bx...
<rcn-ee_at_work> for the xM: http://rcn-ee.net/deb/tools/UBOOT/u-boot-beagleboard-2011.02+r75+gitrc7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8-r75.bin
<garagoth> ok, let me try....
<rcn-ee_at_work> (that's one i built from angstrom's tree and uploaded)
<garagoth> Original Angstrom u-boot.bin file is looking for /boot/uImage from mmc device 0:2
<garagoth> does your look for /uImage on mmc 0:1 ?
<rcn-ee_at_work> no, i redirect it with: http://elinux.org/BeagleBoardUbuntu#boot.scr_-.3E_uEnv.txt  (on my demo images... )
<brendand> is there a way to get flash working on pandaboard?
<garagoth> mmc0: unrecognised SCR structure version 6
<garagoth> mmc0: error -22 whilst initialising SD card
<garagoth> mmc_erase: erase error -110, status 0x800
<garagoth> end_request: I/O error, dev mmcblk0, sector 334793
<garagoth> This is on your 39.1-x1 kernel
<rcn-ee_at_work> I'd really test another mmc card.. i might have the same one that came from beagle here at work.
<garagoth> rcn-ee: This is different card.
<garagoth> Transcend microsd
<garagoth> 4GB
<garagoth> but there is only one such error and system boots up
<garagoth> on stock card there were hundreds of those...
<garagoth> rcn-ee: On 2.6.38-8 kernel there are no such errors.
<garagoth> and there seems to be some error with usb0 (network) - interface is up, bot not communication goes through. On 2.6.38-8 all is fine again.
<garagoth> but your u-boot works.
<rcn-ee_at_work> garagoth, the only error i'm getting so far is: "mmc0: unrecognised SCR structure version 10, mmc0: error -22 whilst initialising SD card" but i believe that's related to the expansion mmc setup (it doesn't find it)
<garagoth> What can I say.
<rcn-ee_at_work> the one big difference between my 2.6.39 and the older 2.6.38 is we know have support for this mmc based device: http://boardzoo.com/product_info.php?products_id=1
<garagoth> Beagle wlan adapter?
<rcn-ee_at_work> same wlan as on the panda
<GrueMaster> beagle has wlan?
<rcn-ee_at_work> expansion
<GrueMaster> ah.
<rcn-ee_at_work> garagoth, i had one of the mmc card's that came with a beagle xm, but i can't even write an image to it without that task hanging at the moment.. here's my pastebin with a good working card: http://paste.ubuntu.com/625969/
<garagoth> Hm, looks like you have different xM revision
<garagoth> Mine is: [    0.149444] OMAP3 Beagle Rev: xM C
<rcn-ee_at_work> yeah in the lab here i only have my "xM B" labeled, my C is out in the field with another engineer..
<NCommand1r> rsalveti: did you file a bug on the OMAP3/4 boards failing to reset with the new images?
<rsalveti> NCommand1r: nops, as I didn't test with the new images yet
<NCommand1r> rsalveti: well I haven't built a new image yet (and the old images are sitll pre-install, but I'm working on it)
<GrueMaster> NCommand1r: what reboot failure?
<GrueMaster> On oneiric?
<NCommand1r> GrueMaster: when you boot a panda with a partition formatted with the new mkdosfs patch, the reset button onthe panda stops working
<GrueMaster> Ah.
<GrueMaster> I wonder if it is similar to the toolchain issue with the omap3 kernel and usb?
<GrueMaster> bug 791552
<ubot2> Launchpad bug 791552 in linux "No USB support on beagle/beagleXM" [High,New] https://launchpad.net/bugs/791552
<NCommand1r> rsalveti: is three a packaging for x-loader/u-boot? I need to create udebs
<rsalveti> NCommand1r: yup, for both
<rsalveti> NCommand1r: why do you need udeb for them?
<NCommand1r> rsalveti: for d-i
<garagoth> Hmm. I have Beagle-xM trainer board from tin can tools. u-boot correctly detects it.
<garagoth> But, when ubuntu boots, I cannot see i2c bus 2
<garagoth> only 1 and 3 are visible
<garagoth> any hints?
<garagoth> (Angstrom boots and sees i2c bus 2 out of the box and I am able to communicate on it. So not a hardware issue)
<rcn-ee_at_work> garagoth, i don't think ubuntu's kernel has support for any of the expansion board's..  (the patches angstrom have come with haven't been pushed to mainline either..)
<garagoth> but i2c bus 2 is available on expansion port
<garagoth> beagle trainer board just translates voltage levels
<rcn-ee_at_work> only 1 & 3 are visable because port 2 isn't setup in ubuntu or mainline either: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=7f21d24bd437732724a45af9302c50a514f56482;hb=HEAD#l418
<rcn-ee_at_work> for the expansion boards you need a patch similar to this: https://github.com/RobertCNelson/stable-kernel/blob/master/patches/sakoman/2.6.39/0032-OMAP3-beagle-add-support-for-expansionboards.patch
<garagoth> Just great...
<garagoth> Thanks. will think over it tomorrow. It is already 11 PM here. I need to sleep...
<garagoth> Cheers!
<garagoth> and good night...
#ubuntu-arm 2011-06-14
<Jef91> Anyone know if Ubuntu ARM is fully functional on the apple TV box?
<cipher> does anyone know the latest "start on" type upstart stanza one could use to start an executable/script?
<cipher> latest in terms of time since boot
<cipher> I have a specific issue where the daemon I'm trying to start depends on a fully booted system being ready to go and "start on runlevel [2345]" doesn't seem to be good enough, requiring me to restart my process before it works correctly
<cipher> the process is dependant on modprobe of a linux gadget and setting of permissions for the led in /sys/class/leds
<persia> cipher, Don't do that in upstart.  Have udev start your service when it detects the device (hotplug)
<cipher> persia: unfortunately udev doesn't detect it, at least when I use udevadm to monitor there's no event for my device
<cipher> because it's a platform device, methinks
<persia> There's a bug there somewhere.
<persia> If you need to modprobe, then it *should* provide an event.
<ScottK> NCommand1r: Is "There is no default kernel flavour defined for your architecture." on Kubuntu images something I need to worry about of a general problem that will go away soonish?
<MrCurious> sweet. ubuntu wifi working without having to login
<MrCurious> fires up on boot
<garagoth> Good morning/afternoon/evening
<garagoth> What was the reasoning then i2c bus 2 was not added to arm kernel for Ubuntu?
<garagoth> s/then/when/
<garagoth> for Beagleboard ofc
<ogra_> ScottK, thats fallout of the switch to the new live rootfs build system
<ogra_> ScottK, i got it too for our images
<sveinse> upowerd constantly keeps stealing my USB serial adapter which I connect to my target. Is there anyone here who knows a fix for that?
<ogra_> funny, never heard of such probs
<persia> sveinse, I found some USB micro host cables: http://www.henj.in/ : they seem physically correct, although apparently my device with micro doesn't support HOST mode.
<persia> (no it's not listed on the website, but really I bought some from them)
<jeremiah> ehlo earthlings!
<jeremiah> If I find a bug (heaven forbid) in one of the oneiric daily builds
<jeremiah> do I file a bug?
<jeremiah> And if so, where?
<persia> Please.
<jeremiah> I'm about to test the oneiric headless OMAP 4 on a fresh pandaboard.
<persia> `ubuntu-bug ${best-guess-at-package-name}` running on the affected system.
<jeremiah> :)
<jeremiah> persia: Thanks. :-)
<persia> Extra points for including the fix with the bug submission :)
<jeremiah> heh
<hrw> oneiric on panda...
<hrw> works fine for me
<hrw> dpkg: ostrzeÅ¼enie: parsing file '/var/lib/dpkg/available' near line 33305 package 'x-loader-omap4': error in Version string 'L24.9git20100901-0ubuntu5': version number does not start with digit
<garagoth> hrw: mogÄ chÅopaki ostrzeÅ¼enia nie zrozumieÄ :-)
<hrw> garagoth: second part is understandable
<GrueMaster> jeremiah: persia:  ubuntu-bug is not installed on headless, so you will need to install it.
<persia> GrueMaster, Oh, hm.  Right.
<lool> Does someone care about debian-cd and debian-installer support for imx51 based on RedBoot (redboot-tools)?
<lool> I'd like to remove the scripts, configs and build-deps in debian-installer's tip and in debian-cd's oneiric tree
<ogra_> just drop it
<lool> Thanks
<jeremiah> GrueMaster: Thanks, good to know. :)
<ogra_> GrueMaster, did you try a dist-upgrade on oneiric in recent times ?
 * ogra_ has the feeling upgrades of gnome-user-guide got much much worse in 11.10
<ogra_> its taking like 25min here
<Gelmi> has anyone run Ubuntu 11.04 on PandaBoard Rev A2 with success?
<Gelmi> I spent all night last night trying to boot ubuntu, with practicly no results
<Gelmi> I have managed to get console surring by changing bootargs in boot.scr, but I always get some errors in one point of instalation of 10.10 and I have also tried with 11.04 but it hangs where the graphics should be initiated
<Gelmi> I have tried some tricks from https://wiki.ubuntu.com/ARM/OMAPMaverickInstall and https://wiki.ubuntu.com/ARM/OmapNetbook but still no luck
<hrw> ogra_: I just finished dist-upgrade oneiric->oneiric on a1 panda
<ogra_> did you get an update of g-u-d ?
<hrw> probably not have it installed
<ogra_> ah
<ogra_> well, the update works just fine
<hrw> yep. uninstalled state
<ogra_> but it takes like 25-30 min to unpack an update to gnome-user-docs
<hrw> btw - do we want armhf cross toolchain for armel?
<ogra_> that used to be under 10min ... which is still long but more bearable
<ogra_> hrw, is there a usecase for it ?
<hrw> what it does on upgrade? recompilation of every format etc?
<ogra_> i.e. do yu expect people to build for hf on el ?
<hrw> ogra_: just got asked once for it so why not ask here
<ogra_> it doesnt do anything but inpack its contents
<ogra_> there are no postinst preinst scripts at all
<ogra_> *unpack
<hrw> I think that armhf people can do chroot of debian one
<ogra_> well, i dont see a rel benefit for such a cross toolchain but others might feel different
<hrw> ~51MB of data in g-u-g
<ogra_> if i want hf i will build on an hf install
<ogra_> yes, its huge
<hrw> ~6k files
<hrw> you have / on sd?
<ogra_> well, emmc, but yes
<ogra_> still it took less than half the time with natty
<ogra_> (same kernel)
<hrw> had less files?
<ogra_> might be
<hrw> 6k files + sd == problems
<ogra_> i wonder if we should ship it anyway ... in times of unity :)
<ogra_> well, probelms i didnt have with the older userspace
<hrw> unity? I do not use it ;D
<ogra_> well, ubuntu doesnt use much of gnome anymore either
<ogra_> i know that you dont use it :)
<hrw> 1-2 years ago I was joking that I am waiting for GUbuntu - now it exists
<hrw> ;D
<ogra_> does it ?
 * ogra_ didnt know someone started that
<hrw> I thought that someone did it
<GrueMaster> ogra_: I haven't done any oneiric image testing in a couple of weeks.  Last week was getting benchmarking started and several other tasks.
<ogra_> GrueMaster, yeah, i thought so ... too many other tasks
<GrueMaster> That and the images were very unstable after alpha 1.
<ogra_> yup
<hrw> ogra_: http://ugr.teampr0xy.net/
<hrw> The system includes both GNOME 3 and a fallback to a classic GNOME interface as of 0.1.0.
<hrw> lunch time
<ogra_> hrw, heh, funny
<ogra_> lool, is there any ubuntu armhf rootfs tarball anywhere ? (or at least a repo) ?
<ogra_> (i know about the debian image but thats not what i look for)
<lool> ogra_: there's debian-ports.org, you can debootstrap from it; no Ubuntu debootstrapable repo yet, albeit we're working on it
<ogra_> k
<lool> ogra_: Would you know which Ubuntu releases had debian-cd-backed imx51 images?
<lool> I will remove the scripts from oneiric, but dunno how far back I can remove -- natty?  maverick?  lucid?
<ogra_> hmm, not sure if maverick still had it, lucid definitely did
<lool> ogra_: http://cdimage.ubuntu.com/ports/releases/10.04/release/ lists an mx51 image, but not http://cdimage.ubuntu.com/ports/releases/10.10/release/
<lool> ogra_: does that mean I can kill it for maverick?
<lool> worst case, it can be resurrected from bzr history
<lool> also, we wont release any updated maverick image in theory (not like LTS where we have .1, .2 etc.)
<ogra_> i dont think we'll ever re-roll imx51 images anyway
<brendand> er, once i boot the oneiric image, what username and password do i need to give?
<ogra_> brendand, the one you gave it during the oem-config installer
<ogra_> lool, just remove it ... i'll blame you if we ever re-roll maverick images :P
<brendand> ogra_ - didn't go through that step...
<ogra_> brendand, sounds like a bug with the daily images
<ogra_> file it :)
<brendand> ogra_ - any idea where?
<ogra_> lool, also note that lucid for arm is only 18months
<ogra_> brendand, see the topic ... file it against live-build ...
<ogra_> (if it is todays image, else the bug is somewhere else)
<lool> ogra_: Still, we keep the scripts of released images in subdirs
<ogra_> i know
<lool> but I'd like to avoid carrying them in oneiric, oneiric+1 etc. and I took the occasion to strip them of releases they weren't used in
<lool> anyway, removed now
 * ppisati wonders how long does it take to compile a kernel on a panda...
<ogra_> lool, thanks for doing all that mopping up :)
<GrueMaster> ppisati: You have acces to both, test it.  :P
<ogra_> ppisati, in ac100 the ac100 kernel package takes me about 1.5-2h ... (that doesnt build docs or debug)
<ppisati> GrueMaster: i was sarcastic, i'm doing it right now...
<ppisati> so fat...
<ppisati> ops
<ppisati> far
<ppisati> 1h20mins and still going...
<ogra_> on panda a kernel package build should take about the same plus the time it takes to build any additional bits (docs headers ddebs)
<ppisati> :(
<lool> ogra_: np; next step is demoting redboot-tools and redboot-imx51-babbage
<lool> or whatever it's called
<ogra_> demoting ?
<ogra_> just rip them out :)
<ogra_> they will just bit-rot otherwise
<lool> I thought redboot-tools was in Debian but apparently not; I agree with removal, I'm fine either way
<ogra_> better remove ... if they are ever needed back or so we can re-vive them still
<lool> there is a small chance that redboot-tools is useful to some, albeit I can't think of a modern armv7 platform which uses redboot
<lool> maybe if we rebuild Ubuntu for v5
<ogra_> well, then they can come back
<ogra_> the branches still exist
<lool> I could flip your argument the other way around  ;-)
<lool> better keep, less work than pushing them back   ;-)
<ogra_> sure, if you feel like :P
<lool> I don't think I care, albeit I do care that they get demoted out of main
<ogra_> but who eill maintain them :)
<ppisati> around 2 hours
<ppisati> that's what it takes to compile a natty kernel on a panda + usb disk
<ogra_> yeah, about the same on ac100
<ppisati> ogra_: do you compile it on the internal flash?
<ogra_> yes
<ogra_> everything else needs patience
<ppisati> doesn't it wear out quickly?
<ogra_> dunno, mine didnt since oct being my main work device
<ppisati> ok
<ogra_> might make it wear out in 4 years instead of 5 i guess
<ppisati> dunno, i thought it would die much sooner
<ogra_> or so ...
<ogra_> well, its true that swapping and lots of RW reduce the life cycle ... but that doesnt mean it dies tomorrow if you start today
<ppisati> i've been badly impressed by a couple of sd i bought
<ogra_> by wearing them out ?
<ppisati> they died really quickly (2 months or so)
<ppisati> i think so, since then i moved to a usb disk
 * ogra_ is working with tiny laptops since 4 years now, i managed to wear out exactly one usb stick
<ogra_> i have never worn out an SD ...
<ogra_> even though i do myriads of install tests since several years with them
<ppisati> then perhaps mine were crap, but i feel a bit uncomfortable compiling a kernel on a flash device
<ogra_> well, if you use the ac100, the MMC is the fastest disk option
<ogra_> faster than USb
<ppisati> definitely i'll use that
<ogra_> and faster than external SD
<ppisati> and i can confirm you that we lost usb on omap4 too
<ppisati> both native compilation or cross
<GrueMaster> Yea.  :(
<ogra_> who needs USB as long as we have a shiny new version number on your compiler suite
<ogra_> s/your/our/
<ppisati> yesterday i rolled a new 4.6 toolchain using the devian packages
<ppisati> let's see if i can reproduce it there
<ppisati> debian
<ppisati> (today i have a problem with my beayboard)
<ppisati> ...
<ppisati> keyboard
<ppisati> latest linaro .39 kernel has it too
<ogra_> thats a good indicator
<ppisati> let's see with the debian cross toolchain now
<ppisati> and it's there with the debian toolchain too
<ppisati> uhm
<ogra_> ppisati, not surprising
<ppisati> ogra_: actually it doesn't show the sda even with the 4.5.x toolchain
<ppisati> ogra_: i wonder if it's an unrelated issue
<ogra_> oh, you didnt say 4.5
<ppisati> ogra_: i'm trying all the combinations
<ppisati> at last i thought "did i try this with 4.5? uhmm..."
<jburkholder1> hmm, no love from canonical
<NCommand1r> ScottK: which architecture speciically?
<ScottK> NCommand1r: It was omap and omap4.
<NCommand1r> ScottK: and where did that error pop up? (sounds like the installer ...)
<ScottK> NCommand1r: IIRC it was the ISO build failure mail.
<NCommand1r> cjwatson doing the footwork to change us over to live-helper, probably a few hiccups here and there
<ScottK> Probably.  Just wanted to check and make sure.
<ogra_> ScottK, already fixed
<ScottK> ogra_: Thanks.
<beagleboarduser> hello, i just downloaded ubuntu 11.04 on a sd card for my beagleboard xM. however, it booted into command line, instead of the unity gui...how do i get unity to show up?
<ogra_> beagleboarduser, but you used the netbook image ?
<beagleboarduser> i got the image from this website: http://cdimage.ubuntu.com/releases/11.04/release/
<beagleboarduser> is that wrong?
<ogra_> no, thats fine, but which one ?
<beagleboarduser> the Omap3 preinstalled netbook image.
<beagleboarduser> this was the name: ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz
<ogra_> that should be fine
<ogra_> and you dont see the installer on your hdmi display after booting ?
<beagleboarduser> no, it had the "ubuntu" image with the purple background. it said something about resizing install image, then it suddenly put me in the command line
<beagleboarduser> i didn't get any options to make an account, etc.
<ogra_> it should have rebooted at the end of the resizing
<beagleboarduser> ok. should i restart it from the commandline (at the very top it said  "No init found. Try passing init = boot" or something similar)
<rsalveti> probably you got a broken install and busybox came up
<rsalveti> yeah, sd card issues
<rsalveti> could be that your dd got broken in the process or your sd card doesn't work as expected with your beagle
<beagleboarduser> yeah, busybox showed up...broken install already? wow, i didn't even start with ubuntu yet, this must be a record :/
<ogra_> how did you put the image on the sd ?
<ogra_> did you follow the ubuntu install instructions (linked from https://wiki.ubuntu.com/ARM/OMAP)
<beagleboarduser> i put my 16 gb card into my laptop card reader, clicked on "unmount", then used the commandline given in the install instructions
<beagleboarduser> yep, i used the gunzip one (gunzip -c ubuntu-11.04-preinstalled-netbook-armel+<omap image>.img.gz | sudo dd bs=4M of=/dev/<device name>), but i changed the requisite things
<beagleboarduser> omap.img.gz, and then /dev/mmcblk0
<ogra_> well, that line should be fine
<rsalveti> I have one sd card that I usually get the same issue you got
<rsalveti> never worked with ubuntu images
<beagleboarduser> ah that's a bummer....so i need another sd card?
<rsalveti> maybe, try dd again
<beagleboarduser> ok, how should i clear the files already on the card?
<ogra_> dd will do that
<beagleboarduser> er...what is dd?
<beagleboarduser> (sorry for my beginner-esque questions... :) )
<ogra_> see what you pasted above :)
<ogra_> gunzip -c ubuntu-11.04-preinstalled-netbook-armel+<omap image>.img.gz | sudo dd bs=4M of=/dev/<device name>
<ogra_> dd is the second command on that line :)
<ogra_> or "sudo dd"
<beagleboarduser> haha, oops, i missed that, it looked like another option to my eye, thanks!
<ogra_> the | connects the output of the first command to the input of the second one
<beagleboarduser> ok, got it
<beagleboarduser> i'll try the "dd" again, hopefully it'll work
<ogra_> lool, oh, regarding your mx5/efika stuff that was mentioned on the debian-arm ML, do you plan to pull that soon into debian (i still have a pending merge for flash-kernel in oneiric adn was wondering if i should wait for that)
<ppisati> flag@omap:~$ cat /proc/version_signature
<ppisati> Ubuntu 2.6.38-1208.11-omap4 2.6.38.2
<ppisati> flag@omap:~$ ifconfig eth0
<ppisati> eth0      Link encap:Ethernet  HWaddr 00:01:04:1b:2c:1f   inet addr:192.168.0.65  Bcast:192.168.0.255  Mask:255.255.255.0 inet6 addr: fe80::201:4ff:fe1b:2c1f/64 Scope:Link UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1 RX packets:10 errors:0 dropped:0 overruns:0 frame:0 TX packets:17 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000  RX bytes:1056 (1.0 KB)  TX bytes:1992 (1.9 KB)
<ppisati> flag@omap:~$ lsmod
<ppisati> Module                  Size  Used by
<ppisati> sg                     21574  0
<ppisati> wl12xx                 90763  1 wl12xx_sdio
<ppisati> wl12xx_sdio             3044  0
<ppisati> btsdio                  2816  0
<ppisati> unloaded all the modules but eth0 is still there
<ogra_> yeah, looks ok
<ppisati> flag@omap:~$ dmesg | grep smsc
<ppisati> [    2.744903] usbcore: registered new interface driver smsc95xx
<ppisati> [    3.920196] smsc95xx 1-1.1:1.0: usb_probe_interface
<ppisati> [    3.920196] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
<ppisati> [    3.920227] smsc95xx v1.0.4
<ppisati> [    4.001525] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 2e:40:70:f0:12:06
<ppisati> [   62.695220] smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
<ppisati> [flag@newluxor canonical]$ grep -i smsc ubuntu-natty/debian/build/build-omap4/.config
<ppisati> CONFIG_SENSORS_SMSC47B397=m
<ppisati> CONFIG_SENSORS_SMSC47M1=m
<ppisati> CONFIG_SENSORS_SMSC47M192=m
<ppisati> CONFIG_SMSC911X=m
<ppisati> # CONFIG_SMSC911X_ARCH_HOOKS is not set
<ppisati> CONFIG_SMSC_PHY=m
<ppisati> # CONFIG_USB_NET_SMSC75XX is not set
<ppisati> CONFIG_USB_NET_SMSC95XX=y
<ppisati> NCommand1r: can't you break into initrd?
<ppisati> i know there was an option...
<ogra_> d-i has a terminal running on tty4, shouldnt be a prob
<ppisati> ah, didn't know
<ogra_> (debian-installer actually *is* your initrd :) )
<ppisati> ah right, it's an installation scenario
<ogra_> right
<ppisati> Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:48:22)
<ppisati> U-Boot 2011.03 (Apr 20 2011 - 07:37:43)
<NCommand1r> back, sorry
<NCommand1r> ppisati: something that is a m should be a y or listed in the proper udeb
<ogra_> NCommand1r, SMSC95XX isnt m
<ogra_> and eth0 is there for him apparently
<NCommand1r> ogra_: well I don't have ifconfig in the preboot enviornent
<ogra_> NCommand1r, can you capture dmesg in d-i and paste that somewhere ?
<ogra_> NCommand1r, cat /proc/net/dev
<NCommand1r> /lib/modules/2.6.38-1208-omap4/kernel/net # cat /proc/net/dev
<NCommand1r> Inter-|   Receive                                                |  Transmit
<NCommand1r>  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
<ogra_> should show you all interfaces the kernel knows
<NCommand1r>     lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
<ogra_> thats inside d-i ?
<NCommand1r> yeah
<ogra_> unbelivable ...
<ppisati> hw version?
<ogra_> does the kernel-image.udeb use some special config or some such ?
 * ogra_ doesnt get it ... eth0 should definitely be there 
<NCommand1r> ogra_: nope, its the same old vmlinuz
<ogra_> any trace in dmesg about smc ?
<NCommand1r> /lib/modules/2.6.38-1208-omap4/kernel/net # dmesg | grep smc
<NCommand1r> /lib/modules/2.6.38-1208-omap4/kernel/net #
<ogra_> well, "same old" ...
<ppisati> NCommand1r: do you heate zcat?
<ppisati> have
<ppisati> zcat /proc/config.gz | grep -i smsc
<ppisati> flag@omap:~$ zcat /proc/config.gz | grep -i smsc
<ppisati> CONFIG_SENSORS_SMSC47B397=m
<ppisati> CONFIG_SENSORS_SMSC47M1=m
<ppisati> CONFIG_SENSORS_SMSC47M192=m
<ppisati> CONFIG_SMSC911X=m
<ppisati> # CONFIG_SMSC911X_ARCH_HOOKS is not set
<ppisati> CONFIG_SMSC_PHY=m
<ppisati> # CONFIG_USB_NET_SMSC75XX is not set
<NCommand1r> ppisati: same
<ppisati> CONFIG_USB_NET_SMSC95XX=y
<ogra_> ppisati, ugh, that should definitely be disabled in paclkaged kernels
<ppisati> that's running config
<ppisati> ogra_: really?
<ppisati> NCommand1r: and you have it
<ogra_> ppisati, yes, by design we ship a text fuile with the config in /boot
<ogra_> s/design/default
<ppisati> at this point, if you have CONFIG_USB_NET_SMSC95XX=y then it could be a:
<ppisati> -different hw rev
<ppisati> -faulty hw?
<ppisati> because in the kernel boot you should have it
<ppisati> userspace is not involved
<ppisati> i mean, perhaps someone could "delete it" later but when the kernel bootas
<ppisati> should recognize/probe it
<rsalveti> sorry, what is the main issue here?
<ppisati> argument passed via boot.scr?
<ogra_> rsalveti, debina-installer
<ppisati> rsalveti: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/796892
<ubot2> Ubuntu bug 796892 in linux-ti-omap4 "OMAP4 kernel udebs don't include NIC drivers" [High,Confirmed]
<ogra_> unrealted to that problem the bug is ture though
<ogra_> there should be a ton of NIC drivers in the udeb for anything you can potentially attach via USB
<ogra_> but the actual problem doesnt seem to be udeb related
<NCommand1r> ogra_: its a panda shipped out of the box from davidm
<ppisati> NCommand1r: and you just got it?
<NCommand1r> two weeks ago
<rsalveti> ppisati: with just a uImage (without modules) can you get the interface?
<ppisati> rsalveti: if it's builtin i think so
<ppisati> rsalveti: i don't have any module loaded to get eth0
<ppisati> should be this one:
<ppisati> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
<ppisati> Device Descriptor: bLength                18 bDescriptorType         1 bcdUSB               2.00 bDeviceClass            9 Hub bDeviceSubClass         0 Unused bDeviceProtocol         2 TT per port bMaxPacketSize0        64 idVendor           0x0424 Standard Microsystems Corp. idProduct          0x9514  bcdDevice            2.00
<NCommand1r> ppisati: lets approach this another way, do you want to try booting the netboot installer image I'm using and see if you get ethernet?
<ppisati> ops
<ppisati> wait, pastebin
<ppisati> NCommand1r: yeah, give it to me
<NCommand1r> ppisati: http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/
<NCommand1r> I'm using boot.img-seiral
<ogra_> NCommand1r, did you ask colin already, probably we're overseeing something obvious
<ogra_> (though i couldnt imagine what)
<ppisati> NCommand1r: http://pastebin.ubuntu.com/626724/
<ppisati> NCommand1r: should be this one
<ogra_> bDeviceClass            9 Hub
<ogra_> ??
<ogra_> thats surely not the NIC
<ppisati> idProduct          0x9514
<ppisati> isn't it?
<NCommand1r> ppisati: I don't have lsusb in the installer enviornent
<ppisati> NCommand1r: ok
<ogra_> not sure, but there should be a wlan entry too
<ppisati> yep
<ppisati> NCommand1r: do i dd the image to a sd?
<ogra_> yes
<ppisati> ok
<ppisati> tty4?
<ppisati> anyway
<ogra_> could be tty3 ... its a while ago that i used d-i
<ppisati> how do i switch to it?
<ppisati> serial console
<ogra_> heh
<ogra_> screwed ... :P
<ppisati> anyway
<ppisati> it said "network auto configuration ok"
<ppisati> or something like that
<NCommand1r> ...
<NCommand1r> so its something with my panda
<NCommand1r> Great
<ogra_> heh
<ppisati> wait
<ppisati> execute a shell
<ogra_> ah
<ogra_> yeah, you can get one from the menu
<ppisati> ASD! :)
<ppisati> ~ # cat /proc/net/dev
<ppisati> Inter-|   Receive                                                |  Transmit
<ppisati>  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
<ppisati>     lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
<ppisati>   eth0:    4311      21    0    0    0     0          0         0     3030      25    0    0    0     0       0          0
<ogra_> aha
<ppisati> ~ #
<ppisati> different hw or faulty
<beagleboarduser> angstrom linux is supposed to work well with the beagleboard xM, right? How come it keeps freezing whenever I want to record audio in?
<ogra_> i guess rather new HW revision
<ppisati> could be
<ogra_> beagleboarduser, thats a question for Ã¤#
<ppisati> NCommand1r: can you find your hw revision/
<ppisati> ?
<ogra_> grrrmpf
<ogra_> beagleboarduser, thats a question for
<ogra_> #beagle
<beagleboarduser> whoa, didn't know that existed
 * ogra_ has days where he hates his kdb 
<beagleboarduser> ah, ok, i'll try that. also, ogra_, do you know whom I can ask for audio help in beagleboard?
<ogra_> or it hates me
 * ppisati -> shower and then concert+beer :)
<ppisati> later guys
<ogra_> beagleboarduser, not really, usually GrueMaster tries to attack audio probs, but he is travelling this week
<ogra_> ppisati, enjoy the concert !
<beagleboarduser> ah, ok. that's fine. thank you for the help though!
<NCommand1r> ppisati: how do I do that
<ogra_> NCommand1r, well, i'd start with inspecting /proc/cpuinfo ... then dmesg ...
<NCommand1r> Hardware        : OMAP4 Panda board
<NCommand1r> Revision        : 0020
<ogra_> A2 i guess
<NCommand1r> anyone else here have an A2 board that can test?
<ogra_> NCommand1r, probably ndec knows if there were USB related silicon changes between A1 and A2 ...
<ogra_> though prpplague might too
<NCommand1r> ^- ndec prpplague
 * ogra_ goes for dinner ... bye
 * prpplague looks in
<prpplague> ogra_: no changes to my knowledge
<prpplague> ogra_: i can verify that
<NCommand1r> does anyone else here have an A2 panda who can test?
 * prpplague reads back
<prpplague> what kind of issues are you finding?
<MrBIOS> what is the difference between ARMv6, ARMv6L and ARM6J ?
<persia> MrBIOS, Support for different instructions (none are supported in Ubuntu).
<MrBIOS> "none are supported in ubuntu" is a silly statement
<MrBIOS> the OS doesn't "support" instructions
<MrBIOS> I think what you mean is "ubuntu doesn't build armv6 optimized binaries, at present"
<MrBIOS> (including the kernel)
<persia> I mean that the instructions used in Ubuntu (including the kernel) cannot be executed on ARMv6 processors, that the default compiler settings enforce this, and that much of the porting effort has been done in Debian targeting ARMv5 or Ubuntu targeting ARMv7, with the result that complex build scripts may not even recognise the existence of ARMv6 for some packages.
<persia> Actually, Debian targets ARMv4, but I've seen a few v4/v5 things in packages imported from Debian and otherwise without changes.
<persia> Note also that the vast majority of packages are actually compiled to produce Thumb-2 code, which is a completely different ISA than the ARM* set (although it tends to be supported on hardware that supports ARMv7a)
<cipher> how do you control the default gpio exports so that you don't have to do echo "<gpio#>" to the export file each time
<cipher> do I have to write a kernel module to call gpio export at boot?
<phh> ?
<phh> like putting the echos rc.local ?
<phh> +in
<cipher> well I'm running into a race condition where I am putting it in rc.local but my app which runs in userspace doesn't see it
<cipher> and does /etc/modules get loaded before /etc/rc.local?
<phh> i'd guess so
<Gracana> How do kernel upgrades work in ubuntu arm? Is there anything special that needs to be done, or is it just a matter of having a boot partition mounted to allow Ubuntu to copy in a new kernel for u-boot?
<Gracana> FWIW, I have a beagleboard.
<persia> Gracana: WHen the kernel is updated, it will call flash-kernel to make the kernel bootable.  If you started with an Ubuntu image, and are just updating/installing, then it just updates for the next boot.
<persia> If you're booting from flash, or similar arrangements, the implementation in flash-kernel may not do what you expect.
<Gracana> Okay, interesting. The beagleboard has capabilities to boot from flash, but I can also boot from mmc, so I guess that is the way to go.
<persia> The distributed images boot from MMC by default.
<persia> This was considered easier to handle than attemtping to deal with unknown bootloaders in flash for a first-time install.
<persia> (mind you, if you have an interest, and want to find a way to try to detect how a given board was booted, and do the right thing, I'm sure others would appreciate the patches)
<Gracana> Hah, that would be very nice, but unfortunately I have other things to work on.
<persia> Heh :)  In that case, I recommend to boot from MMC.
<Gracana> Yeah, that sounds good to me.
#ubuntu-arm 2011-06-15
<aholler> hello, having read about the problem to build 20,000 packages for arm and the panda-cluster, I wonder if the ubuntu-devs ever tried or even heard about icecream? http://en.opensuse.org/Icecream
<ogra_> yes
<GrueMaster> aholler: Distribuited buildshave not been the issue.  The issue has been lack of hardware for native builds.
<aholler> using icecream you could use every x86 box
<aholler> to help you build your packages
<GrueMaster> How can anx86 build arm "native" packages?
<aholler> read about how icecream works
<GrueMaster> Not cross-compiled. Native.
<aholler> sure
<GrueMaster> x86 does not run arm instructions w/o emulation.
<aholler> read about how icecream works
<aholler> ogra_: do you have tried it?
<GrueMaster> After a quick glance, again I ask how this would have helped the lack of arm hardware issue we faced prior to our panda cluster?
<GrueMaster> btw:  I have worked on distribuited build environments before.
<ogra_> package builds are usually single threaded, that doesnt gain you much with most packages
<aholler> GrueMaster: you could use e.g. make -j20 and the compilation would be done by the x86-boxes
<aholler> but the tests would be done localy = native
<GrueMaster> Listen to what I am saying.  how does an x86 box compile native arm code w/o cross-compiling?
 * ppisati didn't read anything about "the problem to build 20,000 packages"
<GrueMaster> I spent 8 years in processor validation at Intel, and now work on arm code.  The instruction sets areentirely different.
<aholler> GrueMaster: again, read about how icecream works.
<aholler> nothing on your arm-box will see the difference
<aholler> there is cross-compiling and cross-compiling
<ogra_> the binaries will be built with a cross toolchain ...
<ogra_> thats the difference
<aholler> just the objects
<ogra_> you cant guarantee that you get identical binaries with a cross toolchain
<GrueMaster> We build all binary packages on their native hardware.  We do not rely on cross-compilation.
<aholler> GrueMaster: I assume you haven't understand how icecream works. anyway, I'm off, I don't see why I should try to continue this discussion
<GrueMaster> I know how icecream works.  I have talked with some of the devs when they started building it.
<ogra_> iirc NCommand1r used it across 4 babbages for OOo builds
<GrueMaster> No, he used distcc.
<ogra_> hmm, i thought it was icecream
<hrw> I love this kind of talks
<ogra_> hrw, you could have chimed in :)
<hrw> 'hey guys, why you are building natively? are you insane? cross compilation on farm of cheap x86 is better' etc...
<ogra_> as compiler expert
<suihkulokki> I guess the guy you chased away was trying suggest running the build on one arm machine which the calls icecream/distcc to x86 machines running crosscompilers
<ogra_> suihkulokki, yes
<ogra_> SuSE OBS ...
<suihkulokki> OBS dodn't due that
<ogra_> i thought they inject an x86 compiler into a native build env
<suihkulokki> you should invite the guy back if you are really intersted in how they do instead of rejecting them on sight ;)
<GrueMaster> I honestly don't see how ANY distributed environment would benefit anyone that needs native hardware and doesn't have it.
<ogra_> the distributed part only helps with packages using -jN
<GrueMaster> We could easily deploy icecream (or any other distributed build environment) on our cluster, but the issue was the lack of hardware.
<hrw> suihkulokki: like GrueMaster said - we lack native builds and this is a problem to solve
<hrw> xU with 120 a9 quadcores for example - I read on linuxdevices that someone is working on such beast
<GrueMaster> yep.  That would be a nice addition to my rack cabinet at home.  :P
 * ogra_ waits until he can buy that in a mac mini like case
<garagoth> GrueMaster: Hi. You and rsalveti have provided patched kernel for Beagle xM rev C. Is it possible to have it patched to support i2c bus 2, which is available on expansion port/
<garagoth> ?
<GrueMaster> garagoth: Have to ask rsalveti.  As soon as he provides me with a binary, I'll update the tarball.
<hrw> ogra_: btw - how much ac100 costs in .de?
<garagoth> GrueMaster: Ok, thanks.
<garagoth> rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ?
<ogra_> hrw, my last one costed me 170â¬ off the shelf
<hrw> 202EUR here
<ogra_> ppisati, http://hackaday.com/2011/06/12/how-canonical-automates-linux-package-compilation/ ...
<GrueMaster> ogra_: It was cheaper because of that funky keyboard.  :P
<ogra_> "Canonical needed a way to compile about 20,000+ packages for the ARM platform, however they did not want to cross-compile, which is quite time consuming."
 * ogra_ shakes his head
<ogra_> why would cross compiling be quite time consuming
<garagoth> on the contrary I would say...
<ogra_> heh, yeah
<ogra_> probably i'm reading it wrong though
<suihkulokki> there is no ubuntu-arm mailing list?
<hrw> bug 791302 needs someone familiar with library symbols?
<ubot2> Launchpad bug 791302 in libechonest "libechonest version 1.1.3-1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791302
<hrw> suihkulokki: no, ubuntu-mobile was dropped
<hrw> suihkulokki: ubuntu-devel is used
<suihkulokki> I shall spam ubuntu-devel then =)
<aholler> ok, I'll try it again.
<aholler> To enlight the people here about waht I'm speaking, using icecream only a part of the compilation process is distributed. And there is absolutely no problem when this part is a cross-compiler/-assembler. Thats a whole difference to what people usually are thinking about cross-compiling.
<aholler> And using icecream is much better than using distcc, because the building machine distributes the (cross-)compiler (as a chroot, once).
<aholler> what gets distributed is a tar-archive containing that stuff: http://www.fpaste.org/PyrG/
<hrw> aholler: does it takes care of mix of amd64/i386/armel/armhf build machines too?
<aholler> yes, the build-machine gets informed about the architecture of the slaves and can send them the needed chroot
<hrw> I think I will have to setup icecream farm of pandas here
<aholler> or just don't use them
<aholler> that even speeds up compiling using only -j1
<ogra_> aholler, as i said above, we wouldnt get much benefit from a distributed env, the majority of the packages will default to not use -jN
<hrw> aholler: I spent 6 years on cross compilation
<ogra_> there are some where it really helps, i agree
<ogra_> i.e. libO
<aholler> hrw: fine for you
<ogra_> or firefox ... but the majority wont really benefit from it... for us its more important to build as many *differnt packages* at the same time as possible
<aholler> most packages could be build using -jN, at least when ext4 is used.
<ogra_> the target of the build cluster is to empty the queue as fast as possible to keep up with the other arches, so "more paralell builds" > "faster builds"
<aholler> with ext3 there are more problems, because of the limited timestamp
<aholler> a single source is still compiled a lot faster on x86 (+network transfer) than on an arm
<ogra_> it would be good to have a fully native icecream setup on another panda cluster though and route the packages that can benefit from it to that build system
<ogra_> we definitely wouldnt use it with a cross compiler
<GrueMaster> Actually, if icecream can manage client build systems appearing on the fly, it could easily be deployed now on our panda cluster.
<ogra_> but the concept could indeed help with native compilers too ...
<aholler> do you expect a different output from a cross-assembler than native?
<ogra_> the possibility exists
<GrueMaster> aholler: Yes, and we have actual documented bugs with that.
<aholler> don't mix that concept icecream/distcc uses which the stuff people usually are understanding with cross-compiling
<aholler> s/which/with/
<aholler> anyway, it is just a suggestion, I don't need to convince the people here.
<ogra_> well, i like the concept of distributed building ...
<aholler> ditributed cross- is even better
<ogra_> thats something i would not agree on :)
 * ppisati -> out to get some food
<aholler> I've used that a lot to build x32packages on x64-machines (and vice-versa) several years before
<aholler> no, wrong, the other machines helped building the packes, they haven't build them
<aholler> anyway, maybe one of you might try it. I'm off again. ;)
<GrueMaster> we use x86_64 machines to build i386 packages all the time.  That isnt an issue.
<ogra_> he's gone
<hrw> hm. how to call shell in perl and get return as value of variable?
<GrueMaster> hrw:  give me a minute and I'll pastebin a sample ofcode I wrote while at Intel.
<hrw> $var = `command`; ;)
<ogra_> thats as clever as using system() :P
<hrw> with system I have to play with $? etc to get result
<hrw> looks like gnu-smalltalk will be fixed
<hrw> not that I know perl but fix was needed in perl script
<GrueMaster> hrw: Looks like you have it.
<hrw>     my $multiarch_dir = `dpkg-architecture -qDEB_HOST_MULTIARCH`;
<hrw>     chomp($multiarch_dir);
<hrw> and then one more check in script
<hrw> ok. passed step where it was failing
<hrw> now time for debdiff
<persia> hrw, Why not "use Dpkg:Arch ..."?  That should save considerable cycles.
<persia> (if you just care about multiarch, then "use Dpkg:Arch qw(debarch_to_multiarch);" is probably sufficient)
<hrw> persia: because I do not know perl?
<hrw> persia: so I am trying to get some hack which works and then it can get improved
<persia> hrw, Heh.  So, take a look at the dpkg-architecture source.
<persia> It's fairly trivial to just pull the value from the libary (and we have a nice code example)
<hrw> thx
<persia> Around line 196 is the bits you'll need, although you'll also  need the use statement near the top.
<hrw> my $multiarch_dir = debarch_to_multiarch(get_raw_host_arch());
<persia> That looks cleaner to me.  Does it work?
<persia> Also, how is get_raw_host_arch() implemented?  Is this something you could also pull from the library?
<hrw> both are from Dpkg::Arch
<hrw> I picked code from dpkg-architecture
<persia> Ah, heh.  That sounds ideal then, if it works :)
<hrw> persia: build in process
<persia> Just be sure to specify both in the use statement, so they are available.
<hrw> did
<persia> Perfect :)
<hrw> persia: thanks for tips
<persia> No problem.  Thanks for asking for help on the channel *before* you found the final solution.
<hrw> persia: as I'm not perl programmer I prefer to make sure that my thinking is right.
<hrw> persia: and my workflow for bugs is: make a fix and then make a fix to be a proper fix
<persia> Makes sense.  I tend to try for a precise problem statement, then a proper fix (which is nearly the same thing, except that I tend to express the problem in English rather than code).
<hrw> persia: first ver of fix was good but implementation was bad ;D
<persia> Not bad, just didn't take advantage of the fact that dpkg-architecture was itself implemented in perl, with a handy library.
<persia> Was dpkg-architecture in C, then I think your implementation would have been the least bad.
<persia> (assuming nobody had created perl bindings for the library)
<rsalveti> ppisati: ogra_: GrueMaster: http://comments.gmane.org/gmane.linux.redhat.fedora.arm/1266
<rsalveti> pointed by agreen, if we want to have a better buildd this would be something to look for
<garagoth> rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ?
<rsalveti> garagoth: sure, sorry, just got on-line
<rsalveti> garagoth: what exactly do you need?
<garagoth> I have trainer board from tin can tools attached to beagle xm C and I need to use i2c which is there.
<garagoth> It is nice as it is level translated to 5V
<garagoth> it is i2c bus 2
<garagoth> but on your kenel only buses 1 and 3 are visible
<rsalveti> garagoth: oh, ok, guess it's the patch pointed by rcn-ee
<garagoth> I hope so :-) I had no sources of your kernel, so could not test it myself.
<GrueMaster> rsalveti: I had seen a blurb on the pandaboard mailing list regarding usb drive speed & networkiing.  When I get home I mean to do some additional testing, including using a usb-nic (not the on-board nic) to see if that makes a difference.
<rsalveti> garagoth: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary if you get the HEAD you'll get the same working kernel
<rsalveti> 10.44
<rsalveti> garagoth: if you build this kernel and add the patch https://github.com/RobertCNelson/stable-kernel/blob/master/patches/sakoman/2.6.39/0032-OMAP3-beagle-add-support-for-expansionboards.patch it may work
<rsalveti> didn't check if you need any other dependencies
<garagoth> rsalveti: So, build it myself or will you be doing it anyway?
<rsalveti> garagoth: I can guide you if you want, then you can hack it later if needed ;-)
<ogra_> rsalveti, what exactly do you suggest ? rinning a ping daemon ?
<ogra_> *running
<rsalveti> ogra_: well, agreen is investigating the kernel to see if we can get a fix
<garagoth> Would be nice. I need to setup cross-compile env for ubuntu then... somehow :-) Or compile on Beagle
<rsalveti> but would be good to keep an eye on it
<rsalveti> garagoth: http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives
<garagoth> rsalveti: Ok, processing...
<garagoth> I guess you are cross-compiling?
<ppisati> rsalveti: weird
<rsalveti> garagoth: yes
<rsalveti> ppisati: why? same chip for both usb and eth :-)
<persia> I like the FIFO queue not overflowing answer.  It's more plausible than most of the other proposed "why"s.
<ogra_> well, the ignore_oc stuff seems like a red herring to me
<persia> I'd say so.
<persia> But that's different than the queue management.
<zumbi_> persia: can i have unity on pandaboard?
<zumbi_> (on natty I mean)
<persia> zumbi_, You can have unity-2d.  I don't believe everything was ported to work properly with the GLES drivers TI provided.
<persia> (someone please correct me if I'm wrong).
<zumbi_> so unity-3d not yet ready on arm hw :/
<zumbi_> persia: thanks
<ogra_> zumbi_, in th enext weeks
<zumbi_> ogra_: sure, I guess as part of oneiric
<ogra_> there are two bugs left afaik ... once these are solved it should be available for natty
<ogra_> later then oneiric
<ogra_> (all work is done on the natty branches atm and will need forward porting then)
<persia> ogra_, This is GLES porting?
<ogra_> yes
<zumbi_> uhm.. ok, sounds fine, I'll try it on few weeks then
<ogra_> for compiz, nux and unity
<ogra_> zumbi_, rsalveti should be able to point you to a PPA for that
<persia> zumbi_, What's your specific interest?  The interface, or reviewing the code paths?
<ogra_> (beyond that they should show up in the natty release PPA for panda)
<persia> If the former, then unity-2d is supposed to be mostly the same (although some things are different)
<persia> If the latter, I'm sure folk would appreciate additional testing/help with the remaining few bugs.
<rsalveti> zumbi_: https://launchpad.net/~rsalveti/+archive/unity-3d-gles
<persia> ogra_, Do you happen to know the bug numbers?
<rsalveti> zumbi_: not fully working yet
<zumbi_> persia: right now, my interest is have a technology preview, we are currently using Qt for UI design
<zumbi_> rsalveti: thanks
<rsalveti> but you should be able to try it in the following days
<ogra_> persia, for what ?
<persia> zumbi_, unity-2d is implemented in Qt, so yeah, that doesn't necessarily show anything particularly different.
<persia> ogra_, The compiz/nux/unity bugs.
<ogra_> i dont think there are bugs
 * persia grumbles
<persia> When "there are two bugs left", those should be filed in launchpad, and discussion happen there.
<ogra_> there is a team working fulltime on fixing them though :)
<persia> And the team doesn't want another member, for some reason?
<ogra_> and they report to places i am
<ogra_> ask linaro :)
<ogra_> i guess they wont deny if someone wants to help indeed
<persia> rsalveti, Are there bugs?  What sort of help could speed the process?
<rsalveti> persia: https://bugs.launchpad.net/unity-gles
<persia> Only one left!
<persia> zumbi_, ^^
<ogra_> i thought there was one nux bug too
<ogra_> but seems that got fixed already
 * jussi prods at persia
<rsalveti> we just discussed at the call and we may have an additional bug for nux
<rsalveti> but still not confirmed
<rsalveti> but it should all be sorted out during this and next week
<ogra_> the screenshots look cool though
<ogra_> you should leave it that way and call it unidelic instead of unity :)
<rsalveti> ogra_: hehe :-)
<rsalveti> and another porting jam just starting at #linaro! come and help us making ubuntu better on arm :-)
<rsalveti> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby=-id
<ogra_> GrueMaster, soo, your ac100 ... did you actually test if the issues also show up if you manually untar the rootfs ?
<GrueMaster> I have put it back on the back burner.  Need to be productive on current tasks.
<ogra_> k
<ogra_> well, i cant do much until we have identified the actual problem
<ogra_> make sure to definitely bring it to dublin
<GrueMaster> I plan on it.
<ogra_> will surely be faster to find the issue if i have direct access
<GrueMaster> Not sure what the final goal is.  If it is just to get me enabled with an ac100, I'll do it as time allows.  If we plan on deploying a working installation for other users, it makes sense to debug it and I can add it to the test pool as time allows.
<ogra_> well, i want the installer to work properly on all models indeed
<ppisati> seems we are not the only one experiencing issue with usb and gcc 4.6:
<ppisati> https://lists.yoctoproject.org/pipermail/poky/2011-April/005703.html
<ppisati> the thread continues in may 2011 too
<ppisati> https://lists.yoctoproject.org/pipermail/poky/2011-May/005763.html
<garagoth> rsalveti: Ok, more or less the patch succeeded. Is git clone of the kernel source already with proper config, same as it is on beagle?
<brendand> fully updated 11.04 running on a pandaboard, when i try to boot it i get things like
<brendand> (stk) : line disc installation timed out
<brendand> (stc) : KIM failure complete callback
<GrueMaster> that is the bluetooth driver.  known issue.
<brendand> ah - i just needed to wait long enough
<brendand> never saw that before, is it an update-regression?
<ppisati> and it seems there's a fix... testing...
<GrueMaster> Yes and no.  It didn't happen in maverick as the driver was rewritten and hasn't been finalized at time of release.
<hrw> what is a proper way to request arm rebuild of package?
<hrw> octave-communications 1.0.10-3 was ftbfs on armel 7 weeks ago due to lack of build deps. now they are fulfilled
<ogra_> one sec
<hrw> I am building this package on panda now
<hrw> it was bug 791314 btw
<ubot2> Launchpad bug 791314 in octave-communications "octave-communications version 1.0.10-3 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791314
<ogra_> rebuild triggered
<hrw> thx
<ogra_> https://launchpad.net/ubuntu/+source/octave-communications/1.0.10-3/+build/2469824
<hrw> I just loaded that
<GrueMaster> ppisati: The thread continues in June as well.
<ogra_> yeah
<ogra_> differently named though
<ogra_> https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html is very intresting
<ppisati> and there's a fix
<ppisati> wait...
<ogra_> ppisati, https://lists.yoctoproject.org/pipermail/poky/2011-June/006646.html this one ?
<ppisati> yep
<ppisati> but it seems it's not working :(
<ogra_> well, they later say you should just remove the line completely
<ppisati> let's try...
<ppisati> nope
<ppisati> anyway, let me forward this info the toolchain people
<ogra_> yeah
<ogra_> a disassembly like that from our own binaries might help too i guess
<ppisati> yep
<ppisati> in the April they were saying they had this issue with the vanilla FSF 4.6 toolchain so it seems it's an upstream bug
<ogra_> could be
<ppisati> ok, mail sent
<ppisati> let me update the lp bug too
<ogra_> ++
<garagoth> I'm trying to compile ubuntu kernel for Beagle, but process fails with error: "as: unrecognized option '-Qy'"
<garagoth> Any hints?
<hrw> which ubuntu?
<hrw> and do you have binutils-arm-linux-gnueabi installed?
<garagoth> natty
<garagoth> and yes, I have
<garagoth> so...?
<garagoth> rsalveti: ping
<melis51> hi, anyone knows the uname+pwd for ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz, thx
<ogra_> there is none
<ogra_> you set it up during the first boot
<garagoth> during install you setup your user
<melis51> this is a pre-installed image
<garagoth> pre-installed image which install itself
<garagoth> at least should...
<ogra_> yes
<garagoth> you boot it, it should show you installer
<garagoth> you select lang, keyboard, packages, user
<melis51> the first thing I see is a log-in screen
<melis51> the only option is to click 'other' user
<garagoth> on dvi port?
<melis51> yes
<garagoth> is it ubuntu branded?
<melis51> yes, and this is where I downloaded from: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz
<GrueMaster> melis51: What platform are you using?
<melis51> Beagleboard
<GrueMaster> What rev?
<melis51> c3
<GrueMaster> Odd, although you may be running out of memory.  I don't remember an issue testing on my C4 though.
<garagoth> on bb-xM rev C I saw setup screen on X
<ogra_> try the headless image instaed and then install ubuntu-netbook using tasksel
<GrueMaster> When you boot, is it pulling anything from nand, or is it booting completely off the SD?  You can tell by watching the serial console.
<ogra_> oh, right, NAND !
 * ogra_ totally forgot 
<GrueMaster> ogra_: That's why you keep me around. :P
<ogra_> indeed, it might not pull the right initrd in
<ogra_> GrueMaster, yeah, we all love you :)
<melis51> I can't tell right now, but will check
<lag> Do the ARM PPAs build naively?
<ogra_> melis51, there are instructions on the wiki how to make sure to boot right
<ogra_> lag, yes, thats why they arent public
<lag> ogra_: All of them? Even my own PPA?
<ogra_> only trusted people have upload permission
<GrueMaster> melis51: Check the Maverick instructions.  They have more detail on the beagleboard w/ nand.
<ogra_> indeed you can make the binaries public
<melis51> ora_ I fallowed GrueMaster's instructions on the wiki that worked up until the log-in screen
<lag> ogra_: Let me try to explain
 * GrueMaster updates the instructions for natty.
<melis51> ok I will try Maverick, but would be nice to get the latest ver to work too
<ogra_> you dont need to try maverick
<ogra_> only the maverick instructions for booting begales with NAND on them
<melis51> ok
<garagoth> Maybe someone can help me with cross-compiling to beagle on natty? I have "as: unrecognized option '-Qy'"
<ogra_> garagoth, well, hrw is your best option ... beyond that, file a bug against the cross toolchain
<GrueMaster> melis51: You can use natty, just follow the maverick instructions specific to the beagleboard rev C.
<GrueMaster> Natty Instructions updated to include these now.
<hrw> garagoth: fill a bug with exact info what you are doing ok?
<melis51> ok thanks I'll try
<garagoth> hrw: ubuntu-bug or ..?
<hrw> garagoth: ubuntu-bug armel-cross-toolchain-base
<hrw> garagoth: add "arm-linux-gnueabi-gcc --version" into bug raport
<garagoth> Ok.
<lag> ogra_: http://ppa.launchpad.net/linaro-landing-team-ste/st-ericsson-u8500-public/ubuntu/pool/main/l/linux-u8500/
<lag> Would that have been build natively
<ogra_> lag, yes
<lag> ogra_: Great, thanks!
<ogra_> we dont so any non native builds in the datacenter
<melis51> thanks everyone for your help!
<ogra_> s/so/do/
<garagoth> hrw: it says: no such package: armel-cross-toolchain-base
<GrueMaster> melis51: got it working?
<hrw> garagoth: so use binutils-arm-linux-gnueabi one
<hrw> garagoth: armel-cross-toolchain-base is source package
<melis51> I'm not at home, so I will try it a bit later today and will let you know, thanks
<garagoth> hrw: Hm, can it be because I have no arm-linux-gnueabi-gcc? It is in package gcc-4.4-arm-linux-gnueabi, but I have gcc-4.5-arm-linux-gnueabi which install /usr/bin//usr/bin/arm-linux-gnueabi-gcc-4.5
<garagoth> and there is no symlink or anything to arm-linux-gnueabi-gcc
<hrw> garagoth: apt-get install gcc-arm-linux-gnueabi then
<hrw> ok, time to finish session for me
<hrw> have a nice rest of day
<garagoth> Oooh. I removed from PATH /usr/arm-linux-gnueabi/bin and it started working
<hrw> ARGH YOU! :D
<garagoth> Yes, I create errors. But without your hint I would never find it.
<garagoth> I was missing one package
<garagoth> So, thanks a lot and have a nice day as well :-)
 * garagoth crossess fingers to make it compile.
<garagoth> If I do not click 'Submit bug report' on web page, it is not visible to anyone, right?
<zul> persia: heya im working on a fix for libvirt on arm fyi
<jkridner> excuse the FAQs, but is there an LTS release for ARM yet and will there be an armv7 Ubuntu release?
<jkridner> my googling is returning misleading info.
<GrueMaster> jkridner: 12.04 will be thefirst LTS release for arm.  Armv7 has been supported since 10.04
<GrueMaster> (but 10.04 was not LTS for arm).
<jkridner> thanks!
<jkridner> I think 10.04 was armel, compatible with armv7, but not optimized for armv7.
<GrueMaster> It was the first armv7 release.
<infinity> Our armel port has been armv7 for a while.
<infinity> Don't confuse the dpkg arch name with the compiler target.
<infinity> (Much like our i386 port won't actually run on 80386 machines)
<GrueMaster> True, not all packages were built with full armv7 optimizations, but main was.
<zumbi> ogra_: there?
<zumbi> someone know if ubuntu still needs mx51 or omap4 subarches on debian core, more specifically debian-installer
<zumbi> lool: ^
<melis51> GrueMaster: hi, I changed the setenv as you suggested, but ubuntu won't boot on my beagle
<garagoth> rsalveti: ping
<garagoth> Hm. I am trying to compile ubuntu kernel with expansion boards support and I have encountered a problem. Some boards have irq_set_irq_type(...) invoked but it is nowwhere defined
<garagoth> google claims it to be a standard interrupt api function...
<garagoth> hm, it is there named set_irq_type, not irq_set_irg_type... confusing...
<rcn-ee_at_work> garagoth, that got changed in 2.6.39...
<rcn-ee_at_work> garagoth, 2.6.38 and earlier used "set_irq_type", 2.6.39+ uses "irq_set_irq_type"
<garagoth> damn. One small revision number...
<garagoth> I'm sooo close to make it work, damn...
<garagoth> So much trouble to have i2c bus 2 working ;-)
<rcn-ee_at_work> well the simplistic patch would just to add: "omap_register_i2c_bus(2, 400, NULL, 0);"  in the i2c section... but i thought you had a trainer board..
<garagoth> yes
<garagoth> I have
<rcn-ee_at_work> well, the big patch set's everything up for the trainer.. (and more..)
<garagoth> and I found usage for gpio, so I need more then i2c, so patching...
<garagoth> back to soldering while kernel continues to compile...
<persia> zumbi, Support for mx5 and omap4 continues to be useful :)
<zumbi> persia: thanks, you mean mx51?, I realized that reading omappedia.org
#ubuntu-arm 2011-06-16
<zumbi> persia: someone wanted to do some omap4 cleanup on d-i
<persia> I think I mean "mx5".  I've heard folk say that the same code supports the i.MX51 and the i.MX53, and that someone was calling that mx5 while adding support in Debian.
<zumbi> debian is likely enabling omap subarch
<zumbi> persia: yes, that someone was me
<persia> Will Debian "omap" support omap3 and omap4?
<zumbi> mx51 and mx53 are not yet compatible
<persia> Heh.  Then you know what string I need more than I :)
<zumbi> yes, omap in debian will be for omap3 and omap4
<persia> They aren't?  I thought linaro had a kernel that worked on both.
<zumbi> persia: is not about what I need, I am trying not to break your stuff
<persia> If "omap" in Debian is for both omap3 and omap4, then it makes sense for Ubuntu to carry "omap4" is a patch, for as long as it continues to be required.
<zumbi> as someone submitted a patch which removed omap4 from libdebian-installer
<persia> As long as we know about it, it oughtn't be a disaster.
<zumbi> persia: ok - but there are old trees with omap4 and documentation all over teh place
<persia> NCommander, Are you about?  Would you have time to review this with zumbi to figure out what makes sense as an Ubuntu patch?
<zumbi> persia: this was the thread triggering this question.. http://lists.debian.org/debian-boot/2011/06/msg00184.html
<persia> Ah, and now it all makes sense.
<persia> Yeah, it's probably better to leave "omap4" and "imx51" in the reserved list for now, as this makes the Ubuntu patching easier (reassinging some boards,etc.).
<zumbi> yes, that was what I thought
<zumbi> we'll see how we end up with mx51 and mx53
<persia> What's outstanding there?  A merged kernel, or something larger?
<zumbi> persia: is it just an offset issue
<zumbi> at boot time
<persia> Hrm.  That confuses me.  I've been told that folks with both Efika smartbooks (mx51) and Quickstarts (mx53) are booting with the linaro kernel.
<persia> I thought that was the same kernel.
<zumbi> http://lists.debian.org/debian-arm/2011/04/msg00067.html
<persia> apachelogger, What's your `uname -a` output?
<zumbi> persia: well, maybe it has been fixed
<zumbi> that issue was raised back in april
<zumbi> I have not tested mx53 stuff yet
<persia> Uwe also seems to be talking about mainline, and I suspect Linaro's Freescale Landing Team has a number of patches in the pipeline.
<zumbi> persia: yes, Uwe is mainline.. but certainly if that is in Linaro eventually it'll get into mainline
<persia> Sometimes the patches need a fair bit of rewriting :)
<zumbi> if it is not there yet... I need to update myself
<persia> (but yeah, it's heaps better than the old abandoned vendor trees)
<zumbi> well, there is not much involved into have mx53 and mx51 in one kernel
<zumbi> we really hoping for unified kernel
<persia> I think there is one.  Unfortunately, jcrigby, who'd know for sure, seems to be away from IRC this week.
<persia> Unfortunately, my git-fu isn't up to finding shortlog difference between trees sufficiently to distinguish which patches may have been applied to achieve this.
<zumbi> well, that's upstream call I suspect
<persia> Heh, well.  Depends on your feeling towards distro-patches :)  I suspect that for Ubuntu we'll be telling base-installer to use the linaro kernels (since they regularly get uploaded into the archive).  I'm not convinced Debian wants N kernel source packages, which makes it much harder to do without upstream support.
<zumbi> persia: debian kernel team sticks to upstream/mainline
<persia> Sensibly :)
<zumbi> and they have a policy of only backporting patches which have been accepted into mainline HEAD
<persia> Ubuntu kernel team does the same (mostly), but there are something like 6 kernel source packages in Ubuntu, of which only one is managed by that team.
<zumbi> unless it is a bugfix
<persia> For Ubuntu, even bugfixes get asked if they are upstream (although I suspect some that aren't yet get applied)
<zumbi> well, it becomes insane if you do it other way, you need an upstream to distribute
<zumbi> Debian distributes GNU
<zumbi> free and open stuff
<zumbi> Ubuntu is more into commercial world, I want it to work even if it is not open/free
<zumbi> I mean Ubuntu besides being driven by business, it also does not comply to Debian free and open source guidelines...
<persia> It's not about free/non-free and it's not about money.
<zumbi> in a sense Debian is freedom taliban
<zumbi> persia: I was not trying to be annoying that was just my point of view
<persia> All the extra kernels in the archive are GPLv2-only, and some of them are uploaded by people I know not to be receiving any compensation for doing so.
<persia> I agree that having a single upstream is *lots* easier to manage, and generally cleaner.
<zumbi> well, you really do not want to carry 6 different kernels for x86
<zumbi> then dealing with bug reports is insane
<persia> They have 6 different source packages.
<persia> (but I think we only have 2 source packages for x86)
<persia> And different binary package names
<zumbi> when talking about free/non-free, I was thinking on ti-sgx 3D drivers, nvidia stuff, etc...
<persia> I don't believe any of that is in Ubuntu.
<zumbi> and surely there is community around Ubuntu
<persia> TI has a PPA in which they distribute some stuff.
<persia> I don't think nVidia has one.
<zumbi> uhm.. I might be wrong
<zumbi> persia: but then why fork Debian and not work with it?
<persia> I wasn't involved in that decision.
<persia> At the time, I was following Debian mailing lists, and had the impression that there was a desire to do ~1000 NMUs, which were considered to be unfreindly at the time.
<persia> I believe the fork comes from the desire to be able to upload things *without* considering whether it's NMU, and the desire to release every six months (Ubuntu was announced around the time that sarge was looking like it would never release)
<persia> I think many Ubuntu Developers, especially most of those who have been around a while, do also work in Debian in one way or another.
<persia> I'm not sure it's fair to say "and not work with it"
<zumbi> persia: yes, that's for sure
<zumbi> persia: well in a way we use debian tweaked for our needs at work
<persia> Now, since 2005 NMUs in Debian have transitioned from being an injury to being a help to other maintainres, there's lots more team maintainership, the DAM lock that nobody understood is gone, etc.
<zumbi> we got some extra packages in internal repo
<persia> So lots of the initial rationales for Ubuntu would probably be considered differently if considered today.
<persia> But at this point, deciding to not have Ubuntu gets messy and complicated: too many people have too much invested in continued existence.
<persia> As some of the first changes in Ubuntu were toolchain patches, which required rebuilding all the rdepends, I don't think "extra packages in a third-party repo" would ever have worked.
<persia> Ubuntu continues to be a testing ground for new toolchains in Debian, which I think benefits Debian in terms of patches available for FTBFS at least as much as it benefits Ubuntu in terms of tighter optimisations.
<zumbi> persia: I agree
<zumbi> surely one is testbed of the other
<persia> Mind you, there's been *lots* of argument about this, from lots of directions in the past.  There have been some periods where cooperation was weak.
<zumbi> yes, lots of flames
<micahg> some of the toolchain diffs (hardening defaults) were brought up at UDS in the Debian health check session
<persia> But I very much hope that more teams follow the example of the Mono/CLI team, where a common set of folk have upload rights to both distributions, tend to do most of their stuff in Debian (except where variation is required to comply with other variation), and everyone stays (mostly) happy.
<zumbi> persia: some DD are annoyed to not be able to upload to ubuntu
<zumbi> and find some packages are not in sync
<persia> zumbi, Sure, but some DD *can* upload to Ubuntu.  There's more than a few that have requested (and been granted) upload rights for the stuff they maintain.
<zumbi> DEX is great opportunity to improve cooperation
<zumbi> persia: I did not know about that.. in any case I am not against any
<persia> Those DDs who are annoyed to not be able to upload should demonstrate they are watching LP bugs, and apply to get upload.
<persia> On the other hand, some DD complain and say that Ubuntu should sync their latest upload all the time: in several cases this has broken chunks of the archive that go beyond that specific package late in the release cycle.
<persia> This is especially common when Debian is just coming out of freeze while Ubuntu is entering freeze.
<persia> And some DDs don't bother to test whether their new uploads even build under Ubuntu (but still insist on sync)
<zumbi> yes, slightly similar, but not same
<persia> Luckily, those are the extreme minority, but it's fear of that sort that leads to the process of requiring folk to apply and demonstrate they do care about Ubuntu (which has been described as overly bureaucratic by some)
<zumbi> I think there is material to write a book
<persia> Several :)
<zumbi> well, I think the base system is well built but either debian and ubuntu developers
<zumbi> I have lots of friends that are working or have worked for canonical
<persia> There's lots of Ubuntu Developers that don't work for Canonical as well (although, to be honest, we've not been as good at recuiting new developers lately, and Canonical has hired a lot of folk, so I'm not sure whether Canonical employs a majority currently)
<zumbi> It is quite amazing how all that is structured
<zumbi> it is hard to understand properly :)
<zumbi> I am not sure I got contributions to ubuntu, but at least if I fix something in debian I ping the packages in ubuntu, so they can check
<zumbi> and I have even signed the ubuntu code of conduct
<persia> What's your LP account?
<zumbi> but not sure how can i help ubuntu, I try to keep debian alive at least on embedded arches which have been in my interest since the beginning
<zumbi> persia: my nickname
<persia> You've not been granted specific credit for any patches in Ubuntu (although I know you've been helping folk for a long time).
<zumbi> I do not maintain much packages in debian, but fixed tslib driver for X.org in debian and pinged the bugreport in ubuntu
<zumbi> well, not helping, really is cooperation
<persia> Sure: I tend to think of cooperation as "folk helping each other" :)
<persia> If your patches are getting applied in Debian smoothly, and flowing to Ubuntu well enough that you're comfortable, I'd say you have nothing to worry about.
<persia> If you want to deploy patches that aren't being accepted, or there are issues with getting stuff into Ubuntu that you want to fix, then it may make sense to prepare debdiffs for bugfixes and send them to Ubuntu bugs for application.
<persia> But it all depends on your personal motivations, and whether you have any desire to identify as an "Ubuntu Developer".
<zumbi> I see
<zumbi> well, I don't care.. I would like to close LP#1 :)
<zumbi> I think that was that one bug Mark wrote time ago
<persia> That's getting very close to closed, unfortunately not from our work (iOS, Android)
<zumbi> sadly, yes
<zumbi> but still .. they are around
<persia> Oh, indeed.  And lots of the Android work ends up being directly useful to us.
<zumbi> later moves with Nokia were not good
<zumbi> I am still waiting for the ubuntu-phone
<persia> I keep hearing good things from Nokia, although for stuff that isn't phones.  I'm not yet ready to have an opinion.
<persia> I believe Kubuntu Mobile has a working dialer and some baseband support.
<zumbi> persia: no, you need to ship actual devices, not expect people to fit that into a mobile
<zumbi> pre-installed ubuntu phones
<persia> Yeah, well.  All we can do is build it, and hope they come.
<zumbi> well, you need to contact manufacturers
<persia> Sure, some of us, as individuals, can go talk to ODMs, etc., but at that point I'm not sure that it's still part of the wider "we".
<persia> I'm not convinced that it's yet possible to deliver a product with turnkey free software.
<zumbi> HTC has recently open the bootloader
<zumbi> to make their devices more hackable
<persia> If we can reach that point, where it just works, and can usefully be installed on nearly any phone, then it becomes a relatively safe option for someone to release a phone based on that stack (rather than requiring in-house development effort)
<zumbi> not open as in source, but open as in access
<persia> Given the number of tablets and handhelds released with Ubuntu Jaunty when the ARM port first became available, I would expect several devices to appear shortly after it was known to work.
<zumbi> we build a lightwriter for disabled people, not only helps them to speak up but it also works as a phone
<persia> (mind you, most of this was not available outside the Chinese market, but that's the hot location for early adoption in consumer electronics: everywhere else folk are very conservative)
<zumbi> yes, the Chinese just go for it..
<zumbi> I know Anthony Fok and Paul Liu
<zumbi> great developers
<persia> Right.  There's lots of cool stuff to do.  I believe that we (being developers) need to focus on making sure that our software stack works, is easily adapted to a wide variety of hardware, and is widely available at no cost (free code is something we care about.  free beer is something the manufacturers care about)
<persia> Whereas we (being the free software community) need to encourage or develop entrepreneurs who will take these things to retail devices.
<zumbi> Yes, I have thought many times to develop some hardware and use free software to develop retail devices
<zumbi> but all of it is complex
<persia> It's no more complex than software :)  It's just different.  There are very few folk who can do both.
<zumbi> getting parts sorted
<zumbi> MOQs
<persia> Oh yeah.
<persia> Anyway, getting late in the morning for me, and I must run.  Have a good evening.
<zumbi> hardware is .. don't know how to describe.. hardware to be ready for production is just tough
<zumbi> persia: sure.. bye
<zumbi> persia: just one more thing, linux is the testbed of new processors which tomorrow (years away) will be part of products, besides mobile world which it changes so fast
<persia> I wish it was that simple.
<persia> Lots of the things that get tested (much of which goes mainline) ends up being PoC to drive design wins, which end up with derivations for production deployment.
<persia> Even with many of the SoC vendors collaborating within Linaro to help make BSPs be mostly upstream(able) code, I suspect there remain cultural barriers to having vendor devices mainline enabled.
<persia> (with the exception of a few bright spots, where vendors are very cooperative)
<persia> In many ways, I welcome Windows 8 to the game: it helps the conversations about having hardware be a base platform on which arbitrary software is delivered.
<zumbi> yes, it'll bring all the fun on how broken it is
<persia> At least with more things reaching mainline these days, the SoC vendors haven't dropped support for recent kernels before the devices ever reach retail.
<zumbi> omap is keeping up with community very well
<persia> I don't care about the actual operation of Windows 8: the reasons I am unlikely to use it have nothing to do with what it does or who makes it.
<persia> I care more about how the presence of multiple operating system choices for a given platform provide incentives for board manufacturers to have known working generic solutions.
<persia> TI does good.  I like TI.  I'm not happy with how bootstrapping works: it still requires omap-specific code.
<zumbi> it is already happening due to android, linux duality
<persia> From what I understand, this is a ROM issue with ROM inside the SoC, which can't be fixed until OMAP6 or OMAP7.
<persia> Android and Linux are almost identical code (ignoring userspace).
<persia> As a result, the *same* set of enablement patches is likely to work for both.
<zumbi> yes, omap has a ROM which calls x-loader, u-boot, etc...
<persia> The nice thing about Windows 8 is that the Android/Linux patches *will not apply*, which means thinking about generics at a design level.
<persia> Anyway, I'm getting very late :)  It's always fun chatting with you, but ...
<zumbi> omap ROM code loads x-winloader which loads winkernel
<zumbi> persia: sure, later .. :)
<ogra_> zumbi, to answer yesterdays question, imx51 was just removed in ubuntu in favor of mx5, omap4 is one of our supported arches so needs to stay
<ogra_> IMAGES !!!!
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/20110616/
<ogra_> yipiee
<ogra_> hmm, nearly 1G
<zumbi> ogra_: what's the difference between omap and omap4?
<zumbi> in the cdimage build
<ogra_> omap4 has a special kernel package
<ogra_> and special boot options
<ogra_> for omap4 we also provide additional packages that make it easy to enable the TI
<ogra_> PPA
<ogra_> which holds the sgx drivers and HD video codecs etc
<zumbi> I see.. thanks
<ogra_> the prob is, while you can have a jiont kernel packqage for all omap arches, you still need a separate binary bootloaders and cmdline options atm
<ogra_> -s
<zumbi> ogra_: part of that can probably be solved with boot scripts
<ogra_> not really
<ogra_> TI initializes half the HW in their bootloaders instead of the kernel ...
<ogra_> if you would have x-loader and u-boot binaries that support all omap arches and only switch through boot scripts, you would end up with huge binaries
<ogra_> and i even doubt a multiarch x-loader would be possible at all
<ogra_> i fear until UEFI gets default for ARM we will have to live with SoC specific bootloader binaries here
<zumbi> yes, x-loader upstream maintainer was a bit sick of all that
<zumbi> Why doesn't TI just boot directly into kernel and this one is responsible to do everything
<ogra_> no idea
<zumbi> don't really need u-boot, unless you rely on it to initialize everything
<ogra_> for the build cluster we tried to use a raw kernel boot ... and initially ended up with no MMC and no USB
<ogra_> getting that initialized needed a good bunch of first stage bootloader hacking
<ogra_> sadly you need x-loader, there is not enough memory to carry u-boot
<ogra_> so x-loader needs to init the ram first
<zumbi> now, everything starts to make sense
<ogra_> sadly it grew more heads over the years it seems
<ogra_> as well as u-boot did
<GrueMaster> The processor only has 64K memory on boot, that's why x-loader is the way it is.  It initializes ram (and a bunch of other crap), then u-boot can load and do more.
<ogra_> so even if you wanted to do something like booting a raw minimal kernel and then kexec into something full, you would still need x-loader and u-boot
<GrueMaster> Well, x-loader at least.
<ogra_> which makes kexec moot since it just adds boot time for no benefit
<GrueMaster> You can boot a kernel from xloader.
<ogra_> well, you should be able to dd a binary header in front of uImage that replaces x-loader
<janimo> ogra, would an xloader/uboot that supports OMAP3 and 4 be that huge? Even if it were double the current size - which it probably would not be - it's not an issue
<ogra_> at least with newer omaps
<GrueMaster> Can't.  not enough memory to load both.
<ogra_> janimo, for x-loader it is ... as GrueMaster said above, 64k is your limit
<janimo> not having both binaries but one that handles both. Is the extra code/data so much different it would increase the size beyond what it fits?
<ogra_> for u-boot it might be possible to be a big multisoc binary
<ogra_> but surely for the cost of bootspeed
<zumbi> is it true that TI had problems with memory controllers as those did not match, so omap was unable to use memory (as LPDDR)
<ogra_> on XM, yes
<ogra_> (beagle XM omap3)
<zumbi> yes, I heard on 3530 early revs
<zumbi> all this is just insane.. :)
<hrw> XM used 36/37 iirc from start - or not?
<hrw> 34/35 was on normal beagleboard
<ogra_> the wonderful world of ARM :)
<hrw> I hope for cheap ARM board with 2MB of flash on board
<hrw> so there will be space for bootloader so boot from usb/sd/sata/network will be easy
<ogra_> i think you will see flash on board less and less
<ogra_> eMMC costs only half of i t
<hrw> ogra_: flash/emmc/esomething/whatever
<hrw> a way to just connect power and get board booted
<zumbi> hrw: sounds about right, xM using DM3730
<hrw> ogra_: if you want to use sdio on panda you have to solder second sdmmc or use other computer to send bootloader over usbdevice
<zumbi> there is "Automotive eMMC" much more reliable/tested than current eMMC
<hrw> I miss real developer boards
<zumbi> I need to play with TI Wilink module, I hope it performs as expected
<ogra_> oh, there goes tomboy
<garagoth> Good morning
<garagoth> A little question, if I may. I cross compiled kernel for Beagle (that is, for arm). In parent directory (relative to kernel sources) I have now 5 .dev biles and a lot of .udeb files. What are .udeb files? Is it sufficient if I install linux-image-2.6.38-10-omap_2.6.38-10.44_armel.deb and linux-libc-dev_2.6.38-10.44_armel.deb? What are -versatile packages? (ok. Maybe not a little question, but I am tired as hell...)
<ogra_> udeb files are packages used by debian-installer
<persia> udebs (micro-debs, but created with an assuption of weak unicode support) are only for the installer.
<ogra_> you dont need them if you dont build an installer image based on d-i
<garagoth> Ok, good.
<garagoth> So only *.deb are of my interest then..
<ogra_> you should really make your build command more explicit
<ogra_> -versatile is another arm subarch
<garagoth> I just followed manual pointed by rsalveti ;-)
<garagoth> It was not very... um, explanatory.
<persia> That doesn't have instructions for only building some flavours of the kernel?
<ogra_> fakeroot debian/rules binary-debs should just build the linux-image and headers packages
<garagoth> http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives
<ogra_> sigh
<persia> ogra, That still builds all the flavours though
<ogra_> why didnt you use any ubuntu documentation instead ?
<garagoth> in manual there is binary-arch
<garagoth> not binary-debs
<ogra_> persia, oh, right, its the main ubuntu soucretree
 * ogra_ forgot 
<garagoth> ogra_: I used what rsalveti told me...
<persia> garagoth, You did the right thing.  We're unhappy with the docs, not with your execution.
<ogra_> well, there are about three very detailed wikipages on the ubuntu wiki
<persia> garagoth, You did more than you needed, because the docs suck.
<persia> Just use the "omap" kernel .deb on your beagle.
<garagoth> Ok. Many thanks.
<persia> ogra, I thought the omappedia page was based on one of them
 * persia is looking
<garagoth> ogra_: If you would be so king and provide a link to better tutorial...
<ogra_> persia, well, as the omappedia pages are all based on something ... the prob is there was a snapshot taken but the updates dont move over
<persia> ogra, https://wiki.ubuntu.com/Kernel/Action/BuildKernelPackage doesn't help much :(  The wiki hates me.
<persia> I agree that it's better to use the w.u.c source, but we have to know a good one, and I fear the messiness of w.u.c is biting us here.
<garagoth> persia: heh, this is even shorter then omappedia...
<persia> garagoth, Sure, but it skips a lot, doesn't explain how to cross compile, and still results in what you got.
<garagoth> :-)
<ogra_> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is one
<persia> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is a bit nicer, but I thought there was a cross-compile one.
<ogra_> there is amitk's blog
<ogra_> but thats not up to date, i think hrw had a more up to date one
<amitk> ogra_: yes, go to hrw's blog post
<persia> No, there's a wiki page about it.
<persia> If that's not up-to-date, then we fail at docs.
<hrw>  http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/ one?
 * ogra_ likes https://wiki.ubuntu.com/SergeHallyn_ppakernels
<ogra_> short and simple
<persia> Doesn't cover the use case though.
<ogra_> no
<ogra_> covers mine though :)
<hrw> https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel is more complicated
<persia> Only because you're refusing to participate in Ubuntu these days.
<ogra_> who uses cross compilers anyway :P
<garagoth> ... me?
<ogra_> persia, huh ?
<ppisati> me
<ppisati> :)
<persia> ogra, Pushing kernels to PPAs when they ought be in the archive.
<ogra_> pfft, *REAL MEN* compile natively :)
<ppisati> no way
<ppisati> two hours to get a kernel
<ogra_> persia, it cant be in the archive yet ...
<ppisati> i would prefer to pull myself a tooth
<garagoth> I cross-compiled this kernel for few hours. I took looots of disk space.
<garagoth> No way I would do this natively...
<persia> ogra, Why not?
<hrw> garagoth: define looots
<ogra_> ppisati, i just always have a tree around where i only remobuild changes
<ogra_> *rebuild
<ogra_> only if i know they work i roll a package
<ogra_> persia, because i cant upload to natty :P
<ogra_> (and even if i could i wouldnt gain any benefit from that)
<persia> The rest of us are working on oneiric these days :p
<garagoth> hrw: looots == 7.9 GB
<hrw> ogra_: add kernel to oneiric and provide it also in ppa?
 * persia stops teasing ogra
<hrw> garagoth: 8GB for kernel tree?
 * ppisati tries to figure out what's the plan for oneiric/ti-omap4
<ogra_> hrw, if you donate me 24h every day :P
<garagoth> this is what I have in kernel dir when cross-compile finished
<hrw> garagoth: huge
<garagoth> inclugind generated packages
<ogra_> garagoth, you did it wrongly
<hrw> garagoth: good that my panda has still 153GB free on /home
<hrw> ops. 135GB
<ogra_> you only wanted an omap3 beagle deb, but built *everything*
<garagoth> hrw: USB HDD ?
<persia> ogra, Yeah, but that's our fault: the documentation sucks.
<hrw> garagoth: yes - 320GB sata
<garagoth> ogra_: Now I know. I blame documentation :D
<ppisati> actually to cross compile i do:
<ppisati> export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi-
<garagoth> hrw: How you connected SATA to Panda?
<ppisati> fakeroot debian/rules clean; fakeroot debian/rules binary-$flavour
<ogra_> garagoth, ogra@isis:~/kernel/linux-ac100-2.6.37$ du -hcs
<ogra_> 501M	.
<ogra_> oh, wait, thats unbuilt
<garagoth> :D
<ppisati> [flag@newluxor ubuntu-natty]$ du -sk .
<ppisati> 3937700 .
<ogra_> :P
<ppisati> 3.8G
<ogra_> still to much if you only build the linux-image and -headers debs
<ppisati> binary-omap -> omap3
<ppisati> fakeroot debian/rules binary-omap
<ppisati> natty/master
<ppisati> if you have any recepie to cut it, i'm all ears :)
<ogra_> doesnt that roll udebs and -docs and the like (and ddebs)
<ppisati> when i'm doing bisect/bug finding i use linus vanilla
<ppisati> copy .config from some ubuntu kernel
<ppisati> and then make uimage
<ppisati> it works and it takes much less time and space
<ppisati> nope
<ogra_> yeah
<ppisati> onlye kernel and header
<ogra_> thats how i do it for the ac100 too
<persia> Oh my.  The page on the wiki got removed as part of Kernel Wiki Gardening, and replaced with a link to amitk's old blog post.
<ogra_> only for a release i actually roll a test package
<ppisati> btw, one day i want to find out what are the minimun required configs to make a vanilla kernel boot an ubuntu userland
<hrw> garagoth: usb->sata enclosure?
<persia> garagoth, Sorry.  For now, the omappedia page is the best one, but if you look at the Ubuntu pages, you can find ways to build fewer kernels to achieve your goals.
<garagoth> persia: Linking to someones blog from wiki for official instructions... well, looks unprofessional :-)
<persia> Especially when the author of the blog post recommends a different resource (see backscroll).
<garagoth> hrw: Mm. And what transfer rates you have? I wanted to replace my home server with a panda/beagle cluster
<persia> In general, we don't do much with cross-compiling (except hrw).
<hrw> garagoth: poor - 20MB/s max
<persia> hrw, You should take over some area of the wiki, and build the comprehensive cross-compilation resource, and make all the other wikis (e.g. omappedia) point there.
<hrw> persia: sounds like a plan
<persia> \o/  Real Documentation!
<ogra_> ppisati, didnt you have a spec for that ?
 * ogra_ thought he saw one
<ppisati> ogra_: about what?
<ogra_> <ppisati> btw, one day i want to find out what are the minimun required configs to make a vanilla kernel boot an ubuntu userland
<ppisati> ogra_: nope, unfortuntaly no
<ogra_> oh ?
<ogra_> did it get dropped ?
<ppisati> never heard of a spec about it
<garagoth> YESSS!!!!! i2c bus 2 working !!!
<garagoth> But for some reason there is no entry about expansion board in dmesg... hum...
<ogra_> ppisati, yeah, i only saw the workitem on https://launchpad.net/ubuntu/+spec/other-kernel-o-config-review ... seems i mixed that up
<persia> ogra, The minimums are tricky (but there is work to document them).  There's a number of cases where things work for *some* systems and break horribly for others, because of assumptions in userspace about kernel config that only are exposed in non-default environments.
<ogra_> sure
 * ogra_ didnt say it was an easy task
<ogra_> :)
<persia> Heh, yeah.  But seriously, I believe the kernel team has been collecting this data since ~karmic because of some regressions discovered at karmic release because the release config didn't match userspace expectations.
<persia> I doubt they have *all* the quirks documented yet, but there ought be a fair collection of information.  I forget where, but remember apw telling me that it was in git somewhere.
<persia> Hrm.  The magic summon-the-man-who-remembers-stuff-about-the-kernel incantation didn't work :(
<apw> persia, collecting which data ?
<ogra_> LOL
<ogra_> it worked :)
<persia> apw, Which kernel options are required to match userspace expectations for Ubuntu.
<apw> ahh i see, we have been codifying the values of ones we have found to be required, in the enforcer file, but that doesn't cover everything which is required sadly
<persia> Where is the enforcer file, so ogra can have a peak at the current knowledge?
<ogra_> persia, i know where it is i think
<ogra_> ogra@isis:~/kernel/linux-ac100-2.6.37$ ls debian.ac100/config/enforce
<ogra_> debian.ac100/config/enforce
<ogra_> here we go
<persia> apw, Thanks!
<persia> ogra, Good luck.  If you find more required configs, please make sure they reach that file for all the kernels.
<ogra_> i dont get why its in the flavour subdir though
<ogra_> since it checks lots of general values ... that should just be in debian/
<persia> Because debian.foo/ generates debian/ so anything in debian/ is subject to wiping.
<ogra_> only parts of debian/
<persia> Yeah, well.  debian.foo/ is where all the kernel team work happens.
<persia> They like to leave debian/ alone if possible, considering it strange black magic (which it is)
<ogra_> s/black magic/insane perl/
<ogra_> :)
 * persia agrees with Arthur C. Clarke, and continues to call it "magic" in compliance with common duck-typing algorithms.
<ogra_> heh
<ogra_> magic always has something positive in it for me ...
<ogra_> sick parl code somewhat misses that positivity :)
<ogra_> *perl
 * persia uses "black" and "white" to indicate relative positions on that continuum
<persia> And "strange" relates to it's unrelation to anything else anywhere else
<ogra_> well, even 'black' magic might make me sit in awe ... while some perl code just lets me sit in tears ;)
<garagoth> ;-)
<persia> Right.  That's the "strange" part.
<rsalveti> morning
 * rsalveti reading backlog
<persia> Good morning.
<rsalveti> garagoth: awesome, good you got it working
<rsalveti> yeah, next step is to build just the omap flavor :-)
<rsalveti> then it'll be even faster
<rsalveti> persia: problem is that there is no official cross-build documentation anywhere at wiki.ubuntu
<rsalveti> that's why I pointed the omap one
<rsalveti> as it describes well how to do it
<persia> rsalveti: hrw volunteered to create some, so that's a solved problem.
<rsalveti> well, it's solved once it's done ;-)
<persia> No criticism was implied to giving garagoth helpful advice: the critism was at *all of us* for not having the pages on the wiki.
<ogra_> lool, i'm looking at debian bug 550584, i dont really understand the purpose of your highest-abi file ... cant we determine the highest abi from just listing /boot ?
<ubot2> Debian bug 550584 in flash-kernel "flash-kernel not run when going to new upstream kernel version" [Important,Open] http://bugs.debian.org/550584
<persia> rsalveti: The problem of "What are we goind to do about the lack of docs" is solved.  The problem "There are no good cross-compilation docs on the wiki" is pending :)
<rsalveti> garagoth: I believe if you run with binary-omap it should just build for omap flavor, but need to check
<ogra_> yes
<persia> Indeed.
<garagoth> rsalveti: :-)
<garagoth> Took me to compile this 3-4 hours
<rsalveti> garagoth: that's because you compiled for both versatile and omap
<rsalveti> so just omap should be half
<rsalveti> and takes a while because there are tons of modules
<ogra_> well, thats still quite long for cross building
<garagoth> rsalveti: I need to verify one more thing, as in dmesg there was no info that expansion board was detected. But i2c works fine!
<ogra_> the ac100 package natively takes 2h here
<rsalveti> well, that depends on the host ;-)
<garagoth> I have dual core 2Ghz
<persia> ogra_: Right.  Two flavours ~ 3-4 hours.  One flavour ~ 2 hours.
<garagoth> 4255 bogomips per core
<ogra_> persia, natively ...
<ogra_> persia, vs 4 for two flavours cross
<persia> Heh, I know.  See prior point about ARM hardware being good these days :)
<ogra_> heh
<rsalveti> garagoth: can you paste me the patch you used?
<persia> (and cross-compilation not actually being an interesting problem anymore)
<ogra_> yeah
<ogra_> as i said, real men build native
<garagoth> uh. I used one that you pointed me to and tweaked it a little.
 * ogra_ wants a T-Shirt with that *g*
 * persia suspects this also applies to real women and real small green furry things from Alpha Centuri
<garagoth> one chunk was failing, so I added it manually... and irq_set_irq_type I corrected to set_irq_type
<ogra_> not sure about the furry things ... but you could read men as "humans"
<rsalveti> garagoth: ok, that should be fine
<ogra_> i doubt green furry things from alpha centauri use C ... they will likely use green furry C ...
<garagoth> I gen generate a patch for you
<garagoth> I still have original file
<garagoth> http://nevander.eu.org/patch_expansionboards_2.6.38.10.patch
<rsalveti> garagoth: your u-boot needs to set the buddy kernel argument
<rsalveti> I believe the extension support is enable at u-boot already
<rsalveti> but then you probably need something like buddy=${buddy} at your kernel cmd line
<rsalveti> let me check u-boot sources
<garagoth> aaah.
<garagoth> true!!!
<garagoth> Let me check :-)
<rsalveti> garagoth: see if you're u-boot is already saying that you have an expansion board
<lool> ogra_: one way is to scan /boot, the other is to note down the versions when installing kernels; but note that the bug concludes we should copy the grub logic
<garagoth> Yes, it is detecting it correctly
<lool> ogra_: debbugs are a bit hard to read because they are threaded; I usually download the mbox and either read by thread or by date
<rsalveti> garagoth: so try adding buddy=${buddy} at your kernel cmd line arguments
<rsalveti> garagoth: edit /boot/boot.script and then run flash-kernel
<ogra_> lool, yeah, i read that ... do you think the patch will make it into debian soon ? i would like to have it before A2 8we have massive upgrade probs due to that bug)
<ogra_> if it doesnt make debian in time, i'll just addi it to ubuntu until i can sync it, but if avoidable i wouldnt like to waste time on having to carry it in ubuntu
<lool> ogra_: the patch needs to be reworked to use the grub bits and heavily tested; I'm getting asked about f-k stuff in Debian frequently, but I have a hard time making progress on it
<lool> should improve in the next weeks hopefully
<ogra_> well, oneiric can be your guinea pig
<garagoth> rsalveti: It works !!!
<rsalveti> garagoth: awesome
<garagoth> Definitely. Fully working beagle now...
<uragano2> hello, is ubuntu-omap4-extras still instable on natty?
<ogra_> instable ?
<rsalveti> uragano2: should be, why?
<rsalveti> tested yesterday with a fresh image and it worked fine
 * ogra_ still wonders if instable is a typoed installable or unstable :)
<uragano2> because i installed it already one time and my system become unstable, so searching on google i found this https://bugs.launchpad.net/ubuntu/+source/jasper-initramfs/+bug/759817
<ubot2> Ubuntu bug 759817 in jasper-initramfs "ubuntu-omap4-extras from the TI PPA is not installable in natty" [Medium,Fix released]
<ogra_> thats long fixed
<ogra_> your unstability surely doesnt have to do anything with ubuntu-omap4-extras itself
<ogra_> probably with something this pulls in, but these are plenty of packages
<uragano2> ok...i try to install it again hoping that this time it'll work fine :D
<ogra_> we didnt chnage anything since release
<ogra_> *change
<hrw> chromium-browser build passed 310 minutes. just 2.5h to possible breakage
<ogra_> hrw, how long does it usually take ?
<hrw> last time it took 440 minutes to fail
<ogra_> (and why is everyone building chromium today ?)
<hrw> on panda
<hrw> ogra_: it ftbfs on armel
<ogra_> ah
<ogra_> well, someone in #ac100 compiles it too today
<hrw> I have a patch for 440 minutes breakage applied
 * ogra_ crosses fingers
<hrw> bug 791283 btw
<ubot2> Launchpad bug 791283 in chromium-browser "chromium-browser version 11.0.696.71~r86024-0ubuntu1 failed to build on armel" [Undecided,Confirmed] https://launchpad.net/bugs/791283
<hrw> 12.something.x.y also fails
<ogra_> yeah, i saw it on the fstbfs list since a while
<uragano2> this time the installation finished successfully :D
<uragano2> audio throws hdmi doesn't work...can u help me?
<uragano2> *through
<jeremiah> Hi. The oneiric daily headless OMAP 4 doesn't want to boot the kernel
<ogra_> heh, that can well be
<jeremiah> Is there a place to file bugs or does one just report here?
<ogra_> see the topic
<jeremiah> Ah, cool
<ogra_> we just changed the build system completely, so its no surprise there are issues :)
<jeremiah> Okay.
<jeremiah> No problem. Is there a more stable version that one might try?
<jeremiah> Like a natty build?
<jeremiah> Or what do people recommend for getting a debian based OS onto the Panda?
<ogra_> ah
<ogra_> https://wiki.ubuntu.com/ARM/OMAP
<persia> jeremiah, There are working natty images.
<ogra_> see that page
<jeremiah> persia: Oh really? Okay, I'm happy to try on of those. :)
<jeremiah> I guess I'll use my google-fu :)
<persia> No, check the page ogra gave you
<jeremiah> Ah, okay, will do.
<persia> Has direct links and everything.  Without sponsored links or ads or anything :(
<persia> s/(/)/
<jeremiah> heh
<jeremiah> Well, I'll try the 11.04-preinstalled-headless-armel+omap4 and see what happens.
<persia> Beware that you have selected a *very* minimal install: you likely have to install bundles of things to make it do what you want.
<GrueMaster> jeremiah: what rev board do you have?
<jeremiah> persia: I plan to do that, I'm going to try to spin up the Automotive respin
<jeremiah> GrueMaster: Let me check . . .
<ogra_> ah, for the automotive respin that image might actually still be a bit big :)
<GrueMaster> Should be a label on the bottom of the board.
<jeremiah> GrueMaster: Looks like the lable says REV A#
<jeremiah> Sorry, Rev A3
<persia> ogra, Isn't it just ubuntu-minimal?
<ogra_> jeremiah, you might want to talk to Dr_Who i know he knows some tricks to make them even smaller
<ogra_> persia, -standard iirc
<jeremiah> ogra_: Really? Okay. :)
<GrueMaster> A3???  Didn't know they were available.
<persia> jeremiah, Do you particularly want to do it as a remix (as it is called in our nomenclature)?
<jeremiah> GrueMaster: I just got onw
<GrueMaster> cool.  let me know how it goes.
<ogra_> persia, yes, it was defined at UDS
<jeremiah> persia: Well, I've been working with some Canonical folks to get this up and running.
<ogra_> an IVI remix
<jeremiah> I work the GENIVI consortium
<persia> ogra, It's not tricks: it's a smaller seed collection (linaro nano)
<Dr_Who> Hi jeremiah
<jeremiah> And Canonical is planning on releasing the official GENIVI "respin"
<ogra_> persia, its also omitting the installation of any docs etc
<jeremiah> Dr_Who: Hi!
<ogra_> nano is surely so shrunk down for a proper ubuntu
<jeremiah> Dr_Who: I was hoping to do some testing of the Ubuntu / GENIVI respin for automotive
<Dr_Who> yeah and in the next incantation, replacing some of the core elements with their busybox counterparts
<ogra_> but something between minimal and nano should be cleanly possible
<persia> Ah.  I'd be in favour of having an automotive flavour from which Canonical derived, but that may require more coordination.
<jeremiah> I have a list of packages and I'll add some of the GENIVI components
 * GrueMaster wanders off ins search of something called the "loo".
<Dr_Who> jeremiah: sounds like fun!
<jeremiah> Dr_Who: It is! :)
<ogra_> GrueMaster, two times right
<jeremiah> Any time I get to fool around with Ubuntu its fun
<ogra_> down the corridor
<Dr_Who> jeremiah: you might be interested in https://wiki.linaro.org/LiveHelper/Hacking
<Dr_Who> basically how to roll your own images
<jeremiah> persia: Well, there has been a bit of co-ordination with Chris Kenyon, Ken Edwards, et. al. from Canonical.
<jeremiah> Dr_Who: Okay, I'll read that.
<jeremiah> Thanks
<Dr_Who> I can point you at the things we did for nano which may or may not be of interest to you
<jeremiah> I think if I can get a kernel to boot on the OMAP I'd be happy. I'm willing to leave the userland pretty plain for a bit.
<Dr_Who> jeremiah: o actually its in that wiki page
<jeremiah> We don't have an official OMAP release until October.
<Dr_Who> ah .. plenty of time
<ogra_> ah, well in that case the headless image is surely the least painful startin point
<jeremiah> (Even though the official Canonical press release claiming compliance is out!) =)
<jeremiah> ogra_: Cool, I'll start there.
<jeremiah> I already have the headless running on the OMAP 3
<jeremiah> Really nice.
<ogra_> and then apply nano imporvements where possible
<jeremiah> So the steps would be to boot Natty on the panda then use Live Helper?
<GrueMaster> image is the same on omap4.
<persia> Booting Natty on the panda gives you a development environment.
<persia> Live Helper lets you build images based on some archive (you might use natty).
<ogra_> jeremiah, live helper is to actually produce rootfses
<jeremiah> persia: Ah, okay. Thanks.
<persia> Running live-helper (or rather live-build) on the panda lets you build images for use on the panda.
<ogra_> right, it was renamed
<jeremiah> ogra_: okay, now I get it. So it would allow me to create a custom root file system
<jeremiah> That is frickin' great.
<jeremiah> Just what I'm looking for.
<persia> If you're testing experience, you can run live-build on an arbitrary platform where you know you have support, and build images for that platform.
<persia> If you're testing platform support, you want to run it natively (at least on the same architecture)
<jeremiah> persia: Hmm, interesting. I need to do some testing but don't really have a testing environment yet.
<persia> Do you need to test images, or just test software?
<jeremiah> The goal is to port some automotive software to the OMAP
<persia> In that case, I'd recommend completely ignoring live-build for now.
<jeremiah> So mostly just testing apps
<jeremiah> Ah, okay. Fair enough.
<ogra_> yeah, what persia said
<persia> Just install Natty on the panda.
<jeremiah> I plan to do some building and then package the apps so others can test
<persia> Then install the application you want to test (package it for easy uninstall/upgrade/etc.)
<jeremiah> Later we'll do the integration.
<jeremiah> Cool, sounds like a plan.
<persia> If you're doing packaging, I'd strongly recommend either doing packaging on *some other* machine, and just build on the panda *OR* install the Netbook image on the panda and use that as a development environment.
<persia> (depends how many Ubuntu boxes you have around)
<jeremiah> I have a Tegra2 box
<persia> Starting from the headless image as a development environment will get annoying very quickly.
<jeremiah> And a Intel Core 2 duo
<persia> Ah, that works :)
<persia> Either is good for packaging.  For building, you want to build the package on the tegra or the panda.  If both are running Ubuntu, the results ought be identical.
<jeremiah> I won't need an magic VFP flags for the tegra?
<persia> Once you know the set of packages you want to deploy, then it's worth looking at seeds, live-build, etc. and attempting to make an image to distribute as the remix.
<persia> No.
<jeremiah> I thought that I might face some NEON issues. But the box I have, called the TrimSlice seems to be working pretty okay
<ogra_> by default ubuntu doesnt use NEON at build time anywhere
<ogra_> thats a requirement
<jeremiah> Ah okay, good to know
<persia> No.
<persia> Rather, Ubuntu doesn't default to NEON instructions anywhere, and only uses NEON where runtime detection is available.
<ogra_> your Sw either needs runtime detection two binary packages
<persia> Ubuntu *definitely* uses NEON at build time, or we wouldn't be able to support NEON runtime detection :p
<ogra_> ubuntu doesnt support packages using neon at build time
<persia> The buildds can't execute NEON?
<ogra_> sure they can
<persia> So, how isn't it supported?
<persia> By policy, packages aren't allowed to depend on NEON being available at runtime.
<persia> But I don't see how this affects build-time.
<ogra_> it isnt supported to default to NEON and to hardcode that at build time
<persia> And, further, I suspect that test code run at build time *would* run NEON, as the runtime detection should notice it is available.
<persia> Ah, yes, that's not supported :)
<ogra_> phew
<ogra_> finally i got the formulation of the sentence in a way that persia agrees
<GrueMaster> Amazing.
<persia> P.S. It's easier to talk about not supporting NEON-by-default *at runtime* than fussing about build-time :p
<persia> jeremiah, Anyway, my understanding is that the base VFP stuff is implemented the same for a range of SoCs, and we're mostly using that.  This does mean that we don't take advantage of some of the capabilities of TEGRA (but that would need runtime detection, etc. for all the same reasons it's required for NEON)
<jeremiah> Okay, cool!
<uragano2> somebody know why during the boot i see IP-Config: eth0 hardware address MAC-A mtu 1500 DHCP [ 2.775718] eth0: link up IP-Config: no response after 60 secs - giving up
<persia> uragano2, Maybe there is software attempting to bring up a network link that you aren't using?
<uragano2> i see this since the first time that i installed natty
<uragano2> persia: no, sorry. the error was an other i confused! anyway i have installed only ubuntu-omap-extras and dropbear,
<shirgall> Anyone know where I can get the stuff to enable the sound on my pandaboard on Oneiric?
<ogra_> stuff ?
<shirgall> ogra_: not sure what I need to make it work
<shirgall> ogra_: So I punted and was non-specific. :)
<shirgall> ogra_: If I plug in a USB sound "card" that works fine.
<ogra_> bug 746023
<ubot2> Launchpad bug 746023 in alsa-utils "No sound on omap4" [High,In progress] https://launchpad.net/bugs/746023
<ogra_> see the pre-last comment from tobin
<ogra_> it is also in the release notes and on various wikipages
<shirgall> Ah, thanks, will look.
<uragano2> i am experiencing many issues with natty!!! did u do too???
<hrw> uragano2: natty is past...
<uragano2> what do u mean?
<hrw> I am experiencing issues with oneiric
<MrCurious> by any chance does a pandaboard compiling ubuntu kernel page exist?  Its been years since i built a kernel, and that was on familiar hardware.  I have no idea what to enable/disable for a pandaboard.
<persia> MrCurious, Grab the kernel from the archive, and look at the config as a base.
<MrCurious> you mean apt-get install kernel?
<NCommander> MrCurious: the config files for an ubuntu kernel are installed to /boot/config-*-omap4
<MrCurious> oh sweet
<MrCurious> now the end of persia's sentence parses (in my head)
<persia> apt-get source, but that was the idea.
<MrCurious> just to locate the kernel.  reading through a apt-cache search now
<persia> It's "linux-to-omap4" for the panda, isn't it?
<persia> Err, "linux-ti-omap4"
<MrCurious> from looking at the uname compared to the avail kernel sources it seems there were some patches put against it?
<MrCurious> the -1208-omap4
<persia> That's the name of the binary package.  GO ahead and grab that, and apt will do the right thing.  I'm not sure it does the right thing with the source name for kernel packages (I know it does the wrong thing for the main Ubuntu kernel, and filed a bug about it a few years ago)
<MrCurious> so grab the source on teh -1208-omap4 binary kernel?
<persia> Right.  That gets you the source, all the patches, and the configuration used.
<persia> You can fiddle with that with relative confidence that you can undo what you did and get back to what was installed by default.
<MrCurious> oh sweet, the source tag is going to become my new best friend of the minute
<persia> apt-get source is a handy tool: it's part of what makes using an open source operating system fun :)
<uragano2_> what means if i run arp -a form my pc and it returns "pandy.homenet.telecomitalia.it (192.168.1.217) at <incomplete> on wlan0"..why is it incomplete?
<MrCurious> to build the image for pandaboard, on pandaboard, its make uImage then make uinstall  (will that work right when the msdos partition is on SD, and the root partition is on a USB drive?
<MrCurious> here is to hoping that all the configuration options are auto set
<MrCurious> well, make uImage fails 3 files in with no rule to make target
<MrCurious> it has been a long time.  make dep is now un-needed
<MrCurious> guessing i have to copy the config from /boot to defconfig in the kernel dir?
<persia> MrCurious, Build a kernel package, and then install it.  Let flash-kernel take care of the details.
<MrCurious> having trouble getting the kernel build to take off
<MrCurious> trying to put in teh patch to usb that prpplague mentioned in teh pandaboard post from a few hours ago
<MrCurious> trying to work out how to get /boot/config-2.6.38-1208-omap4 to apply to the kernal-image-2.6.38-1208-omap4 sources i downloaded
<MrCurious> and get that image built
<MrCurious> ubuntu/aufs/magic.mk no such file or directory
<MrCurious> thinking i am on teh wrong path
<MrCurious> make clean doesnt work
<persia> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel might help.  It'S written from the i386/amd64 perspective, but most things are basically the same.
<MrCurious> ty
<MrCurious> persia: when i get to the fakeroot debian/rules step i discover i lack a debian/rules
<MrCurious> any hings?
<MrCurious> hints rather
<persia> How did you get the source?
<MrCurious> apt-get source linux-image-$(uname -r)
<MrCurious> which gives me /usr/src/linux-headers-2.6.38-1208-omap4
<MrCurious> i wonder if make clean nuked that
<persia> It shouldn't.
<persia> It should give you a .dsc file, a .gz file, and an unpacked directory "linux-omap" in the directory in which you ran apt-get source.
<MrCurious> it did make a src dir in the dir i ran that
<MrCurious> is that the kernel dir i should be messing with instead of the one in /usr/src?
<persia> Yes.
<persia> I'm not sure how you got the one in /usr/src
<MrCurious> i grabbed the kernel in a variety of ways, i guess
<MrCurious> building the kernel outside of /usr/src feels ODD
<persia> Heh.  We do offer several choices, so that people who want to do different things can.  Sometimes that seems like a good idea, and sometimes it makes it awkward (as many fok randomly search the internet for solutions, and find all sorts of recommendations out there)
<MrCurious> yup
<MrCurious> i am documenting my travels, so i can only ask once
<persia> Ask as much as you like.
<MrCurious> ty
<persia> We don't always agree on things, but if you ask, we're more likely to point you to reasonably heavily trod paths :)
<persia> If you don't ask, you never know what you might find.
<MrCurious> thanks! oh, a bud pointed me to a rather simple way of getting ubuntu to bring up wireless on boot
<persia> Which?  I have a suspicion I won't like it, but still ... :)
<MrCurious> i pm you it
<MrCurious> it may not be perfect, as i noticed the box lost networking after being on for a day or two
<MrCurious> make: *** No rule to make target `binary-generic'.  Stop.
<MrCurious> that sounds ominous
<MrCurious> wonder if i need binary-generic
<persia> It's a rule in debian/rules.  Not something external you need.
<persia> You shouldn't have to uninstall Network Manager to do that: Network Manager is supposed to check /etc/network/interfaces and ignore anything defined there.
<MrCurious> hmmm
<MrCurious> hmm debian/rules lacks a binary-generic
<MrCurious> root@unwin-desktop:~/linux-ti-omap4-2.6.38# grep binary debian/rules
<MrCurious> binary: binary-indep binary-arch
<MrCurious> include $(DROOT)/rules.d/2-binary-arch.mk
<MrCurious> include $(DROOT)/rules.d/3-binary-indep.mk
<MrCurious> perhaps the build mechanism has mutated since the howto page was last touched
<persia> Oughtn't have been.
<persia> Maybe the ti-omap kernel is different somehow.
<persia> Anything in rules.d/* ?
<MrCurious> well, i think i will just push on, and hope that dependency management catches any missed steps
<MrCurious> 3 different rules.d dirs (debian.ti-omap4, debian, and debian.master
<MrCurious> ti-omap4 dir only has armel
<MrCurious> .mk
<persia> debian/rules.d/*
<MrCurious> 0-common-vars.mk  1-maintainer.mk  2-binary-arch.mk  3-binary-indep.mk  4-checks.mk  5-udebs.mk
<persia> debian.ti-omap4 *should* have been used to populate debian/ when the source package was uploaded, so you oughtn't need to worry for making local packages.
<MrCurious> binary-arch is the one we want
<MrCurious> ?
<persia> I don't remember what debian.master does.
<persia> binary-arch.mk probably includes the definition for binary-arch:
<persia> make sure debian/rules includes debian/rules.d/binary-arch.mk
<MrCurious> nope
<MrCurious> well it does i think
<MrCurious> include $(DROOT)/rules.d/2-binary-arch.mk
<MrCurious> binary-arch appears to be building stuff
<MrCurious> back in a bit. going to let it cook and see what it makes
<persia> Oh, right.
<persia> "binary-generic" is the expansion of "binary-${FLAVOUR}".
<persia> You probably wanted "binary-ti-omap4"
<persia> Oughtn't matter in practice: I believe this kernel source only has the one flavour.
<MrCurious> make: *** No rule to make target `binary-ti-omap4'.  Stop.
<MrCurious> hmmm
<MrCurious> well binary-arch was making something think i will let that cook
<persia> We'll see what it makes :)
#ubuntu-arm 2011-06-17
<MrCurious> persia: it finished cooking
<MrCurious> and it made a bunch of _armel.udeb files and some armel.deb
<MrCurious> persia: this look right to you? linux-headers-2.6.38-1208_2.6.38-1208.11_armel.deb  linux-headers-2.6.38-1208-omap4_2.6.38-1208.11_armel.deb  linux-image-2.6.38-1208-omap4_2.6.38-1208.11_armel.deb  linux-ti-omap4-tools-2.6.38-1208_2.6.38-1208.11_armel.deb
<MrCurious> history
<MrCurious> anyone here who has built a ubuntu 11.04 kernel on arm in teh past month?
<MrCurious> i would love to compare your procedure against the one i got pointed to
<MrCurious> :( all i want is a kernel with todays usb patch
<MrCurious> sudo apt-get build-dep linux-image-2.6.38-1208-omap4
<MrCurious> Picking 'linux-ti-omap4' as source package instead of 'linux-image-2.6.38-1208-omap4'
<MrCurious> no apt-get, YOU DO NOT KNOW BETTER!
<MrCurious> and sadly, i dont know how to get around this
<StevenK> MrCurious: Yes it does. linux-ti-omap4 is a source package, which contains the Build-Depends, linux-image-2.6.38-1208-omap4 is a binary package, which has no concept of Build-Depends.
<MrCurious> but when i try to play along with the instructions here https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<MrCurious> it derails with fakeroot debian/rules binary-headers binary-generic
<MrCurious> as there is no binary-generic
<MrCurious> dont suppose i could petition you tohold my hand with this process some?
<MrCurious> or point to a set of instructions for doing it
<StevenK> I have no idea, sorry. I was just pointing out that apt-get is reporting a correct message.
<MrCurious> ok
<MrCurious> then i will continue on and try binary-arch instead of binary-generic
<persia> MrCurious, The kernel you compiled is inside linux-image-2.6.38-1208-omap4_2.6.38-1208.11_armel.deb : install this package (`dpkg -i`` may be helpful).
<MrCurious> i think i tried that and something went amiss
<MrCurious> on a new compile recipe now http://www.omappedia.org/wiki/Ubuntu_kernel_for_OMAP4
<MrCurious> giving that a crack
<MrCurious> well that build instruction is a bust
<MrCurious> the working origin/ti-omap4 branch is a bust
<persia> Well, expanding on "something went amiss" and "is a bust" is likely to get more information.
<persia> I make it a point to actively avoid building my own kernels, and even when I do need to generate a kernel, tend to do it by uploading it to an archive, and then installing it.
<persia> So I'm probably not the best person to provide insight here.
<MrCurious> perhaps i am attacking this upside down
<persia> ppisati, Any suggestions on how to tweak linux-ti-omap4 locally to play with different config settings?
<MrCurious> i should really say where i want to be, rather then some point on the road i think leads there
<persia> Always :)
<MrCurious> there is a patch to the usb code
<MrCurious> https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html
<MrCurious> i want a kernel for ubuntu panda with THAT fix
<MrCurious> do you know a easier way to get that one line fix in
<MrCurious> to a kernel that i can get installed :D
<MrCurious> see any alt paths than the one i am on?
<MrCurious> getting further with this source tree :D
<MrCurious> lets hope that WARNINGS are normal for kernel builds on this platform
<persia> There's a bug outstanding.  I don't have the bug number in my immediately-accessible logs.
<MrCurious> no worries
<persia> The easiest solution is to just wait until someone uploads a kernel with the patch, but that doesn't help with either doing it soon, or with learning how to help test patches in the future to help them get uploadede faster.
<MrCurious> can i get you to ping me in days to come if you know how i can get my fingers on a fixed kernel with that fix
<ppisati> persia: what you mean? any config in particular?
<persia> No.  I'll forget :)
<ppisati> MrCurious: unfortuntaly that fix doesn't work
<persia> ppisati, MrCurious wants to help test https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html but I don't seem to be able to find good instructions that let that happen.
<MrCurious> it seems prplplague has tested and verified the performance of the fix
<persia> Could you help?
<ppisati> MrCurious: nor the other one suggested in that thread
<MrCurious> you mean no performance perk?
<ppisati> actually i tried it yesterday, and it didn't work
<ppisati> i mean that fix
<ppisati> uhm
<MrCurious> didnt work as in compile bug, or clean build, no affect on behavior
<ppisati> no affect, the change is trivial
<ppisati> you can change the attribute the way they say, or entirely delete that attribute line
<MrCurious> just to lay a few lashes on the dead horse...
<MrCurious> we are talking file: include/linux/usb/ehci_def.h
<ppisati> no changes in beahevious, usb devices are still MIA
<MrCurious> new line
<MrCurious> __attribute__ ((packed,aligned(__alignof__(int))));
<ppisati> yes
<ppisati> MrCurious: did you try it?
<MrCurious> my usb devices are all present
<ppisati> really?
<ppisati> which kernel?
<MrCurious> just way slower than on every other machine
<MrCurious> this fix only came out in past 24 hours
<ppisati> i know
<ppisati> wait
<MrCurious> [pandaboard] Speed Problems with USB HDD or Networking
<MrCurious> that thread
<ppisati> https://bugs.launchpad.net/linux-linaro/+bug/747639
<ubot2> Ubuntu bug 747639 in linux-linaro "No USB devices on omap3 (beagle/overo) with recent linaro-2.6.38 based kernels or 2.6.29-rc1" [High,Fix released]
<ppisati> amd here is the bug in ubuntu
<ppisati> no wait, but that;s a different bug
<MrCurious> we are talking different bugs :D
<ppisati> yep
<MrCurious> phew. thought the fix to my bug wasnt good
<MrCurious> back to trying to build a kernel
<ppisati> this one: https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html
<ppisati> is about the missing usb devices on omap3/4 with gcc 4.6
<MrCurious> i think i read somewhere that .0 GCC vers bring pain
<MrCurious> and for some reason its being used
<MrCurious> fall back to older gcc and be happy?
<ppisati> 4.6 is the official toolchain for oneiric
<brendand> is there any way to get higher than 640x480 on pandaboard?
<ppisati> MrCurious: but you pointed me to the missing usb devices patch
<ppisati> MrCurious: and you said prplplague tested the fix, and it was working
<MrCurious> he tested it for performance on panda
<MrCurious> i could see that fix causing usb issues
<ppisati> MrCurious: i should ask him
<ppisati> prpplague^2: ^
<MrCurious> yes. i mean to ask him how i can get the image he built :D
<hrw> brendand: you connected lcd to hdmi or dvi output?
<brendand> hrw - it's the one labelled HDMI-1080p right next to usb/ether connectors
<brendand> hrw - other one doesn't work
<brendand> hrw - the cable i am using is hdmi to dvi though, my samsung monitor only has vga and dvi ports
<hrw> thats fine
<hrw> brendand: which kernel you run?
<brendand> hrw - stock natty
<brendand> 2.6.38-1208-omap4.11
<hrw> linux-image-2.6.38-1208-omap4 2.6.38-1208.11
<hrw> here
<hrw> and my hdmi->dvi monitor gives 1680x1050
<persia> Those are the same kernel: the differences in versions are because of how the versions were collected.
<hrw> yep
<brendand> persia - yep
<brendand> i used uname -a
<brendand> anyway
<brendand> in 'monitors' i can't select anything but 640x480
<brendand> and xrandr only reports that as well
<hrw> so your monitor was not recognized
<hrw> brendand: you have any graphics on screen?
<brendand> hrw - absolutely
<brendand> yeah, monitors says 'unknown'
<brendand> whereas my laptop says 'Samsung 23"'
<persia> If you attach the same screen to something else, can it parse EDID?
 * brendand installs read-edid
<brendand> hanging?
<brendand> should it complete quickly? parse-edid that is
<persia> It ought.
<persia> `parse-edid < /sys/class/drm/${PORT}/edid` ?
<brendand> okay
<brendand> yeah, it can
<brendand> hanging was obviously waiting for input
<persia> OK, so you're getting good EDID, with the right resolution and name, etc?
<MrCurious> GOSH but the CPU gets hot durring a kernel build
<MrCurious> i now have NINE fingerprints!
<persia> Um, putting one's finger on a CPU that has no heatsink is rarely a good idea.
<MrCurious> yeah
<MrCurious> they get hot. but they seldom glow
<persia> OMAP4s don't get very hot, but many chips have thermal densities exceeding that of most nuclear reactor cores.
<MrCurious> the gumstix cpu gets much hotter ALL the time
<MrCurious> i have been debating tossing some passive heat sink on it
<persia> Won't hurt (unless you cause physical damage in the process).  Not required for long-term system health.
<brendand> http://paste.ubuntu.com/628319/
<brendand> ARM chips are very much designed to run without one
<persia> 2048x1152?  I thought you said 1680x1050
<persia> brendand, That's not universally true: some designs run at sufficiently high clock speeds that they would melt.
<hrw> persia: I said 1680x1050
<persia> Your paste says 2048x1152
<hrw> his paste - sorry for mess
 * persia suffers from id3entity failure,. and decides to go wake up a bit more
<brendand> problem is that's for the vga port
<brendand> my laptop has no hdmi port, so can't attach a cable to that
<persia> I *think* EDID info ought be the same regardless of the port used.
<persia> You could try forcing resolution on the kernel command line.
<brendand> how?
<persia> I think it involves editing boot.scr and fiddling with u-boot.
<persia> hrw, Do you know the specifics there?
<hrw> nope, my monitors work with panda
<ogra_> www.omappedia.org/wiki/Bootargs_for_enabling_display ... look for hdmimode and hdmicode
<persia> hrw, I meant about adjusting the command line:  I thought you might know uboot.
<persia> ogra, Thanks!
<ogra_> there is a wikipage about editing the cmdline in our wiki somewhere
<ogra_> though just edit /boot/boot.script and run flash-kernel and reboot should be enough
<hrw> persia: ah. adjusting is easy - cp /dev/mmcblk0p1/boot/boot.scr /boot/boot.script, vi /boot/boot.script, drop crap in front, edit, run flash-kernel
<hrw> hdmimode/code are unknown for me
<persia> hrw, Thanks.  Sorry for the confusion.
<ogra_> hrw, why do you copy /boot/boot.scr to /boot/boot.script ?
<hrw> ogra_: cause my system lacked it?
<ogra_> on an ubuntu install they should always be identical
<ogra_> despite the header indeed
<ogra_> uh, why were you lacking it ?
<persia> Some folk who run Ubuntu don't perform an Ubuntu install.
<hrw> ogra_: iirc plain test one was added during natty cycle - my rootfs is quite old
<ogra_> nah, that cant be :P
<ogra_> the plain text boot.script exists since we support omap4
<ogra_> so your install must be really old :)
<hrw> ogra_: boot.script was part of kernel image?
<hrw> 10:44 hrw@malenstwo:chromium-browser-12.0.742.91~r87961$ dpkg -S /boot/boot.script
<brendand> in the middle of an update will try after that
<hrw> dpkg-query: no path found matching pattern /boot/boot.script.
<ogra_> no, but part of the preinstalled image
<zumbi> ogra_: I think boot.script was missing here too. My card reader is broken, cannot check properly.
<hrw> ogra_: this rootfs was probably generated with linaro-media-create
<ogra_> ah
<zumbi> hrw: strings boot.scr > boot.script
<hrw> zumbi: header has 'ubuntu boot script' in it iirc
<zumbi> yep, capital U
<zumbi> I thik i tried the headless image
<ppisati> prpplague^2: did you really get an ubuntu kernel to work with gcc 4.6?
<r3> hi guys.. is this the right place for asking some struct alignment (packed) questions how to solve in order to port a package x86->arm?
<persia> r3, You can ask.  No promises that folks who know enough to answer are around at the moment.
<r3> ok, thank you, i will try
<r3> i found issues in coova-chilli which is working well in x86 but sometimes not in arm. issue is during a cast of a packed struct which contains generic fields to a in_addr struct, which is unaligned of course.  now i have a working workaround, but i try to understand if there's an easier solution, because with this workaround i need to check and fix every cast of every file. i'm no expert, so probably there's a simple compiler flag which fixes this (?) would be g
<r3> reat that, would'nt it? :D
<r3> here is a bit of code containing the wrong cast commented out and my workaround: http://pastebin.com/VgxRxzJn
<r3> for more context: coova-chilli is a captive portal which during login asks a radius server for AA.. it is possible to assign (within radius) for each mac-address a static ip address which should be assigned then to that particular mac-address. we get this ip address by the radius response (that packed struct)
<r3> if such a static ip address is set within radius database, i get it, but instead of getting 192.168.11.66 after the cast i have 192.168.11.6.   digging in depth, i understood that packed struct does not add the alignment padding but the cast then jumps over 2 bytes of padding, because somehow it does not know that the source struct is packed
<r3> now with that double cast (cast from packed to unaligned const struct to my in_addr struct) this problem is solved.  but do i really need to change this everywhere? is this normal procedure you need to do when you port software from x86 to arm?
<zumbi> r3: maybe http://wiki.debian.org/ArmEabiFixes helps?
<_r3_> zumbi: thank you! i'll take a look
<_r3_> hmm, no this case is missing. but very interesting.. i need to check some of them too, since python for example on our platform is really slow. maybe because of wrong alignment
<dmart> _r3_: This is really nothing to do with ARM -- the affected cast is invalid C for at least two reasons
<dmart> _r3_: first, the code is type-punning, which is not allowed
<dmart> _r3_: second, the code is casting without meeting the alignment requirements of the target type, which is not allowed either
<dmart> Some arches (i.e. x86) are rather forgiving about this, but many are not
<dmart> _r3_: the correct fix would be something like http://pastebin.ubuntu.com/628360/
<_r3_> dmart: hmm.. i get it in correct byte order, since that is already converted in receive function.. but with wrong byte order instead of 192.168.11.66 i would get: 66.11.168.192 but not 192.168.11.6.. that '6' comes from 2 bytes after the i field
<_r3_> and well type-punning is needed since radius protocol is at it is .. i can't change that.. it is casting without meeting the alignment req. yes.   is there an easy way to make the compiler understand that?
<_r3_> without doing the double cast i mean :)
<lag> ogra: If I was a member of the public wanted to host my own ARM PPA, what would I have to do?
<lag> ogra_: -^
<ogra_> lag, talk to IS and convince them that only employees can upload
<lag> ogra_: So they can't host an ARM PPA?
<ogra_> or upload to a private arm ppa you only have access to and do a binary copy of the debs to a public one
<lag> I don't mean for me
<lag> I mean if I weren't an employee
<ogra_> well, we dont have public PPAs until the cluster is in place
<lag> I don't know what that means, what cluster?
<ogra_> which will happen soon, but due to the fact that we could only fit 10 boards in it instead of 20, ppas might still take a while
<ogra_> the panda build cluster
<ogra_> currently arm PPAs are non virtualized
<lag> So all ARM builds are completed on a Panda Board cluster currently?
<ogra_> which means you can do very bad stuff if you have upload permission
<ogra_> no, currently we have a bunch of babbage boards as build machines
<ogra_> they are supposed to be replaced by a pandaboard cluster
<ogra_> that cluster will have special tecnology to fake virtualization
<lag> Right, but members of the public can't build on them?
<ogra_> so we can make public PPAs available
<ogra_> until thats in place there wont be any public PPAs for arm
<lag> Okay, so what are the plans ETA?
<ogra_> the first cluster should be in place within the next 7-10 days, its physically in the datacenter but hasnt been set up
<ogra_> that one will likely only replace the existing build machines
<lag> So the bottom line is, non-employees will be able to host their own ARM PPAs in the upcoming weeks?
<ogra_> when the second cluster is ready (which will get us PPAs most likely) isnt predictable atm
<lag> Okay, I guess that answers my question
<lag> Thanks dude
<ogra_> i would say ETA for public PPAs is likely not happening before P
<ogra_> #probably earlier, but thats a matter of luck
<lag> Right, thanks
 * ogra_ would love to have it this cycle but life goes slower than planned wrt build machines
<dmart> _r3_: did you try my code from pastebin?  By reading the adress from hisipattr without a type cast, the compiler shouldn't get confused
<dmart> _r3_: ...though actually, your code is roughly equivalent.  However, casting from one packed structure type to another shouldn't be necessary.  If reading that field from struct radius_attr_t is giving wrong results, that suggests a compiler bug, but the compiler is not required to give sensible results if you cast a struct radius_attr_t * to in_addr_t * and deference the result
<jeremiah> Well, the Natty image didn't want to boot either on the Panda A3
<jeremiah> And this page: http://www.omappedia.org/wiki/Get_started_with_ubuntu_on_omap4
<jeremiah> Appears to be out of date
<dmart> lool: is there a common mailing list for Ubutntu arm developers?
<persia> dmart, ubuntu-devel@
<dmart> persia: thanks!
<dmart> persia: was there previously a separate ubuntu-arm@, or am I mis-remembering?
<persia> There never was.
<dmart> fair enough
<persia> Theoretically, everyone is supposed to care about all the architectures.
<persia> In practice, this isn't actually true, but nobody is going to complain about some architecture-specific threads.
<dmart> For reasons totally unrelated to this IRC thread, I was thinking of suggesting that everyone gets mroe proactive about getting rid of alignment faults in userspace apps
<persia> On the other hand, it needs to stay relevant to Ubuntu: so "how to deal with porting issues" is interesting, as it helps us all solve FTBFS issues.  "Here's a new device" is less interesting, unless someone is doing the work to have that device supported in Ubuntu.
<ogra> jeremiah, yes, rather use ubuntu docs to install ubuntu ;)
<jeremiah> heh
<jeremiah> Well, that would make sense. :)
<persia> That's definitely applicable to ubuntu-devel@ : powerpc folk are just as prone to that sort of thing, so it's not even that arm-specific.
<ogra> http://wiki.ubuntu.com/ARM/OMAP
<ogra> try that :)
<dmart> persia: ok, thanks
<lag> hrw: Is our toolchain available for on Debian?
<ogra> though it might be that we're missing bits for A3 borads
<persia> lag, Debian uses a slightly different toolchain (although some of the same folk are contributing).
<jeremiah> thanks ogra
<lag> hrw: persia: I mean the Linaro toolchain
<jeremiah> I hope we're not missing any A3 bits - but we'll soon find out. =)
<ogra> yeah
<persia> lag, So do I.
<jeremiah> At UDS I saw a lot of Debian folks doing Linaro stuff. :)
<lag> persia: Okay, thanks
<persia> As "Ubuntu toolchain" and "Linaro toolchain" are essentially equivalent (if not, someone is slacking, or we're not all working on the same thing anymore)
<jeremiah> Not as many as the Ubuntu folks, but still.
<persia> jeremiah, I think the lines begin to blur in that area: given that both Debian and Ubuntu are community projects, and share lots of code, I think many people involved in the area end up working with both projects.
<jeremiah> persia: I certainly have a hard time telling where one project begins and the other ends.
<jeremiah> I mean, those who are paid by Canonical one can assume they spend a good deal of their time on Ubuntu
<jeremiah> But, as Mark Shuttleworth says, every Ubuntu developer is a Debian Developer. :)
<jeremiah> Although that might not be literally true.
<lool> dmart: there was an ubuntu-mobile@ list but it's dead nowadays
<lool> and I don't think it ever cared of ARM
<ogra_> during the team transition phase probably
<lool> but the people on the list were fairly overlapping with people caring about ARM  ;-)
<persia> It didn't.  In it's latter days, it mostly consisted of apologies about lpia, and backporting efforts.
<persia> No.  Lots of regulars on ubuntu-mobile@ left and did something different when it stopped being a focus, and more ARM stuff was happening.
<persia> jeremiah, I believe the quote was the other way: that every Debian Developer is an Ubuntu Developer.
<persia> I know of folk paid by Canonical who do all their work in Debian and none in Ubuntu.
<persia> The boundary isn't really about individuals, as many folk participate in both, or about code, as much code is shared, but rather about the goals and output.
<jeremiah> persia: Ah, you may be right. :)
<jeremiah> about the shuttleworth quote, for sure
<persia> Debian strives to generate a universal operating system.  Ubuntu strives to present a (limited) selection of the results of applying opinionated defaults to generate specific user experiences.
<jeremiah> But Ubuntu also wants one to assign copyright to ubuntu, which is sometimes controversial.
<persia> There's obviously overlap in those goals (and plenty of other goals which I've simplified away), but the answer in Debian is often "Let's enable users to do things how they wish, but sanely" and the answer in Ubuntu is often "Users should be doing things like this, so let's make sure that works very well."
<persia> No.  Ubuntu has no interest in having copyright assigned.
<persia> Canonical happens to provide some Ubuntu infrastructure, and also happens to sponsor some upstream projects that require copyright assignment, but that's not that relevant to Ubuntu.
<persia> There's a number of cases where Ubuntu has patched Canonical software, but refused the copyright assignment, so the software in Ubuntu differs from that Canonical provides.
<jeremiah> Really? I didn't know that. Interesting.
<jeremiah> So there certainly is a degree of independence
<hrw> lag: there are no cross compilers in Debian archive. If you want them then Emdebian guys have repositories with cross compilers.
<lag> hrw: Can a Debian user use our binaries?
<hrw> lag: Linaro gcc changes are part of Ubuntu gcc now. Debian uses same packaging as Ubuntu but iirc does not apply Linaro changes
<ogra_> they might pull in unwanted deps
<hrw> lag: no warranty that they will install but may work
<ogra_> unimportant stuff like a different libc and such
<lag> hrw: Great
<lag> ogra: I'm sure they will live :)
<ogra_> i wouldnt be that sure when mixing debian and ubuntu
<ogra_> on a binary level at least
<hrw> ogra_: both debian and ubuntu uses eglibc 2.13 now
<ogra_> hrw, which release ? :P
<ogra_> if someone run lenny they will surely not have a happy system after installing a natty toolchain (which pulls in the ubuntu libc)
<persia> Debian and Ubuntu are not guaranteed to be binary compatible.  There isn't even any serious attempt made to be so, and most folk who push in that direction get strong push-back.
<hrw> ogra_: testing
<ogra_> and most often just fall over at some point
<hrw> ogra_: I do not have to support Debian so I limit my Debian work to sid
<persia> It's supposed to be *source* compatible (although that's slowly eroding for some categories, and several folk are working to get it back)
<ogra_> mixing debian and ubuntu on a binary level is asking for trouble
<_r3_> dmart: aaah now i got it. assign directly to s_addr! ..  i will try it, thank you!
<persia> For ARM, it's raw madness: The ABIs are known to differ.
<ogra_> right
<ogra_> and there are the compiler defaults etc
<persia> That's part of why the ABI differs :)
<ogra_> well, beyond the obvious ABI difference between v5 and v7 :)
<persia> Does that force an ABI difference?
<persia> I thought that was just an ISA difference, but didn't actually affect exported symbols.
<ogra_> no idea if -as-needed is ABI specific for example
<persia> It's not.
<ogra_> or -no-shrink-warp
<persia> That's just a linker thing.
<ogra_> etc
<ogra_> i think we have a good bunch of non ABI related config diffs
<persia> Oh, heaps.
<persia> But the ABI differences are the reason it's not safe to mix binaries.
<jeremiah> Hmm. I can't get the ubuntu-11.04-preinstalled-headless-armel+omap4.img.gz to boot past the kernl
<jeremiah> kernel even
<jeremiah> I'll try another version, like the netbook.
<jeremiah> md5sum was correct anyway.
<persia> What sort of error are you getting?
<persia> I very much doubt that you'll get different behaviour from a different image in terms of intiial startup.
<jeremiah> persia: It just says; "uncompressing kernel . . ."
<jeremiah> No, I imagine its the same kernel for all of them most likely
<ogra_> how long did you wait ...
<jeremiah> ogra_: Not particularly long this time.
<persia> It is, and the same bootloader, and the same set of code to launch the startup process.
<ogra_> it takes a while until oem-config has parsed the debconf db before it shows the UI
<jeremiah> But I'll check again, because I onlyl closed minicom
<persia> ogra, Where "a while" is measured in minutes or tens of minutes?
<ogra_> minutes
<persia> Thought so: just wanted to set some bounds :)
<jeremiah> I've just rebooted
<jeremiah> It stops here: Uncompressing Linux... done, booting the kernel.
<ogra_> right, give it a moment
<jeremiah> okay :)
<ogra_> debconf produces a lot of I/O
<ogra_> Sd cards arent really great for that
<jeremiah> What makes me nervous is that one of the leds has stopped and the other has goine into a steady blinking state
<persia> Yeah :/
<ogra_> which one blinks ?
<persia> jeremiah: I think that's expected (or at least my panda usually only has one blinking light)
<ogra_> the left one is heartbeat, it means the board is alive
<jeremiah> ah, okay
<ogra_> the right one (closer to the SD) is disk access
<ogra_> if thats solid there is a lot IO
<jeremiah> D1 was blinking (that is on my left) but has now stopped.
<jeremiah> Now both have gone out.
<ogra_> hrm
<_r3_> dmart: yeah, that's working, thank you!   .. however.. i have to change every cast, that's always necessary i guess, is it?     i was searching for some neat compiler-flag or something easy which solves this, hehe .. but ok, probably the game really isn't played that way :)
<jeremiah> Yeah. Definitely stuck, kernel won't boot.
<jeremiah> I wonder if there are complications from the new u-boot?
<jeremiah> I notice that on OMAPedia it talks about compiling u-boot with omap4430sdp_config
<jeremiah> But it looks like the config has changed to omap_panda_config
<jeremiah> But that is for u-boot, and it looks like we've gotten past the bootload by the time the "booting the kernel" message comes up
<ogra_> omappedia has a lot outdated info
<jeremiah> Yeah, you're right.
<jeremiah> It does seem quite out of date
<jeremiah> Sheesh. That page was last edited about six months ago.
<jeremiah> Well, I'm compiling linaro-gcc here to see if I can't compile a kernel here.
<ogra_> why are you compiling gcc ?
<ogra_> dont you like the binary packages ? :)
<ogra_> jeremiah, i just talked to TI, seems for the A3 panda we will need some patches to x-loader to make it work
<prpplague^2> ppisati: i haven't booted ubuntu on pandaboard in atleast 3 months, much less compile with gcc-4.6, why do you ask?
<ppisati> prpplague^2: becasue someone said you had usb devices in a ubuntu kernel compiled witg gcc 4.6
<ppisati> prpplague^2: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552
<ubot2> Ubuntu bug 791552 in linux "No USB support on beagle/beagleXM" [High,New]
<prpplague^2> ppisati: i am guessing that is reference to this - https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html
<prpplague^2> ppisati: i normally don;t any testing of ubuntu kernel/rootfs
<ppisati> prpplague^2: yes, tried that and it didn't work and since someone said you had it working
<ppisati> prpplague^2: i was asking
<prpplague^2> ppisati: ahh, well i didn't try anything with an ubuntu kernel, or with gcc 4.6
<prpplague^2> ppisati: np
<ppisati> prpplague^2: ok
<prpplague^2> ppisati: the problem also affects some performance issues on the EHCI
<prpplague^2> ogra: uh what changes are they refering to ?
<jeremiah> ogra_: Ah okay.
<ogra_> prpplague^2, no idea, i need to ask sebjan
<prpplague^2> ogra: there shouldn't be any changes to x-loader to support A3 boards
<prpplague^2> ogra: i'll check on that when i get to the office
<ogra_> prpplague^2, well, i was just told there are patches
<prpplague^2> ogra_: hmm, sounds odd to me. i validated A3 boards with mainline x-loader and u-boot
<prpplague^2> ogra_: i'll give you a ping when i get to the office
 * prpplague^2 heads to the door
<ogra_> k
<ogra_> lilstevie, hehe
 * ogra_ just saw the mail 
<lilstevie> ogra_: :)
<garagoth> Hm, a question about kernel packaging, again.
<garagoth> I have that 2.6.38-10 kernel I have compiled
<garagoth> but kernel-headers-..-omap.deb required kernel-headers.deb
<garagoth> how to generate it?
<garagoth> hrw: Good to see you. A question, if I may...
<garagoth> I have that 2.6.38-10 kernel I have compiled. There is linux-headers-2.6.38-10-omap_2.6.38-10.44_armel.deb package, but it depends on linux-headers-2.6.38-10 package. How to generate it?
<garagoth> ...
<garagoth> Ok, nwm, I managed to make it...
<rsalveti> garagoth: I think you need to build binary-indep
<rsalveti> or binary-headers
<garagoth> binary-headers
<garagoth> I spent a while reading debian/rules :-)
<garagoth> And figured it out.
<garagoth> But thanks for answer anyway.
<garagoth> You guys on this channel are really helpfull.
<rsalveti> awesome :-)
<rsalveti> so you're good at ubuntu kernel pack hacking already :-)
<garagoth> Eheheh. Good... no. Still green, but green as seasoned grass, not young one.
<mcmx5> whats the best way to get XMBC up and running on my ubuntu pandaboard with working SGX?
<hallyn> ogra_: hey, so i've been trying to use the dynabook over the last week just to check for any weird architecture gotchas.  The only thing that really stands out is, every 30 seconds or so, it freezes for 10 seconds.  (and the touchpad doesn't work at all, but touching the touchpad doesn't cause the freezes)  Known?
#ubuntu-arm 2011-06-18
<sveinse> It is generally recommended to run a debootstrap installer for a target system on a native machine. Is it considered safe to do installations/upgrades (like apt-get update and such) for a target chroot system on a native machine?
<sveinse> persia ^^
<persia> sveinse, All native operations are considered safe and expected to work.  Foreign operations may work, but aren't promised to do so.
<persia> The common pattern for generating an image is to use debootstrap to create a base filesystem, then to install packages into that, then to wrap the bundle for deployment onto target systems, which then perform the upgrades.
<sveinse> thanks. What do you mean by "wrap the bundle" ?
<persia> Implementations differ, but it's essentially taking some bundle of files (the chroot), and putting in some structure that may be treated as a filesystem.
<sveinse> Ah, ok, then I understand. It's the part where in our case, generate the uSD card image FS
<persia> This may involve copying it into a loop-mount, running something like mksquashfs or ubunize, etc.
<sveinse> yep
<persia> Precisely.
<sveinse> But you mention the upgrade post deployment or am I misunderstanding?
<persia> Some implementations will create a loop-mount first, then mount it, then debootstrap on that mount: but this requires knowing the space you require in advance.
<persia> Yes, upgrades are usually post-deployment.
<persia> So, when you construct the filesystem, you want to construct it to include all the updates available at the time of filesystem creation.
<persia> If you have -updates in your sources.list when creating it, apt will take care of this for you.
<persia> Then, post-deployment, end-users will continue to update their systems, which provides a channel for bugfixes, security fixes, etc.
<sveinse> Here's how I think it should be (from my understanding):  1) debootstrap chroot, 2) install packages into chroot, 3) create uSD image from chroot, 4) Install into device. The user should then not have to see an upgrade process while his first boot. Or?
<persia> Some users may choose to "upgrade", meaning to move to the next release of Ubuntu, but this is outside the scope of your filesystem creation.
<persia> The user *may* see an update process at first boot, depending on the time between filesystem creation and first-boot.
<persia> For each Ubuntu release, we generally have 10-15 updates available at the time of the release announcement, so 0.1% of packages.
<persia> (or a bit less, but close to that)
<persia> So, you're a bit different, because you're doing a derivative, with a fair bit of software that isn't in the Ubuntu repositories.
<sveinse> Yeah, that will happen if the user has a working internet access on the device. I.e. the device will apt-get update itself upon firstboot
<persia> Right.
<persia> You'll need to have available repositories containing that software, to provide updates and security fixes to it.
<persia> (unless you got things working with qt4-x11, and want to put your stuff in the regular archives :) )
<persia> The moreso because if you just point users at the regular archive, they may end up with updates that impact your software.
<sveinse> What exactly triggers the apt-get update in the first place? The first boot?
<persia> There's a few things.
<persia> So, if you're using oem-config (recommended), I believe there's an update at first boot as part of that.
<sveinse> yeah, ok
<persia> There's a bunch of packages in the archive that provide scheduled update-type stuff: some will do an apt-get update, some will just check to see if one needs to be done, some will update the cache and download (but not install) all the updates, and some will automatically update the software.
<persia> If you want any of these features, you'll want to have one of those packages included in your filesystem.
<sveinse> yes. The only detail which comes into mind now, is the fact that the user may not have setup the wireless yet, so internet will not be available early in the process
<persia> I think that if oem-config doesn't have access to the internet, it doesn't ask the user questions about it.
<persia> (but you want to test, especially in your (fairly different) environment)
<sveinse> Anyways, my question was how to migrate from nothing via debootstrap to the device image, and I got my answer, thanks
<sveinse> I'll dive into oem-config later -- but I will eventually
<persia> If you're planning scheduled updates, the recommendation is to have something that uses update-notifier-common (you may find muon-notifier a good example from which to collect code)
 * sveinse taking notes
<persia> Sorry.  I don't mean to overwhelm you :)
<sveinse> No, no problem. I'm just afraid of coming back weeks later and repeating the same questions :P
<sveinse> In fact, I'm grateful
<sveinse> Obviously from our previous discussions, the way I've found is not necessarily the correct way of doing things
<persia> At least it's not the way that things are commonly done in Ubuntu, so may not be getting the level of testing you might expect.
<persia> I'm hesitant to say that other ways are wrong (with specific exceptions), if they are known to work.
<sveinse> Since my setup is somewhat unique, I need to do the testing and QA qualification anyways. I wouldn't expect nor ask that of the community
<persia> Heh.  If you are planning on a product release and don't have an internal qualification process, something is likely to go very wrong, even if you weren't special.
<sveinse> very true
<persia> That said, it makes sense to select solutions that are more common in many cases, as they likely receive more testing, are more mature, etc.
<persia> (this isn't always the case: sometimes there are cool new things that are genuinely good, but they do require more attention if selected, just in case)
<sveinse> as said before, we're living on the edge between native and cross compilation, so in that respect we are stretching the Ubuntu normal way of doing things. I believe neither method is bad, just different. So we know the added risk of being on that edge
<persia> I agree that neither is bad.  I'm deeply suspicious of mixing them.  I can only wish you luck.
<sveinse> But that being said, we are actually considering buying a target system (for the build server) to do the debootstrap staging and making the final images
<persia> Some of them are getting *really* inexpensive these days.  Pandas and Quickstarts seems to work rathre nicely, considering the cost.
<sveinse> But for performance reasons, I belive we will cross build some of the binary debs (kernel, Qt libs and Qt app -- all of which are designed well for cross compilation)
<persia> And everyone else is coming out with similar things (although I haven't gotten as much feedback about them)
<persia> Development-performance, build-time performance, or run-time performance?
<persia> I think they ought be equivalent for runtime performance.
<sveinse> Yup, The IT dept will cheer the day I come with a armel box in a 19" rack. (And I'm not to persue a rack building process like you guys are doing for your pandas :) )
<sveinse> But I admire you're effort on that
<persia> cross-build for development performance makes sense, although in Ubuntu a final native build is always done for deployment.
<sveinse> your
<sveinse> yes
<persia> Thank davidm: it's his idea, and his labour.  Lovely stuff though.
<sveinse> BTW does anyone here know how I can list which dirs and their order ld.so is searching for so's? I'm not sure if "cat /etc/ld.so.conf.d/*.conf" is giving the right order
<persia> I think it does.
<persia> If not, then the .d implementation is not matching expectations.
<persia> `ldconfig -p` seems to generate something that may help if you're encountering an issue.
#ubuntu-arm 2011-06-19
<sveinse> Is there a packages.ubuntu.com which search the armel packages?
<persia> No, nothing on ports.ubuntu.com shows up somewhere like that.
<persia> The best option is to use a package manager in an armel environment *OR* to pull local copies of the Packages files, and then dig through them (apt-cache can be tricked into using an alternate file, and grep-dctrl (from dctrl-tools) gives even more options.
<sveinse> I can run apt-cache natively and search from it. Albeit I don't know how to find the name of a package when I know the name of the file
<persia> *but* there ought be almost no difference in the available packages on a per-architecture basis.
<persia> Install apt-file for that (although `dpkg -S ${FILE}` works for currently-installed files)
<sveinse> thanks
<persia> Or just use packages.ubuntu.com : the contents of packages really shouldn't differ much between architectures
<persia> (although they do for some special cases)
<sveinse> Hmm. It does in this case: I'm looking for the powervr/SGX drivers rsalveti added. These are OMAP3 specific
<persia> https://wiki.ubuntu.com/ARM/OMAP/Graphics might help with that
<sveinse> perfect! Thanks
<persia> I believe those drivers *only* work on the PVR core in omap3, and don't do the right thing for arbitrary PVR implementations.
<sveinse> Yes, I'm aware of that. I've been talking to rsalveti earlier
<sveinse> thanks anyways
<sveinse> Are there any specific plans for armel HF in ubuntu?
<armin76> another question bites the dust :P
<GrueMaster> ogra: ogra_ Ping.
<GrueMaster> Gotta run, but I got an ac100-10U (showed up when I got home from UK).  Backed it up and installed your natty image.  worked no problem.  The partitions are different than on the 10Z.  Very odd.
<GrueMaster> Anyway, off to do yard work.
#ubuntu-arm 2012-06-11
<angs> I have some boards that runs debian and some of them runs ubuntu. How can I understand which one is ubuntu and which one is debian? uname -a shows "Linux omap 3.2.0-psp7 #1 Fri Apr 13 04:55:05 UTC 2012 armv7l armv7l armv7l GNU/Linux"
<rbasak> angs: on Ubuntu, "lsb_release -a" will tell you. I don't know if there's a better way.
<angs> thanks a lot, it shows it is ubuntu:)
<djszapi> ogra_: hey
<djszapi> ogra_: gpio library is not available for Ubuntu arm ? :o
<djszapi> perhaps it is the sysfs that is advertised for usage nowadays.
<janimo> lilstevie, do you know if there are git trees of tf101 kernels with better history and changes rationale than what ASUS' tarballs provide?
<lilstevie> janimo, yes/no
<janimo> lilstevie, please expand on the yes branch :)
 * janimo figures this is an interactive adventure
<lilstevie> janimo, we can match to where they most likely branched from nvidias tree
<lilstevie> with their history
<lilstevie> but asus themselves strip *ALL* history before releasing it
<janimo> lilstevie, that is what I was going to check, seeing only it is a 2.6.39.4
<janimo> but compared to upstream pristine linux-stable 2.6.39.4 there
<janimo> is a 15Mb patch :)
<lilstevie> yeah, well matches with nvidias android tree
<lilstevie> look at androids 2.6.39.4
<lilstevie> it is a pain though
<lilstevie> cause there are a few tags
<lilstevie> RaYmAn has a script which diffs each tag against the asus release and suggests the closest match
<lilstevie> we have done it to the tf201, tf101 is next on the list to be moved over to nvtegra
<janimo> lilstevie, by moved over to nvtegra and 'we' what do you mean? Kernels used by the mod community?
<lilstevie> androidroot team, me bumble-bee RaYmAn kmdm and IEF
<lilstevie> janimo, ^^
<janimo> lilstevie, ok
<xase_> I cant believe theres no tutorials for running ubuntu on nookcolor besides  that silly chroot nonsense.
<prpplague> hehe
<GrueMaster> xase_: I was going to work on that for Oneiric, but was swamped with the arm server bringup.  Sadly, I have since moved on to a differnt job (and subsequentially lost time/interest).  Sorry.
<xase_> GrueMaster: no problem do you have an archive of your work available?
<GrueMaster> No.  I didn't get too far into it.  I barely spent a week on it, mainly going through the Nook source and seeing what I needed to implement.
<xase_> damn
<janimo> marvin24, are you working more on nvec until it gets out of staging?
<marvin24_DT> janimo: yep
<janimo> marvin24, do you have the docs from nvidia?
<marvin24_DT> yes
<janimo> the README in the tree suggests there are no docs at all
<marvin24_DT> oh, that deserves a patch ;-)
<marvin24_DT> in fact, I "appeared" some month ago
<janimo> ok, just making sure you're not missing out :) I just discovered they're public last week, and downloaded them today
<marvin24_DT> together with the tegra2/3 documentation
<janimo> yes, Nov 11 from what I saw
<marvin24_DT> janimo: public?
<janimo> ah tegra3 as well? I thought that's still WIP
<marvin24_DT> you need to register first ...
<janimo> well, public with annoyance, but not private/NDA etc :)
<marvin24_DT> mmh, I think there is a NDA at least, but I didn't read it to the end
<janimo> marvin24, so this means the EC doc that was floating around of the chip used in the ac100 is not necessary, as you only need the tegra2 side/protocol
<janimo> ah did not read either :)
<marvin24_DT> mmh, I don't know of any EC doc floating around ... wait
<marvin24_DT> ah, found it
<marvin24_DT> of course, for this has no NDA ;-)
<marvin24_DT> normally, you would have to register here http://developer.nvidia.com/tegra-2-technical-reference-manual
<janimo> yes, I registered and downloaded this and the TRM today
<janimo> there was an EC doc for an embedded keyboard controller in the ac100 last year
<janimo> which I was told was the only doc that helped the nvec initial development
<marvin24_DT> maybe that was the original source
<marvin24_DT> it had some documentation inside
<marvin24_DT> janimo: can you try to get linux-backports-modules-cw-3.3-precise-generic building on ARM ?
<janimo> is that a package?
<marvin24_DT> eh, no, the binary
<marvin24_DT> wait ...
<janimo> found it
<janimo> but it's for the 3.2.0 precise kernel
<marvin24_DT> linux-meta is the source :-(
<marvin24_DT> should be buildable on any kernel
<janimo> not even amd64 is enabled
<marvin24_DT> I have it here on my amd64 ...
<marvin24_DT> https://launchpad.net/ubuntu/precise/amd64/linux-backports-modules-cw-3.3-precise-generic
<janimo> ok, so Architecture: is misleading
<janimo> linux-backports-modules-3.2.0 the package
<janimo> marvin24, which drivers are needed on arm?
<marvin24_DT> I don't know, but paz00 needs rt2xx
<marvin24_DT> I think they can also be useful for panda whatever
<marvin24_DT> the package contains all wifi drivers
<marvin24_DT> btw, I still can only get a 3.1 kernel booting with "console=ttyS0,115200n8 quiet" enabled
<marvin24_DT> this ensures nothing it printed to the console on boot
<janimo> so not yet ready for uploading I guess? Any chance of newer kernels being better?
<janimo> how much of what's working now is not yet ported to 3.5?
<marvin24_DT> everything gpu and power save related is missing
<marvin24_DT> (which is too important to be skipped)
<janimo> marvin24, are the changes in 3.5 too big so that code need significant rewrite?
<janimo> I see nvidia devs steadily sending patches upstream
<marvin24_DT> yeah, still unportable I think
<marvin24_DT> there are lots of nv engineers already working on it
<marvin24_DT> but it takes time
<marvin24_DT> somehow nv decided to rewrite everything at least three times
<marvin24_DT> this is the price you have to pay to get a product quickly to market
<marvin24_DT> you just cannot do it in a sane way
<marvin24_DT> and mainlining is only low priority compared to that
<marvin24_DT> I don't want to know how many developers worked on porting win8 to tegra3
<marvin24_DT> and even less I want to see that code
<janimo> :)
<janimo> in that case they may not rewrite at all as there's no mainlining required ever, and win8 will be around for many years
<janimo> maybe it's only the FOSS model that gives grief to developers. Or at least this type of grief
<marvin24_DT> I would be interested in some kind of statistics how much developer month it takes to port some arch to linux and windows
<marvin24_DT> and how much time it consumes to maintain it
<marvin24_DT> during product lifetime
<lilstevie> marvin24, tbh because of UEFI, it would be more the UEFI code that you would want to see less :p
#ubuntu-arm 2012-06-12
<janimo> marvin24, do you keep tracking nvidia's tegra tree with your ac100 3.1 one? I just sa you did a merge recently
<janimo> any specific ac100 bugs solved?
<marvin24> janimo: last merge was yesterday
<marvin24> beside the console, I'm not aware of any bugs
<janimo> I am testing a build now
<marvin24> eh, maybe reboot doesn't work - I need to check this
<marvin24> maybe someone at nv is already looking into the console problem
<satellit__> I have been unable to get ifupdown (eth0) to work on my TrimSlicePRO / wireless is very slow/ using USB eithernet adapter for wired networking ATM any Ideas how to fix stock cat-5 in TrimSlicePro?
<janimo> ogra_, marvin24 uploaded a 3.1 based package. It finally booted here, not sure what I did wrong initially but it had bad UUID for the boot partition
<angs> I get the following error for wpa_supplicant -u http://paste.ubuntu.com/1037470/
<angs> can anyone tell me why do I get that error?
<infinity> janimo: Your linux-ac100 had a sad.
<infinity> janimo: /bin/sh: 1: lzop: not found
<marvin24_DT> yes, lzo compressed kernels need lzop
<marvin24_DT> janimo: also make sure to boot with "console=tty1"
<marvin24_DT> this does not enable splash, but at least it doesn't crash anymore
<angs> why can't I find any result for "realtek" or "rtl8192cu" on http://packages.ubuntu.com
<marvin24_DT> angs: should be supported by the kernel already
<marvin24_DT> drivers/net/wireless/rtlwifi
<angs> I can see rtl8192cu  on lsmod, does it mean that the driver is already installed?
<infinity> angs: Yes.
<angs> thank you
<angs> ifconfig wlan0 up shows me "wlan0: ERROR while getting interface flags: No such device" and the usb adapter is plugged
<angs> uname -a  > Linux omap 3.2.0-psp7 #1 Fri Apr 13 04:55:05 UTC 2012 armv7l armv7l armv7l GNU/Linux
<angs> do I need to install something to use the wifi module?
<janimo> infinity, oh, I had no idea it used lz by default, I certainly did no intend to enable that
<janimo> marvin24, that is up to the installer to set up no? Or shall I change default cmdline in the kernel configs?
<marvin24_DT> angs: you may post the output of dmesg somewhere
<marvin24_DT> janimo: it's a kernel config option
<marvin24_DT> (kernel compression)
<infinity> angs: ifconfig -a, and find the right device?
<marvin24_DT> I have it enabled
<angs> ifconfig -a shows eth0 and l0. I can not see the whole dmesg, because it is too long
<angs> is there any command to paste the output into pastebin or paste.ubuntu.com?
<marvin24_DT> angs: run "dmesg | curl -F 'sprunge=<-' http://sprunge.us"
<marvin24_DT> and post the output
<angs> http://sprunge.us/XQWW
<marvin24_DT> angs: urg
<marvin24_DT> your usb host has problems
<angs> is it too bad?
<marvin24_DT> well, just a kernel bug I think
<marvin24_DT> file a bug report I would suggest
<angs> are you able to see that if it is because of the image that I loaded or the problem generated after the image loading?
<angs> where can I report it on bugzilla.gnome.org?
<marvin24_DT> angs: what platform is it?
<marvin24_DT> I only identified omap
<marvin24_DT> where did you got the image from?
<angs> I am using beaglebone and get the image on http://elinux.org/BeagleBoardUbuntu
<marvin24_DT> looks like ubuntu precise, to you can file a bug on bugs.launchpad.net
<angs> thank you
<infinity> angs / marvin24_DT: Ubuntu doesn't provide beaglebone kernels, that's a third-party deal.
<infinity> (So, please don't file Ubuntu bugs about their kernels)
<marvin24_DT> infinity: sorry, exchanged beaglebone with beagleboard
<infinity> I think it would be shiny if someone made our omap kernel work with the bone, but it sure doesn't right now. :P
<ogra_> well, someone should send someone of us a bone then :)
<marvin24_DT> isn't this the same SoC?
<ogra_> nope
<ogra_> its amXXXX someting vs omap3 iirc
<ogra_> not sure, that amXXX might be omap based but its definitely different SoCs in the end
<marvin24_DT> never heard of this one
<marvin24_DT> but the ubuntu kernel seems to boot
<infinity> It does?
<marvin24_DT> Linux version 3.2.0-psp7 (root@panda-a1-1gb) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) ) #1 Fri Apr 13 04:55:05 UTC 2012
<ogra_> AM335x is the actual SoC name
<marvin24_DT> it's an omap2
<infinity> marvin24_DT: That's not an Ubuntu kernel.
<marvin24_DT> maybe the kernel was only compile on ubuntu
<infinity> Compiled with our toolchain, yes, but not our sources. :)
<ogra_> http://www.ti.com/lsds/ti/dsp/platform/sitara/whats_new.page?DCMP=AM33x_Announcement&HQS=am335x
<ogra_> TI's new $5 CPU
<ogra_> heh
<ogra_> AM335x Evaluation module (EVM) from TI is available for $995.
<ogra_> wow, so they added peripherials for $990
<prpplague> GrueMaster: ping
<GrueMaster> prpplague: pong
<parabyte> interesting
<parabyte> I did not realise there was a ubuntu arm channel
<prpplague> parabyte: there is a ubuntu leg channel as well
<parabyte> i might install ubuntu on my nasty android netbook i like the interface you guys got unity
<parabyte> looks interesting from selling netbooks point of view
<parabyte> me personally i like my e17 or xfce
 * prpplague is not a fan of unity
<parabyte> newbies love it ;)
<parabyte> wondermedia wm8650 i got
<prpplague> indeed
<parabyte> iv had it running Debian squeeze
<parabyte> cheapest computational device i could find on ebay with a display and keyboard
<parabyte> !
<parabyte> cpu is really weak
<parabyte> from what i can make out has a arm Version 4 architecture
<infinity> janimo: Thanks for the fixed ac100 upload.  I was just about to nag you again, but figured I'd check LP first, and there it was. ;)
#ubuntu-arm 2012-06-13
<infinity> janimo: I uploaded -meta for you.
 * prpplague looks around 
<prpplague> ogra_: hello
<prpplague> ogra_: hmm, some folks are reporting that they are not able to send to the channel
<infinity> prpplague: Are they joined?
<infinity> prpplague: The only two modes this channel has (+c and +n) mean, respectively, no colour messages, and no external messages.
<prpplague> thats probably it
<prpplague> infinity: just thought i would ask since i have no troulbes
<prpplague> infinity: ahh indeed, these users were logged in via the web interface on the beagleboard.org web site
<cheng> Hi, I have create a file system using 'sudo rootstock --fqdn evm8168 --login ubuntu --password ubuntu --imagesize 4G --seed build-essential,openssh-server,apt --dist natty --serial ttyO2', during booting i cannot see the login prompt on ttyO2 (http://pastebin.com/ZwexEa0U)
<waltermixxx_> testing
<waltermixxx_> ah, I can type now....
<prpplague> waltermixxx: now that you have a real client
<waltermixxx_> thanks again for your help :)
<waltermixxx_> now, do you happen to know why my keyboard and mouse are not being detected by my newly installed ubuntu image 11.10 ;)
<prpplague> waltermixxx: helps to report what your platform is
<waltermixxx_> Beagleboard xM
<waltermixxx_> using the image and instructions from https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<waltermixxx_> using the 11.10 image
<waltermixxx_> :)
<waltermixxx_> booted up, and it went through the configuration on it's own, but when it came time to select a country, i was unable to.
<waltermixxx_>  the site mentions this patch:
<waltermixxx_> Download http://people.canonical.com/~tobin/maverick/beaglexm.tar.bz2
<infinity> cheng: We'll skip for a moment that rootstock is unsupported, and natty will be soon too.
<waltermixxx_> but when i clicked on it,  the file could not be found
<infinity> cheng: You almost certainly wanted tty02 (with a zero), not ttyO2 (with an oh)
<infinity> waltermixxx_: I highly recommend using 12.04, not 11.10.
<waltermixxx_> i heard there were issues with speed?
<waltermixxx_> i could certainly down load and try
<waltermixxx_> :)
<infinity> I'm not sure what those issues would be.
<infinity> 12.04 is armhf, and tends to be a little speedier overall.
<waltermixxx_> do you suspect I won't have keyboard and mouse issues, must be a driver issue. :)
<waltermixxx_> I will do that
<waltermixxx_> thank you for your advice
<waltermixxx_> should not take too long...
<infinity> I suspect 12.04's kernel will treat you better.  I don't have an xM, but I know others who tested on them.
<waltermixxx_> it's 12:30 AM here but I cannot resist
<waltermixxx_> :) cheers
<infinity> https://wiki.ubuntu.com/ARM/OmapDesktopInstall
<cheng> can this (https://wiki.ubuntu.com/ARM/OmapDesktopInstall) be run on dm8168-cortex A8 chip?
<cheng> am i am not using xM, I can still apply the kernel to my board?
<infinity> cheng: I know nothing of the dm8168, but I suspect we don't supply images that will boot on it directly.
<waltermixxx_> downloading as we speak :)
<cheng> 12.04 suppose to run under beaglexM?
<waltermixxx_> i will let you know cheng if it runs... but infinity says it does :) just writing the image to the sd card now.
<waltermixxx_> well it's running
<waltermixxx_> mouse and keyboard working
<waltermixxx_> just waiting for it to finish configuring
<waltermixxx_> i was able to select English
<waltermixxx_> and click continue
<waltermixxx_> :)
<janimo> infinity, thanks for the meta, I was first going to wait and see if the kernel boots for people in quantal before making it the default, but hey it's quantal
<waltermixxx_> well ubuntu 12.04 is up and running on beagleboard xM
<waltermixxx_> no sound working
 * satellit_ testing Deja Dup on TrimslicePro - Backing up to external USB 500GB HD  should I expect any problems?
<satellit_> backing up / and /home
#ubuntu-arm 2012-06-14
<sapiens> hello :)
<sapiens> I have a question...
<sapiens> I'm quite new, so some things may be harder for me to understand :)
<sapiens> but I want to install flightgear on the beagleboard
<sapiens> I have an xm, rev c
<sapiens> I installed ubuntu 11.04 on it
<sapiens> ubuntu 11.04 r7 minimal armel...
<infinity> sapiens: That's not an official Ubuntu image.
<infinity> sapiens: For starters, I'd suggest an official 12.04 image.
<infinity> Oh, at which point, you'll find out that flightgear doesn't work on ARM...
<sapiens> infinity, I'd like to, but I need to have the openscenegraph installed
<sapiens> how come it doesn't work?
<infinity> Because of the lack of openscenegraph, as you note.
<sapiens> well... I have it installed on 11.04
<sapiens> ;)
<sapiens> It installed good with the synaptic
<infinity> Yeah, and flightgear is also in 11.04
<infinity> I have no idea if either actually works.
<sapiens> I can boot it too
<micahg> hrm, openscenegraph looks like it just needs one of those GL fixes
<infinity> Oh, I see, it's GL/GLES fallout.
<sapiens> but when in subsystems... I have a nasal runtime error
<GrueMaster> sapiens: You would see better performance with 12.04 armhf.
<infinity> So, yeah, OSG on natty will work, but it won't have any hardware acceleration.
<infinity> GrueMaster: Yeah, but no openscengraph or flightgear on 12.04, so it's a moot point for him. :P
<sapiens> :)
<infinity> It's going to suck anyway.
<infinity> No hardware acceleration, and I can't imagine it'll be "fast" with software rendering.
<micahg> hrm, if it's the same issue in precise, it's SRUable :)
<micahg> and it looks to be that way
<infinity> micahg: "one of those GL fixes", you say?  You say this as if you've done some QTGL->GLES porting.
<micahg> infinity: no, but I've seen other people's patches :)
<infinity> micahg: Well, I look forward to seeing yours, then. :)
<micahg> I keep telling myself one of these days I'll figure them out
<sapiens> ok, but seriously... I have these nasal runtime errors
<micahg> I guess at this point in Debian's release cycle there's no chance of GLES on arm for Debian
<sapiens> how can I fix them :)
<infinity> sapiens: "nasal runtime errors" means nothing to me.
<infinity> micahg: Nope.
 * micahg passes sapiens a tissue
<infinity> micahg: And it'll be a bit of an uphill battle to convince people to do it, since our motivation is binary drivers.
<sapiens> lol
<infinity> micahg: In Debian, if no one cares about binary drivers, it's just crazy extra work to have one port use GLES.
 * infinity is still really annoyed that GLES even exists and wasn't just, say, GL1.2
<infinity> Would have been so much simpler if it had been a strict subset (or older version), instead of what it is. :/
<waltermixxx_> howdy
<waltermixxx_> howdy, I just installed the latest 12.04 ubuntu for beagleboard xM and I'm not getting any sound...
<waltermixxx_> dummy output is listed in the sound control panel, play sound through....
<waltermixxx_> initrd.img version 3.2.0-24-omap
<waltermixxx_> if that helps
<infinity> waltermixxx_: Probably needs someone to write a ucm profile for it.  I don't have an xM.
<infinity> waltermixxx_: See the profiles in /usr/share/alsa/ucm/ for other boards.
<waltermixxx_> ok will check that out
<infinity> waltermixxx_: And /lib/udev/rules.d/90-alsa-ucm.rules is where they get loaded.
<waltermixxx_> no beagle in there
<waltermixxx_> just panda pandaes spd4430 and tegraalc5632
<infinity> waltermixxx_: That's sort of my point.
<waltermixxx_> i understood that, simply confirming :)
<waltermixxx_> should ubuntu be so slow on this board?
<waltermixxx_> not slow all the time
<infinity> Everything should be slow on that board.
<waltermixxx_> lol
<waltermixxx_> :)
<infinity> Also, running from SD is awful.
<waltermixxx_> yes I saw the swap file on it
<infinity> If you have a USB hard drive, I *highly* recommend installing to it.
<infinity> (using a d-i netboot image)
<waltermixxx_> just put the boot files on the sd and put the rest on the usb drive
<infinity> We're dropping the preinstalled images in quantal for this very reason.
<infinity> It's an awful user experience.
<waltermixxx_> i understand.
<waltermixxx_> so sound isn't happening any time soon?
<waltermixxx_> i suspect I don't need sound
<infinity> You could probably make sound go yourself with minimal effort.  And if you do, I'd happily integrate the patch in Ubuntu.
<waltermixxx_> not sure I need a gui at this point... but it's nice to have another working sd image :)
<infinity> But I have no xM of my own to fiddle with, so..
<infinity> Not much I can do.
<waltermixxx_> i appreciate the advice...
<infinity> If you don't need a GUI, start with a server image, you'll be much happier with the speed.
<infinity> Our default GUI environment kinda eats all your RAM.
<waltermixxx_> :)
<waltermixxx_> i think that is a good idea
<waltermixxx_> the server images available where I got the desktop image....
<waltermixxx_> ?
<waltermixxx_> that was a question :)
<waltermixxx_> and the ones listed there, they don't have a gui?
<waltermixxx_> Ideally I just want a basic web server,  and something to mess with gpio's
<waltermixxx_> i have a Trainer xM for beagle board
<waltermixxx_> hoping to light up some leds
<waltermixxx_> :)
<waltermixxx_> (people get so excited about that... me included...)
<waltermixxx_> starts there and then a dog treat dispencer....
<waltermixxx_> with a web interface :)
<waltermixxx_> does the server image on the site come with apache?
<waltermixxx_> and python?
<waltermixxx_> or would I simply do a get-apt install apache
<waltermixxx_> kinda thing...
<waltermixxx_> you may be able to tell, I'm a linux nubee
<waltermixxx_> :)
<waltermixxx_> is it easy to take the sd card that I currently have and move the linux install onto a usb hard drive?
<infinity> waltermixxx_: Oh, sorry.  Got distracted.
<waltermixxx_> np
<waltermixxx_> :)
<infinity> http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-server-armhf+omap.img.gz
<waltermixxx_> awesome...
<infinity> Alternately, if you have an external HDD (do you?), you should try a netboot image.
<waltermixxx_> i think i saw some instructions on that
<infinity> Not much to instruct.
<infinity> http://mirrors.0c3.net/ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu136/images/omap/netboot/
<infinity> Grab either boot.img-fb.gz or boot.img-serial.gz (depending on if you're using a keyboard and monitor, or a serial console), zcat the image to an SD card, and boot.
<infinity> It'll install the OS to your hard drive, and the kernel and bootloader to the SD.
<waltermixxx_> wicked
<infinity> As for what's included in a barebones server install, the answer is "not much", but the whole archive is available to you.
<infinity> So, "apt-get install apache2", etc.
<waltermixxx_> keyboard and monitor
<waltermixxx_> so boot.img-fb.gz
<infinity> Right.
<waltermixxx_> http://mirrors.0c3.net/ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu136/images/omap/netboot/  does not want to open...
<infinity> Oh, hahahaha.
<infinity> That would have worked better if it wasn't my local mirror.
<infinity> s/mirrors.0c3.net/ports.ubuntu.com/
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu136/images/omap/netboot/
<waltermixxx_> thank you... that works
<infinity> I really should punch a hole for that mirror from the outside, since I make that mistake so often. :P
<waltermixxx_> np :)
<waltermixxx_> i appreciate the correction
<waltermixxx_> the uncompressed boot.img-fb file
<waltermixxx_> i zcat that to the sd card
<infinity> Well, the compressed one.
<waltermixxx_> oh no need to uncompress it, that's right
<infinity> zcat boot.img-fb.gz > /dev/sdX
<waltermixxx_> :)
<infinity> Whatever X is your card reader.
<waltermixxx_> mmcblk0
<waltermixxx_> :)
<infinity> Or that. :)
<waltermixxx_> once I boot from it, will it give me the choice of what I want to install on the external drive?
<waltermixxx_> server or desktop?
<waltermixxx_> gonna try it now.
<infinity> It'll just be serverish, IIRC.
<infinity> You could preseed it to do desktop (or install ubuntu-desktop later), but since that's what we're trying to avoid... ;)
<waltermixxx_> server I think is what I am after :) and a slim line server sounds good
<waltermixxx_> i took some notes on the above,  and will give it a shot when I find an external hd that is powered by external power adapter and not via usb
<waltermixxx_> hmmm
<waltermixxx_> I may try it first on an 8 gig usb stick
<waltermixxx_> that should work... for testing...
<waltermixxx_> boot from sd, and install on 8 gig usb stick?
<infinity> waltermixxx_: Yeahp, that works.
<infinity> waltermixxx_: That's how I test the installer when I don't have a spare hard drive to kill.
<infinity> waltermixxx_: It's obviously not going to be fast, though still a bit better than SD, in most cases.
<waltermixxx_> ok cool
<waltermixxx_> thanks again for your assistance :)
<codinho> Hi guys
<codinho> is gstreamer works with ducati in 12.04 ?
<twb> Your car is running ubuntu?
<twb> Er, motorcycle
<codinho> twb I mean omap4 ducati
<twb> Never heard of it
<twb> But AFAIK Ubuntu works well on omap4 generally
<codinho> Ducati is hardware accelerator for image processing and video/audio decode/encode
<twb> Oh.  Well I don't know, sorry :-)
<heathkid> anyone here runnning ubuntu on an ARM with a USB wifi adapter that works 100%?
<twb> heathkid: define "100%
<heathkid> as in it actually works and is reliable
<heathkid> doesn't work for a few hours or a day and then stop working...
<codinho> is it possible to install ubuntu-omap-extras-multimedia from trunk ppa on 12.04?
<ppisati> if anyone has an idle panda board and an empy sd card, could you try to reproduce lp1013204? thanks
<ppisati> bug 1013204
<ubot2> Launchpad bug 1013204 in linux-ti-omap4 "Serial losing characters" [Undecided,New] https://launchpad.net/bugs/1013204
<mythos> ppisati, erm, so you loose chars over a serial-console
<mythos> which char is missing?
<mythos> i mean, in your bugreport
<mythos> and you know, that with the default settings (http://www.omappedia.com/wiki/Serial_Port_Settings) it's not unusual, that bits are not transfered right?
<ppisati> any kind of characters
<ppisati> just type and you'll see that some won't get through
<ppisati> some times it works, some times it won't
<ppisati> on armel
<ppisati> on armhf everyhing is ok
<mythos> maybe they use another baudrate?
<ppisati> identical
<ppisati> 115200n8
<mythos> so... which ubuntu should i use?
<mythos> 11.10?
<mythos> oh, i see 12.04 armel
<mythos> i'm going to try it later
<ppisati> the simplest way to reproduce it
<ppisati> get the O omap4 preinstall
<ppisati> once you finished with the installation, let it reboot till the serial console
<ppisati> then paste a long line of text and see what happens
<mythos> i'm going to try it in an hour or so
<mythos> but first i have to go home ;)
<ppisati> mythos: i updated the bug with a comment about reproducing the problem
<ogra_> and make sure the insulation of your cable has no cracks, might be that the chars are dripping out through it :P
<ogra_> what a weird bug :)
<ppisati> yes it is
<ppisati> i swapped hw
<ppisati> cables
<ppisati> sd cards
<ppisati> distributions
<ppisati> kernels
<ogra_> serial terminal app ?
<ppisati> now i want someone else to reproduce it
<ppisati> nope
<ppisati> i'm using cu
<ppisati> well
<ppisati> it works with my amrhf installation
<ogra_> well, did you try screen or minicom ?
<ppisati> so should work with armel
<ogra_> oh, ok
<ppisati> nope
<ogra_> well, who cares ... its armel :P
<ppisati> :)
<ppisati> ogra_: if you can devote and sd card to the cause, i would love it
<ppisati> i want someone else to say "yes, i've it too"
<ppisati> my bad
<ppisati> the sd that i used was actually a preinstalled system were i used to mess on
<ppisati> :P
<ppisati> mythos: ^
<ppisati> ogra_: ^
<mythos> ppisati, so i don't have to? :O
<ppisati> nope
<ppisati> forget about it
<mythos> hurray \o/
 * ppisati feels really stupid now
#ubuntu-arm 2012-06-15
<GrueMaster> http://www.phoronix.com/scan.php?page=article&item=phoronix_effimass_cluster
<lilstevie> GrueMaster: wow, 6 pandaboard ES clustered was heaps more efficient than the atom, that is unexpected
<infinity> lilstevie: It's an Atom 330, that's not a useful or fair comparison.
<lilstevie> infinity: yeah just realized, old as atom
<infinity> lilstevie: Oldest Atom core there is, yeah.
<lilstevie> the z530 atom was also less efficient too though
<infinity> lilstevie: z530 is the same vintage.
<infinity> lilstevie: Both are 45mn non-SoC cores from 2008.
<infinity> lilstevie: A comparison with something from this year would be much more interesting.
<lilstevie> ah
<lilstevie> I didn't know where the z530 fit
<lilstevie> the medfield atom would be interesting
<infinity> Indeed.
<lilstevie> also would be interesting to see performance of something like the S4 in the same situation
<infinity> Well, it would also be interesting to make that an OpenCL cluster, and let the AMD Fusion actually use its GPU.
<infinity> Perf/W could skew a bit there.
<infinity> Cause it's powered up, despite it not being used.
<lilstevie> yeah
<infinity> (Though this is true of the PVR on the OMAP4 as well, there's no way it can come close to delivering the performance of the on-die Radeon on the Fusion)
<lilstevie> agreed
<lilstevie> but then use the tegra powered openCL rig and see how that one goes :p
<infinity> Has anyone mangled OpenCL for the Tegra yet?
<lilstevie> that isn't an on-die gpu though
<infinity> "Tegra does not currently support CUDA or OpenCL. NVIDIA believes in and invests heavily in GPGPU computing so this is an area we're investigating but do not have any announcements for Tegra at this time."
<lilstevie> yeah
<lilstevie> not likely to happen
<lilstevie> :p
<infinity> Oh, right, I remember researching this before.  There was some internal corporate fear that supporting CUDA and OpenCL on the Tegra parts would cut into other business units.
<infinity> Cause one could ditch the x86/GeForce clusters and build Tegra clusters instead.
<infinity> To which, I say, "let 'em", cause they'd still hit two different HPC markets.
<infinity> Given the workload-per-core characteristics would be dissimilar.
<infinity> But, arguing with management over money issues is never easy.
<lilstevie> heh
<infinity> That actually puts AMD in a unique situation.  I wonder if they realise this and have tried selling into that market more heavily.
<infinity> Cause, one would think, bang-for-buck, Fusion would beat Atom, i7, and any ARM part for an OpenCL solution.
<lilstevie> yeah
<lilstevie> imagine how killer they could be with tegra if they put their gpu tech to work though, full OpenGL rather than just the embedded standard
<infinity> Yeah, it could be shiny.
<lilstevie> I can't see why the ULP GeForce would be ruined with GL
<infinity> I'd also love to see an AMD ARM part, but I suspect they don't have the spare cash flying around internally to hedge their bets on forking their CPU division.
<lilstevie> yeah
<infinity> And no, there's no reason whatsoever that the GeForce on the Tegra couldn't support full OpenGL, it was a conscious decision not to.
<infinity> Partially because of the CUDA/shader/CL concerns and, of course, because GLES is the mobile standard.
<lilstevie> yeah, well GLES being the mobile standard isn't so much of a problem
<lilstevie> you could handle compat in driver really
<infinity> But, from what I understand, it's just a "normal" GeForce under the hood.
<infinity> Like, electrically.
<lilstevie> I suspect you may be right with CUDA/shader/CL
<lilstevie> yeah
<lilstevie> thats what I have heard too
<lilstevie> it will be better if the open driver ever makes it too
<lilstevie> the nvidia ones are pretty bad
<infinity> lilstevie: Pretty bad is an understatement.
<lilstevie> infinity: well I have a tegra3 device and it is pretty bad, but the earlier drivers were way worse on the trimslice
<lilstevie> :p
<prpplague> ho ho hum
<_william_> Hi all :)
<_william_> i'd like to setup a chrooted environment and i'm looking for packages repositories in order to add software into the chroot. Is there some ARM repo existing ?
<ogra_> _william_, http://ports.ubuntu.com/ubuntu-ports/
<ogra_> use that as the mirror in your sources.list
<mlankhorst> *sighs at binary drivers* immediately know when they're loaded because you start seeing glitches :\
<mahmoh> does /etc/flash-kernel.conf get used any longer with Quantal flash-kernel?
<GrueMaster> mahmoh: Simple test.  Delete it (or change it) and see what flash-kernel does.
<dannf> mahmoh: no ref to it in the source i can find
#ubuntu-arm 2012-06-16
<mahmoh> GrueMaster: thx, I tried that and it did nothing - turns out the new flash-kernel doesn't use it, all that's handled in the initrd now, which appears broken
<mahmoh> dannf: thx for looking ^
<cvanvliet> should I have an omaplfb module being able to load with a stock Linaro (Ubuntu) image. When I try to start PVR, tells me I have no module
<cvanvliet> I have an Overo IronStorm (dm3730)
<infinity> cvanvliet: Make up your mind, is it a Linaro image, or stock Ubuntu?
<infinity> Two very different kernels.
<infinity> If you use a 12.04 Ubuntu image, PVR will Just Work.
<infinity> If you're using Linaro images, those are entirely different kernels, meant to hilight the latest and greatest upstream bits, but the PVR drivers aren't built to work with them.
<cvanvliet> infinity, thanks
<cvanvliet> I think that is the info I needed
<cvanvliet> I cant use 12.04 as it is armhf and we need the SGX drivers
<infinity> Hrm?
<infinity> TI is only building the drivers for armhf now.
<cvanvliet> OMAP3?
<cvanvliet> I thought is was only OMAP4
<infinity> Oh.  No, for Panda.  I'm not sure what they're doing for omap3.
<infinity> I missed the bit above about the plaform.
<infinity> You could use 12.04/armel, though.  We just don't provide preinstalled images for that.
<cvanvliet> infinity, it is all new to me, all info helps ;)
<infinity> We do provide d-i netboot images, if you have an external HDD to install to.
<cvanvliet> ahh, i did not no there was a 12.04 armel, I was under the impression it was only armhf
<cvanvliet> where is the best walkthrough (as I said noob)
<infinity> armhf is the only thing we're supporting as an LTS, and the only thing we made nice preinstalled images for.
<cvanvliet> got it
<infinity> But you can install armel readily enough with a d-i image.
<infinity> Like I said, if you have an external HDD.  Which is the sane way to go anyway.
<lilstevie> where possible armhf is much better
<lilstevie> but yeah, not possible for you
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/omap/netboot/
<cvanvliet> lilstevie, yeah, understood
<infinity> lilstevie: Yeah, we tried to lean on TI to get armhf builds of omap3 binary blobs, but they really only seemed to care about omap4.
<lilstevie> I was in the same boat
<infinity> Which made some sense.
<cvanvliet> our target has to be for now omap3
<lilstevie> infinity: yeah, why waste resources on old hardware
<infinity> lilstevie: Pretty much.
<infinity> lilstevie: I might push them again at some point.  I'd happily SRU armhf blobs into precise.
<lilstevie> or if you are nvidia why waste resources period
<lilstevie> heh
<infinity> ndec: Say, can we get armhf builds of omap3 sgx blobs for precise?  Kthx.
<infinity> robclark: ^
<lilstevie> I will just be happy once I can get live-build to cooperate and build me a nice image
<infinity> lilstevie: Oh, one of my work items (if I find the time to do it) is to mangle live-build so that it can produce "proper" Ubuntu images end-to-end.
<lilstevie> but then part of me says I should wait until nvidia release r15rc
<infinity> lilstevie: In other words, taking all the "magic" that we do with cdimage/debian-cd out of the loop, so what happens on the buildds can happen on your local machine, and the result is identical.
<lilstevie> oh nice
<lilstevie> I still am at the stage of configuring it to build something for me
<lilstevie> getting ready to produce tf201 images
<cvanvliet> infinity, any chance TI , will change their opinion, we are using gumstix / IGEP devices
<infinity> Well, for the weird way ogra_ does ac100 images, that goal's already there.
<cvanvliet> and that is why stuck at omap3
<lilstevie> infinity: yeah, but that isn't how I do things
<lilstevie> :p
<infinity> Installing livecd-rootfs, and mangling the ac100 target to do what you want, and building with -fplain will get you a bootimg/tarball installer mess.
<lilstevie> I have no bootimg
<lilstevie> :)
<infinity> Ahh.
<lilstevie> I boot a zImage/initrd from /boot
<lilstevie> in the fs
<infinity> Well, that's obviously cleaner.
<infinity> Not sure why that wasn't an option on the ac100.
<infinity> Maybe it was, and Oli's just weird.
<lilstevie> well
<lilstevie> cause by default it isn't
<infinity> That would do it.
<lilstevie> this is a highly customized kexec solution
<infinity> Check.
<lilstevie> although multiboot would offer the same
<lilstevie> kexec doesn't work by default on the tf201, but with some magic that hardboots the device it does :p
<lilstevie> bl inits all the hw from scratch
<lilstevie> kernel decompressor code finds a flag in memory
<lilstevie> jumps to different logic that boots the other kernel
<infinity> lilstevie: That sounds like a pretty violent abuse of kexec.  Well done.
 * infinity thinks it might be sleep time.
<lilstevie> it is violent but gotta thank the guy who thought of it
<lilstevie> it works amazingly
<lilstevie> night
<cvanvliet> night infinity and thanks
<cvanvliet> following these instructions here, for netboot -> http://testcases.qa.ubuntu.com/Install/ARM/NetBoot
<cvanvliet> I need to load a specific module for my network card
<cvanvliet> how do i do that?
#ubuntu-arm 2012-06-17
<lilstevie> infinity: this shows the hacked up kexec in action https://www.youtube.com/watch?v=sK_4cXHnyss
<gildean> lilstevie: any idea if the same would be possible on a samsung galaxy tab 8.9?
<gildean> i got one from work, haven't had much time to play around, but dualboot would be awesome
<lilstevie> gildean: most likely
<gildean> you haven't seen anyone do it yet tho'?
<lilstevie> well I did it for the original galaxy tab
<lilstevie> admittedly not as well
<lilstevie> but
<lilstevie> :p
<lilstevie> I've always thought the tab 8.9 would be fun
<lilstevie> what SoC does that have? is that one tegra as well?
<gildean> yeah
<gildean> tegra2
<gildean> i watched this yesterday, http://www.youtube.com/watch?v=MShbP3OpASA
<gildean> the last guy says they're upstreaming tegra support
<lilstevie> heh
<lilstevie> gildean: I am finding it hard to follow that video tbh
<lilstevie> gildean: the guy taking it just reminds me too much of http://www.youtube.com/watch?v=AW9Ak9lrJp4
<gildean> lilstevie: well to summarize: at around 49mins linus says fuck you to nvidia and then there's a guy from nvidia at around 60mins who says that despite linus giving the finger they're upstreaming tegra support
<lilstevie> lol
<gildean> and linus actually says: "Nvidia: Fuck you!" and gives the finger
<lilstevie> lol
<lilstevie> I skipped ahead to see it
<janrinze> lovely! just watched it
<lilstevie> janrinze: you have a transformer or transformer prime?
<janrinze> transformer tf101\
<lilstevie> ah
<lilstevie> nothing to show off for that one yet :p
<janrinze> it actually runs Ubuntu 12.04
<lilstevie> yeah
<lilstevie> I know
<lilstevie> :p
<janrinze> and rtviewer runs on it too :-)
<janrinze> i have the armhf distro on it so it uses full floating point hardware
<janrinze> too bad nvidia did not implement NEON in the Tegra 2
<lilstevie> heh
<janrinze> that would speed up the image processing by a factor of 4
<janrinze> since NEON can do SIMD on 4 floats at a time!
<janrinze> i will do some more testing on a different ARM platform which does have NEON and see if that is possible.
#ubuntu-arm 2013-06-10
<hrw> tgreer: yes, you did
<hrw> tgreer: forgot to select right board
<tgreer> hrw: board type tegra and then support for tegra20 is selected
<tgreer> im wondering if the tegra20 doesnt have the right signatures
<hrw> tgreer: such error means that kernel is not targetting 0xaab machine id
<tgreer> hrw: so i've made a mistake when compiling the kernel then...
<hrw> looks like
<tgreer> but i selected machine type tegra
<tgreer> and ticked the box for tegr 20
<tgreer> i'm wonderinf if the signature for the Hamrony board I'm using is missing...
<tgreer> because there's 2 tegra board types
<tgreer> theres Ventana also
<tgreer> both the same cpu but different model
<tgreer> so I'm wondering if thats the issue
<hrw> tgreer: don't you use DTB?
<tgreer> i've no idea...
<tgreer> all this is very much new to me
<hrw> ok, which kernel version?
<tgreer> 3.8.13
<tgreer> just running make menuconfig just now to double check
<tgreer> CONFIG_ARCH_TEGRA_2x_SOC=y
<tgreer> CONFIG_ARCH_TEGRA_3x_SOC=y
<tgreer> CONFIG_ARM_APPENDED_DTB is not set
<tgreer> you mentioned DTB
<tgreer> do i neeed to set that?
<hrw> depend on bootloader
<hrw> if you use uboot (not too old one) then you can pass dtb to kernel on boot
<hrw> if you bootloader cannot pass dtb then use CONFIG_ARM_APPENDED_DTB
<tgreer> ah
<tgreer> im using fastboot.bin as the bootloader
<tgreer> which im assuming cant do DTB
<tgreer> so i'll set CONFIG_ARM_APPENDED_DTB=y and give that a go
<tgreer> hrw: thanks for your help. /me scoots out
<ValDuare> hi guys
<ValDuare> hey guys how can I upgrade to 13.04 without do-release-upgrade  it requires me installing update-manager and 134 megs of extra packages that i don't have room for heh
<infinity> ValDuare: You could s/quantal/precise/ in /etc/apt/sources.list && apt-get update && apt-get dist-upgrade.  No guarantees that it'll be happy with that.
<ValDuare> ah just change all the names to the new release name eh?
<ValDuare> i'll try that when I get into the office today ty
#ubuntu-arm 2013-06-11
<tgreer> hrw: ping?
<hrw> tgreer: pong
<tgreer> hrw: tried setting that flag to Y
<tgreer> but still getting the same issue
<tgreer> was just wondering if you had any other tips
<tgreer> although i ticked another few boxes so not sure if that made a mess or not
<tgreer> Support for the traditional ATAGS boot data passing is selected
<tgreer>  Provide old way to pass kernel parameters
<tgreer> is selected
<tgreer> as is Supplement the appended DTB with traditional ATAG informati
<hrw> tgreer: but have you appended dtb to the kernel?
<tgreer> er
<tgreer> no idea
<tgreer> how would i do that
<tgreer> i think i can see the option for it in make menuconfig
<tgreer> but no idea what to put
<hrw> tgreer: https://patchwork.kernel.org/patch/1432321/
<tgreer> hrw: so i need a dtbImage.... where would I get one of those?
<tgreer> board-dt-tegra20.c << aha
<tgreer> still no idea how to use it :(
<hrw> marvin24: you know Tegra more than I do. can you help tgreer?
<marvin24> tgreer: make dtbImage?
<tgreer> oh that simple?
<marvin24> I usually attach it "by hand"
<marvin24> so I don't know, but it seems like this
<tgreer> marvin24: so what make dtbImage
<tgreer> and then flash that to the bootloader
<tgreer> or is that not the right image?
<marvin24> ah, there is a .<dt>
<marvin24> tgreer: what do you want to do at all
 * marvin24 didn't read the backlog
<tgreer> tegra 250 harmony development board
<tgreer> trying to get an updated kernel on it to include pcie and the wifi drivers
<tgreer> currently running  3.1.10-g1ff6b94 that came with ubuntu core
<tgreer> got the latest kernel source from ubuntu's git repo
<tgreer> i have 2 questions: which are the right options under Boot options in make menuconfig
<tgreer> and the 2nd is what commands should I run to get the relevant file
<tgreer> normally i do make menuconfig
<marvin24> ubuntu has a tegra kernel?
<tgreer> and then make zImage
<tgreer> marvin24: the armhf kernel boots on it
<marvin24> you have to make dtbs target
<marvin24> and then cat arch/arm/boot/dts/tegra20-harmony.dtb >> zImage
<tgreer> is that after i make zImage?
<tgreer> or instead of
<marvin24> at the same time ;-)
<tgreer> blah
<marvin24> make zImage dtbs
<tgreer> marvin24: ok thanks
<tgreer> before i make the image again
<tgreer> was just wondering if you could confirm if i have the right options ticked
<marvin24> this dtbImage isn't upstreamed as it seems
<tgreer> i will be documenting ALL of the things once i get it working
<marvin24> tgreer: make tegra_defconfig should give you a usable config
<tgreer> okay
<tgreer> will just double check it has the right bits in it for pci-e and then boom we're on
<tgreer> okay make zImage dtbs -j2 running just now
<tgreer> and then will do the cat
<tgreer> all going well i owe you some beer
<tgreer> :)
<marvin24> does you board run uboot or fastboot loader?
<tgreer> fastboot
<tgreer> the nvidia dev kit instructions to load u-boot onto it just make it KO
<marvin24> tgreer: in this case you need to modify the tegra_defconfig defaults
<marvin24> e.g. appended_dtb you know already
<tgreer> damnittttt
<tgreer> making clean and starting again
<marvin24> no need to clean
<tgreer> so set appended dtb to y
<tgreer> and thats it?
<marvin24> I think you also need COMPAT_ATAGS
<marvin24> mmh, maybe not
<marvin24> that's only for 3.1 and uboot
<tgreer> ok set appended_DTB
<tgreer> starting compiling again
<marvin24> also ccache helps speedup kernel builds
<tgreer> (for the record I'm not cross compiling)
<tgreer>  Supplement the appended DTB with traditional ATAG information (ARM_ATAG_DTB_COMPAT) [N/y/?] (NEW)
<tgreer> i'm getting propmpted for this
<marvin24> fastboot isn't really supported on mainline
<marvin24> tgreer: answer no for now
<tgreer> okdaydoke
<marvin24> mainline doesn't have atags
<tgreer> is there a better kernel tree to use instead of the generic ubuntu one?
<marvin24> I think the ubuntu kernel doesn't compile at all on arm, I mean the 3.10 one
<marvin24> at least not last time I tried
<marvin24> but that's because mainline is broken for multisoc
<marvin24> tgreer: just try and find out
<marvin24> tgreer: I have CONFIG_ARM_ATAG_DTB_COMPAT set in my config btw
<ogra_> mainline broken for multisoc ?
<ogra_> we ship it with multisoc
<marvin24> well, mutlisoc + enabling all kinds of modules
<marvin24> in 3.10
<ogra_> for armadaxp, omap and highbank iirc
<marvin24> (the saucy kernel)
<marvin24> they are not build I guess
<marvin24> at least now two weeks ago
<ogra_> hmm, i thought they were
<tgreer> marvin24: ok will try it without
<marvin24> ogra_: some fixes are already upstreamed
<marvin24> but I guess not all will make it in
<marvin24> tgreer: you won't be able to supply kernel command line without
<marvin24> or you need to compile in a command line
<ogra_> well, i guess the kernel team will maintain them as sauce patches then
<marvin24> yes, sad enough
<ogra_> and aim for the next merge window for upstreaming
<tgreer> marvin24: do i need to?
<tgreer> marvin24: i dont supply any kernel command lines at the moment
<marvin24> tgreer: well, you won't get far I think without (e.g. no root), but you can try
<tgreer> hmmm
<tgreer> ok will just stop and add it
<marvin24> do you have hdmi output connected?
<ogra_> (or a serial console)
<tgreer> serial console
<tgreer> no hdmi output working yet
<marvin24> yes, serial console should work
<tgreer> so added in CONFIG_ARM_ATAG_DTB_COMPAT=y
<marvin24> hdmi should also work btw
<tgreer> marvin24: getting nothing out on it currently
<tgreer> but that's next on my hitlist...
<ogra_> you will need fbcon and friends enabled in your config
<tgreer> do i need to add anything else into the .config
<ogra_> for hdmi
<marvin24> tegra_defconfig should have them already
<tgreer> i need what?
<ogra_> framebuffer console
<tgreer> neither of them are in the .config
<marvin24> oh, it doesn't ;-)
<tgreer> lets make menuconfig
<tgreer> and find them
<tgreer> where abouts are they
<ogra_> device drivers ... graphics devices
<ogra_> also take a look at character devices, youo want virtual terminals ... (i.e. if the config pmes originally from android thats always off)
<ogra_> *comes
<tgreer> they're enabled
<tgreer>  <*> Framebuffer Console support
<tgreer> as is  <*> NVIDIA Tegra DRM
<marvin24> maybe I was looking at the wrong branch
 * tgreer gets some air while it compiles
<tgreer> i shall report back in when done
<tgreer> thanks ogra_ marvin24 and hrw
<marvin24> gl
<tgreer> compiled :D
<tgreer> moment of truth :)
<tgreer> yuuussssssssssssss
<tgreer> kernel booting :)
<tgreer> root@tegra:~# uname -r
<tgreer> 3.8.13
<tgreer> WOOOOp
<marvin24> concrats!#
<tgreer> annoyingly i dont see the wireless card though
<marvin24> you need to build the modules
<tgreer> oh
<marvin24> and install on mmc before booting
<tgreer> i thought when it was * it was build directly into the kernel
<tgreer> not as a module
<marvin24> well, wifi cannot be in the kernel because it needs firmware
<tgreer> damnit
<marvin24> maybe this changed today, but I don't know
<tgreer> ah right ok
<tgreer> but the drivers in the kernel tree these days?
<tgreer>   â â    <*>   Atheros mobile chipsets support                            â â
<tgreer>   â â    <*>     Atheros ath6kl SDIO support                              â â
<tgreer>   â â    <*>     Atheros ath6kl USB support                               â â
<tgreer>   â â    [*]     Atheros ath6kl debugging
<marvin24> they should
<tgreer> root@tegra:~/ubuntu-raring# modprobe ath6kl
<tgreer> libkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.8.13/modules.dep.bin'
<marvin24> yes, no modules installed
<tgreer> derp
<marvin24> copy them to a usb drive
<marvin24> if you have usb-storage compiled in
<tgreer> i havent built the modules
<tgreer> also
<marvin24> make modules ...
<tgreer> all the kernel compilcation is on the live SDcard
<tgreer> making it just now
<marvin24> ah, lucky you
<tgreer> do i need to do a make moduleinstall or something?
<tgreer> make modules_install it seems
<tgreer> usbcore: registered new interface driver ath6kl_usb hmmm
<tgreer> you mentioned firmware... should i stick that in lib/firmware/ar6000?
<marvin24> yes
<tgreer> righto. so it cant be in the kernel because it needs firmware... so i should rebuild the kernel without that module in it...
<tgreer> have it as an actual module
<tgreer> and then modprobe it to get it in?
<marvin24> it should auto probe
<marvin24> so all should work as it is now
<tgreer> right just by putting the firmware in the right place?
<marvin24> if you installed linux-firmware it should be there already
<tgreer> er dont think i have..
<marvin24> check the dmesg, maybe you find some hint
<marvin24> it should be automaticly installed
<tgreer> usbcore: registered new interface driver ath6kl_usb is the only mention of it
<marvin24> nothing before that line?
<marvin24> do you have /lib/firmware/ath6k/AR6004 ?
<tgreer> no.. but then i didnt have linux firmware... i had the firmware from the nvidia devkit
<tgreer> let me install linux firmware and try again
<marvin24> well, both should work
<tgreer> root@tegra:~# ls /lib/firmware/ath6k/AR600
<tgreer> AR6003/ AR6004/
<tgreer> i think mine is a 6002
<tgreer> i'll put my ar6002 folder in there
<tgreer> only mention of ath is in: usbcore: registered new interface driver ath6kl_usb
<marvin24> maybe you are still missing something
<tgreer> no luck with the wifi...
<tgreer> any ideas on getting hdmi out to work
<tgreer> Error: Can't open /dev/nvhost-ctrl
<tgreer> Opening channel failed 7
<marvin24> tgreer: that's old userspace
<marvin24> you need to remove it and install opentegra
<marvin24> what's the output of lsusb? (to some pastebin please)
<tgreer> http://pastebin.com/GS6GqNsT
<marvin24> tgreer: there is no usb wifi
<marvin24> only the 3g modem
<tgreer> i've noticed..
<tgreer> also: https://launchpad.net/~ac100/+archive/ppa/+build/4306566 << this one?
<marvin24> yes
<tgreer> https://wiki.ubuntu.com/ARM/TEGRA/AC100#Hardware says to use nvidia-tegra
<tgreer> The nvidia-tegra package is not yet available for armhf. For now, just stay with the default open source driver.
<tgreer> ignore me
<marvin24> tgreer: the nvidia tegra package is for downstream kernels only (v3.1)
<tgreer> ahhh
<tgreer> removing and adding opentegra
<marvin24> mainline uses a totally different driver (open source)
<tgreer> damnit
<tgreer> libudev0 is needed
<tgreer> and isnt in raring packages
<infinity> Nope, you can fish it out of quantal, if you really need it.
<tgreer> oh its in raring-proposed it seems
<infinity> But if you run into upstream binaries that link libudev0, please yell at them to recompile.
<infinity> If it's in raring-proposed, that's NBS cruft, and I'll remove it. :P
<tgreer> its not
<tgreer> its gone now
<tgreer> its the opentegra package thats linking it
<infinity> Where does this opentegra come from?
<tgreer> https://launchpad.net/~ac100/+archive/ppa
<tgreer> only place i can find it
<infinity> Oh, a simple rebuild might fix that.
<infinity> marvin24: Want to rebuild that PPA upload? :P
<tgreer> tegra-hdmi hdmi: cannot set audio to 44100 at 81620000 pclk
<tgreer> well thats progresss
<marvin24> tgreer: rebuild for saucy?
<marvin24> tgreer: that's harmless
<infinity> marvin24: The libudev0 -> libudev1 transition happened in raring, you probably want to rebuild https://launchpad.net/~ac100/+archive/ppa/+build/4307597
<tgreer> marvin24: yes harmless
<marvin24> infinity: I think I build on raring, should I change depends
<tgreer> but still not output on hdmi
<infinity> marvin24: You built on raring, but before the transition.  A no-change rebuild should fix it.
<marvin24> ok
<tgreer> xrandr gives me Can't open Display
<tgreer> marvin24: do you have an example xrandr?
<marvin24> tgreer: check Xorg.0.log first
<marvin24> infinity: sorry, how to rebuild - I cannot find it in the web interface, do I need to bumb the version?
<infinity> marvin24: Yeah, bump the version and reupload.
<infinity> dch -i 'No-change rebuild for the libudev0 -> libudev1 transition.'
 * marvin24 really hates launchpad for you cannot replace a package version ...
<infinity> That's a feature, not a bug. :P
 * marvin24 hates this "feature"
<infinity> Having two different packages with the same filename/version is generally a Bad Thing.
<marvin24> I know
<marvin24> but I still hate it ;-)
<infinity> Heh.
<tgreer> http://pastebin.com/raw.php?i=h0iu2j4B
<tgreer> output from startx
<marvin24> tgreer: looks fine
<marvin24> what kind of device is this "800x480" with hdmi?
<tgreer> except nothing on display
<tgreer> its a small touchscreen device
<marvin24> change the console
<tgreer> i need a keyboard for that
<marvin24> chvt maybe
<marvin24> btw, you can get rid of all the command line parameters except root= and rootwait
<marvin24> they are all downstream kernel specific
<marvin24> and console=ttyS0 of course
<tgreer> still 0 on display
<tgreer> its showing as no input
<tgreer> if i plug it into my laptop works fine
<marvin24> tgreer: hdmi is not hotplug capable yet
<marvin24> did you rebooted?
<tgreer> hmm yes but i'll try again
<marvin24> maybe adding cma=64M may also help, but I think this is only required for large screens
<tgreer> <.<
<tgreer> let me try vga..
<tgreer> still no signal :(
<marvin24> tgreer: paste output of dmesg
<tgreer> http://pastebin.com/CB6AFbkE
<tgreer> i wonder if video=tegrafb  is the issue
<marvin24> remove it
<marvin24> remove everything not needed
<tgreer> i dont know where thats set..
<marvin24> something which created the bootimg
<marvin24> mkbootimg ?
<marvin24> vdd_ldo7,avdd_hdmi: disabling
<marvin24> vdd_ldo8,avdd_hdmi_pll: disabling
<marvin24> that's bad
<tgreer> so remove videospec
<marvin24> I'm off for now, but will come back in a few hours ...
<tgreer> ok will try it without videospec and see what happens
<tgreer> made no diff
<tgreer> blahhragggeeeeeeeee
<tgreer> would i be better off with u-boot as my bootloader?
<tgreer> seems the fastboot binary has those details hardcoded
<tgreer> this is so complex... tried changing the fastboot.bin and still same kernel command lines
<marvin24> tgreer: how do you flash the kernel?
<tgreer> using the flash.sh included in the nividia sdk
<marvin24> tgreer: so I guess you need to edit this one
#ubuntu-arm 2013-06-12
<alfonsojon> hrw: Hey, olga_ sent me here
<alfonsojon> ogra_*
<alfonsojon> not olga...
<ogra_> heh
<alfonsojon> sorry ogra
<alfonsojon> honest mistake
<alfonsojon> ogra looks like olga
<ogra_> :)
<alfonsojon> so ogra_
<alfonsojon> (not olga)
<alfonsojon> Is that rumor true or no?
<ogra_> what ?
<ndec> ogra_: not sure you look like this ...  https://www.google.fr/search?q=olga&source=lnms&tbm=isch...
<ogra_> well, i kind of have a similar haircut
<alfonsojon> lol
<alfonsojon> What I'm referring to is that I think phoronix or some other site said that 13.10 is bringing better support for the ARM Chromebook with an accelerated graphics driver
<ndec> if phoronix said it, it must be true.
<ogra_> well, i think hrw uploaded the armsoc driver ...
<ogra_> but you still need to get the GLES libs manually in place
<ogra_> iirc they cant be packaged due to missing licensing
<alfonsojon> darn
<hrw> and we have too old kernel for current ones
<ogra_> (but my info might be ouotdated, hrw is really the better person to answer this)
<alfonsojon> oh hi hrw
<hrw> no change for opengles
<alfonsojon> = no minecraft / games / anything
<hrw> I have decided to not work on packaging them at all
<alfonsojon> ?
 * tgreer puts a brick through his tegra 2 board
<ogra_> hrw, the nexus10 ones work as well, btw
<hrw> alfonsojon: I find your lack of faith disturbing
<alfonsojon> minecraft: pi edition could be ported
<alfonsojon> maybe?
<ogra_> so pepole can just download the android GLES package from google
<hrw> ogra_: my chromebook went to repair
<ogra_> yeah, i saw
<alfonsojon> Actually, couldn't the surfaceflinger driver be ported or is it proprietary?
<hrw> ogra_: does it has any useful license?
<hrw> alfonsojon: feel free to do it
<alfonsojon> I know nothing but shell
<alfonsojon> I would if I could :/
<hrw> I decided to help getting base stuff working. will not work on opengles, openmax etc stuff
<ogra_> hrw, it is a shellscript merged with binary data ... as all these android driver packages ... you have to agree to the scripted eula before it even unpacks to disk
<hrw> no binary blob related stuff
<hrw> ogra_: eula or 'google terms of service'?
<ogra_> the latter i think
<hrw> I do not consider it license
<ogra_> isnt that the same thing, just with different name ?
<hrw> ogra_: ask ubuntu archive maintainers
<ogra_> well, see http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130612/
<ogra_> (the legal notice)
<hrw> ogra_: opengles for chromebook got rejected from NEW with g-t-o-s used as license
<ogra_> we will have to have the N10 blobs in the archive after all
<ogra_> for touch
<hrw> ogra_: if they will work on chromebook then small package providing symlinks and we are done
<alfonsojon> Here's what I'm getting out of this (I'm not very technical compared to you guys)
<ogra_> well
<ogra_> they will likely be shipped inside dteh packaged android ...
<ogra_> and you dont want the container running on a real chromebook
<alfonsojon> The display driver for the samsung display driver is not open source
<hrw> alfonsojon: o rly?
<ogra_> so i guess some hackery will be needed
<alfonsojon> But the one for android is, but that runs on display flinger?
<hrw> alfonsojon: define 'display driver for the samsung display driver' please
<ogra_> (installing the container, but not running it and have a postinst that sets the links for xorg)
<alfonsojon> I feel I'm getting confused
<alfonsojon> hang on
<hrw> ogra_: get it into archive and then we can take a look
<ogra_> GLEs isnt depending on the display server
<alfonsojon> the mali t604
<hrw> alfonsojon: so please explain to my why I have both text console and X11 running on my FOSS chromebook?
<ogra_> well, it is ... but less than you think :)
<alfonsojon> ?
<alfonsojon> to my why I have
<alfonsojon> confusion
<hrw> alfonsojon: start 13.04/13.10 on your chromebook
<alfonsojon> oh
<hrw> alfonsojon: then get x11 working
<alfonsojon> I have a blinking cursor on 13.04 and 13.10, nothing else. Plymouth just dies and I can't even get to tty
<alfonsojon> Plymouth "takes over" tty
<hrw> alfonsojon: you will still do not have any binary blob (other then ones in linux-firmware)
<rbasak> There's a plymouth bug
<ogra_> remove the plymouth upstart jobs
<alfonsojon> No but even without plymouth xorg dies
<alfonsojon> I did that
<alfonsojon> xorg dies
<rbasak> bug 1082742
<ubot2`> Launchpad bug 1082742 in plymouth (Ubuntu) "plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed." [Undecided,Confirmed] https://launchpad.net/bugs/1082742
<ogra_> rbasak, well, its more of a console-setup race :)
<alfonsojon> that's it
<rbasak> Workaround is to disable plymouth. My chromebook-plymouth-hack package in the PPA does it for you
<ogra_> we have one open since 2 years or so for it
<alfonsojon> in which PPA?
<hrw> alfonsojon: arm-chromebook one
<ogra_> the proper workarounf is to use an initrd with FRAMEBUFFER=Y set
<rbasak> ppa:chromebook-arm/ppa
<hrw> ogra_: we do not have initrd
<ogra_> if you cant use an initrd, just add overrides for all plymouth jobs
<hrw> anyway once I will get speakers replaced (which may take weeks) I plan to move to U-Boot instead of signed kernels
<rbasak> Also, you need to fire a plymouth-started event or something like that for lightdm to start. My package does all of that :)
<ogra_> after all someone needs to fix the race ... console-setup needs to be executed before plymouth starts, then everything is fine
<alfonsojon> U-Boot :D
<ogra_> but if you hardcode that it will delay the boot
<ogra_> which is why nobody worked on a fix yet
<alfonsojon> okay so I tried arch arm
<ogra_> s/delay the boot/delay the boot for non affected systems/
<alfonsojon> hated it
<alfonsojon> there was nothing to work with except pacman
<alfonsojon> basically, it's like getting debian with the GNU utilities and apt-get
<alfonsojon> nothing else
<alfonsojon> So will I be able to get unity up and running with the plymouth workaround?
<ogra_> i run it here ... thogh i'm still using the chrubuntu install
<rbasak> AIUI, Unity won't work, due to Google's supplied GLES stuff not supporting compositing. Or has somebody managed to get it to work?
<alfonsojon> I used Chrubuntu
<ogra_> and dont expect it to be fast
<hrw> unity on chromebook?
<alfonsojon> yep
<ogra_> yeah, worls fine
<ogra_> *works
<alfonsojon> Ogra, did you install Chrubuntu 12.04?
<hrw> ogra_: on mesa I think?
<ogra_> hrw, half half it seeems
<rbasak> I worked out my own install instructions yesterday based on 13.04 Ubuntu Core
<hrw> alfonsojon: you want ubuntu on chromebook? 13.04 or later
<alfonsojon> Okay
<hrw> rbasak: https://github.com/jay0lee/chrubuntu-script/commits/master
<ogra_> some bits seem to be accelerated, for some it seems to fal back to mesa
<alfonsojon> oh boy :D
<ogra_> if it would be fully accelerated it would fly on that HW
<alfonsojon> it should
<alfonsojon> this is a beast of an ARM-based machine
<ogra_> Mir will solve that for us ...
<hrw> ogra_: add "--use-gl=egl" to chromium browser and check how it will display
<rbasak> I've not tidied it up yet but will post when it's ready.
<ogra_> but desktop Mir is still two releases away
<hrw> ogra_: 14.10?
<rbasak> hrw: thanks. I didn't know that existed. I'm doing it differently - setting up an SD card on a host machine.
<ogra_> hrw, it does fine, thats what i'm using
<ogra_> just cant use flash
<ogra_> that collides with compiz' compositing
<hrw> ogra_: I had too many issues with opengles on chromebook so decided to skip it
<alfonsojon> Flash is just
<alfonsojon> ugh
<hrw> rbasak: jaylee created that repo on my request
<hrw> rbasak: check amount of changes done after that d:
<ogra_> well, apart from the "x crashes if you switch ttys" i have no issues at all here
<hrw> rbasak: but it supports all chromebooks
<ogra_> and thats not a GLES issue but something with the Xserver
<alfonsojon> hrw: have you considered bitbucket?
<alfonsojon> just curious
<hrw> alfonsojon: for hosting git?
<alfonsojon> Yep
<hrw> alfonsojon: for public stuff I use github cause it is popular and works well. for private I have own server
<alfonsojon> ah
<rbasak> hrw: my approach is to minimise dependencies on Chrome OS. Enabling developer mode, USB boot and grabbing binaries - that's all I want to do there.
<hrw> alfonsojon: I do not care is their backend open or not
<rbasak> Then it's easier to test and develop, since I can automate everything.
<hrw> rbasak: I plan to open case, remove write protect, flash uboot, use as any arm device
<rbasak> I don't want to open the case :)
<alfonsojon> If it is uboot-based, could I boot off the USB 3.0 port?
<hrw> alfonsojon: no
<alfonsojon> darn
<alfonsojon> I have a 32 GB USB 3.0 flash drive, and I can't even use its full speed
<hrw> alfonsojon: but you can load kernel from emmc/sd/usb and boot to usb3 rootfs
<alfonsojon> unless I do a chroot
<alfonsojon> true
<alfonsojon> Is it normal to say "umount: device busy" right before it repartitions the SSD?
<alfonsojon> I just want to be sure partitioning doesn't go wrong. It's worked fine before but I'm not sure if it's supposed to be there
<alfonsojon> hrw: I'm using your modded chrubuntu script
<hrw> alfonsojon: ?
<hrw> alfonsojon: I never had such one in public place iirc
<alfonsojon> hm
<alfonsojon> It's not your script specifically
<alfonsojon> It happens with the normal chrubuntu script too
<alfonsojon> works fine though
 * hrw afk
<alfonsojon_> Hey
<alfonsojon_> hrw: I got Xubuntu working
<alfonsojon_> The performance is terrible though
<alfonsojon_> hrw: Okay, Minecraft's working
<alfonsojon_> At one FPS
<hrw> oh, ah
<alfonsojon_> but it's something
<alfonsojon_> I'm using a fresh Xubuntu install with your chrubuntu script
<hrw> alfonsojon_: one thing: it is not my script. I just did few improvements
<alfonsojon_> No I know
<alfonsojon_> :)
<alfonsojon_> I'm just saying it's "yours" because I don't want to refer to it every time as "the script that you modified"
<alfonsojon_> lazy typing
<alfonsojon_> Also what would be the optimal /etc/X11/xorg.conf?
<alfonsojon_> hrw: *poke
<hrw> alfonsojon_: 'chrubuntu script' is best name
<alfonsojon_> Okay
<hrw> alfonsojon_: copy /etc/X11/xorg.conf.d/ dir from chromeos
<alfonsojon_> oh
<hrw> easiest
<alfonsojon_> also what libs should I copy?
<hrw> none
<alfonsojon_> oh
<alfonsojon_> okay
<alfonsojon_> will this result in some acceleration?
<hrw> I assume 13.04
<alfonsojon_> right now I can get Minecraft at one-two FPS
<alfonsojon_> if I do this, will that break?
<alfonsojon_> (implying OpenGL is working, but not accelerated)
<hrw> alfonsojon_: if you throw chromebook from 16th floor it will get some acceleration before hitting the ground.
<alfonsojon_> true.
<alfonsojon_> lol
<hrw> that's the only acceleration I can offer
<alfonsojon_> Okay
<hrw> alfonsojon_: http://marcin.juszkiewicz.com.pl/2013/04/15/hardware-acceleration-on-chromebook/ is still up to date
<hrw> ogra_: consider alsa-lib 1.0.27.1 from Debian into Ubuntu - ucm profiles are no longer delta
<alfonsojon_> sorry to sound dumb but how do I go about pulling the kernel from Chrome OS?
<alfonsojon_> in order to get the GPU acceleration
<ogra_> hrw, cool
<suihkulokki> hrw: awesome :)
<hrw> alfonsojon_: what makes you think that kernel differ?
<hrw> alfonsojon_: read my blog post please
<alfonsojon_> http://marcin.juszkiewicz.com.pl/2013/04/15/hardware-acceleration-on-chromebook/
<alfonsojon_> this one?
<hrw> yes
<hrw> it is nearly 2 months old but still uptodate
<alfonsojon_> Okay
<alfonsojon_> Wait this is a deb
<alfonsojon_> just unpacked
<alfonsojon_> hrw: Isn't this just an unpacked deb?
<hrw> alfonsojon_: ?
<alfonsojon_> the git repo for this
<alfonsojon_> https://github.com/hrw/chromebook-mali-driver
<hrw> alfonsojon_: it is source version of package
<hrw> alfonsojon_: not maintained anymore
<alfonsojon_> so what now? :/
<alfonsojon_> hey*
<alfonsojon_> he ashams
<hrw> alfonsojon_: feel free to take care of it
<alfonsojon_> just bring in the new files from chrome os and repackage?
<hrw> alfonsojon_: git has whole history how it was done
<hrw> alfonsojon_: I just refuse to do anything with it anymore.
<hrw> alfonsojon_: so please change subject of this discussion
<alfonsojon_> You know
<alfonsojon_> I have an idea
<alfonsojon_> Ridiculous and just off-sounding
<alfonsojon_> What if we got a hold of someone at Google
<alfonsojon_> some how some way
<alfonsojon_> And asked what license it's under?
<hrw> alfonsojon_: as long as you will get it officially etc
<tassadar_> I would imagin he'd respond something like "How did you get into my house at 2AM?"
<alfonsojon_> xD
<hrw> alfonsojon_: I can only say that Samsung licenced OpenGLES driver from ARM and then sublicensed it for Google to use with ChromeOS.
<alfonsojon_> So google is the licensee of the licensee in this case?
<hrw> alfonsojon_: that's kind of answer you can get from Google people in corridor talks
<hrw> alfonsojon_: note "for Google to use with ChromeOS"
<alfonsojon_> Sometimes I love google, sometimes I hate them
<hrw> alfonsojon_: so Google is allowed to distribute it with ChromeOS.
<hrw> alfonsojon_: it is not Google's fault
<alfonsojon_> I know
<hrw> this is how licenses work
<alfonsojon_> It's just
<alfonsojon_> a pile of crap
<alfonsojon_> licensing and licensing
<hrw> alfonsojon_: check my git repo and decide which way to go
<hrw> alfonsojon_: it already covers two ways
<alfonsojon_> I'll take a look
<hrw> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/mali-drivers-0.45-r106.run is latest available publically version
<hrw> chromeos may have newer one anyway
<alfonsojon_> if it works it works
<hrw> it does not with 3.4.0-5 kernel
<hrw> that's also mentioned on my blog
<alfonsojon_> what kernel does this work with?
<alfonsojon_> 3.6?
<alfonsojon_> well
<alfonsojon_> I  would assume 3.2
<hrw> 3.4.0 but from R25 or newer branch.
<hrw> guess what? that's on a blog
<alfonsojon_> oh :/
<alfonsojon_> sorry if I'm getting on your nerves
<hrw> far from it
<hrw> have to go anyway
<alfonsojon> hrw: Okay I think I got acceleration (LightDM works now), but no sessions load
<martin-aa6e> Is anyone running Ubuntu 13.04 on BeagleBoard Black?
<martin-aa6e> (glitch here) still looking for anyone using U13.04 with BeagleBoard Black
#ubuntu-arm 2013-06-14
<DemoOn> how can i get address if pointer is in register r2?
<barredfreak14> sup bros
<isaias> how can i install android on my nexus 7 again after trying ubuntu?
<isaias> i dont have linux anymore
<infinity> isaias: https://wiki.ubuntu.com/Nexus7/Installation#Returning_your_Nexus_7_to_Stock_Android
<isaias> I need linuxfor that guide, right?
<infinity> isaias: If you don't have a Linux machine, I leave it as an exercise to the reader to either google the the Windows version of those instructions, or download an Ubuntu livecd and run the process from there.
<isaias> I plan on installing linux again, but i have to work in an hour, lol
<isaias> thank you though, I'll definately save that page for when I install linux again xD
<isaias> I had been looking for about an hour, ill keep looking though
<dpfos> you where da repos at
<ayzaaz171> http://j.gs/4214460/extremespeed17porsch-spyder-918
#ubuntu-arm 2013-06-15
<Hexxeh> hey
<Hexxeh> I know there's an Ubuntu desktop image for Nexus 7, but what about Nexus 10?
<XMLnewbi> im looking for a good image for a beaglebone black. pref one i can put on a sd and boot from
#ubuntu-arm 2014-06-10
<suihkulokki> wookey, doko, awafaa ping
<wookey> oh. right forgot
<suihkulokki> and I thought I was on #linaro, but same people
<doko> suihkulokki, sorry, ENOTIME. the only thing I have to bring up is to pester yroux about compiler ICEes with pch on arm64
<awafaa> Sorry suihkulokki , can't make today
<suihkulokki> doko on 4.8, 4.9 or both?
<doko> suihkulokki, 4.8 only, lets see if it repeats with 4.9 (which is the default now)
#ubuntu-arm 2014-06-11
<dj___> greetings. anyone here familiar with twonky on embeded debian?
<dj___> having an issue with the webui where I can access it perfectly over the IP but when I use a hostname, it loads the webpage but no library
<dj___> I seem to remember some config.js fix but I can't find it
#ubuntu-arm 2014-06-12
<awafaa> doko any ideas on what work is needed for the erlang port?
<doko> awafaa, no, didn't look
<suihkulokki> awafaa: afaik erlang should just compile, if you don't need high performance
<suihkulokki> awafaa: porting the native compiling bit of erlang (HiPE) to arm64, would take 2000-3000 lines of code (assuming the same amount ot work than ppc/arm ports)
<awafaa> suihkulokki: thanks for the info, so erlang is functional but not feature comparable to other arch?
#ubuntu-arm 2014-06-13
<suihkulokki> awafaa: pretty much
<awafaa> suihkulokki: thanks for the confirmation, so in your view what langs are high/medium/low priority?
<infinity> awafaa: c,c++,java/go,gchi,erlang,ocaml/everything-else, intentionally leaving out purely interpreted languages that seem to generally Just Work (perl, python, etc).
<infinity> awafaa: And probably missing a lot of random favourites from others. :P
<awafaa> infinity: who asked you?! :P
<awafaa> infinity: i was thinking more of what's the priority for langs that need porting?
<infinity> awafaa: I figured our relationship was intimate enough that I could interject.  I have photos to prove it.
<awafaa> infinity: you seen my outfit for the next connect?
<infinity> awafaa: I'm not sure I want to...
<infinity> awafaa: So, with a Canonical hat on, I'd say golang would be a high priority, taking that hat off, a proper ghci port would make a lot of nerds happy.
<awafaa> infinity: guess what? you're going to https://plus.google.com/u/0/103092666279088875227/posts/aCtNPvQdHt1
<infinity> awafaa: a native erlang port wouldn't go amiss, but I've also not (yet) heard people complaining about the performance impact of not having it.
<infinity> awafaa: Dude, if your junk can maintain that contraption in place through an entire evening, more power to you.
<awafaa> infinity: so far the only high priority one i have is go
<infinity> awafaa: There are also stragglers, like fpc, that don't have a ton of users but would probably also take someone with the right intersection of skills (pascal and ARM, in fpc's case) an afternoon to fix.
<infinity> awafaa: So, not a priority at all, but perhaps a fun project for someone.
<suihkulokki> awafaa: my personal opinion is that it's quite low - but it would be still good to have someone assigned to working on porting/optimizing more esoteric languages
<infinity> awafaa: Oh, and v8/node!  I understand there's an AArch64 port sitting on tip/trunk/head/whatever somewhere, but that's of little use while distros are still shipping an old stable libv8 and node to match.
<awafaa> yeah, problem is getting resources to assign to do the work - I have very little to play with so I have to be very picky with what I put it on
<awafaa> infinity: you need to take that up with joyent
<suihkulokki> chasing the long tail and all - it should be made sure at least the languages work so nobody doesn't skip buying and armv8 server because they happen to have a legacy freepascal app as part of their system
<infinity> suihkulokki: I doubt anyone would make a purchasing decision based on pascal, to be fair.
<infinity> But nodejs, definitely.  And saying "there will be a new upstream release some day with support" doesn't cut it.
<awafaa> suihkulokki: I agree, but I have to prioritise - I have the list of things that need work, I just need to prioritise it
<infinity> awafaa: What does joyent have to do with it?
<awafaa> infinity: they have an exceptional amount of say in node - they just canned the CLA, but still have a lot to say
<infinity> awafaa: "porting" nodejs to a new arch is trivial.  libv8, on the other hand, is painful.  And last time I asked about backporting aarch64 support to libv8-3.14 (ie: the version most everyone ships), I was told it was "too much effort", and thus no one cared.  Which seems like a pretty lousy thing to tell potential customers. :P
<infinity> And sure, some day there will be a node/v8 combo based on 3.20 or 3.22 or something, but that doesn't help me today.
<suihkulokki> it's in node.js master - * v8: upgrade to 3.24.35.22
<infinity> suihkulokki: So, maybe I'll see that release before 16.04 ... I'd still love to see a backport to 3.14 for 14.04
<infinity> But, *shrug*...
<suihkulokki> they don't seem to have release schedule
<infinity> Anyhow, I'm not going to lose any sleep over it.  Just a bit disappointing.
<suihkulokki> oddly I'd assume something as hipster and trendy as node being released monthly or so
<infinity> They don't do the hipster release thing.
<infinity> They also maintain stable branches for effin' ever.
<infinity> Which I appreciate, as a stuffy conservative engineer.
<infinity> But their reluctance to cut a new stable out of master is also irksome. :P
<suihkulokki> I think theyll still manage to release faster than awafaa is able to find someone to do the backport of v8 :F
<awafaa> almost definitely :/
<infinity> Perhaps a fair point.
<infinity> awafaa: So, discounting the node/v8 argument, and understanding that you already have people prioritising golang (or, you might do), I'd say that ghci is pretty widely-used and often-ignored.
<hrw> infinity: ocaml is ported
<awafaa> infinity: i've been trying to work out what actually uses ghci? and when yoiu guys were porting ghc, why do a half arsed effort? :P
<infinity> hrw: I know, I was listing priorities period, before he narrowed it to discussing unported things. :P
<hrw> ok
<infinity> awafaa: Colin's GHC port isn't native, it's more just a dirty hack.
<infinity> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014/04/15
<awafaa> ah, that's not what all the noise said - thanks for the clarification
<suihkulokki> https://ghc.haskell.org/trac/ghc/wiki/Platforms
#ubuntu-arm 2015-06-09
<nodtkn> Howdy! Has anyone attempted to boot ubuntu on top of redhat's latest arm kernel and initramfs?
<ogra_> why would anyone do that ?
<ogra_> (instead of using an ubuntu or mainline kernel)
<nodtkn> support for AMD seattle
<nodtkn> and I like pain
#ubuntu-arm 2015-06-10
<infinity> nodtkn: Using a RedHat initramfs to boot Ubuntu isn't going to end well.
<nodtkn> :) I have been trying to use the initramfs shipped in the ubuntu cloud image with some success
#ubuntu-arm 2016-06-13
<NCommander> codegen_c_hdr seems to hate my perl :/
#ubuntu-arm 2016-06-19
<mesger> hi, I'm trying to get a wifi list with the networking manager command line
<mesger> but the command "nmcli d wifi list" always returns no ap's
<mesger> i'm trying to get this to work on an udoo
