#ubuntu-arm 2009-09-14
<lool> Daviey: Hey, what went wront with the netboot installer images?
<lool> Daviey: Oh in qemu
<lool> Daviey: qemu doesn't support dove nor imx51
<lool> Daviey: We stopped doing versatile because we moved karmic to armv6 and versatile in the upstream kernel implies armv5 -- note that it can perfectly work with v6 or v7 though
<Daviey> lool: So does that mean that it's currently note possible to virtualise arm in karmic?
<lool> Daviey: It means that there's no prebuilt kernel to run in our qemu indeed
<lool> Daviey: While it's an useful thing and we have a lot of people running qemu which hang around here, it's not a requirement; you could ask for such a flavour to the kernel team, I personally think it would be useful
<lool> I didnt because I've felt I needed them to focus on the flavours supporting our hardware first
<ogra_> Daviey, http://people.canonical.com/~ogra/arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8 might be of some help
<ogra_> note it's quite old, but enough to get a VM up
<ogra_> (the rootstock builder from /topic uses it to create rootfs'es and qemu images for arm)
<Daviey> ogra_: thanks.. i'll give it a go.
<ogra_> note there are no modules for it or anything ...
<Daviey> ogra_: incidently, the upgrade path cannot be canculated from jaunty to karmic. :(
 * ogra_ has no time/resources to build and patch a fresh one 
<Daviey> :(
<ogra_> in a jaunty qemu vm you mean ?
<Daviey> yah
<ogra_> thats intentional, though i thought i added a proper error message
<ogra_> do a cat /proc/cpuinfo in your vm
<ogra_> karmic only supports v6 and v7
<Daviey> ogra_: do-release-upgrade craps out as it tries to remove ubuntu-minimal, but that is blacklisted and marked for non-removal
<ogra_> u-m should pop up an error message telling you that pre-v6 isnt supported
<ogra_> oh, not sure do-release-upgrade shows the same errors u-m does
<Daviey> ogra_: just booting now.
<Daviey> lool: Sorry for not replying, missed your response.  I understand :)
<Daviey> ogra_: Processor: ARM926EJ-S rev 5 (v5l) :(
<ogra_> right
<ogra_> my kernel fixes that
<ogra_> it has a patch lool developed to fake a cortex-a8
<Daviey> hmm, made qemu core dump :(
<ogra_> you indeed need the right -M
<ogra_> err
<ogra_> -cpu, not -M
<ogra_> -cpu cortex-a8
<ogra_> and -M versatilepb
<Daviey> yah, ogra_ you rock. :)
<ogra_> :)
<erikcorry> I finally got around to filing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41354
<ubot4> gcc.gnu.org bug 41354 in c++ "g++: Inlining constructors puts wrong vtable in objects" [Normal,Unconfirmed]
<erikcorry> clever bot
<rabeeh> j #openplug
<mike^> ogra, thanks to you I have omap3evm with ubuntu :)
<ogra> :)
<mike^> it's somewhat slow on app startup, but even 3D works :)
<mike^> http://2.bp.blogspot.com/_dhW-lh4q-sk/Sqli478fQGI/AAAAAAAAAYo/zHk7-iRgQ1k/s1600-h/ubuntu-greeter3-small.png
<mike^> http://4.bp.blogspot.com/_dhW-lh4q-sk/SqlivloG3fI/AAAAAAAAAYg/3-K5pHMwEa8/s1600-h/xfce2.png
<mike^> ogra, do you know by chance is anybody working on the DSP stuff for OMAP?
<ogra> nobody from canonical at least
<ogra> not sure if there are any community people
<siji> hey mike^, still am struggling with the same issue
<siji>  checking GLES/egl.h usability... no
<siji>  checking GLES/egl.h presence... no
<siji>  checking for GLES/egl.h... no
<siji>  configure: error: Unable to locate required GLES headers
<lool> ogra: I was thinking of something: libc-vfp was dropped but wont be removed on upgrades which mean people might run an out of date libc
<lool> ogra: Would you be interested in an update-manager snippet to drop it on upgade?
<ogra> another u-m hack ?
<lool> *upgrade
<lool> Yeah that's what I had in mind
<lool> Would check with mvo what he things though
<ogra> sure, why not
<lool> ogra: I'll file that now while I think of it and assign it to you then; thanks
<ogra> gar
 * ogra messed up his bug 
<lool> ogra: Actually thinking about it it's more of an eglibc bug, it should conflict/replace
<ogra> yup
<lool> ogra: there's an = dep on libc6 which is why it gets removed on upgrades
<lool> I guess that's ok
<ogra> god, pushing an ubiquity branch takes a century
<lool> Yeah would need an upgrade
<ogra> i thought its under ubuntu-core-dev but it isnt ... so i need to create a brandnew branch for merging
<ogra> OO.o looks better this time ... didnt fail yet
<lool> Well LP uses stacking for modern .bzr branches
<ogra> ah
<ogra> doesnt help me right now though :)
<ogra> but my initramfs-tools install prob is solved
<lool> Cool
<lool> the unr and umr livefs breakages are awful just before A6
<mike^> siji, native as well?
<mike^> siji, I haven't tried to cross-compile... and apparently won't for some time
<ogra> lool, well, i didnt have armel livefses since a few days either
<lool> ogra: Do they build now?
<lool> ogra: I gave back eds over the WE as I saw it was blocking but didn't look since
<ogra> e-indicator and e-couchdb were ftbfs as well
<ogra> but they should be fine now
<ogra> i'll trigger a testbuild for dove and imx51
<ogra> lool, do you know if the dove installer bits are ready so far ?
 * ogra thinks there is still something missing, but not sure
<tasslehoff> I'm trying to get my beagleboard to send 1680x1050 to my display (default it is 640x480). I followed the "Xorg omapfb Drivers"-section on http://elinux.org/BeagleBoardUbuntu, but afterwards X wouldn't start.
<siji> <tasslehoff>,bad luck
<siji> :(
<siji> have u updated the kernel
<siji> ?
<tasslehoff> siji: no, I have just created my own rootFS following the wiki, and started working/installing on top of that
<siji> <tasslehoff>, you have to add some patches in the kernel
<lool> ogra: NCommander said the boot.scr doesn't get generated; probaby a simple bug
<siji> for getting SGX Video Acceleration
<ogra> lool, but flash-kernel and friends are ready ?
<lool> ogra: Well it's a bug in flash-kernel-installer.postinst
<ogra> yeah
<ogra> i meant the rest of the changes there
<ogra> ubiquity surely needs changes too for the bootloader parts
<ogra> i didnt see him touching anything there yte
<ogra> *yet
<tasslehoff> siji: ok, I'll try to follow the wiki all the way to the bottom before asking any more :)
<siji> yes
<siji> it's there in the wiki
<erikcorry> Does -mcpu=vfp get me a binary that uses floating point instructions?
<tasslehoff> On my Beagle Board Xubuntu install update-apt-xapian-index is using almost all the cpu, and all I have set running myself is an xterm..
<lool> erikcorry: That sounds wrong; you want fpu
<lool> erikcorry: if you're using karmic, armv6 + vfp (v2) is the default
<lool> So no need for any flag
<lool> If using jaunty you want --with-float=softfp --with-fpu=vfp
<lool> Sorry these are gcc build flags
<lool> You want -mfloat-abi=softfp and -mfpu=vfp
<erikcorry> Isn't the float ABI softfp by default?
<erikcorry> Or does the mfpu option change that?
<tasslehoff> Is the OMAP35x SDK needed to get SGX Video Acceleration on the Beagleboard?
<lool> erikcorry: Our jaunty ABI is soft
<lool> not softfp
<erikcorry> What I want is a program that uses fp hardware, but is ABI compatible with the Karmic ABI.
<erikcorry> So I think -mfpu=vfp is about right.  No change to the ABI, but use vfp inside functions.
<erikcorry> Unless I am misunderstanding something.
<lool> erikcorry: what's your dist?
<lool> jaunty or karmic?
<erikcorry> Karmic
<lool> erikcorry: So you dont need -mfpu=vfp
<lool> it's the default
<erikcorry> So Karmic doesn't work on a machine with no vfp?
<lool> No
<erikcorry> Ah!
<erikcorry> Good to know!
<lool> And for jaunty you do need both
<lool> Because one tells gcc that it may use vfp instructions in binaries but not in the ABI and actually should and the other tells which fpu instructions to use
<erikcorry> Do Jaunty binaries run on a Karmic machine?
<lool> Yes
<erikcorry> Thanks
<erikcorry> And Karmic also requires ARMv6?
<ogra> yes
<Daviey> Would someone be really kind, and test some packages cleanly install on armel for me?  It's a dkms package, and i want to test it also works of armel before getting it uploaded?
<Daviey> s/of/on
<ogra> all macines i could test on are busy for the next few hours
 * Daviey has an n810.. but possibly not the best native arm device to test on :)
<Daviey> ogra: oh okay, thanks.
<ogra> especially for dkms stuff :)
<Daviey> i've now got a qemu machine, that is almost on karmic.. but i'm not sure it's a fair test, considering how the kernel lives outside.
<Daviey> i'm wondering if my toaster would run faster than qemu. :)
<ogra> likely
#ubuntu-arm 2009-09-15
<vlad> if I have an arm box with the netbook-remix packages installed, is it possible to get -dev packages on there?  Like if I try to install libglib2.0-dev, it complains that the 0netbook2 etc. rel of glib is installed, and that the dev package is coming from normal jaunty and requires the standard non-netbook rev
<lool> vlad: Where is this netbook-remix image from?
<lool> vlad: It's a preinstalled one from Dell?
<lool> vlad: You basically need to use the repos which came in the sources.list of the preinstalled image; you cant mix them with the Ubuntu one
<lool> vlad: Hold on, you said an ARM box and we're on #ubuntu-arm  :-)
<lool> vlad: Is this a pegatron box?
<vlad> yeah
<lool> vlad: Ok so this build was a bit special and I'm not sure the sources.list point at the correct archive
<vlad> it just points to the normal jaunty ports repo
<lool> Nothing more in /etc/apt/sources.list.d/*.list?
<vlad> mm, I only looked in sources.list, not in .d/*
<vlad> sec
<vlad> oh wait, there is
<vlad> deb http://netbook-remix.archive.canonical.com/updates jaunty-watertown public ?
<lool> That sounds like the right thing yes
<lool> vlad: Can you easily paste apt-cache policy libglib2.0-dev?  you might want to apt-get update first
<vlad> though just updates -- is there another repo that'll have the full set of packages, with dev packages and stuff?
<lool> vlad: In theory, unless things are borken, your install should be pointing at the repos which were used to create it
<lool> vlad: jaunty was used as a base with an overlay repo for the packages modified for this build
<vlad> hrm
<lool> That's in theory because I didn't actually see that rootfs and cant easily check its contents
<vlad> I wonder if the entries in sources.list arescrewing it up
<vlad> one sedc
<lool> vlad: It's about 2am for me so I'll drop off; a bunch of people are familiar with imx51 hardware here, and some played with the one you have; I only touched early hardware and have no idea about the final software image shipped by Canonical OEM, but I'm happy to answer questions you leave here
<vlad> ok cool; thanks! I'll poke at it some more
<lool> vlad: Perhaps a less bumpy ride to start development is to create a jaunty or a karmic chroot and work in it; this requires in the 300 MB + whatever you add there (e.g. build-deps of your software)
<vlad> yeah, or just do it via scratchbox :)
<lool> vlad: debootstrap is the regular tool to do this; "sudo debootstrap jaunty my-chroot"
<lool> Oh sure; but since you have a native system... up to you
 * Martyn has karmic running on his development system :
<Martyn> woot!
<Martyn> although I had to do a buildroot :(
<siji> ogra,u there
<siji> while am trying to start the uimage frm MMC
<siji> Unknown command 'mmcinit' - try 'help'
<siji> getting this msg frm uboot terminal
<siji> why it's happening
<siji> ?
<tasslehoff> siji: maybe you have the version where it is called "mmc init" instead? I believe it changed at some point
<tasslehoff> siji: if so, change your bootcmd to use the new command
<siji> mmc init is also not there
<siji> <tasslehoff>, even lot of other commands also missing in by uboot
<tasslehoff> siji: hm. I only got started with beagle yesterday, so I'm afraid I'm not of much help. Experienced the mmcinit -> mmc init, though.
<siji> ok
<siji> <tasslehoff>,actually am not with beagle now.My beagle is wrking fine
<siji> am using compulab's X300 evaluation kit
<siji> which is based on marvel's PXA300 processor
<tasslehoff> siji: ok
<siji> is it cose of some old version of uboot or smthing?
<siji> Am surprised, even erase command is also not there
<siji> :(
<gaspa> siji: check really uboot version, it tends to change often command name. So current online documentation may not work for you.
<gaspa> s/name/names
<siji> oh ok
<gaspa> siji: e.g. I've "nand erase" instead of "erase"...
<siji> gaspa, while help output giving only limited command set
<siji> it doenst contain any such commands
<siji> doesnt
<gaspa> version?
<siji> how to get the version
<siji> ?
<gaspa> 'version' ?
<siji> ok
<siji> U-Boot 2009.03-cm-x300-2 (May 26 2009 - 11:47:40)
<gaspa> or at early boot time ... I'm seeing this:
<gaspa> U-Boot 1.2.0 (Mar 21 2009 - 05:12:20)
<siji> ya
<gaspa> is that uboot shipped with your card?
<siji> ya
<siji> gaspa, so this may be customised version of uboot right?
<gaspa> surely
<siji> ok, thne how will flash it
<gaspa> in fact, perhaps it's worth asking in some list/channel about your board.
<siji> gaspa,ok
<siji> but how will i add new uboot now
<siji> there is no erase command
<gaspa> jtag? it depends from the board.
<siji> gaspa, am not clear
<mike^> siji, there's no MMC on CM-X300 :)
<siji> mike^,mmc connector is there
<siji> in base board
<mike^> siji, yes, but there's no mmc support in U-Boot
<siji> ok
<siji> :(
<mike^> siji, you can use USB instead
<siji> yes that i did
<siji> it's wrking fine
<mike^> siji, good to know :)
<siji> am booting ubuntu with lxde
<mike^> and it works?
 * mike^ surprised
<siji> yes
<mike^> siji, it also should be possible to use mmc for rootfs, as long as you have the kernel on USB or in NAND
<siji> mike^, was trying for that only
<siji> u mean kernel wil start frm nand and wil search the rootfs frm mmc
<siji> right?
<siji> but that also failed
<siji> hey mike^, thanks
<siji> let me give a try again
<siji> I compiled the kernel with mmc support (earlier it was as LKM)
<siji> but i think forget to put the new kernel image in to nand memory
<siji> :)
<mike^> siji, use tftp, it's far more efficient. In U-Boot you can set
<siji> mike^,ok
<mike^> setenv bootcmd 'dhcp; setenv serverip <your tftp server>; tftp 80800000 uImage; bootm'
<siji> ok
<mike^> and to the kernel build you can append 'cp arch/arm/boot/uImage /path/to/tftproot'
<siji> ok
<mike^> siji, btw where are from?
<siji> India Mumbai
<siji> n u?
<mike^> compulab.co.il, Haifa, Israel :)
<siji> oh grt
<siji> oh the same mike who's answering my queries
<siji> in compulab support chanel
<mike^> siji, yep :)
<siji> cool
<siji> nice to meet you
<mike^> siji, you've got one more answer :)
<mike^> no mmc in U-Boot :)
<siji> yes right
<siji> we are using the evaluation kit now
<armin76> NCommander: i want a marvell dove!
<NCommander> armin76, O:-)
 * armin76 pokes rabeeh 
<lool> win 1
<lool> Tss
<MarkG> Anyone know why armv5 is being dropped in the next Ubuntu release?  That seems pretty big news considering V5 ihas huge number of devices.
<vlad> very few of those devices are all that interesting for running a desktop OS, though
<MarkG> Is ubuntu Desktop only now then?
<MarkG> What does this mean in real terms for someone with a brand-new Sheevaplug?  I find it incrddible that Ubuntu is stopping supporting new hardware.
<MarkG> OK, I can assume then that it's game over...
<MarkG> can someone recommend another distro that has a good a package manager as ubuntu thats not dropping armv5 support?
<kblin> MarkG: seriously? weren't they boasting about the sheeva support?
<kblin> MarkG: I guess you could always switch to debian
<kblin> that's certainly my plan if ubuntu drops support for my sheeva
<MarkG> I think they are keeping quiet about it deliberately.
<MarkG> if not too many people know, then what it occurs, it's too late.
<MarkG> I suppose it's a halfway house.  There is no money in embedded ARM devices, Canonical want the high-end server market, where there is money, and also want the desktop bit too, but anything outside that, they don't care about.
<kblin> there's no money in embedded devices?
<kblin> who said that?
<kblin> I've got a couple of rooms full of engineers here who would disagree
<MarkG> you pay money to Canonical?
<kblin> no, but there's certainly lots of people making money on embedded devices
<kblin> I've had a couple of people being very interested in the embedded active directory server I've been demoing
<MarkG> isn't that the point, there is money in embedded stuff, but if Canonical don't make any of it, and it's a market that Microsoft's not in, then why bother?
<kblin> I don't see why you would get less support for an embedded server that's mission critical
<kblin> bus as I said, if ubuntu drops support, just switch to debian
<kblin> you don't even have to get used to a new package manager then
<lool> MarkG: The Ubuntu armel port is mostly aimed at netbook/desktop uses
<lool> MarkG: Also, we look forward at the future devices and would like to benefit of every performance bits we can
<MarkG> OK, so debian is not dropping support, is that correct?
<lool> MarkG: Indeed, Debian has support for armv4t
<MarkG> that's OK, i'll switch to that
<lool> MarkG: We target armv6+vfp for now
<lool> MarkG: Sure
<lool> MarkG: I have a sheevaplug BTW   ;)
<lool> you can run jaunty on it if you like
<MarkG> I'd hate to have to go back to the horrendous emerge of Gentoo
<lool> I think Debian is great for sheevaplug
<MarkG> I have Jaunty on it, but wonder how long things will continue to be supported
<lool> I hope we'll see am armv7 plug soon
<MarkG> I hope not, I only just got mine :-)
<lool> MarkG: AFAIK, ubuntu desktop is supported for 18 months even on armel
<lool> https://wiki.ubuntu.com/KarmicKoala/ReleaseManifest
<lool> not 100% sure for jaunty though
<lool> MarkG: I wish some people would maintain an armv5 rebuild of Ubuntu though; that'd be cool
<kblin> lool: sure, it should build on a sheeva within a couple of weeks, I guess :)
<kblin> how big is the current repository?
<lool> You mean in terms of size?
<lool> I dont know for sure and dont have a mirror to check
<kblin> lool: so karmic is armv6?
<lool> Yes
<lool> +vfp
<kblin> and still doesn't support the beagle
 * kblin sighs
<lool> Eh
<lool> It's a lot of work to support it; if people are interested in doing the maintenance they're welcome to step up
 * kblin shrugs
<lool> there's no support in Debian either for similar reasons
<kblin> people keep filing samba bugs, if someone will step up to fix them, I might have some time
<kblin> :)
<lool> Tss :)
<kblin> but assuming the TI folks get the linux-omap stuff upstream, there shouldn't be too much of a maintenance issue anymore, right?
<lool> My time is 100% busy with the commitments I have so far; it's 11pm, I stayed up til 2 am yesterday fixing armel image issues so I dont have the bandwidth myself; I think for now beagle would have to be a community port
<lool> kblin: Absolutely
<lool> kblin: at least that has been the blocker on the debian side of things
<lool> I dont know whether canonical would support a beagle flavour of the main kernel but it would be doable in the ports kernel for sure
<kblin> I'm beginning to think that for the stuff I'm doing, maybe a small atom board would be less painful.. oh well :)
<lool> Beagle is a nice device and I can tell that the bulk of the work to get it running is the kernel part
<lool> It works fine with a karmic userspace
<kblin> well, yes, mostly fine
<kblin> but to be honest I didn't try karmic on it yet
#ubuntu-arm 2009-09-16
<armin76> uh, emerge is not horrendous
<armin76> its better than apt :)
<Martyn> Ugh
<Martyn> Lets not get into the whole package management religious war again
<Martyn> that -practically- counts as a troll.  grin
<Martyn> Oh, and I got some of the installer scripts to work finally
<Martyn> so I've got the beginnings of an actual Karmic installer that doesn't involve a buildroot
<kblin> you mean other than rootstock?
<Martyn> yep
<Martyn> Getting there slowly.  It's not the actual server installer yet, but I'm grinding away at the problem
<Martyn> my eventual goal is to get an ARM server build that net installs successfully on a couple platforms
<Martyn> PBX-A9, FastModels RealView EB, and the tech my company is working on (Smooth-Stone)
<kblin> none of them ring a bell for me.. anything with a couple of ethernet ports on them? :)
<Martyn> All of them
<Martyn> Well, the RealView EB is not a physical machine .. it runs as a fastmodel software simulation of the entire A9 Core (quad core) at ~150Mhz
<kblin> I'm definetely playing with the wrong hadware right now :)
<Martyn> The PBX-A9 is the Cortex A9 version of ARM's hady PBX platform .. they pretty much recycled it
<Martyn> although the new A9 version has a neat implementation of a dual core Cortex A9 running also at about 150Mhz.   Pretty impressive, considering they basically dropped the soft core onto an ASIC
<kblin> if you say so...
<Martyn> (rather than test silicon)
<Martyn> the tech my company is working on is, of course, a real Cortex A9 ... but I can't really share that much of what we're up to.
<Martyn> But I can't wait to play with the real chips :)
<Martyn> kblin : For a couple of ethernet ports, you're probably going to have to wait until TI starts producing non-sample quantities of the OMAP4
<Martyn> and even then, it's pretty dependent on someone -else- (beagle?) interfacing a chip that doesn't use PCI  (like the SMSC 9118)
<Martyn> Since that can be mapped directly onto SRAM
<kblin> so what I presented on the storage developer's conference yesterday was a Samba4 Active Directory domain controller running on a beagle, as that's the hardware I got
<Martyn> Urk
<Martyn> Cortex A8 though, so at least it has some optimizations
<kblin> and as a proof of concept, it's been pretty impressive
<Martyn> What did you use for an ethernet adapter?   Phoenix chip off the USB port?
<kblin> moschip, but yeah
<Martyn> I did something similar with a shivaplug
<kblin> yeah, I got one of those yesterday
<kblin> not in time for my presentation, though
<Martyn> multicore is win when doing asynchronous IO
<Martyn> but the arm v5 instruction set (since it does v5 multicore) is limiting
<Martyn> kblin : You'll be impressed with the performance that little thing can pump, when it comes to IO
<kblin> what's killing the beagle is the crappy USB
<Martyn> kblin : The Kirkwood core is interesting, if a bit "yesterday"
<Martyn> yep.
<Martyn> you're going to get equally crappy performance out of the shivaplug, I'm afraid
<kblin> it's going to be more yesterday when ubuntu rops v5 support
<Martyn> I ran a Samba 3 PDC on one, and it worked .. but it wasn't anything stunning
<Martyn> what's REALLY going to kill you is the lack of RAM
<Martyn> no danger of dropping arm v5 for a while.
<kblin> it seems to be a bit faster for AD stuff
<Martyn> Hell, the whole build system is geared to MAKING v5 eabi binaries at the moment, built on QEMU of all things
<kblin> I didn't benchmark file server performance
<Martyn> I'm starting to figure out how to configure launchpad to perform v7 builds now
<Martyn> since that's the key to getting some application performance on the new systems, and I really need to start focusing on that
<Martyn> It's slow going
<kblin> however, Samba4 is just starting to support AD replication, so setting up a small embedded box in a branch office that replicates the main office's AD setup seems like a nice product
<kblin> so fileserver performance isn't too critical for that kind of setup
<Martyn> true
<lool> Missed Martyn
<lool> Would have liked to know if it's a d-i bsaed installer
<ogra> lool, wrt usplash, i know that we need USPLASH=y in initramfs.conf (or the .d dir) but i still see no sane way to put it there apart from hacking up the installer and casper probably
<ogra> or use an expensive function that does an arch check in initramfs
<lool> ogra: Just add a file in usplash on build
<ogra> hmm
<siji> hey
<siji> anybody can help me to compile clutter with openGL support
<siji> still am with the same error
<siji> checking EGL/egl.h usability... no
<siji> checking EGL/egl.h presence... no
<siji> checking for EGL/egl.h... no
<siji> configure: error: Unable to locate required GLES headers
<siji> ogra, i got the tutorial abt this for angstrom OS
<siji> anyway to make it for ubuntu
<siji> ?
<ogra> no idea
<siji> ogra,ok
<ogra> did you ask in #beagle (or if there is an angstrom channel, did you ask there)
<siji> ok
<siji> ogra,those header files are in Omap SDK
<siji> and i copied it to unbuntu rootfs
<siji> but no hope
<siji> mike^,u there
<siji> ?
<mike^> yes
<mike^> mostly
<siji> mike^, any idea ?
<mike^> siji, not really, what I did was 'cp -r /path/to/SDK/OGLES/SDKPackage/Builds/OGLES/Include/GLES /path/to/ubuntu/root/usr/include'
<mike^> 'cp -r /path/to/SDK/OGLES/SDKPackage/Builds/OGLES2/Include/EGL /path/to/ubuntu/root/usr/include'
<mike^> and than on omap machine: apt-get -s build-dep clutter
<siji> mike^, i tried
<mike^> apt-get -b source clutter
<siji> mike^ actually i compiled clutter frm Source
<siji> ./configure --with-flavour=eglnative --with-gles=2.0 --with-imagebackend=gdk-pixbuf --with-x=no    --with this prefix
<mike^> siji, I've used the configure options from the .deb itself, I've only changed the --with-flavour to 'eglx'
<siji> mike^, like " apt-get  -s build-dep  clutter eglx "
<siji> ?
<mike^> siji, just "apt-get  -s build-dep  clutter"
<siji> ok
<siji> let me try again
<mike^> siji, and during the 'apt-get -b clutter' I've interrupted it, and changed debian/rules to use eglx
<siji> ok
<lool> rabeeh: http://cdimage.ubuntu.com/ports/daily-live/current/
<lool> rabeeh: note that it's not always there (might fail to build)
<lool> I didnt test this image either so it might not even boot
<ogra> the imx51 one boots fine
<lool> odd my rsync just failed with rsync: link_stat "/ports/daily-live/current/karmic-desktop-armel+dove.img" (in cdimage) failed: No such file or directory (2)
<ogra> so i'd expect the dove one to do that too
<ogra> the link was just moved :)
<lool> ogra: You kicked a build?
 * ogra knows that prob and stopped using current/ long ago
<ogra> no
<ogra> i'm still installing
<lool> I never had an issue with that
<lool> and the web index has /current working fine
<ogra> well, i know it breaks if the link moves while you are actually in the sync process
<lool> I just started my rsync
<rabeeh> which u-boot configuration are you using?
<rabeeh> (bootcmd etc...)
<lool> rabeeh: That's the good question to ask
<lool> the image is meant to be started with the new bootcmd discussed in $bug
<ogra> there should be a wikipage
<lool> yeah
<lool> https://wiki.ubuntu.com/ARM/MarvellDoveKarmicInstall
<lool> rabeeh: ^ that's semi current
<lool> rabeeh: Ideally you'd just the loop and it would autostart the USB key install
<ogra> https://wiki.ubuntu.com/ARM/MarvellDoveKarmicInstall
<ogra> bah
<ogra> lool beats me
<lool> ogra: Young padawan
 * ogra buys http://www.frankelcostume.com/Beard-18-Grey-Oldtimer-P16867C93.aspx :P 
<lool> rabeeh: I pushed support for dove-z0 netboot images if anybody cares; will be published with next debian-installer upload; untested though
<lool> The dove netboots were incomplete (were relying on uimage kernels which we dont have anymore) so these will be fixed at this time as well
<lool> rabeeh: http://ports.ubuntu.com/ubuntu-ports/dists/karmic/main/installer-armel/current/images/ is the base dir for the netboot images
<rabeeh> which one will have UNR?
<lool> ogra: Oh you were the male model below the beard?
<lool> rabeeh: We might add it if we get 3d working
<lool> I mean opengl
<lool> rabeeh: But for now we cancelled that support in karmic
<lool> rabeeh: it's not very hard to add, perhaps some hours + testing but we need a way to test first
<rabeeh> right
<rabeeh> what's the best way to do it -
<rabeeh> 1. clutter + opengl-es
<rabeeh> 2. clutter + opengl + translation to opengl-es + opengl-es
<rabeeh> ?
<rabeeh> lool: translation library like the one you previously mentioned to me?
<ogra> lool, heh, we still have usplash on shutdown on the live image :)
<lool> rabeeh: In theory clutter can work on either IIRC
<lool> rabeeh: But there might be some issues with clutter 1.0
<lool> rabeeh: The point of clutter is to abstract that away
<ogra> sniff, no gdm for me after install :/
<rabeeh> if the performance of 2 is similar to 1; personally i would go with 2, since any other application that uses opengl (which are the majority for netbooks) would use the hardware engine
<ogra> hmm, it starts if i satrt dbus manually
<ogra> sadly i forgot to start hal too :P
<ogra> no xinput
<lool> rabeeh: Sure that's certainly doable; the question is how much time to fix clutter versus how much time to get that bridge working
<lool> I didnt look into the latter
<ogra> sigh, so on second boot dbus comes up fine
 * ogra hates race conditions
<ogra> but but
<ogra> but
<ogra> wow, the babbage boots *faaaaast* !
<lool> ogra: with the new stuff?
<ogra> yeah
<lool> That's really good news
<ogra> incredible
<lool> That was the biggest issue
<ogra> but see above
<lool> Yeah
<ogra> dbus crached on first boot after install
<ogra> *crashed
<ogra> second one is really quick and everything is up
 * ogra digs for his stopwatch
<lool> ogra: is this from SD?
<ogra> 15sec from first screen output to X, pls ten more to see the panels
<lool> or after install?
<ogra> nope, USB key
<lool> wow
<ogra> after install
<ogra> adding the applets takes a bit
<lool> it's comparable to my x301 with jaunty
<ogra> but its a massively different experience
<lool> I think I'll like the boot stuff when it lands
<ogra> i do already !
<lool> I'd love to try that on dove
<ogra> spinning disks are said to be much slower
<lool> too bad we have no live image for z0
 * ogra installs bootchart on the babbage
<ogra> bah, wrong keymap
<rabeeh> lool: i'm trying to use your netboot initrd
<rabeeh> lool: i get the following (with my kernel) -
<rabeeh> RAMDISK: gzip image found at block 0
<rabeeh> RAMDISK: incomplete write (30549 != 32768)
<rabeeh> write error
<rabeeh> which addresses do you tftp load uImage and the initrd?
<bjf> rabeeh, how many "users" of Y* boards exist outside of Marvell or Canonical?
<rabeeh> bjf: i don't know; i don't have the numbers
<bjf> rabeeh, I'm not really looking for specifics, I'm thinking about number impacted if a bad kernel went out for some reason
<bjf> rabeeh, we are thinking about how flexible we should be in taking kernel changes
<bjf> rabeeh, if the number of users that would be impacted is small we can be more flexible
<rabeeh> bjf: hmmm.... i think you should be very flexible and never send a bad kernel for any reason :)
<bjf> rabeeh, lol
<rabeeh> bjf: seriously i really don't have the numbers; but i can say that the demand is huge.
<rabeeh> bjf: i think it's ok for the next few weeks to have bad kernels (for some reason) until people get used to karmic images
<rabeeh> bjf: but as i talked to saeed today; he told me that there are minor changes left for the git tree to be 100% in sync with marvell's
<rabeeh> bjf: so the risk is really very low on having bad kernels due to dove support.
<bjf> rabeeh, I really wouldn't expect a bad kernel to go out, however if we allow lots of changes to the karmic kernel after it has been released, then there is a greater possibility
<bjf> rabeeh, the marvell changes are carried on a topic branch so only that would be impacted
<lool> rabeeh: Didn't try the netboot images yet
<lool> rabeeh: I'd use the same addresses as the boot script
<lool> rabeeh: 0x00200000 for kernel and 0x01100000 for ramdisk
<lool> rabeeh: note that kernel is in zimage format instead of uimage; will be fixed with next debian-installer upload
<armin76> rabeeh: did you receive my mail?
<ali1234> m when compiling
#ubuntu-arm 2009-09-17
<lool> bjf: https://pastebin.canonical.com/22225/ > looks like uboot cant read from IDE which it should; try powering off completely and booting again
<ogra> woah, thats niosy
<bjf> lool, GrueMaster just reported success
<GrueMaster> I've got it working.  Will try to pastebin my minicom log.
<bjf> lool, same after full power off
<lool> bjf: perhaps it's too slow
<lool> bjf: Can you try manually running the bootcmds?
<lool> bjf: So break the script, printenv, and try the commands in the script but slowly
<lool> ** Unable to use ide 0:0 for fatload **
<lool> ** Partition 0 not valid on device 0 **
<lool> ** Unable to read "/boot.scr" from ide 0:1 **
<lool> Scanning ${interface} ${device}:${partition} ...
<lool> reading /bootboot.scr
<lool> bjf: hold on
<lool> bjf: that's the issue
<GrueMaster> I think I see what's happening.  The script is cycling through several usb iterations before booting from sata.
<lool> bjf: did you install with a separate /boot?
<lool> GrueMaster: bjf: Can one of you guys show me the full bootcmd as returned by printenv?
<bjf> lool, I had the installer "use entire disk" and do what it wanted
<lool> The issue is likely in NCommander's UBoot
<lool> bjf: Ok; I'm not sure what it does on dove
<bjf> bootcmd=setenv file_load '${fs}load ${interface} ${device}:${partition} 1000 ${prefix}boot.scr';setenv fat_load 'setenv fs fat; run file_
<bjf> load'; setenv ext2_load 'setenv ext2; run file_load'; setenv attempt_load 'run fat_load || run ext2_load'; echo Scanning for boot device
<bjf> ...; usb start; ide reset; for i in usb ide; do for j in 0 1 2 3; do for k in 0 1 2 3; do for l in / /boot; do setenv interface $i; seten
<bjf> v device $j; setenv partition $k; setenv prefix $l; echo 'Scanning ${interface} ${device}:${partition} ...'; if run attempt_load; then ec
<bjf> ho Found boot.scr, checking ...; if imi 1000; then echo boot.scr OK! Executing ...; autoscr 1000; fi; fi; done; done; done; done; echo No
<bjf>  boot device found. Restarting; sleep 3; reset;
<bjf> lool, i'll pastebin an entire printenv
<lool> bjf: thanks
<bjf> lool, https://pastebin.canonical.com/22226/
<lool> bjf: the issue is bootcmd
<lool> ${prefix}boot.scr should be ${prefix}/boot.scr
<bjf> lool, I don't see "prefix" defined
<lool> or rather "for l in / /boot" should be "for l in / /boot/"
<lool> bjf: prefix is set in the loop
<lool> setenv prefix $l
<GrueMaster> lool: https://pastebin.canonical.com/22227/ is my minicom capture from poweron.
<lool> bjf: change your bootcmd to "for l in / /boot/" and saveenv
<ogra> bug 431963
<ubot4> Launchpad bug 431963 in linux "io/fs errors when launching gdm on imx51 with sata" [Undecided,New] https://launchpad.net/bugs/431963
<lool> GrueMaster: You're using the / prefix
<lool> GrueMaster: and it works for you, great!
<GrueMaster> brb.  household issue.
<lool> bjf: Did this help?
<bjf> lool, taking me a minute to the the change in
<lool> Ok :)
<bjf> lool, is there an easy way to edit that line or do I need to cut and paste a new one in?
<lool> bjf: You need to cut and paste
<bjf> lool, ok that's what I thought
<NCommander> lool, that's an old version of th eboot script
<NCommander> lool, in the bootscript, it needs to be {prefix}boot.scr
<GrueMaster> that's what I have as well.
<GrueMaster> I initially thought it was stuck in a loop, but it is just looping through all of the non-existant usb devices before going to sata.
<lool> Yes
<bjf> NCommander, lool, so do I need to modify mine or not?
<NCommander> bjf, no, just update to the latest binaries, and be patient :-0
<NCommander> *:-)
<bjf> NCommander, did that
<bjf> NCommander, at least I think I did that
<NCommander> GrueMaster, lool, its unfortunately pretty slow. I need to extend the usb/ide subsystem to throw an environment variable so I can iterate on extactly how many devices there are, and then try to see if I can figure out another method to determine the fs then forcibly load ext2/fat
<GrueMaster> bjf: It takes about 20 seconds to run through the loop.
<NCommander> GrueMaster, 20?, it only takes about 5 here
<bjf> GrueMaster, if you look at my pastebin, you see it goes through the entire loop
<bjf> NCommander, I'm checking what I did to see where I went wrong
<GrueMaster> I'm not digging up a stopwatch for exact timing.
<NCommander> bjf, whats the version string? (its posted at the start)
<NCommander> GrueMaster, fair enough. I do know its an issue that I didn't realize quite how bad it was until we were doing full blown installer testing :-/
<bjf> NCommander, U-Boot 1.3.4-dirty (Sep 16 2009 - 20:05:29) Marvell version: 4.2.3 NQ.  Canonical Development Version.
<GrueMaster> Not a big problem.  If I didn't have a serial port hooked up, I would think it is just doing it's normal bios boot (like x86 systems).
<NCommander> bjf, interrupt the autostart, then type ide reset and see if your drive pops up
<bjf> Canonical>> ide reset
<bjf> Reset IDE:
<bjf> Marvell Serial ATA Adapter
<bjf> Integrated Sata device found
<bjf> [0 0 0]: Enable DMA mode
<bjf>   Device 0 @ 0 0:
<bjf> Model: ST9250410AS                              Firm: 0002SDM1 Ser#:             5VG06NA2
<bjf>             Type: Hard Disk
<bjf>             Supports 48-bit addressing
<bjf>             Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
<NCommander> bjf, try: ext2ls ide 0:1
<bjf> Canonical>> ext2ls ide 0:1
<bjf> <DIR>       1024 .
<bjf> <DIR>       1024 ..
<bjf> <DIR>      12288 lost+found
<bjf>          1506745 System.map-2.6.31-204-dove
<bjf>           409765 abi-2.6.31-204-dove
<bjf>            90063 config-2.6.31-204-dove
<bjf> <SYM>         23 vmlinuz
<bjf> <SYM>         26 initrd.img
<bjf>          3360412 vmlinuz-2.6.31-204-dove
<bjf>          3360476 uImage
<bjf>          3273248 uInitrd
<bjf>          3273184 initrd.img-2.6.31-204-dove
<bjf>              356 boot.scr
<bjf>          3360476 uImage.bak
<bjf>          3273199 uInitrd.bak
<bjf>              356 boot.scr.bak
<bjf> Canonical>>
<NCommander> bjf, ext2load ide 0:1 1000 /boot.scr
<NCommander> autoscr 1000
<bjf> Canonical>> autoscr 1000
<bjf> ## Executing script at 00001000
<bjf> Starting Ubuntu...
<bjf> Unknown command 'load' - try 'help'
<bjf> Unknown command 'load' - try 'help'
<bjf> Wrong Image Format for bootm command
<bjf> ERROR: can't get kernel image!
<bjf> Canonical>>
 * NCommander hits head
<bjf> NCommander, let me try that again
<NCommander> why did I think that was going to work >.<;
<NCommander> Sounds like autodetection isn't very happy
<bjf> NCommander, same failure
<ogra> lool, "Configuring the network with DHCP " heh
<lool> ogra: hmm?
<ogra> copying /lib/modules from the usb key that had the former install
<NCommander> bjf, when the autodetection fires up, what does it do when it gets to ide 0:1? (it should be printing out each device as it scans for it)
<ogra> meh, dhcp needs some special love
<lool> ogra: Ah it doesn't work
<lool> ?
<lool> ogra: Check syslog and the like
<NCommander> ogra, where's that message from?
<lool> d-i
<ogra> NCommander, imx51 netinst
<NCommander> hrm
 * NCommander personally doesn't feel like dying anymore, and grabs dove netinstall
<lool> NCommander: I think it's broken
<lool> https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/431945
<ubot4> Launchpad bug 431945 in linux-mvl-dove "Lacks a bunch of modules for d-i support" [Undecided,New]
<ogra> its definately is given it misses all udebs
<NCommander> ogra, I did a netinst though w/ dove back in Dublin
 * NCommander can' tremember what kernel he did it with though ...
<lool> cp: cannot create link `/home/lool/cdimage/scratch/ubuntu/ports_daily/tmp/karmic-armel+dove/CD1/cdrom/uImage.in': No such file or directory
<lool> odd first time I get a different error on a manual build
<NCommander> lool, anyway, after today, I agree on having boot.scr be self-contained is a good thing, but it should detect if its been run off our boot.scr or not to prevent searching twice
<bjf> NCommander, https://pastebin.canonical.com/22227/
<NCommander> bjf, looks like it started up just fine?
<bjf> NCommander, that's not right
<lool> NCommander: Hmm ok
<NCommander> oh bugger
<NCommander> I see
 * NCommander is still not fully there
<NCommander> lool, the search loop is simply very slow (I'll be making improvements to extend it), but we'll have even more specific Canonical-functioanlity in the loop.
<bjf> NCommander, that was GrueMaster's here is mine: https://pastebin.canonical.com/22225/
<NCommander> oh ...
<NCommander> crud
<NCommander> I think I know what happened
<NCommander> GrueMaster, bjf, I think your old envirionmental variables got retained when you upgraded u-boot
<NCommander> or at least bjf's
<GrueMaster> Mine is ok, I think.  Let me pastebin my prinenv for comparison.
<NCommander> bjf, do: bubt u-boot-db88f6781y0bp_hX00_nand_1CS_fast_bank_en-09162009.bin from the Canonical>> prompt (bubt can be used safely once you switch from SPI-NOR to NAND)
<NCommander> bjf, hit yes when it asks if you want to zap the environment
<GrueMaster> https://pastebin.canonical.com/22229/ is my environment
<NCommander> GrueMaster, your got properly reset
 * NCommander isn't sure how that worked out
<GrueMaster> Probably because I didn't have an older Nand boot bin.
<NCommander> Ah, that would explain it
<lool> NCommander: make sure you update the instructions to reflect this
<NCommander> lool, right, let me just make sure bjf's upgrade goes safely/sanely
<GrueMaster> remember, yesterday when I set the dip switches, I was getting bootparam (1.07) > and nothing else.
<GrueMaster> Which I would guess ment that there was nothing at that flash location.
<bjf> NCommander, it's thinking about it... looks like that worked
<NCommander> bjf, \o/
<bjf> NCommander, I'm logging in now!
<NCommander> bjf, woo
 * NCommander notes there's probably a good way to blow away the environment with the nand command ...
<GrueMaster> woohoo!  First error on dove.  Already reported, but reproduced on dove none-the-less.  Bug #418300.
<ubot4> Launchpad bug 418300 in gnome-disk-utility "gdu-notification-daemon crashed with SIGSEGV in gdu_pool_get_devices()" [Medium,Confirmed] https://launchpad.net/bugs/418300
<GrueMaster> Hah!  My usb-nic works on dove.  Broken on imx51.
<lool> GrueMaster: Oh cool, compare lsmod?
<GrueMaster> this one is the dm9601 driver based nic.
<ogra> hmm, even with the whole /lib/modules content copied over i dont get the system on the net
<lool> NCommander: So I fixed the alternate CD for dove
<lool> NCommander: But I'm pretty sure /cdrom is incorrect
<lool> NCommander: http://cdimage.ubuntu.com/ports/daily/current/karmic-alternate-armel+imx51.list uses /install
<ogra> not via dhcp nor via fixed ip
<ogra> lool, for kernel and initrd ?
<ogra> yes, its /install
<lool> ogra: yes
<NCommander> lool, we can change that, as long as the paths in boot.scr and the actual files match up
<lool> NCommander: I think I fixed everything I knew about in dove; I'll leave it to you to fix the actual alternate CD
<lool> NCommander: That's up to you
<NCommander> lool, I'll hit d-cd once I get a chance
<GrueMaster> Interesting.  I unplugged the onboard nic port and plugged in the dm9601.  NetManager crashed (generating bug report now), restarted, and connected through the usb-nic no problem.
<ogra> ~ # ip addres show eth0
<ogra> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
<ogra>     link/ether 00:13:3b:04:05:b5 brd ff:ff:ff:ff:ff:ff
<ogra>     inet 192.168.2.32/24 brd 192.168.2.255 scope global eth0
<ogra> hrm
<ogra> i dont get why it doesnt work
<GrueMaster> heh.  firefox just crashed waiting for LP.
<lool> ogra: What's the error in the log?
<ogra> no errors
<ogra> ah looking closer (i was looking for NIC probs) ...
<ogra> Jan  1 00:32:12 main-menu[701]: DEBUG: resolver (libc6-udeb): package doesn't exist (ignored)
<ogra> Jan  1 00:32:12 main-menu[701]: DEBUG: resolver (libnewt0.52): package doesn't exist (ignored)
<ogra> meh
<ogra> that doesnt explain why fixed IP doesnt work though
<lool> ogra: You dont get a dhcp error?
<NCommander> lool, thank you for fixing livecd-rootfs for dove yesterday
<ogra> nope
<ogra> it silently times out
<ogra> i get the dhcp failed message from d-i though
<lool> ogra: tcpdump?
<ogra> i just resetted
<lool> NCommander: np
<NCommander> lool, did you change the d-cd scripts so alternate boot? (this code looks different then the last time I touched it)
<NCommander> er, build
<lool> NCommander: I actually fixed a bunch of your stuff *cough*
 * NCommander sweatdrops
<lool> flash-kernel and debian-installer notably
 * NCommander goes to go hide 
<GrueMaster> heh.  Firefox just crashed while trying to report a bug on another firefox crash.  sigh.
<NCommander> GrueMaster, recursion: n. see recursion.
<lool> < NCommander> lool, did you change the d-cd scripts so alternate boot? < NCommander> er, build    >>   19:09 < lool> NCommander: So I fixed the alternate CD for dove
<NCommander> right, sorry
<NCommander> I'm going to go get food
<NCommander> then I'll look at straighting out dove alternates
<ogra> lool, http://paste.ubuntu.com/272974/ in case you see something i dont
<lool> ogra: No, looks like dhclient doens't work; it doesn't work manually either does it?
<ogra> nope
<lool> ogra: You could check whether you have CONFIG_PACKET
<ogra> i would assume so, the same kernel works fine in the live image and installed systems
<lool> http://cdimage.ubuntu.com/ports/daily/current/karmic-alternate-armel+dove.img
<ogra> CONFIG_PACKET should be builtin
<lool> plars: GrueMaster: The fun never ends!  ^
<lool> ogra: Yeah I assume the same, just a desperate attempt
<ogra> i was searching for af_packaet for a while half an hour ago :)
<ogra> *packet
<plars> lool: which thing, kernel in alt image lacks CONFIG_PACKET?
<lool> ogra: that's on imx51?
<ogra> yeah
<lool> plars: The new image
<plars> lool: ah, that's dove though
<lool> plars: GrueMaster: You dont need to test it though; it's just to have things working that we build it and test from time to time
<lool> plars: Yeah; we have one for imx51 though
<lool> plars: It's slighlty broken and will be fixed soon
<plars> lool: ok, let me know if you think it needs my attention
<ogra> does it actually need a d-i uplaod ?
<ogra> i would think a respin should suffice for imx51 alternate
<lool> plars: No, unofficial image
<lool> plars: If you are idle and wish to do some extra QA, I'm happy to fix the image but it's not an important image
<lool> ogra: It needs a d-i upload
<lool> to refresh initrd
<plars> lool: if I'm idle, that's funny
<plars> :)
<ogra> oh, right
<lool> Yeah, #if 0
<lool> just a manner of saying that you likely wont ;)
<lool> Ok enough debian-cd/cdimage/flash-kernel/redboot-tools for me today; I did that basically the whole day
 * ogra tries a different NIC
<lool> plars: Note that linux bugs for imx51 should be filed on linux-fsl-imx51 not linux
<plars> lool: ah, crap... thanks
<lool> plars: and assigned to amitk at his request
<lool> plars: For dove it's linux-mvl-dove
<plars> lool: as in, assign it to him when he requests it, or as in "he requested that we always assign to him"?
<lool> plars: I understood the latter
<plars> lool: ok, what about dove kernel? assign to bjf?
<lool> plars: I'd guess so yes
<lool> bjf: ^
<plars> I'll add that to the workflow doc, which reminds me....
<ogra> ha !
<ogra> works as soon as i connect directly
<ogra> the hub was in the way it seems
<ogra> Installing the base system :D
<bjf> plars, yes, dove kernel can be assigned to me
 * ogra cries
<ogra> http://paste.ubuntu.com/272997/
<plars> bjf: ok, thanks
<ogra> Sep 17 17:59:48 in-target: update-initramfs: Generating /boot/initrd.img-2.6.31-100-imx51
<ogra> Sep 17 17:59:48 in-target: readlink: missing operand
<ogra> Sep 17 17:59:48 in-target: Try `readlink --help' for more information.
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: missing  root  /sys entry
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: workaround is MODULES=most
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: Error please report the bug
<ogra> Sep 17 17:59:48 in-target: update-initramfs: failed for /boot/initrd.img-2.6.31-100-imx51
<ogra> Sep 17 17:59:48 in-target: Failed to create initrd image.
<ogra> :(
<kblin> hi folks
<kblin> I'm running a sheevaplug with the preinstalled ubuntu jaunty, and it seems like I don't have any modules in my /lib/modules dir
<kblin> how would I get those?
<lool> kblin: I dont think they are shipped; I suggest you rebuild your own kernel
<kblin> yeah, looking into that when I get home
<kblin> I'm still at a conference, busy enough with other stuff
<NCommander> lool, ogra dove alternates boot and properly come up to d-i, but the ENOMODULES stops anything from working, so other the path issue, they look ok. Once bjf has an opportunity to sort out the udebs, I'll retest off a daily
#ubuntu-arm 2009-09-18
<siji> how to create *kernel.jffs2
<lool> I have no idea what that is
<siji> lool, am tryng to put both kernel and rootfs inside the nand memory
<siji> And i think nand memory will support only jffs2 file system
<siji> so need to convert both kerenl and rootfs to .jffs2 format
<lool> siji: What board is this on?
<siji> Compulab,CMX 300
<lool> What SoC is that?
<siji> Soc means ??
<siji> chip?
<lool> Yes
<siji> marvel pxa 300
<lool> siji: that's v5 right?
<lool> siji: Only jaunty supports that
<lool> siji: What bootloader does it use?
<siji> it's using compulab's customised u boot
<lool> siji: So I understand you can either partition the flash space to have a kernel and a rootfs zone and load them from there or you can put the kernel in the rootfs and tell uboot to load it from there (kernel in rootfs in flash)
<lool> siji: Did you look in the two options?
<siji> lool, yes
<siji> it's taking the rootfs too
<ogra> lool, do you have any idea about http://paste.ubuntu.com/273349/ ?
<ogra> Sep 17 17:59:48 in-target: update-initramfs: Generating /boot/initrd.img-2.6.31-100-imx51
<ogra> Sep 17 17:59:48 in-target: readlink: missing operand
<ogra> Sep 17 17:59:48 in-target: Try `readlink --help' for more information.
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: missing  root  /sys entry
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: workaround is MODULES=most
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: Error please report the bug
<lool> siji: Sorry can't parse what you said
<ogra>         if [ -L /initrd.img -a -e /initrd.img ]; then
<ogra>                 linktarget="$(basename "$(readlink /initrd.img)")"
<ogra>         fi
<ogra>         if [ -L /boot/initrd.img -a -e /boot/initrd.img ]; then
<ogra>                 linktarget="$(basename "$(readlink /boot/initrd.img)")"
<ogra>         fi
<ogra> neither of the initrd.img files exist
<siji> lool,it's giving error kernel panic
<ogra> the if statement is never fulfilled
<ogra> but still update-initramfs calls readlink
<lool> siji: So your kernel gets loaded then
<siji> yes
<lool> ogra: Are you sure it's failing on that spot?
<lool> ogra: Can you run in-target update-initramfs -c manually with set -x?
<ogra> no, just moved forward and i see outfile="$(readlink -f "$outfile")"
<ogra> in mkinitramfs
<lool> There are more uses of readlink in update-initramfs than the one you quoted and the one you quoted seem sufficiently protected that they wouldn't fail
<ogra> and i think i fell for a red herring anyway
<ogra> <ogra> Sep 17 17:59:48 in-target: mkinitramfs: missing  root  /sys entry
<ogra> that must be the actual error
<lool> siji: So your issue is perhaps with your root= cmdline?
<siji> can u just give me the cmd line
<lool> ogra: Yes
<siji> to boot frm nand
<lool> ogra: hook-functions has for instnace sys_walk_mod_add which looks like it would fail if /sys isn't mounted
<ogra>  if [ -z "${block}" ] || [ ! -e /sys/block/${block} ]; then
<ogra> echo "mkinitramfs: missing ${block} root ${root} /sys entry"
<ogra> crap so d-i (or rather base-installer) didnt mount sys
<lool> ogra: well that error is afterwards
<lool> ogra: Run with -x
<lool> siji: I'm not sure
<lool> siji: What's your kernel version?  I think it's something likeroot=jffs2/rootfs or something
<ogra> lool, well, /sys isnt mounted in /target
<ogra> so update-initramfs cant find out which modules it needs
<lool> siji: http://www.denx.de/wiki/DULG/RootFileSystemOnAJFFS2FileSystem
<lool> ogra: Did you verify that was the issue or is it an hypothesis?
<ogra> lool, i see that /sys isnt mounted
<ogra> i'm still in the d-i shell directly after the failure
<ogra> ~ # mount
<ogra> rootfs on / type rootfs (rw)
<ogra> none on /proc type proc (rw,relatime)
<ogra> none on /sys type sysfs (rw,relatime)
<ogra> tmpfs on /dev type tmpfs (rw,relatime)
<ogra> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
<ogra> /dev/sda1 on /target type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
<ogra> /dev/sda1 on /dev/.static/dev type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
<siji> lool,yes the kernel is in jffs2 format
<ogra> tmpfs on /target/dev type tmpfs (rw,relatime)
<lool> ogra: That might be the issue; I wonder if it's a recent change and whether it affects other arches
<ogra> lool, i doubt that, its the A6 candidate image
<ogra> that would have shown up during testing on other arches
<lool> ogra: I dont see the architecture specific issue though
<ogra> me neither but clearly neither /proc nor /sys are actually mounted
<ogra> which is the cause for the error i see
<lool> ogra: So you verified it's enough to mount /sys to fix the install?
<ogra> to bad i'm on serial, else i could repeat the whole thing and watch it from a second console
<ogra> no, i cant easily do that
<ogra> if i start over now, it will reformat /target and start over with a base install
<ogra> and i dont have a second console to manually mount /sys
<lool> ogra: You could go to target, dpkg -C and see if mounting /sys resolves it
<ogra> -C ?
<ogra> you mean --configure -a
 * ogra tries so ... i didnt touch /target yet to not taint the status of it 
<ogra> its hard to get to the same point again (having to copy around firmware and modules for the netinstall to even work)
<lool> ogra: Perhaps it would be best to defer until next debian-installer upload?
<ogra> # dpkg --configure -a
<ogra> Setting up linux-image-2.6.31-100-imx51 (2.6.31-100.7) ...
<ogra> Running depmod.
<ogra> update-initramfs: Generating /boot/initrd.img-2.6.31-100-imx51
<ogra> readlink: missing operand
<ogra> Try `readlink --help' for more information.
<ogra> mkinitramfs: missing  root  /sys entry
<ogra> mkinitramfs: workaround is MODULES=most
<ogra> mkinitramfs: Error please report the bug
<ogra> update-initramfs: failed for /boot/initrd.img-2.6.31-100-imx51
<ogra> Failed to create initrd image.
<ogra> :/
<ogra> sys is mounted
<ogra> and i can list /sys/block
<ogra> hrm
<ogra> err
<lool> Wasn't that obvious that it was /sys   ;-)
<lool> ogra: How about you set -x ?
<ogra> one sec
<ogra> there are supposed to be filled variables before root and after /sys in "missing  root  /sys entry"
<lool> How about you set -x ?
<lool> :-P
<ogra> http://paste.ubuntu.com/273378/ ...
 * ogra tries in mkinitramfs
<lool> ogra: in mkinitramfs
<lool> right
<ogra> http://paste.ubuntu.com/273380/
<ogra> # ls /dev/root
<ogra> ls: cannot access /dev/root: No such file or directory
<ogra> aha
<siji> hey lool,
<siji> mtd0: 00040000 00020000 "OBM"
<siji> mtd1: 00040000 00020000 "U-Boot"
<siji> mtd2: 00040000 00020000 "Environment"
<siji> mtd3: 00140000 00020000 "reserved"
<siji> mtd4: 00400000 00020000 "kernel"
<siji> mtd5: 1fa00000 00020000 "fs"
<siji> this is the nand partition table
<ogra> must be somewhere between line 218 and 226
<ogra> hmm, it uses the output from "mount"
<ogra> which is empty
<ogra> (well empty beyond sys and proc)
<lool> ogra: $(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')
<ogra> yeah
<lool> siji: Read that wiki page I mentionned?
<siji> ok
<siji> oh,it was for me :)
<ogra> # mount
<ogra> proc on /proc type proc (rw)
<ogra> sysfs on /sys type sysfs (rw)
<lool> ogra: see dep_add_modules() in hook-functions
<siji> i thought that it's for ogra :)
<lool> ogra: so where are you installing to?
<ogra> /dev/sda1
<siji> srry
<lool> ogra: can you compare with /proc/mounts?
<ogra> USB key
<ogra> # mount
<ogra> sysfs on /sys type sysfs (rw)
<ogra> proc on /proc type proc (rw)
<ogra> # cat /proc/mounts
<ogra> rootfs / rootfs rw 0 0
<ogra> none /proc proc rw,relatime 0 0
<ogra> none /sys sysfs rw,relatime 0 0
<ogra> tmpfs /dev tmpfs rw,relatime 0 0
<ogra> devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
<ogra> /dev/sda1 / ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
<ogra> /dev/sda1 /dev/.static/dev ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
<ogra> tmpfs /dev tmpfs rw,relatime 0 0
<ogra> proc /proc proc rw,relatime 0 0
<lool> ogra: So your mtab isn't matching /proc/mounts; that code would work with /proc/mounts
<lool> ogra: Now this has no reason of being architecture specific
<ogra> right
<lool> ogra: Is /etc/mtab different outside the target?
<ogra> unles mount has a bug
<ogra> mtab is identical to /proc/mounts outside target
<ogra> and ot the mount output inside
<lool> So this actually looks like an installer bug but I cant figure why it's only hitting us
<ogra> i initially starte because my /vmlinuz symlink isnt created
<lool> ?
<ogra> and i think i heard NCommander say something like that a wek ago
<lool> I dont get what you mwan
<ogra> i saw the readlink error
<ogra> and started debugging the kernel postinst, since i was suspecting the missing /vmlinuz and /initrd.img to be at fault
<ogra> then moved forward to update-initramfs
<ogra> to then get to mkinitramfs and the missing /sys ...
<ogra> which now got me to the hooks
<ogra> the point is that the obvious thing seems to be the missing symlinks
<lool> Oh ok if you sya so
<ogra> thats the error on the surface ...
<ogra> and thats what NCommander dug in a week or two ago in his manually spun dove images
<ogra> crawling through all of d-i if i understood that right, to find why his symlinks were missing
<ogra> so it seems to happen on dove as well
<lool> lunch
<Stskeeps> hmm, is there a typical ubuntu rootfs tar.gz laying about that just uses fbdev?
<lool> Stskeeps: I dont think we publish any regularly; we only build d-i images regularly; but you could easily build your own with rootstock
<lool> It might be a bit borken since some days due to upstart
<Stskeeps> k
<lool> ogra: 427199 isn't on the report but is milestoned
<lool> (from https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.milestone=12715 )
<ogra> ah, thanks, missed that one+
<ogra> lool, thats all ?
<lool> ogra: You can say "UNR theme" for the title of 430277
<ogra> plars, can i strike mobile-unr-karmic-compliance-autotesting  from https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Karmic ?
<lool> ogra: I'm slow because I'm chatting with telepathy people too
<ogra> yep
<ogra> saw that in the other chan.
<lool> ogra: 430344 isn't on the report either
<lool> but is on the milestoned bugs list
<lool> ogra: https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/423346
<ubot4> Launchpad bug 423346 in usplash "[armel+dove] usplash does not currently work on Marvell Dove Y0 boards" [High,New]
<lool> ogra: NCommander forgot to track in karmic...
<ogra> ok
<lool> NCommander: It's really CRUCIAL that you get that right
<ogra> lool, do we really belive its still worth to track banshee ?
 * ogra thinks that can be dropped from the report
<ogra> while it's nice to have and i still hope dyfet finds the issue its really not release critical or even intresting for the release meeting
<ogra> lool, wrt bug 424400 it might also be firmware thats missing ... though only GrueMaster can actually debug and confirm
<ubot4> Launchpad bug 424400 in linux-fsl-imx51 "DM9601 or Pegasus based USB NICs dont find their MAC address under 2.6.31-100-imx51" [Low,Incomplete] https://launchpad.net/bugs/424400
<lool> ogra: That's an idea
<ogra> [ubuntu/karmic] linux-fsl-imx51 2.6.31-101.8 (Accepted)
 * ogra dances !!!
<ogra> my second kernel this release cycle, yay !
<ogra> hmm, based on rc8
<ogra> what made me think i get something based on final :P
<siji> hey how to get the terminal/login window in both lcd and minicom
<plars> ogra: I marked it complete
<ogra> plars, so i can drop it, right ?
<plars> ogra: yeah
<ogra> (i saw its marked implemented, but its still on the release team report)
<ogra> cool
<ogra>  * ARM: IMX51: ENGR00103310 Initial imx_nfc NAND Flash MTD driver
<ogra> lool, ^^^^
<ogra> !
<ogra> * [Config] Run updateconfigs after rebasing to 2.6.31 final
<ogra> ah
<lool> ogra: Cool
<ogra> ha, and i can drop at least one bug from the report again :)
<ogra> Bug 359049 just closed itself
<ubot4> Launchpad bug 359049 in linux-mvl-dove "imx51 udeb hardcodes linux version in vmlinuz binary name" [High,Fix released] https://launchpad.net/bugs/359049
<lool> ogra: I usually keep the bugs which are mentionned on the email or reports and mention that they are closed on the mobile team report
<ogra> what are you referring to ? banshee ?
<lool> ogra: 422101 > removing the milestone?
<lool> ogra: 15:15 < ogra> ha, and i can drop at least one bug from the report again :)
<lool> ogra: I dont drop closed bugs
<lool> I just mark them closed in the report
<ogra> ah, k
 * ogra sighs, i dropped them all already
 * ogra tries to find them again and re-adds
<lool> ogra: https://bugs.launchpad.net/bugs/425464
<ubot4> Launchpad bug 425464 in unr-meta "Favicon for site being bookmarked should be used as part of the icon in the Launcher" [Medium,Triaged]
<lool> ogra: updating milestone
<lool> ogra: *I* forgot to track https://bugs.launchpad.net/ubuntu/+source/unr-meta/+bug/425464 in karmic *sigh*
<ubot4> Launchpad bug 425464 in unr-meta "Favicon for site being bookmarked should be used as part of the icon in the Launcher" [Medium,Triaged]
<lool> Actually i recall killing the browser before launchpad loaded on this bug
<lool> but well
<ogra> added
<lool> ogra: Hmm did you update the milestoned features??
<ogra> i removed them
<ogra> they are all set to implemented
<lool> ogra: https://blueprints.launchpad.net/ubuntu/+spec/mobile-qa-karmic-unr and https://blueprints.launchpad.net/ubuntu/+spec/mobile-qa-karmic-arm are milestoned
<lool> ogra: I'm not sure you're looking at the correct data
<lool> ogra: Goal is to a) move stuff from previous milestone to next milestone and b) comment on everything on the next milestone
<lool> https://bugs.launchpad.net/ubuntu/+milestone/ubuntu-9.10-beta
<lool> You can see two specs of plars there
<ogra> well, i looked at the three specs that were left from last week in the report
<lool> and the moblin remix one
<ogra> all three were marked implemented
<lool> ogra: The ones from last week were for A6
<lool> ogra: Now you need to also list stuff for next milestone
<ogra> and marked implemented when i looked 1h ago
<lool> ogra: the three specs for ubuntu-9.10-beta are not marked implemented no
<ogra> no, the three that were on the report before are
<lool> ogra: Actually there's even your spec on it
<lool> ogra: Well that's good
<ogra> wtf ... how can they show up if they are implementd
<lool> ogra: If the specs we intended to be implemented in A6 were implemented then we can remove them from the report and not move the milestone on them; that's considered normal if you like
<lool> ogra: I think there's a misunderstanding
<ogra> right
<ogra> i think there is a misconception in LP
<lool> ogra: You need to drop everything from the report which was targetted at A6 and implemented
<ogra> right, that i did
<lool> ogra: You need to move everything which was targetted at A6 and was NOT implemented to ubuntu-9.10-beta
<lool> ogra: And you need to report on everything which is targetted at ubuntu-9.10-beta
<ogra> ok, i thought the spec owners do that
<lool> ogra: The spec owners give you a one line summary in their blueprint which gets agregated in the burndown report
<ogra> lool, how did you get any work done on fridays in the past
<lool> ogra: It takes me about 1.5 hours to get the report written; I'm glad you see it's a lot of work   :-)
<ogra> thats eating half the day
<lool> I didn't do much on fridays indeed
<lool> ogra: That's also why I insist on getting this blueprint stuff in shape, the bugs properly milestoned and implemented the status in blueprints in the burndown chart
<ogra> yeah, i understood that before even assembling this report :)
<ogra> but i see how painful it is if they arent up to date
<lool> ogra: So I think I walked on the A6 stuff; you can just check the https://bugs.launchpad.net/ubuntu/+milestone/ubuntu-9.10-beta stuff
<lool> ogra: You want to mention status of the 4 specs
<lool> ogra: And poke plars since his specs are Started only
<lool> plars: ^
<lool> plars: What's the progress on the testcases specs?  Should we say slow progress?  Good progress now?
<lool> plars: they are currently "Started"
<lool> plars: https://blueprints.launchpad.net/ubuntu/+spec/mobile-qa-karmic-arm says you are bringing up your babbage board but that was a while ago
<plars> lool: well
<lool> ogra: So what I do is that I "union" bugs and blueprints from: A6 which need to be moved, beta, the ones mentionned in the report, the bug lists we review during our mobile irc meetings
<plars> lool: I don't feel right about saying beta available
<lool> ogra: I spotted one more blueprint in the agenda: UbuntuSpec:mobile-karmic-marvell-desktop; you might want to comment that it was implemented in A6
<ogra> ok
<plars> lool: because I have the wiki testplan up, but not a bzr repo with the tests integrated at this point
<lool> UbuntuSpec:mobile-unr-karmic-application-res also shows up not sure why
<lool> plars: That's ok but inbetween we could say Slow progress or Good progress
<plars> lool: I can change the status to something else if you'd like... what does it affect?
<lool> plars: I see it like: Started, Slow progress, Good progress, Beta, Implementeed
<ogra> lool, yeah, i was wondering what to do with app-res
<lool> plars: It will allow answering the release team's concerns if they ask where we stand
<lool> plars: Since "started" might worry them
<plars> ok
<ogra> make it good progress ;)
<ogra> lool, think i can drop app-res ?
<plars> I'll mark them both good progress, I've done more work on the unr one than the arm one, but a lot has gone into checkbox already (as expected) that benefits both of them
<plars> I wanted to get my A6 one finished up also, which also benefits UNR in particular.  Now that that's done, I'm going to be focused on these two
<ogra> lool, any suggestion what to do with application resolution ? i'm not sure what to say about it or why its on the report at all
 * ogra gets some more coffee
<lool> ogra: sorry had a phone call
<lool> ogra: I recommend you keep app-res and I'll clear things with paulliu when it's daylight time for him
<lool> ogra: I think the remaining bugs are upstream ones but still we need to update its state; sorry I didn't do that earlier this week
<ogra> remaining bugs ?
<ogra> so what do i write for app-res ?
<lool> ogra: in the app res spec
<ogra> ah
<lool> ogra: That most bugs are upstream one and we will look at reducing its scope next week
<ogra> well, i'm happy with a summary line to add to the report ...
<ogra> ok
<lool> ogra: you can take summary lines from http://piware.de/workitems/mobile/karmic/report.html when that's up-to-date
<ogra> which it isnt :P
<lool> Well the report is, the spec wasn't kept up-to-date
<ogra> so https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Karmic looks ok to you now ?
<lool> ogra: status for #423767 seems out of date
<ogra> well, who is pushing to linux-firmware then ?
<lool> ogra: It says "pending push from amitk but driver doesn't work and needs porting"
<ogra> yeah, i looked at the bottom
<ogra> its irritating that we have them twice
<lool> I think it should say something like "Needs kernel love to add firmware from upstream" or smth
<lool> ogra: agreed
 * ogra moves description from the bottom one to the top one as well
<ogra> Dove squahfs's ...
<ogra> hhe
 * ogra fixes NCommanders typos i copy/pasted
<lool> ogra: 425547 > we're blocked on telepathy-mission-control-5 port of moblin stuff but I just clarified the plan with upstream
<ogra> ok
<lool> ogra: there's a typo in the bug number 427199 for dove squashfs
<lool> in the report it says #27199
<ogra> fixed
<lool> ogra: lool started testing on the ffmpeg bug if you like
<lool> ogra: status of #420555 is out of date
<lool> You might want to mention FSL is looking into it
<ogra> i updated it though
<lool> ogra: Ok that's all I had
<ogra> might not be massively obvious, i just mangled your sentence
<ogra> thanks, will add the changes
<lool> ogra: Looking at general status stuff
<lool> "inmportant" typo
<lool> ogra: I would mention addition of installer support in dove and the oo.o issue in the sections at the bottom
<lool> ogra: and moblin remix being blocked on the TMC 5 port
<lool> ogra: Perhaps the ooo issue can go in armel general status
<lool> ogra: As a reward I'll share something with you in some minutes
<ogra> updated
<lool> ogra: email sent
<ogra> thanks :)
<GrueMaster> So, I heard my name, metaphorically speaking.
#ubuntu-arm 2009-09-20
<kblin> ah, great, now that was easy...
<kblin> I just bricked my sheevaplug by setting wrong networking settings, it seems
<kblin> and that usb connector that supposedly can be used to get a console doesn't seem to be working
<kblin> oh, ok, so that seems to be a special cable after all
<lool> kblin: You cant really brick it
<lool> kblin: The mini USB cable is not special, but the sheevaplug has a JTAG and a serial console over this USB port so you can always recover
<lool> kblin: Start with the serial console
<lool> kblin: Plug the mini USB cable, reboot your sheevaplug and immediately run "screen /dev/ttyUSB* 115200"
<kblin> lool: dunno, I had to use the cable that came with the device for the serial ports to show up
<kblin> also it seems like the settings were ok, it just takes a couple of minutes for the thing to boot
#ubuntu-arm 2010-09-20
<Neko> anyone know of any progress with bug 628587 ?
<ubot2> Launchpad bug 628587 in ubiquity (Ubuntu) "Ubiquity 2.3.13 (oem-config) fails to create initial user (affects: 1) (heat: 234)" [Undecided,New] https://launchpad.net/bugs/628587
 * persia looks
<persia> Looks to me like rcn-ee is the only person chasing that report.  If I'm understanding the bug correctly, something odd is happeng when user-setup is called.
<persia> Could either do additional bisection by bzr revisions from lp:ubiquity OR turn on all the debugging output and try to pinpoint the offending code that way.
<persia> rootstock images tend to be weakly supported (if it's an issue with rootstock itself, the rootstock devs are typically happy to fix it: if it's an issue in Ubuntu, most folk are willing to review a patch, but only support debian-cd derived images)
<Neko> persia, indeed but right now I'm having trouble getting even a minimal image, which I then want to use to set up livecd-rootfs stuff like you suggested
<Neko> it's really annoying :(
<Neko> setting the login details is okay I guess
<Neko> it just adds extra steps for everyone involved
<persia> Given that lucid works, you might try creating a lucid environment, and using that to run debian-cd and livecd-rootfs
<Neko> persia, doing that now :D
<hrw> morning
<ndec> ogra: hi!
<ogra> hey
<ogra> how was your release ?
<ndec> ogra: how can I know which version of MLO is put in an image?
<ogra> i guess only from the serial console
<ndec> release was bad ;-) main problem is our non standard gst packages... that cause headache to install...
<ogra> since MLO doesnt get installed as a package (we only use the binary in the boot partition)
<ndec> add to play with pinning...
<ogra> ouch
<ndec> well, somehow it would be nice to track (in the manifest?) which source for uboot and MLO is used in image..
<ogra> the manifest only holds installed packages
<ogra> the image will always have the version that was recent in the archive when the iage was built ...
<ogra> https://edge.launchpad.net/ubuntu/maverick/+source/x-loader-omap4/L24.9git20100901-0ubuntu1 is in the current ones and i dont expect that to change unless we add ES2.1
<persia> When we do a proper release, it becomes easier to track, as the archive is frozen, and another created.
<ogra> u-boot has a bit less obvious version number https://launchpad.net/ubuntu/maverick/+source/u-boot-linaro/2010.09~rc1.1-0ubuntu2 (we need to talk to linaro if you need that changed)
<persia> Well, depends.  Seems we changed it at least once since the last upstream.
<persia> (but definitely *best* to talk to linaro: forks are to be limited)
<ogra> but you dont know from when the upstream checkuot it
<ogra> i'm not sure the tag matters at all since they merge multiple branches
<persia> Far as I'm concerned, linaro is the upstream for that.
<persia> I know there's groups upstream from linaro, but they are outside the scope of my attention :)
<ogra> doesnt help much if you want to know about one specific branch
<persia> Yeah.
<ogra> i.e. omap4
 * ogra hopes todays image resizes again
<persia> Anyone know anything about tbb?  I see http://software.intel.com/en-us/forums/showthread.php?t=67133 but I'm having trouble determining if ARM support is present in the Ubuntu version.
<ogra> there arer days where i really ponder to drop set -e from the scripts
<persia> Please don't.  Better to find out when there is an issue.
<ogra> well ...
 * persia has spent the majority of the past week fixing up type naming for a package that just made it work, rather than doing it right
<ogra> (indeed i would never drop it, but it costs a day usually)
<persia> Better a day here and there than a week or two for some poor sod in six months.
<ogra> especially for such minor changes as the one that broke yesterdays image
<ogra> colin hardcoded linking mtab to /proc/mounts in initramfs-tools/init ... which we do since day one
<ogra> (in jasper)
<ogra> so the script died silently and just moved on without resizing
<persia> That's probably just a coordination issue.  We need better means of tracking changes on surrounding packages of interest.
<ogra> well, we have the changelog ...
<persia> Relying on people to contact other people isn't a good way to do it, and things change fast enough that it's not possible to read the patches anymore.
<persia> Sure, but who reads all the changelogs anymore?  I used to do it, but I often can't these days, as they come too fast.
<ogra> bah, and the LED heartbeat is way to fast
<ogra> XM at least has a 1sec interval
<ogra> ah, great, it is resizing again
 * ogra now has a hectical blinking board in front of him
<ogra> i think the frequency is 25-30ms or so
<ogra> sigh and the swap creation is really taking long
<ogra> gah, and indeed apturl doesnt work as expected :(
<hrw> Xm, panda... /me -> picocom ttyS2 to check beagleboard c3
<hrw> ops.. its ttyS6
<fgu> ogra: hi just a question about your toshiba ac-100...you succeeded to get root access etc on it?
<ogra> fgu, yes, i managed to brick it too :P
<fgu> ogra: gloups...because I have just found this one: http://tosh-ac100.wetpaint.com/
<fgu> coming from here: http://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=217864&#217864
<hrw> ac100 looks nice of photos
<ndec> ogra: about the images, is the latest (20109020) okay?
<fgu> hrw: hi, yes but regarding the test for video playback, some people are finding it too short in battery life...
<hrw> fgu: for battery life I have my x86-64 laptop
<fgu> hrw: ;o)
<hrw> fgu: CULV intel core2duo with 8-10h life
<ogra> ndec, yes, PPA install is broken still (working on that) and swap file creation adds a few mins to the resizing process
<fgu> hrw: real 10h ??
<ogra> ndec, beyond that it should be good to use
<hrw> fgu: will test it during trip to uds-n. so far never used it for longer then 5-6h
<fgu> hrw: sounds more realistic..but that's nice already if it's a real 6h
<hrw> booting bbC3 is fun. local-premount starts, then nothing for long long time then oom, then normal boot
<hrw> I really need to upgrade ;D
<hrw> "apt-get -f -yes install", then "apt-get install aptitude", then remove all x11 related stuff
<ogra> fgu, the rooting works fine ... and if you are not as silly as me to link /bins/sh to something broken, you can even boot afterwards :P
<ogra> fgu, i had an ubuntu chroot running on it just fine and also a loopback vnc session to an ubuntu desktop
<ogra> (just very slow through vnc)
<ogra> but maverick runs fine in that setup
 * ogra will return the device today and see if he can get an replacement or if they send it in to toshiba
<hrw> ~curse sd slot on omap3 and its lack of any speed
<fgu> ogra: good job even if the end of the story is a brick netbook...hope you will get a new one then...
 * ogra too :)
<fgu> ogra: my previous links were droid related..so at the end not usefull for you I think..
<ogra> rageagainstthecage-arm5.bin works fine for rooting
<fgu> ogra: yep, ok, I have read this one
<ogra> then creating a passwd file with root user and making busybox suid root gets you permamnent root
<fgu> ogra: well done!
<ogra> still that doesnt get you any bootloader access though
<ndec> ogra: about the PPA install, so is done exactly? just the setup of the PPA, or do you install some packages?
<ogra> which is essential for changing the android params to a sane OS
<hrw> ogra: replace kernel with uboot+kernel image
<ogra> ndec, there is an icon on the desktop (with the next build, i messed something up in the current one) if you click it, it is supposed to fire up software-center with the offer to enable the ppa and install
<ogra> hrw, where ?
<ogra> hrw, there is no place you can find the kernel
<ndec> ogra: thx.
<hrw> ogra: auch.. no flash partition even?
<ogra> hrw, its nvidia crap, it uses some hidden NAND to hold bootloader, kernel and initrd
<hrw> ok, no question asked then
<ogra> even on the tegra dev boards you can only use nvflash to write them
<ogra> but that requires a special flash7recovery mode which was patched out in the toshiba version
<persia> !ohmy | ogra
<ubot2> ogra: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<ogra> all that bootloader can do is install update.zip files for android
<ogra> yippiee ! i managed to trigger an ohmy from persia :)
<ogra> (or do a factory reset)
<persia> Just hard to get folks to cooperate when you insult their product scatalogically.
<ogra> persia, yeah, i'm just upset by the setup
<ogra> (funny sentence ... would make a good T-Shirt print)
<persia> I understand.  Even more so because it's useless to you unless it runs the OS you use, and it became even more useless in the process :(
 * ogra takes a coffee break
<hrw> arm people: fpc fails to build, hedgewars also fails. both require fpc to be present. any way to solve?
<persia> hrw, fpc needs bootstrapping.  It's been done N times, but never actually works at the moment lamont tries to do it in the archive.
<persia> Figuring out precisely what goes wrong for lamont (when it works for other folks), and ensuring that is fixed is the trick.
 * persia looks up the bug report
<hrw> is same with haskell?
<suihkulokki> fpc bootstraps nice these days, you can ofcourse shortcut that by taking the fpc from debian
<persia> haskell is broken for other reasons.
<persia> suihkulokki, We're shortcutting, but it still doesn't work for lamont.
<persia> hrw, For haskell, I'd recommend asking Laney in #ubuntu-motu: he's been driving that mostly.  He'd really appreciate some help testing some things (he has no arm hardware today)
<persia> Right, fpc is bug #67544
<ubot2> Launchpad bug 67544 in fpc (Debian) (and 3 other projects) "Bootstrapping needed for fpc for armel (heat: 12)" [Unknown,Fix released] https://launchpad.net/bugs/67544
<persia> Fixing fpc would mean we get something like 20 packages that we don't have today: the trick is to get something that works for lamont: just because the rest of us can do it doesn't mean it can be uploaded.
<hrw> persia: need to get my bb/c3 upgraded - will take most of day probably
<hrw> die sd card, die
<persia> hrw, Won't help.  Fixing it requires building it on a bbg3.0 with a buildd chroot image.
<persia> buildd chroot images can be downloaded from launchpad.  Getting a bbg3.0 running the config on the buildd is a bit trickier (not least because one has to have the right hardware first)
<hrw> persia: I prefer to do builds on local hardware before going to externals
<persia> hrw, I understand.  I'll tell you now that if you install maverick on your bb/c3, and you download the source, and you grab the bootstrap binaries (either doko's or from Debian), you will bootstrap it successfully.
<persia> The issue is only in finding out why it doesn't work on the buildd, and getting that working, and uploaded.
<persia> The actual code is fine.
<hrw> ok, thx
 * persia has bootstrapped it twice on armel, with perfect success, and no archive results :(
<cjjnjust> hello anyone online
<persia> Lots of folks.  /names will give you a list :)
<rsalveti> morning
<rsalveti> hm, seems we have images now
 * ogra_ac waves from a new ac100
<dmart> ogra_ac: android, or ubuntu?
<ogra_ac> dmart android, i managed to root it but bricked it yesterday
<persia> ogra, The RMA worked?  Congratulations!
<ogra_ac> yeah, just play dumb and they feel pity for you
<dmart> ogra_ac: sounds more interesting, are there instructions somewhere?
<ogra_ac> dmart someone posted them today above, essentially you just need a terminal app and run a binary called rageinthecage or something like that  ... next term you open is rooted
 * ogra_ac will root this one too later today ... but this time not delete /bin/sh :P
<ogra_ac> its really embarassing
<ogra_ac> dmart, btw, ubuntu maverick chroot works fine, i also had a vnc loopback connection to a localhost chroot that worked buut wasnt of much use (to slow)
<ogra_ac> but i had a desktop running
<dmart> ogra_ac: heh :)
 * dmart has had similar fun replacing /sbin/init with garbage in the past
<ogra_ac> at least i found out that the recovery mode works in two parts and that the second part requires a shell :)
<dmart> though not as embarrassing as hexedit /dev/tty2 <>/dev/sda >&0 2>&0 (I was having a bad day that time)
<ogra_ac> ouch
 * robclark discovers sudo apt-get remove maximus
<ogra> heh
<robclark> makes gnome session behave much more like gnome session
<ogra> for fixing the ugly fullscreen bug ?
<robclark> yeah
<robclark> I wonder why maximus starts for gnome desktop session?
<ogra> its easier than removing it ... you can just disable it in the gnome session
<ogra> in the session properties
<robclark> ahh, ok.. where are session properties?
<ndec> robclark: system/preferences/startup applications
<robclark> ahh.. gui even.. I was assuming some config file hidden somewhere ;-)
<ndec> robclark: if you prefer, there should be a config file hidden somewhere!
<robclark> ndec: heheh.. no, it's ok..  I was just not looking for the easy solution ;-)
<rsalveti> or at least gconf-like cmd line
<jo-erlend> I have an IGEPv2 board. I've installed Maverick on a memory card, and it seems to boot. However, the screen goes black when X starts up. Any ideas on how to fix this?
<armin76> replace with omap4 :D
<hrw> ;D
<hrw> first they have to appear on market
<jo-erlend> heh. I think the hardware is quite sufficient for my needs, but it would be nice if I could see what I'm doing. :)
<robclark> jo-erlend: anything suspicious in /var/log/Xorg.0.log?
<ogra> jo-erlend, i think the linaro folks have such HW, though i'm not sure they use actual maverick images on them
<jo-erlend> robclark, you're smart, you are! I'll have a look.
<jo-erlend> robclark, indeed, it does. Perhaps you could have a look and see if you get any good ideas?
<robclark> jo-erlend: can you pastebin?
<jo-erlend> robclark, http://pastebin.com/6hAjUwCW
 * robclark looks
<jo-erlend> it looks to me like it doesn't detect any screens.
<robclark> hmm, no framebuffers?
<robclark> ls /dev/fb*
<jo-erlend> I have no way of doing that, since I haven't got either network or screens to see what the results are.
<robclark> consolefb would still work with no fb device files.. but x wouldn't
<robclark> oh... doh
<robclark> hmm
<jo-erlend> perhaps I can deactivate X in order to get a console and then see what ls /dev/fb* gives me? How do I do that?
<robclark> add the word "text" to your bootargs
<rsalveti> weird thing is that it seems you don't have any fb device
<rsalveti> are you able to get anything before X starts?
<jo-erlend> robclark, in what file do I do that?
<ogra> boot.scr or in u-boot prompt
<jo-erlend> rsalveti, well.. First the screen is completely white, then it becomes a psychedelic mess of colours, and then it goes black.
<ogra> sounds like my touchbook
<jo-erlend> ogra, I don't get any prompt, and I have no boot.scr file. The install guide told me to remove all files except uImage.
<ogra> you should have an u-boot ptrompt on the serial console
<ogra> *prompt
<jo-erlend> I have no serial console :(
<rsalveti> ouch
<rsalveti> no network, no screen and no console :-)
<jo-erlend> right. :)
<ogra> thats bad indeed
<rsalveti> but you can change it at your sd card
<jo-erlend> change what?
<rsalveti> but to debug it properly you should at least have access to the serial console
<rsalveti> boot.scr
<jo-erlend> I have no such file.
<ogra> you had it initially, right ?
<ogra> (since you said you had to delete everything)
<ogra> what howto were you following btw ?
<jo-erlend> ogra, http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution#Ubuntu_10.10_.28Maverick_Meerkat_BETA.29
<jo-erlend> yes, I think I had it initially.
<ogra> lol
<jo-erlend> I can give it another go and skip deleting those files.
<ogra> why do they call it boot,ini ?
<jo-erlend> I have no idea.
<ogra> boot.ini is whats boor.scr on all other omap systems
<rlameiro> jackd doesnt start on maverick, it hangs in there i thing crashing, how do i collect data of it runnig to give it to bug hunters?
<ogra> so you want to edit the boot.source file and re-run the mkimage command
<ogra> but given that you have no output at all, adding "text" to the bootargs wont get you much further i fear
<jo-erlend> oh, ok. Thanks.
<ogra> rlameiro, best is to have network and run "ubuntu-bug jackd"
<ogra> that will collect all info
<rlameiro> yea , but i will want to collect some more data before that, is it possible?
<ogra> then you need gdb i guess
<rlameiro> will it run jackd to see what is going?
<ogra> no
<ogra> it will collect a defined set of logs and info thats defined in the jackd package
<rlameiro> i want to give maximum info possible
<ogra> fi you run a graphical session, apport should come up and collect a crashdump
<ogra> non graphically you can take a look in /var/crash ... that might have a coredump file for the crash, but be careful, it contains your RAM content (might have passowrds etc)
<rlameiro> problem is that it doesnt crash, it hangs, i do a ps and the process is active
<ogra> well, then gdb and capture a backtrace
<rlameiro> lol, i can tell my pass :D 123456
<jo-erlend> ogra, it might be imagination, but the colorful screen seemed to stay longer. The screen still went black though.
<rlameiro> so i run gdb <COMMAND>
<ogra> https://wiki.ubuntu.com/Backtrace
<rlameiro> ogra thanks
<rsalveti> ogra: jo-erlend: I guess by removing the uInitrd the sd card will not be resized
<jo-erlend> rsalveti, what does that mean?
<rsalveti> from the pre-installed image
<rlameiro> lol gdb crashed my board
<ogra> rsalveti, well, by following these instructions the image will also stay completely unconfigured
<rsalveti> yep
<ogra> it wont run oem-config ever
<rsalveti> a really ugly hack :-)
<ogra> these instructions are quite a mess
<jo-erlend> any computer shop should have what I need for a serial connection to the board, right?
<rsalveti> what kind of connector do you have at your board? is it similar to the beagle one?
<ogra> jo-erlend, USB to serial adapter ... and probably a gender changer for the sub-d port or a null modem cable
<hrw> igep uses icd10 connector
 * ogra has no idea how the IEGP2 looks like wrt serial
<hrw> same as bb
<ogra> which BB :P
<rsalveti> c4
<hrw> the only existing for customers one
<ogra> XM just has a sub-d socket :)=
<hrw> ogra: xM still is you-can-dream device rather
<ogra> nah, they are on sale
<hrw> finally?
<hrw> good
<ogra> big backlog, but they sell them
<ogra> you should know !
 * hrw waits for personal pandaboard anyway
<ogra> i know some of your colleagues have A2's
<hrw> ogra: infrastructure team has some toys, yes
<hrw> ogra: I work on cross compiler packages so no linaro hw for me
<ogra> and they were ordered in a std. way afaik
<ogra> mean !
<hrw> anyway before uds-n I should have panda @home for any experiments
<jo-erlend> ogra, do you think I might have better results with another monitor?
<ogra> i dont even know how well the kernel supports IEGP2 at all
<ogra> especially the framebuffer code
<ogra> we dont have such boards in the team so nobody tested it ... and the configuration tool on the image expects a display so you end up with a pretty much messed up image following the howto
<rsalveti> I'd recommend you to try linaro's kernel
<rsalveti> maybe you have a better result
<ogra> yeah
<ogra> though i think they are using them mainly with a minimal image for development
<ogra> they might not care about graphics there
<ogra> hey lag_
<ogra> had a safe flight ?
<rsalveti> but if it works, it should at least show something at his monitor
<ogra> yeah
<lag_> Hey orga
<lag_> Yeah, 23hrs ...
<rsalveti> lag_: out, taiwan?
<rsalveti> *ouch
<lag> Yeah
<lag> :)
<prpplague> rsalveti: looks like gnome-power-manager has an issue with my netbook
<rsalveti> prpplague: hey, so did you try to disable it?
<lag> Has anyone managed to get ftrace working on the Panda yet?
<rsalveti> has anyone tried?
<lag> I think so
<lag> mpoirier was working on it last I heard
<rsalveti> well, don't think mpoirier got his panda already
<lag> I think he was working on omap generally omap/omap4
<lag> If it works on OMAP it should work on OMAP4
<rlameiro> lp #643626
<ubot2> Launchpad bug 643626 in jackd-defaults (Ubuntu) "Jackd doesnt start on ARM Beagle board clone IGEPv2 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/643626
<prpplague> rsalveti: yea, just turned it off so that it doesn't autoload on startup
<prpplague> rsalveti: works fine after that
<prpplague> rsalveti: i'll start debugging the issue this week
<rlameiro> persia: lp #643626 , does it need more info ?
<ubot2> Launchpad bug 643626 in jackd-defaults (Ubuntu) "Jackd doesnt start on ARM Beagle board clone IGEPv2 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/643626
<rsalveti> prpplague: cool, please file a bug for it when you have time
<rsalveti> just to let people know that we have issues with your hardware
<hrw> ~curse omap3sd
<rlameiro> mpoirier: Persia told me that you are into audio in ARM
<mpoirier> rlameiro: yes, that is correct.
<rsalveti> hrw: haha, giving apt-get update/upgrade is *painful* on on it
<rlameiro> mpoirier: waht is your board?
<hrw> rsalveti: 6-7h so far
<rsalveti> ouch
<mpoirier> I will get an 8 layer panda
<rlameiro> mpoirier: lucky.... i have a IGEPv2
<hrw> rsalveti: when it will finish this 4GB SD will be /boot only - rest on usb pata harddrive
<rlameiro> having some problems with audio on it
<mpoirier> rlameiro: did you get it from amitk ?
<rlameiro> mpoirier: lp #643626  and #642465
<ubot2> Launchpad bug 643626 in jackd-defaults (Ubuntu) "Jackd doesnt start on ARM Beagle board clone IGEPv2 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/643626
<ubot2> Launchpad bug 642465 in puredata (Ubuntu) "Puredata outputs Very bad sound when using ALSA backend (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/642465
<mpoirier> rlameiro: again, did you get the board from amitk ?
<rlameiro> mpoirier: amitk? I bought it from the builders - ISSE
<mpoirier> rlameiro: ok.
<rlameiro> what is amitk?
 * amitk looks up
<ogra> lol
<rlameiro> ahhhh
<rlameiro> lol
<mpoirier> amitk works with me on the linaro side.
<ogra> amitk, you are selling boards  ?!?
<rlameiro> nice
<amitk> ogra: had to supplement my income :-p
<ogra> *giggle*
<mpoirier> he and I had a run-in with and IGEPv2 board a couple of months ago.
<rlameiro> amitk: website???
<rsalveti> hrw: yep, at my devel board I'm using an usb disk
<ogra> linaro.org
<rlameiro> no, i tought amitk had a shop :D
<rlameiro> lol
<rlameiro> i know linaro
<amitk> :)
<mpoirier> rlameiro: i'm not surprised sound isn't great on IGEPv2.
<rlameiro> mpoirier: well, the codec isn nothing special, but i cant use my edirol ua4fx  also
<rlameiro> I dont know but it doesnt work
<rlameiro> audio is the same that the beagle, the twl 4030
 * rsalveti lunch
<mpoirier> rlameiro: I know - it should work, until you find different setting in the board file or some place else...
<rlameiro> i am thinking on making a custom audio board for it using the TI bus /12S
<mpoirier> rlameiro: I currently have the same problem with a Gumstix overo.
<mpoirier> rlameiro: related to display.
<rlameiro> i never wanted to use the onboard audio codec , its too noisy, but if jack isnt starting i dont know if it will be of help, also plugin my edirol usb interface doesnt work either, it is detected but cant play anything, not even with aplay...
<mpoirier> rlameiro: not cool.
<rlameiro> mpoirier: i am feeling like a devil's advocate, 2 days runnig ubuntu on my board 2 bugs posted
<rlameiro> and I didnt posted the edirol issue yet...
<mpoirier> rlameiro: that is normal.
<mpoirier> we haven't worked much with the IGEPv2 board.
<rlameiro> well, but it seems to be a nice board
<mpoirier> rlameiro: no doubt, no doubt friend.
<rlameiro> 512/512 MB, 720 Mhz etc
<mpoirier> rlameiro: i know.
<rlameiro> wifi bluetooth and stuff
<rlameiro> I prefer it way more to the beagle... and after buying it, the beagle XM came out....
<rlameiro> but anyway since igepv2 come from spain, its cheaper for me here in Portugal
<hrw> anyway it works
<mpoirier> rlameiro: file the bugs you find - our agenda may permit to address them.
<hrw> I remember playing with igep during platform sprint when we had one with SD not working under linux (working in uboot)
<rlameiro> mpoirier: do you have igepv2 at canonical?
<mpoirier> we have a few but again, ran in some SD card trouble with them.
<mpoirier> rlameiro: back then I didn't have the time to address them.
<rlameiro> ahh ok
<mpoirier> Getting the boads aren't the problem - time to work on them is.
<furibondox> hello
<rlameiro> well have to go to work
<rlameiro> cya latter everyone
<furibondox> I've a problem with udev... it seems that udev doesn't read my custom rules
<mpoirier> rlameiro: thanks for your comment and feedback on the IGEPv2.
<furibondox> I'm using ubuntu lucid
<furibondox> the rules are correct and worked fine in jaunty
<furibondox> my concern is that during the init, the mount -o move /dev should be responsable of this behavior... once I am into the rootfs (after run-init) all devices are copied into the rootfs and the udev has already took effect but I'm not sure if it read the rules again or not (but seems not)
<furibondox> again, if I manually run "udevadm control --reload-rules", my custom rules are not processed
<furibondox> any idea?
<ogra_ac> where do you put them ?
<furibondox> in /etc/udev/rules.d/
<ogra_ac> that should work
<furibondox> ogra_ac: just another question... if you want I can send you my rootstock script with 2 little mods
<ogra_ac> file a bug, attach the patch
<ogra_ac> i'm not doing much on rootstock atm
<furibondox> I've never submit a bug for ubuntu, where should I do it?
<ogra_ac> so are you using update-initramfs now  ?
<ogra_ac> (for bugs see /topic ;) )
<furibondox> well... now I'm using the same initrd as the ubuntu but w/o update-initramfs
<ogra_ac> i'm not sure, but it might copy the rules into teh initramfs
<furibondox> I simply copied it from the one present after the rootstock (used with the beagle kernel) and then I modified it a little to fit our needings
<furibondox> but is almost the same
<furibondox> except little hw configuration
<ogra_ac> did you compare with an unmodified one ?
<furibondox> yes...
<furibondox> is the almost the same
<ogra_ac> and that doesnt read your rules either ?
<furibondox> I've not the original initrd now so I can't try to do it
<furibondox> I will try to set the rules in the initrd
<furibondox> tnx
<furibondox> now I must go...
<furibondox> see you tomorrow
<furibondox> bye
<ogra_ac> ciao
<furibondox> ciao ;)
<ogra_ac> oh my
<ogra_ac> the android browser refuses to open https links with selfsigned certs
<GrueMaster> Yes, this is known.
<armin76> feature
<GrueMaster> ogra_ac: Use opra for android.
<ogra_ac> thats unusable
<ogra_ac> i have it installed
<ogra_ac> opera is just painful to read
<ogra_ac> it renders awfully
 * ogra_ac wishes there ws afirefox build
<ogra_ac> *was
<ogra_ac> or chromium
<GrueMaster> Hey, hostname has returned to oem-config.  Nice.
<slangasek> GrueMaster: u-boot-linaro made it over the weekend - how does it look on omap4?
<rsalveti> slangasek: working fine at our current daily image
<rsalveti> leds are now working
<rsalveti> no other issues until now
<GrueMaster> I booted today's image.  Serial console shows U-boot 2010.09-rc1 (Sep 18 2010 - 11:15:35) for u-boot.
<GrueMaster> Looks good.  And I have blinking lights next to the SD slot.  :D
<ogra_ac> is there a chance that we can make it blink a little slower ?
<slangasek> rsalveti, GrueMaster: awesome to hear, thanks
<rsalveti> ogra_ac: heartbeat? need to check the code
 * ogra_ac would prefer once a second
<rsalveti> depends on the cpu load currently
<ogra_ac> ah
<ogra_ac> higher load means faster ?
<rsalveti> yup
<rsalveti> that's why heartbeat
<ogra_ac> then we need to improve the userspace !
<rsalveti> ogra_ac: playing with android?
<rsalveti> or using ubuntu already?
<GrueMaster> So, is the heartbeat tied to actual cpu load or all load?  Don't need excessive flutter waiting on SD I/O.
<rsalveti> don't remember the code, but it should be cpu load
<ogra_ac> rsalveti, i bricked the device on sun. so i'm a bit more careful now :)
<rsalveti> hahah, got it :-)
<ogra_ac> (with teh replacement)
<ogra_ac> luckily the guys at the discounter where they sell it are totally clueless so it was easy to get a replacement
<rsalveti> hehe, cool
<GrueMaster> slangasek: Was that u-boot omap4 only?
<ogra_> grmblfjx
<GrueMaster> Yea.  My XM is finally working again (so far).  3rd time trying a fresh daily image today.  Currently finishing oem-config stage.
<devilhorns> woot ! :)
<GrueMaster> And...it crashed.
<GrueMaster> sigh.
<devilhorns> must be because I said something, sorry ;)
<GrueMaster> It's possessed.
<devilhorns> hehe
<ogra_ac> kill the daemons
<slangasek> GrueMaster: there's an omap3 as well, but you guys aren't using that yet
<ogra_ac> slangasek, yeah, i havent switched over yet
<slangasek> GrueMaster: you're welcome to test it, however: u-boot-linaro-omap3-beagle
<ogra_ac> will do so next time i touch debian-cd
<devilhorns> ogra_ac, real quick ... any hardware news for me ?
<ogra_ac> devilhorns, ask davidm ?
<ogra_ac> he has it
<GrueMaster> slangasek: Ok, now I know why XM was reporting a different version.  Thanks.
<devilhorns> ogra_ac, haven't seen him on yet today, but I'll ask when I see him, thanks :)
<ogra_ac> Gruemaster; which Xm version did you have ?
<GrueMaster> P8
<ogra_ac> you might need to boot with mem="%&M
<ogra_ac> grr
<ogra_ac> 256M
<GrueMaster> Extra flaky goodness.
<ogra_ac> i'd love to know why the kbd always does that
<GrueMaster> Actually, it was running fine before Friday's power glitch.
<ogra_ac> ouch
<GrueMaster> Oddly enough, it is behind two surge protected power strips.
<ogra_ac> well
<ogra_ac> wait for the a2
<GrueMaster> I spent all day Friday trying to get Beta to reinstall.
<ogra_ac> p8 is really not worth to invest much time into it
<GrueMaster> I may have hosed my microSD cards or something.
<ogra_ac> i know david is on it
<GrueMaster> I do what I can with what I have.
<GrueMaster> Yea, he mentioned it this morning.
<ogra_ac> sure but the hw is known to be flaky
<rsalveti> yep, you shouldn't waste too much time on your xM
<rsalveti> I always get some weird results with mine
<rsalveti> even with mem=265M
<rsalveti> 256
<GrueMaster> As I said, I haven't had issues until Friday.
<ogra_> grmpf
<GrueMaster> Well, it is now official.  I can not get audio out of the default apps on any of our armel platforms in Maverick.
<GrueMaster> I can at least get speaker-test to work on beagle with some massaging in alsamixer, but no gui apps.
<GrueMaster> And now dove is down.
<GrueMaster> And not a peep from my panda ES2 8L.
<dcordes> GrueMaster: No good :( Unfortunately I don't have the working alsa yet else I could test
<dcordes> I'm running 19th preinstalled
<GrueMaster> I'm running today's (20100920).  Devices are visible, but nothing works.
<dcordes> Maybe some pulseaudio thing ?
<GrueMaster> No.  speaker-test can bypass it and go directly to hw.
<dcordes> Well if that is the only thing that works ...
 * dcordes shrugs
<dcordes> How come all the gnome-panel applets are fixed now and what is the correct way to change this ?
<dcordes> Couldn't find settings in  ~
<persia> Could you give more context?
<persia> GrueMaster, What did you need to do in alsamixer to get the beagle to work?  Is this different from what you had to do before?
<GrueMaster> On beagle, in alsamixer, I had to unmute DAC2 Analog and crank it to 100, Crank Headset to 100, and unmute HeadsetL Mixer Audio L2 & HeadsetR Mixer Audio R2.
<GrueMaster> That will at least get speaker-test to work (that's the cli speaker-test with -c 2 -t wav options).
<persia> That's enough :)
<persia> mpoirier, Did you have a chance to look at the beagleboard kernel-side config?  Which amps are turned on there?  Which have sensible volumes?
<mpoirier> persia: not haven't yet - I'm currently setting up my board.
<mpoirier> persia: I got sound going though using the scripts.
<persia> Oh.  My apologies.  I thought you'd had a working beagle for some time.
<mpoirier> persia: i have a working beagle indeed.  Just received my panda today.
<mpoirier> persia: I'm on panda now.
<persia> Ah, and you don't easily have both wired to audio.  I can understand that :)  Anyway, figured that with GrueMaster having just gotten audio to work post-fiddling would be a handy time to get it to work pre-fiddling kernel-side.
<persia> GrueMaster, Have you tried USB audio also?  Are you able to reproduce rlamiero's report?
<mpoirier> persia: I'll address panda first.
<GrueMaster> I don't have any usb-audio devices.
<persia> mpoirier, OK.
<persia> GrueMaster, Aha.  Then no, and because you can't.  Thanks for trying :)
<GrueMaster> Oh, wait.  I bought a converter several years ago for hooking up to a record player.  Let me find it.
<mpoirier> persia: where's the u-boot git tree we are using for the omap4 image ?
 * persia has no idea
<persia> I *think* we're using the linaro uboot package.
<GrueMaster> mpoirier: it is the linaro u-boot.  slangasek would know.
<persia> I don't know where the upstream git tree lives.  Note that there is at least one Ubuntu-specific patch against upstream applied, so you may want to examine the source package.
<jo-erlend> is there any difference between distros in hardware support for omap3 devices like IGEPv2?
<mpoirier> jo-erlend: we haven't had a chance to really fit ubuntu to the IGEPv2 board.
<jo-erlend> so I've been told.
<mpoirier> jo-erlend: there's always stuff in the board specific file that needs to be adjusted.
<jo-erlend> board spesific file?
<jo-erlend> I'm new to these ARM-stuff. :)
<mpoirier> jo-erlend: each board is different - same processor but different mapping of devices.
<persia> jo-erlend, the kernels differ between distributions, meaning that the specific handling of various devices tends to differ slightly.  Everyone tries to feed upstream, but it may take more or less time in some places or other.
<persia> Userspace should have nearly precisely the same level of hardware support everywhere.
<jo-erlend> ok, so I might be able to get it working by simply replacing the kernel with one from another distro?
<persia> If you're a kernel person, please use Ubuntu, hack the kernel to work for you, and report how the kernel needs changing.
<persia> Potentially, although we (obviously) can't support someone else's kernel.
<persia> Note that there are at least 2 omap kernels in Ubuntu, so you get to try both before you go somewhere else :)
<persia> If you aren't a kernel person, you ought be able to use Ubuntu userspace with some other kernels, but you do need to have some specific configuration options set: you may end up recompiling if the folks who produce your kernel don't set those.
 * ogra_ac would recommend trying the linaro kernel
<jo-erlend> Thanks. There is a wiki page about running ubuntu on the igep. This tells me that someone there must have been successful. That's encouraging, I think.
<persia> Why would you expect it to be better than the mainline kernel?
<slangasek> mpoirier, GrueMaster: git://git.linaro.org/boot/u-boot-linaro-stable.git
<ogra_ac> because linaro uses iegp2 for development
<mpoirier> fantastic slangasek - thanks.
<ogra_ac> while we dont have a single of these boards
<dcordes> is ac nvidia smartbook ?
#ubuntu-arm 2010-09-21
<jo-erlend> dcordes, I think I would have rephrased that question if I were you.
<dcordes> jo-erlend: Sorry ?
<GrueMaster> jo-erlend: I think he is referring to the Toshiba AC100 that ogra_ac is on.  And yes, it is a Tegra 2 system.
<jo-erlend> ah. :)
 * dcordes is waiting for decent qualcomm smartbook
<dcordes> Keeping track of one SoC is enough
<dcordes> Only need to convince somebody I can't make it through the winter term alive without one :D
<GrueMaster> ha!
<dcordes> Doubt it will work but I need to find a job anyway
<jo-erlend> Is it possible that it is my monitor that causes this? http://pastebin.com/6hAjUwCW
<persia> I think it's unlikely.  I think you have to pass a framebuffer mode argument.  Are you booting from recent dailies, or something else?
<jo-erlend> beta. It seems to be the only readily available image?
<persia> Oh, if you're using raw beta, that ought be passing a parameter
<persia> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ has some more recent images.  Mind you, those are entirely unvalidated, so might not work, or not exist, etc. on any given day.
<jo-erlend> grand! Thank you. I'll give that a go immediately. I couldn't find that earier today. Perhaps I gave up too quickly. :)
<rsalveti> hm, ureadahead is now using a 8mb buffer, instead of 128mb
<rlameiro> persia: did come out some upgrades to maverick today?
<rsalveti> interesting
<GrueMaster> persia: I found my usb-audio device.  RCA & SPDIF in/out.  Tested ok on my laptop.  What were you suggesting I test it on?
<rsalveti> and should fix the oom killer messages at beagleboard
<persia> GrueMaster, Anywhere you can, once per kernel flavour.  No point on two devices with the same kernel, but otherwise.
<GrueMaster> I'll add it to the to-do list.
<persia> GrueMaster, rlamiero was reporting that on IGEPv2 (omap3) with the kernel from "linux", usb audio didn't work.  I wouldn't be surprised to see other kernel flavours affected.
<GrueMaster> As it stands, my XM is the only one with spare USB ports, and it is borked.
<rlameiro> well it work on i686
<persia> No rush, but it would be nice to be able to tell folks they can use usb-audio in the event that we don't have working wiremaps for various boards.
<persia> rlameiro, Sure, but that's a different kernel flavour: linux-generic vs. linux-omap (although it comes from the same source package, which means we're more likely to have it just work)
<rlameiro> yeap
<rsalveti> GrueMaster: so, did you test the audio at the c4?
<rlameiro> it is weird because the problem aplay output was about the bit rate or something like that
<rsalveti> if it's not working this could explain why the same behavior at the xM
<rsalveti> and a regression, as it worked fine for lucid
<rsalveti> different kernel tree though
<GrueMaster> rsalveti: On my beagle, I had to tweak alsamixer settings to get the alsa speaker-test to work.
<rsalveti> GrueMaster: same for xM, am I right?
<GrueMaster> My xm has other issues.
<GrueMaster> (like getting through a boot process).
<rsalveti> but last time you tested audio you said it worked after setting up alsa-mixer correctly, IIRC
<GrueMaster> I thought I had.  With as much testing as I do, unless I find a bug, I tend to forget what I tested where.
<GrueMaster> And it is very hard to test everything on everything.
<rsalveti> haha, np
<GrueMaster> Especially with special requests coming in fast & furious.
<rsalveti> but yeah, I remember you tested at the xM and you got it working after setting up alsa-mixer
<rsalveti> that's why we discussed it at our call
<rsalveti> and where we got the idea to test it on a normal beagle
<rsalveti> because with lucid it just works
<GrueMaster> Right.
<GrueMaster> But now I can't get my XM to boot through a known good image.
<GrueMaster> These sudden audio issues eat at my soul.
<rsalveti> this is something weird, let me try to boot mine
<rsalveti> GrueMaster: what errors are you getting?
<GrueMaster> On which?  Audio or XM in general?
<jo-erlend> can someone translate this for me? "omapfb.mode=dvi:1024x768MR-16@60". It's the bootargs I've been told to use. :)
<rsalveti> xM in general
<GrueMaster> persia: usb-audio device shows up and is configurable on dove.  Still no audio output from rythmbox.
<rsalveti> jo-erlend: while setting up omapfb with dvi, this should be your default resolution
<rsalveti> otherwise you'll get 640x480
<persia> rlameiro, Does GrueMaster's report on dove match your experience on the IGEPv2?
<rsalveti> that's the default one
<jo-erlend> rsalveti, what would happen if my monitor didn't support that resolution?
<GrueMaster> rsalveti: On my XM, it fails randomly.  Sometimes it is a corrupted filesystem on second boot, sometimes it gets most of the way through oem-config before it crashes.
<rsalveti> jo-erlend: will probably give out of sync or something like that
<rlameiro> jo-erlend: use the Digital output of omap framebuffer driver with a res of 1024x768 with a bit depth of 16 bits at 60 hz refresh rate
<GrueMaster> I have not seen any errors that could be traceable.
<rsalveti> GrueMaster: sounds like the random mem issues I'm facing with 512
<GrueMaster> Possibly.
<rsalveti> mine just works when I add mem=256M
<rlameiro> persia: i didnt used rythmbox, but yea, it is configured but no sound output
<GrueMaster> I'll give it a try.
<GrueMaster> Hate hacking the boot.scr
<rsalveti> the interesting thing is that some times it just works fine, but most of the time I try to boot with 512mb it'll give me random segfaults
<jo-erlend> I thought that since it fails to load the omapfb module, it might be because the modes were incorrect?
<rsalveti> welcome to the club
<persia> How about lower level sound tests?  Let's find the point at which it breaks.
<rsalveti> jo-erlend: default should be safe, then you can try different resolutions
<rlameiro> aplay should be a good ground level
<rlameiro> persia:
<lag> Morning all
<rsalveti> jo-erlend: what's you problem regarding omapfb?
<rsalveti> lag: haha, morning
<rsalveti> crazy timezone
<persia> rlameiro, I don't have an environment to help: tell GrueMaster :p
<rlameiro> australia?
<jo-erlend> rsalveti, http://pastebin.com/6hAjUwCW
<rsalveti> taiway
<GrueMaster> persia: speaker-test works with usb-audio on dove.
<rsalveti> *taiwan
<rsalveti> jo-erlend: oh, ok, the missing fb0
<rsalveti> jo-erlend: can you grab your dmesg?
<lag> haha?
<lag> Oh, I see
<lag> :)
<jo-erlend> rsalveti, I'm currently overwriting the memorycard with todays daily to see if that works.
<persia> rlameiro: Weren't you having issue with *any* audio?  I don't think you were using pulse.
<rlameiro> i dont use pulse
<rlameiro> just lasa
<rlameiro> alsa
<rlameiro> if alsa is broken, pulse will be also
<rsalveti> jo-erlend: could be better, but it's probably not going to fix this weird missing fb0 error
<rsalveti> because we didn't change our kernel much regarding this driver
<GrueMaster> rlameiro: too true.
<rsalveti> but please try, let's see what happens
<rsalveti> if still doesn't work, you can try linaro's kernel
<rlameiro> persia: GrueMaster http://pastebin.ubuntu.com/497342/
<GrueMaster> rlameiro: Try "speaker-test -c 2 -t wav -Dhw:1"
<rlameiro> GrueMaster: persia http://pastebin.ubuntu.com/497343/
<ogra_ac> hmm
<ogra_ac> seems not using andchat gets me a far more stable network
<rlameiro> i should remind that this usb interface doesnt have software mixer
<GrueMaster> rlameiro: try without the -D parameter.
<rlameiro> that will play on the board.
<GrueMaster> Worked on usb-audio here.
<jo-erlend> the daily image doesn't seem to have anything except the boot partition. Well there is another partition too, but it only contains lost+found.
<rsalveti> the daily should have 2 partitions
<rsalveti> boot and rootfs, that will get resized at the first boot
<rlameiro> GrueMaster:  its working on the board output
<jo-erlend> yes, it does, but the rootfs is empty.
<rsalveti> jo-erlend: after or before the first boot?
<jo-erlend> sorry.... Nautilus fooled me. :)
<jo-erlend> uh. I get lots of io errors now.
<jo-erlend> rsalveti, what do you mean? Everything should be on the board before the first run?
<rlameiro> GrueMaster: speaker-test says this at the help file --- Recognized sample formats are: S8 S16_LE S16_BE FLOAT_LE S32_LE S32_BE
<rsalveti> jo-erlend: sorry, after you putting the card and giving the first boot or before
<rlameiro> but i am prety sure my board only send 24bit streams
<rlameiro> any way it should work
 * rsalveti brb
<rlameiro> i will try the interface with the advanced mode off
<rlameiro> lol another problem, each time I unplug a usb device, when i plug it back it cant be enumerated
<rlameiro> i need to restart the board
<rlameiro> GrueMaster, persia http://pastebin.ubuntu.com/497351/
<rlameiro> strange is that the stream of the driver is defined to 44100hz when the board is capable and hardware selected to 48000
<rlameiro> I forced speaker-test to the driver parameter and it worked, just the problem was that the audio file was at 48khz, so nothing happened
<persia> rlameiro, That looks like a deep bug, and ALSA is probably doing some internal resampling.  Probably worth running the testing shell script and sending it upstream.
<rlameiro> humm
<rlameiro> persia: is that test on the repos?
 * persia isn't sure
<rlameiro> found this
<rlameiro> it says nothing special
<rlameiro> persia: unless this  ----EDIROL UA-4FX at usb-ehci-omap.0-1.2, full speed
<persia> Hrm.
<rlameiro> this means that the driver is on the specific module usb-ehci-omap.0-1.2 ?
<rlameiro> i dont have the sources of the kernel from rcn-ee so i cant check it out
<GrueMaster> rlameiro: Unfortunately, I have a completely different usb-audio device.  http://paste.ubuntu.com/497363/
<GrueMaster> And it supports 48000
<rlameiro> well, then yeah, this driver is completely   broken
<rlameiro> I just wanted to know where do i find the sources for it
<GrueMaster> Either in the kernel or from http://alsa-project.org.
<GrueMaster> What is loaded by Ubuntu is in the kernel.
<GrueMaster> alsa-project.org may have newer updates that will be in the next kernel.
<rlameiro> well, but it works on my laptop, i even helped testing the patch made for this device some years ago
<rlameiro> and it went already to alsa release
<rlameiro> and it is fully supported on ubuntu, so i dont get it, it shouldnt be platform dependent should it?
<GrueMaster> No, it shouldn't.
<rlameiro> well i gues i will digg into it tomorrow
<GrueMaster> /proc/asound/card1/stream0 should be identical across platforms.
<rlameiro> well i will compare it with the one on my laptop
<rlameiro> 1 sec
<rlameiro> GrueMaster: well its definetly an ARM/Board/ubuntu kernel issue or ubuntu driver
<rlameiro> http://pastebin.ubuntu.com/497368/
<GrueMaster> interesting.
<GrueMaster> Same kernel on both?
<rlameiro> it seems something is wrong with the driver that doesnt detect the card correctly
<rlameiro> nope
<GrueMaster> The omap driver is part of the main stream kernel.
<rlameiro> Linux studiobeta 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:24:04 UTC 2010 i686 GNU/Linux
<rlameiro> Linux beagleboard 2.6.35.4-l1 #1 PREEMPT Fri Aug 27 22:09:57 UTC 2010 armv7l GNU/Linux
<GrueMaster> apples<>oranges.
<GrueMaster> Unfortunately.
<rlameiro> ??
<GrueMaster> Completely different alsa versions.
<GrueMaster> cat /proc/asound/version
<DanaG> Say, is Tegra2 going to be an officially supported architecture?
<rlameiro> my is 1.0.23
<GrueMaster> rlameiro: on both?
<DanaG> Supported as in, has kernels built and won't get illegal-instruction errors?
<rlameiro> this is on arm, let me check the board
<GrueMaster> DanaG: If someone pushes a kernel into the pool, sure.
<rlameiro> 1.0.21
<rlameiro> regression?
<GrueMaster> rlameiro: very possibly.
<DanaG> "has kernels built" could even be unofficial, as rcn-ee's OMAPs are/were/are.
<rlameiro> well, then i have to download the ubuntu beta to test it...
<GrueMaster> rlameiro: Try downloading one of the ubuntu i386.iso files and run it live.  Compare results.
<DanaG> A bigger concern is the CPU instruction-set support -- can't use NEON on it.
<GrueMaster> rlameiro: I would try a daily.
<GrueMaster> http://cdimage.ubuntu.com
<GrueMaster> DanaG: Shouldn't be an issue.  Marvell doesn't either.
<GrueMaster> Most apps don't care.
<DanaG> Marvell doesn't even do armv7l, at least in any currently available products. =/
<rlameiro> oversized images...
<GrueMaster> rlameiro: Write one to USB.  faster and doesn't waste a CD.
<GrueMaster> Use usb-creator to make a bootable usb stick.
<rlameiro> well downloading
<rlameiro> i need to buy a usb stick for this stuff :D
<rlameiro> 1438 KB/s not bad...
<GrueMaster> rlameiro: WIll your laptop boot from SD?
<rlameiro> dont think so
<GrueMaster> I'm jealous btw.  My max speed is 468KB/s  :P
<rlameiro> GrueMaster: never tried it, it does have an removable disk options
<rlameiro> axel rocks :D
<rlameiro> great downloader for the cli
<GrueMaster> Where are you on this great rock in space?
<rlameiro> Portugal
<GrueMaster> Ah.  Closer to our servers.
<rlameiro> UK?
<GrueMaster> I'm in Oregon, USA.  Much farther for bits to travel.
<GrueMaster> Yes.  Millbank, I believe.
<jo-erlend> rsalveti, you're right. It didn't change anything. Which files do you want?
<rlameiro> i will test some download from Oregon after the download finish
<rlameiro> do you have some link to a mirror from a uni there or something?
<GrueMaster> You can try http://members.dsl-only.net/~tdavis/beagleboard-bug.jpg
<rlameiro> lol
<GrueMaster> Not very big, but it is my ISP.
<rlameiro> too small to test
<GrueMaster> There is a mirror server at http://ubuntu.osuosl.org/ubuntu/
<rlameiro> but i will try anyway
<rlameiro> GrueMaster: Downloaded 694,7 megabytes in 8:14 seconds. (1437,95 KB/s)
<GrueMaster> I hate you.  :P
<GrueMaster> I have DSL here.  And I am paying premium for the fastest speed available.
<rsalveti> jo-erlend: dmesg would help, for sure
<GrueMaster> And I still get pidgeon-net speeds.
<rlameiro> yeap, the connection to there is way worse than to the ubuntu server
<rlameiro> GrueMaster: i have DSL to, my sync is about 17 MB/s
<jo-erlend> rsalveti, rbelem has quit (Quit: Leaving)
<jo-erlend> * o
<jo-erlend> bah. :)
<jo-erlend> rsalveti,  http://pastebin.ubuntu.com/497379/
<rsalveti> [    1.497497] omapfb omapfb: no displays
<rsalveti> [    1.501312] omapfb omapfb: failed to setup omapfb
<rsalveti> probably because of:
<rsalveti> [    0.269592] omapdss VENC error: can't get VDDA_DAC regulator
<rsalveti> [    0.269622] omapdss CORE error: Failed to initialize venc
<rsalveti> which points to bug 607250
<ubot2> Launchpad bug 607250 in linux (Ubuntu) "omapdss: VDDA_DAC regulator on IGEPv2 (affects: 1) (heat: 65)" [Undecided,Incomplete] https://launchpad.net/bugs/607250
<jo-erlend> rsalveti, do you think changing the kernel would fix this?
<rsalveti> probably not, as this was reported to linux-linaro
<jo-erlend> any ideas at all?
<rlameiro> GrueMaster: rebooting, going to test it now
<GrueMaster> ok
<rsalveti> jo-erlend: needs to find the missing patch for it
<DanaG> Is there a page that that pic goes with?
<rsalveti> jo-erlend: could be this one: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head:/patches/igepv2/0001-ARM-OMAP3-Add-S-Video-output-to-IGEPv2-board.patch
<rsalveti> will build a new kernel for you to test, give me 10 min
<jo-erlend> thanks :)
<rlameiro> GrueMaster: well, back
<rlameiro> the card was detected correctly, speaker test gave the same error but i think it has to do with the format of the streaming "SE24_LE"
<GrueMaster> Hmmm.
<rlameiro> the iso is not woking ok, it didnt booted completely after selecting try it.. lol i had to use ctrl+alt+F1 :D
<rsalveti> jo-erlend: please test http://people.canonical.com/~rsalveti/kernel/uImage.igep2
<rsalveti> jo-erlend: just copy it over your uImage from the first partition
<jo-erlend> rsalveti, then I simply replace the uImage with that one?
<jo-erlend> right.
<rsalveti> then please get your dmesg for me again
<rlameiro> rsalveti: brasileir?
<rlameiro> brasileiro?
<rsalveti> rlameiro: sim, portugues?
<rlameiro> BOA !
<rsalveti> :-)
<persia> !pt :p
<ubot2> Factoid 'pt :p' not found
<persia> !pt
<ubot2> Por favor, use #ubuntu-br para ajuda em brasileiro. Para entrar no canal por favor faÃ§a "/join #ubuntu-br" sem as aspas. Para a comunidade local portuguÃªsa, use #ubuntu-pt. Obrigado.
<rsalveti> persia: :P
<rlameiro> persia: lol, we got it, it was just that moment of hapiness finding a language brother :D
<persia> I know :)
<persia> And since the two of you have such similar interests, I suspect there's going to be a lot of value to portuguese coordination for ARM audio :)
<rlameiro> rsalveti: also into audio?
<rsalveti> haha, not yet, still fighting with display issues :-)
<rlameiro> lol
<rlameiro> i took that out of the picture,
<GrueMaster> Hey, alsa on armel sounds the same, regardless of language.  :P
 * rlameiro runs is board headless :D ssh rulezzz
<rsalveti> haha, for sure, but we need to get it working for our users haha
 * rlameiro ssh -X even better :D
<rsalveti> haha :-)
<persia> Not when your armel laptop is closer than your desktop :p
<jo-erlend> rsalveti, http://pastebin.ubuntu.com/497388
<rsalveti> jo-erlend: [    0.000000] Linux version 2.6.35-22-omap (buildd@satinash) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #32-Ubuntu Fri Sep 17 09:09:03 UTC 2010 (Ubuntu 2.6.35-22.32-omap 2.6.35.4)
<rsalveti> jo-erlend: still not my kernel
<jo-erlend> rsalveti, what I did, was to rename uImage to uImage.old and then rename uImage.igep2 to uImage.
<rsalveti> same one as before
<rsalveti> jo-erlend: hm, weird, could be a bug at u-boot
<rsalveti> we got a similar bug with the older u-boot we used for panda
<jo-erlend> I should delete uImage.old as well?
<rsalveti> to make sure, copy your files to your pc, give mkfs.vfat -F 32 /dev/sd<X> and then copy them again
<rsalveti> if you're facing the same bug, then it's not going to work even if you remove the older uImage
<jo-erlend> rsalveti, I read somewhere that using -F 32 wouldn't work though. It was old, but still.
<rsalveti> well, don't know much of igep2
<rsalveti> do it as you can find at your igep2 tutorial :-)
<rsalveti> but recreate it and then copy the new files
<rlameiro> what is the problem with it?
<rsalveti> in this case, just copy the new uImage
<rsalveti> rlameiro: display not working for igep2 using default kernel for omap3
<rlameiro> omapfb?
<rsalveti> yup
<rsalveti> I found a patch but waiting jo-erlend to test it
<rlameiro> this is mine dmesg
<rlameiro> http://pastebin.ubuntu.com/497390/
<rlameiro> and boot args, sorry for the flood
<rlameiro> fatload mmc 0:1 0x80000000 uImage
<rlameiro> fatload mmc 0:1 0x82000000 uInitrd
<rlameiro> setenv bootargs-base vram=12M omapfb.mode=dvi:hd720-16@50
<rlameiro> bootm 0x80000000 0x82000000
<rsalveti> rlameiro: which kernel?
<rlameiro> rsalveti: Linux beagleboard 2.6.35.4-l1 #1 PREEMPT Fri Aug 27 22:09:57 UTC 2010 armv7l GNU/Linux
<rlameiro> rcn-ee one
<rsalveti> rlameiro: cool, the patch I found was applied at his kernel
<rsalveti> and it's not giving you errors
<rsalveti> so it seems to fix it
<rsalveti> once confirmed will send to the kernel team
<rlameiro> i can try to test it tomorrow on my hdmi tv, my girl is sleeping there now..... she will kill me if I wake her up :D
<rsalveti> rlameiro: haha, don't need to worry, I completely understand you :-)
<rlameiro> rsalveti: lol, and I am Ricardo too
<rlameiro> w00t
<rsalveti> #win
<rsalveti> :-)
<jo-erlend> rsalveti, http://paste.ubuntu.com/497395
<rsalveti> hm, weird, same error
<rsalveti> jo-erlend: could you try rlameiro's boot args?
<rsalveti> vram=12M omapfb.mode=dvi:hd720-16@50
<rlameiro> well it is for a tv, but should be ok
<rsalveti> but now a different error
<jo-erlend> rsalveti, I keep the others, I just add those arguments?
<rsalveti> [    0.269592] omapdss VENC error: can't get VDDA_DAC regulator
<rsalveti> [    0.269622] omapdss CORE error: Failed to initialize venc
<rsalveti> and now
<rsalveti> [    0.255493] omapdss SDI error: can't get VDDS_SDI regulator
<rsalveti> [    0.255493] omapdss CORE error: Failed to initialize SDI
<rsalveti> jo-erlend: change omapfb.mode=dvi:1024x768MR-16@60 to vram=12M omapfb.mode=dvi:hd720-16@50
<rsalveti> hm, currently you don't have vram
<rsalveti> mem=512M console=ttyS2,115200n8 console=tty0 omapfb.mode=dvi:1024x768MR-16@60 root=/dev/mmcblk0p2 rw rootwait text
<rsalveti> this is your current boot line
<rsalveti> try just adding vram=12M first
 * GrueMaster is calling it a day.
<rsalveti> while a look for an additional patch
<rsalveti> *I
<jo-erlend> rsalveti, no change.
<jo-erlend> rsalveti, http://paste.ubuntu.com/497402
<rsalveti> could be another bug =\, just a moment, looking for other patches
<jo-erlend> thank you. I appreciate it.
<jo-erlend> well. I did change the omapfb.mode setting. I had already done that when you told me to only add the vram setting. Does that matter?
<rsalveti> nops, seems a different bug
<rsalveti> but wanted to check just to be sure
<rlameiro> rsalveti: do you want my uImage?
<rsalveti> rlameiro: no thanks, I got the sources of it already, trying now to understand what's missing
<rsalveti> seems that it's just missing a regulator definition
<jo-erlend> is that something you can fix? :)
<rsalveti> jo-erlend: it seems I found the problem, working for a fix
<rsalveti> seems that the cause is another dss2 patch that we got at our tree
<rsalveti> jo-erlend: give me some minutes and I'll send another uImage to test
<jo-erlend> great! :)
<rsalveti> building a new kernel
<jo-erlend> :)
<jo-erlend> it would be really cool if that worked. I think the board is very cute, but it would be nice to be able to use it for something too :)
<rsalveti> sure :-)
<rsalveti> jo-erlend: http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v2
<rsalveti> same procedure, please :-)
<rsalveti> hopefully at least a different error message
<rsalveti> :-)
<jo-erlend> rsalveti, hey, I have something!
<jo-erlend> I have text! It's kinda blue!
<devilhorns> quick Q for those "in the know" ... the default netbook launcher (clutter one) ... what ships there for sound ? that depend on pulse ? or is it also using canberra ?
<rsalveti> jo-erlend: awesome
<devilhorns> oh nvm, I can find out via synaptic
<rsalveti> blue should be fine
<rsalveti> at least I get blue text at my panda
<rsalveti> but it works fine on X
 * rsalveti never tested the clutter based netbook launcher
<rsalveti> jo-erlend: can you send me your dmesg
<rsalveti> jo-erlend: even if you get something, to be able to login at your serial you probably need to create a ttyS2.conf file for your upstart
<rsalveti> with correct parameters
<persia> devilhorns, I believe the default stack should be canberra-on-pulse: which layer a given app hits depends on the app.  More use of canberra for simple alerts would be appreciated.
<jo-erlend> rsalveti, I have no serial :/
<rsalveti> oh, that's fine
<rsalveti> jo-erlend: so you should be able to see something at your monitor
<devilhorns> persia, ok, just wanted to check if canberra was the way we want to go wrt the efl one
<jo-erlend> I get a fatal error, missing files in /lob/modules/blabla. I noticed that before, I have no /lib/modules directory. Am I supposed to?
<rsalveti> jo-erlend: that's ok for now, that's just because I got you just the uImage
<persia> devilhorns, I think we should go that way, as it makes it easier long-term to have global alert management.
<rsalveti> still missing the modules
<rsalveti> jo-erlend: but does it stops at this fatal errors?
<devilhorns> persia, fair enough :)
<jo-erlend> rsalveti, it does.
<rsalveti> jo-erlend: ok, let me get you the kernel modules
<jo-erlend> rsalveti, and I get lots of "modules does not exist" in my xorg.log.
<rsalveti> hm, could be another issue
<persia> devilhorns, That said, if you know of some reason why it's better not to use libcanberra, I'd be happy to hear arguments, but based on everything I've heard, it's a sensible direction.
<rsalveti> but can you see something from your X11 session?
<rsalveti> I mean, does it show something at your monitor?
<jo-erlend> rsalveti, no.
<rsalveti> one step at a time :-)
<rsalveti> jo-erlend: can you paste me your dmesg?
<jo-erlend> yes! I have characters on my screen. That's awesome :)
<jo-erlend> rsalveti, http://paste.ubuntu.com/497419
<jo-erlend> hmm... [    0.000000] Linux version 2.6.35.4+ (rsalveti@evatp) (gcc version 4.4.5 20100824 (prerelease) (Ubuntu/Linaro 4.4.4-9ubuntu2) ) #42 Mon Sep 20 22:15:20 BRT 2010 (Ubuntu 2.6.35-21.31-omap 2.6.35.4) <-- Didn't it say that before too?
<rsalveti> yup, but check the timestamp
<rsalveti> it's now different
<devilhorns> persia, no particular reason comes to mind ... I was just curious if canberra was the "preferred" way to go wrt sounds, or if it was just something the netbook-efl devs dropped in
<jo-erlend> actually it isn't. It sais 1/1 2000.
<rsalveti> jo-erlend: hm, with error and etc
<jo-erlend> hmm?
<rsalveti> so same dmesg as before
<rsalveti> were you able to login and get the dmesg?
<persia> devilhorns, it's currently used in many flavours (Ubuntu Desktop, Ubuntu UEC live, Edubuntu Desktop, Edubuntu Desktop KDE, Xubuntu Desktop, Mythbuntu Desktop, Ubuntu Netbook), so I think it's safe to say it's well-supported in Ubuntu.
<rsalveti> if not you're probably pasting the older one
<jo-erlend> no. I had to eject the card and mount it in my laptop.
<persia> Doesn't seem to be in Kubuntu Desktop or Netbook, but since it's in Edubuntu Destktop KDE, I suspect there's some integration bits in place.
<rsalveti> well, it's the same dmesg
<rsalveti> same kernel
<jo-erlend> rsalveti, perhaps I can just remove the logs?
<rsalveti> same timestamp and same errors
<rsalveti> sure
<rsalveti> try generating a new one
<devilhorns> persia, well, support wasn't my concern :) just didn't know if the netbook-efl devs picked it out of the blue or something :)
<jo-erlend> right. Is it ok to simply delete them, or must I create a new empty one?
<rsalveti> just delete them
<rsalveti> it should create a new one when booting
<persia> devilhorns, At least everyone else uses it.  I can't say much more :)
<devilhorns> persia, ok :)
<devilhorns> persia, was wondering cause gonna be adding sounds back into the new one soon
<persia> Cool!
<jo-erlend> rsalveti, http://paste.ubuntu.com/497424
<rsalveti> jo-erlend: still the old one
<rsalveti> weird
<jo-erlend> heh, I deleted all the logs! :)
<jo-erlend> but you spoke of a bug earlier.. Perhaps I should try to create a new fat32 partition again?
<rsalveti> haha, not possible, at least the timestamp should be different
<rsalveti> jo-erlend: please
<rsalveti> and remove all your logs again
<devilhorns> persia, btw, new one supports changing icon sizes too :)
<jo-erlend> rsalveti, I think I know the problem... :)
<jo-erlend> gedit was smart enough to know that it already had the file open, but not smart enough to understand that the file had changed.
<rsalveti> :-)
<jo-erlend> rsalveti, http://paste.ubuntu.com/497433
<rsalveti> OK, now it's different
<jo-erlend> yes. What are all those filesystem errors?
<rsalveti> jo-erlend: probably because you're still using the pre-installed image without resizing the disk
<rsalveti> you're only able to do that when using the uInitrd and giving at least one boot
<jo-erlend> oh, ok. Does it have any consequences?
<rsalveti> yep, you're going to be able to do much work on it
<jo-erlend> :)
<rsalveti> the good thing is that we now have the display fixes
<rsalveti> so I'll submit them and when we get them applied you'll need to change just the x-loader and u-boot, if needed
<jo-erlend> yes. It looks to me that the missing /lib/modules is what's causing it to halt.
<rsalveti> probably
<rsalveti> I'm uploading the modules for you
<rsalveti> but for the moment you could try to mount your sd card at your host and get inside with qemu
<persia> devilhorns, careful now, you might make something so nice nobody wants the clutter version :)
<rsalveti> and try to run depmod
<rsalveti> this will create the modules.xxx files that the boot is complaining
<jo-erlend> rsalveti, can you be a little more spesific? :)
<rsalveti> or wait until I get my package uploaded, so you can install it by using qemu
<rsalveti> jo-erlend: which ubuntu release are you using at your host?
<rsalveti> if you're using ubuntu :-)
<jo-erlend> maverick.
<rsalveti> cool
<rsalveti> so you could get inside your partition with chroot and qemu, to install the needed packages
<rsalveti> like running it at your arm machine
<rsalveti> mount your sd card at your host computer
<rsalveti> then get inside the rootfs partition
<rsalveti> cp /usr/bin/qemu-arm-static usr/bin/
<rsalveti> mount --bind /dev dev
<rsalveti> mount -t proc proc proc/
<rsalveti> and then you can just give chroot /media/<rootfs>
<devilhorns> persia, that's the idea :)
<rsalveti> now you're running an arm environment, and able to give apt-get normally
<rsalveti> then all you need to do is to get my kernel package and give dpkg -i on it
<rsalveti> umount everything, boot your arm board and be happy with it
<persia> One may well have to install qemu-kvm-extras-static to make that procedure work...
<rsalveti> yup, was too lazy to find the package for it :-)
<jo-erlend> rsalveti, I'm in an arm chroot with the rootfs from my memorycard.
<jo-erlend> ... now what? :)
<rsalveti> jo-erlend: create the correct kernel directory for the kernel I sent you
<rsalveti> mkdir /lib/modules/2.6.35.4+
<rsalveti> I guess
<rsalveti> then run depmod with correct parameter, one sec
<rsalveti> depmod -a 2.6.35.4+
<rsalveti> please try it
<jo-erlend> uh, how? :)
<rsalveti> at your chroot
<rsalveti> mkdir /lib/modules/2.6.35.4+
<rsalveti> depmod -a 2.6.35.4+
<jo-erlend> I did that. No response
<rsalveti> that's fine
<rsalveti> ls -l /lib/modules/2.6.35.4+ should show you some files
<rsalveti> now exit your chroot
<rsalveti> umount dev
<rsalveti> umount proc
<rsalveti> and umount the rootfs
<rsalveti> put your card at your board and boot it
<jo-erlend> it does.
<jo-erlend> you mean I exit my chroot by issuing those commands?
<rsalveti> no, after you get out your chroot
<jo-erlend> how do I do that? "exit"?
<rsalveti> yep
<rsalveti> or control + d
<jo-erlend> rsalveti, well. Some of the errors have gone, but I'm stuck with one: "mount: unknown filesystem type 'binfmt_misc'
<jo-erlend> and that's where it stops.
<rsalveti> hm, ok, so it's really missing some modules
<rsalveti> jo-erlend: http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-43_armel.deb
<rsalveti> you can find all kernel modules you need on it
<jo-erlend> then I enter a chroot again, download that package and install it?
<rsalveti> jo-erlend: yup
<rsalveti> jo-erlend: but I'm afraid you'll get fs errors
<rsalveti> let's see
<rsalveti> just dpkg -i <deb>
<jo-erlend> hmm. it seems I don't have networking in the chroot?
<jo-erlend> oh. nvm
<rsalveti> you have it, could be a problem with your resolv.conf file
<persia> jo-erlend, You have qemu-kvm-extras-static installed?
<jo-erlend> possibly. Why?
<rsalveti> persia: he was able to get inside the chroot before
<rsalveti> so it should be able to get inside it again
<jo-erlend> rsalveti, when installing the package inside the chroot, I got _lots_ of "Unsupported ioctl: cmd=0xc020660b"
<rsalveti> jo-erlend: that's normal
<persia> Well, rather, it's a bug, but it doesn't break installing a kernel
<jo-erlend> rsalveti: dpkg: error prosessing linux-image-blabla: failed in write on buffer copy for backend dpkg-deb during /lib/modues/2.6.35.4+/kernel/drivers/media/common/tuners/tda18271.ko": no space left on device
<rsalveti> jo-erlend: :-(
<rsalveti> that's the fs error I was afraid of
<rsalveti> this is because your kernel never got the resize
<rsalveti> jo-erlend: so you need to start from beginning
<jo-erlend> how much from the beginning?
<rsalveti> dd the daily build
<rsalveti> hm
<jo-erlend> oh..
<rsalveti> probably by copying the uInitrd from the daily image
<rsalveti> and uImage
<rsalveti> here's the problem, you need to at least boot the image using the original uImage and uInitrd once
<rsalveti> it'll just resize it (with some additional things)
<rsalveti> and reboot
<jo-erlend> oh. The guide from igeps wiki told me to delete those.
<rsalveti> jo-erlend: yep, the guide is wrong :-(
<jo-erlend> well, everything except uImage.
<rsalveti> after the first boot and reboot, you're able to do whatever you need/want with your image
<jo-erlend> ok. Is it sufficient to copy the uInitrd back into the boot partition and run it?
<rsalveti> without facing these weird fs errors
<rsalveti> probably
<jo-erlend> do I need MLO and u-boot.bin?
<rsalveti> nops
<rsalveti> yours should be fine
<rsalveti> jo-erlend: just make sure you have the right commands to load uInitrd and uImage at your boot.scr or boot.ini
<rsalveti> depends on what you have
<rsalveti> http://paste.ubuntu.com/497451/
<rsalveti> example from beagle
<rsalveti>         fatload mmc 0:1 0x80000000 uImage
<rsalveti>         fatload mmc 0:1 0x81600000 uInitrd
<rsalveti> than your boot cmd line
<rsalveti> and:
<rsalveti>         bootm 0x80000000 0x81600000
<rsalveti> with that you should be able to load uImage and uInitrd
<rsalveti> the uInitrd is the responsible for calling jasper, the one responsible for resizing it
<jo-erlend> oh, ok.
<rsalveti> jo-erlend: well, need to go now, quite late already
<rsalveti> jo-erlend: please try using uInitrd and let me know what happens
<rsalveti> if not, the recommended step would be to start from the beginning, but without removing the uInitrd file
<jo-erlend> will do.
<rsalveti> jo-erlend: just don't give up :-)
<rsalveti> I'm able to help you again tomorrow
<jo-erlend> I've seen text! That gives me courage. :)
<rsalveti> jo-erlend: :-)
<jo-erlend> thank you very much :)
<rsalveti> jo-erlend: if you're able to test, please update bug 607250
<ubot2> Launchpad bug 607250 in linux (Ubuntu) "omapdss: VDDA_DAC regulator on IGEPv2 (affects: 2) (dups: 1) (heat: 24)" [Undecided,Confirmed] https://launchpad.net/bugs/607250
<rsalveti> once we have a successful test, I'll send to the kernel team
<jo-erlend> one more thing...
<rsalveti> the kernel patches, if you're interested: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/fix-igepv2-display
<rsalveti> sure
<jo-erlend> in that fatload directive, you use some numbers. Are they ok to use?
<rsalveti> yup, should be fine
<jo-erlend> what about those other lines?
<jo-erlend> "fixrtc" should I add that? Should I add the bootm directive?
<rsalveti> the third one should be your own cmd line
<rsalveti> that you were using before
<rsalveti> you could, should cause no harm
<rsalveti> bootm 0x80000000 0x8200000 is just to load from the memory location
<rsalveti> fatload mmc 0:1 0x80000000 uImage means to load uImage from mmc0 partition 1 to memory addr 0x80000000
<rsalveti> the bootm says that you should now boot from this memory location
<Martyn> ah, the joys of uboot
<jo-erlend> ah.
<persia> Martyn, You have a grub port yet?
<rsalveti> jo-erlend: time to go now, anything else I can do to help?
<jo-erlend> I guess not today, but if you're around tomorrow, I'm sure I will have something. :)
<jo-erlend> thanks again for your help.
<rlameiro> wow that was a tough ride
<rsalveti> jo-erlend: sure, np!
<rsalveti> see ya
<Martyn> persia : There will be no grub port.  Once we added Jason and Rob to the SStone team, we went for u-boot as the solution
 * rsalveti out for bed
<rlameiro> hours of debbuging
<jo-erlend> rsalveti, sleep well. :)
<jo-erlend> rlameiro, I got more normal text now! Improvement. :)
<persia> Martyn, Awww..  but...  :(
<Martyn> persia : So we're concentrating on that, and adding what we need to u-boot to make the platform work
<Martyn> persia : No buts .. it came down to return for the time spent on it .. and grub2 was going to be too much work to be worth it.
<Martyn> persia : Michael's software bootloader also went by the wayside .. it's always the same story.
<Martyn> BUT .. we got pxe working .. and that's something
<persia> That's something.
<persia> Now I just have to find another group that's more idealistic than underfunded :)
<rlameiro> lol
<rlameiro> is uboot beeing customized for ubuntu?
<rlameiro> detection routines?
<persia> rlameiro, I believe the plan is to mostly use linaro's uboot, and leave the coordination between the many uboot trees to the linaro project.
<Martyn> yep
<Martyn> and eventually probably move to UEFI, but who knows when that will work...
<rlameiro> nice
<persia> We're good at making a distribution, but we're less good at making individual bits of software good for everyone.  Some of us work upstream in various ways, but as a team, it's better to focus on integration.
<rlameiro> I never got that linaro heads stuff
<persia> Martyn, UEFI works without a second-stage?
<Martyn> UEFI works when device tree is finished
<persia> rlameiro, I don't understand linaro "heads" stuff either, but the linaro project does seem to be putting a lot of effort into collaboration between different trees, making it *lots* easier for us to select the right thing when building a general-purpose distribution.
<Martyn> and yeah .. UEFI is a complete little boot shell
<Martyn> 'little'
<rlameiro> kinda lilo ? hehe
<persia> So, what was the deal with all the amd64 grub2 stuff this cycle to make it work for UEFI?
<Martyn> persia : Because I went to LinuxCon:Boston .. my boss won't let me to go LinuxCon Japan :( :(
<Martyn> I'm a sad panda
<persia> Clearly you shouldn't have attended LC:B :)
<persia> MIssed you last time, but if you come visit when I'm actually on this side of the world, be fun to do something.
<Martyn> Yeah :)
<Martyn> Coming to UDS:Orlando?
<persia> That's the current plan.
<Martyn> Great :)  See you there :()
<Martyn> :)
<DanaG1> oopsie, that was me having two computers with pidgin open.
<persia> DanaG, Thanks for sorting it quickly :)  By the way, you might be interested in using smuxi or bip or similar sorts of things if you often want to IRC from multiple computers.
 * GrueMaster uses quasselcore on a server and connects to it from multiple laptops.
<GrueMaster> persia: While i am thinking of it.  I filed two regression bugs; Bug 644028 & Bug 644037
<ubot2> Launchpad bug 644028 in linux-meta-mvl-dove (Ubuntu) "Audio regression on Marvell Dove images (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/644028
<ubot2> Launchpad bug 644037 in pulseaudio (Ubuntu) "defaults need adjustment for Dove A0 for audible audio (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/644037
<persia> GrueMaster, Why is 644037 a pulse bug?
<persia> Surely it's best to fix in ALSA or udev or the kernel.
<GrueMaster> It is a duplicate of Bug #451635
<ubot2> Launchpad bug 451635 in pulseaudio (Ubuntu Karmic) (and 8 other projects) "defaults need adjustment on dove X0 for audible audio (affects: 1) (heat: 11)" [Undecided,New] https://launchpad.net/bugs/451635
<GrueMaster> That was fixed in Lucid.
<persia> But fixed with a dirty hack, and nobody went back to clean it up, and now we have a regression :(
<Martyn> So much for getting 10.10 installed on an imac 27" ... display port detection is broken in the current kernel
<Martyn> I was kind of hoping I could convert this thing to a useful machine :)
<persia> GrueMaster, Grab a kernel guy, and make alsa/udev see the right thing and report the right thing to pulse :)
<persia> A good fix for 644028 might also fix 644037
<GrueMaster> persia: That may be part of the fix needed for the first bug.
<GrueMaster> I'll test the Beta image on beagle tomorrow to see if it regressed as well.
<GrueMaster> At any rate, wife calls.  Must go veg in front of the TV before bed.
<DanaG> I still have yet to see where you get one of those "dove" boards.
<Martyn> ddon't bother
<Martyn> the panda board is as good for development :)
<Martyn> the Marvell boards were useful stepping stones, but I see the panda board as being a good measuring stick
<DanaG> I mean, I've never even seen so much as a picture of said "dove" boards... the only things I've seen retail are the old Kirkwood.
<persia> I don't believe there are any retail dove boards.
<persia> I believe the only retail stuff on which Ubuntu is easily available is imx51 or omap3 currently.
<Martyn> yep
<Martyn> the Marvell boards I got were direct from the engineering group
<Martyn> the whole point of the Dove boards is like the Lange boards .. engineering testing and development
<hrw> morning
<ogra> bah, sigh
<ogra> two openoffice build. one linux-linaro and more linux builds in the queue
 * ogra guesses we wont see much from the buildds today
<amitk> why two OO.org?
<ogra> maverick and a lucid SRU
<persia> maverick is a good thing.  This one should build.
<ogra> its the same source for both
<mk0> is it possible to install ubuntu-arm on very old dell axim x5?
<ogra> what CPU is in it ?
<hrw> it is not
<hrw> mk0: its armv5
<ogra> should be fine with jaunty
<hrw> pxa27x iirc
<ogra> but nothing newer
<hrw> ogra: jaunty works on 64MB ram?
<ogra> (userspace at least, kernel and bootloader is up to you)
<persia> I'd recommend installing Debian on an ARMv5 device.
<persia> hrw, Sufficiently stripped, yeah.
<ogra> hrw, yes, we offered an NSLU2 image in jaunty
<ogra> its super painful, but works ... kind of
<mk0> oh shi... too advanced answers
<mk0> for me
<hrw> ogra: nslu2 can have 256MB ram ;D
<hrw> all depends on soldering skills
<ogra> we only used the default
<hrw> I want to drop my beagleboard to floor and jump on it few times
<persia> You'd end up having to get a new one ...
<hrw> persia: I have other C3 here
<hrw> but it will not change situation. even worse
<persia> mk0, Short answer: you'd do better to install Debian.  Ubuntu support for that device happened once, but isn't continuing.
<hrw> both my C3 have usb problem
<hrw> but one which I use has expansion header soldered so usb fix was easier
<mk0> persia, thanks) will lurk towards deb
<ogra> but even there you might need to do a kernel and bootloader setup on your own
<persia> bootloader at least.  I believe there to be pxa2xx kernels in Debian
<zumbi> persia: what?
<zumbi> pxa2xx kernels in debian :?
<zumbi> persia: i use pxa270 board
<persia> zumbi, Maybe it was just leftover (unused) config in a kernel source I read once.  I haven't looked recently.  I'll trust your word over my memory.
<zumbi> persia: debian arm sadly does not provide pxa2xx support :/
<zumbi> persia: i am fighting kernel guys and see if we are lucky to include mv78xxx machines
<persia> It's always a matter of having kernel folk to support stuff.
<zumbi> but kernel build takes so long in native that it is a blocker for adding more platforms
<persia> Clearly you need more, faster, buildds :)
<zumbi> well.. now we have them, so we'll see if more platforms are added
<zumbi> but with the freeze, all development is somehow stalled on bugfixing
<persia> This is a good thing :)
<zumbi> well, it is good yes, for release (I hate releases :) )
<zumbi> btw, are you guys playing on omap4?
<persia> Some folk have dev boards.
<hrw> 10.10 on arm require 768MB ram or 512MB is enough?
<ogra> zumbi, well, we release images for it :)
<zumbi> ogra: omap4 seems to be a beast
<ogra> hrw, 256M should be enough, 512M is recommended
<persia> 384 is the regular requirement.  256 may work, depending.
<ogra> right
<ogra> 256M should kind of work
<ogra> with -fun :)
<persia> Just don't try to do too many things at once :)
<hrw> I need to kill plymouth, ureadahead and then maybe it will finally boot
<ogra> +fun starts at 512M and above :)
<ogra> hrw, ureadahead is supposed to be fixed in the recent images
<persia> +fun is *supposed* to happen at 384MB.  Do the requirements need a bump?  Do we need a general bloat reduction push again?
<ogra> nah
<ogra> +ok starts at 384
<ogra> +fun starts at 512 :)
<persia> Ah.
<hrw> ogra: first I need to boot to be able to run apt
<ogra> yeah, booting is such a thing ...
 * ogra is really happy that all his ubuntu probs vanished when he started to use the tegra netbook
<hrw> ogra: how much it costs?
<ogra> 380-400 â¬
<persia> What do you mean "all ubuntu probs vanished"?  You aren't using Ubuntu anymore?
<hrw> ogra: too much ;)
<ogra> persia, no, i have only android probs now
<persia> heh.  Ubuntu problems *exist* but aren't quite as intense.
<hrw> nice... bb hang on
<hrw> beagle login: hrw
<suihkulokki> ogra: bought from where?
<ogra> suihkulokki, media markt in germany
<ogra> they sell it off the shelf here
<suihkulokki> interesting
<ogra> but its locked down and runs android ... i managed to unlock it and can run ubuntu chroots just fine for working ... but there is no way to access the bootloader to change the preinstalled os
<suihkulokki> did you write up hacking notes somewhere?
<ogra> someone did
<zumbi> suihkulokki: pandaboard is very much near if you want A9 hw
<zumbi> near in time
<hrw> nice... /var/lib/dpkg/status trashed
<ogra> suihkulokki, http://tosh-ac100.wetpaint.com/
<ogra> wow, the rooting howto is completely worng :P
<ogra>  /data is mounted noexec there is no way to run binaries in it ... funny
<ogra> i wonder if people test such stuff if they write howtos
<hrw> in glibc systems noexec has no meaning iirc
<NekoSchool> ouch, ac100 needs "rooting"? :D
<NekoSchool> damn toshiba :D
<ogra> NekoSchool, its android
<dcordes> ogra: I am sure there will be ways eventually
<NekoSchool> yeah sure but there isn't some nice standard bootloader in there like redboot or uboot with a serial console or something and some pads on the board for a serial cable?
<ogra> i dont think anyone ever shipped an andriod based device off the shelf with root enabled
<ogra> NekoSchool, nope, nothing like that
<ogra> its a patches down android fastboot bootloader it seems
<NekoSchool> even if you ship a completely locked down software on a device, this isn't a phone.. running ubuntu on it should be a nice feature for those who have the right SD card or something :D
<ogra> dcordes, ?
<dcordes> ogra: do boot your own kernel/initramfs
<ogra> dcordes, ways to install ubuntu you mean ?
<ogra> ah, likely
<ogra> the more people complain to toshiba the more likelier it gets
<dcordes> DIY
<ogra> it seems to use a raw partition for the bootloader stuff
 * ogra made a dd copy from the eMMC
<dcordes> They don't have to let you boot your own kernel so I think it does not matter how many people will complain.
<ogra> first partition only starts at block 33 so there is "free space" before it
<dcordes> ogra: what's eMMC? Any documentation ?
<ogra> a builtin flash like device that exposes itself as MMC
<persia> dcordes, It's the same as MMC, except you can't remove it.
<dcordes> ok
<ogra> i think the e stands for embedded (not sure though)
<dcordes> ogra: can you provide the dd ?
<ogra> not sure if thats legal, so not publically, no
<dcordes> ok
<dcordes> Are any system upgrades anounced by toshiba ?
<ogra> apparently there is an andriod 2.2 one expected in the next 4-6 weeks
<ogra> oh !
<hrw> eMMC describes an architecture comprised of an embedded storage solution with MMC interface, flash memory and controller, all in a small ball grid array (BGA) package.
<hrw> It is based upon the industry-standard MMC system specification version 4.1/4.2 and JEDEC BGA packaging standards
 * ogra just found a proper recovey mode by accident !
<hrw> thats from JEDEC informations
<dcordes> hrw: thanks
<dcordes> AC100 looks real nice. Checking some videos
<zumbi> hrw: hey! i got that jedec document :P
<persia> ogra, You mean that next time you brick it, you can recover without help?
<ogra> persia, not sure, depends if the bootloader is in two parts :)
 * persia continues to hold off on a purchase decision
 * ogra doesnt know where that recovery mode lives ... first or second stage
<ogra> and i wont play with it right now
 * ogra has work stuff to do :)
<persia> Of course :)
<dcordes> ogra: Did you think about possibility to boot new kernel from within running system ?
<ogra> dcordes, that would require kexec support in the running kernel
<persia> dcordes, Most kernels provide a userspace environment that prohibits that.
<dcordes> grep -i kexec ac100_defconfig
<dcordes> CONFIG_KEXEC=y
<dcordes> ogra: j/k :>
<dcordes> ogra: you have a 3g device ?
<ogra> yes, but no sim
<dcordes> ogra: I have a hard time finding the ac100 kernel source code. Do you have a link ?
<ogra> dcordes, i dont think its public, toshiba will liekly ship it to you if you give them the product id
 * ogra goes for some late lunch
<dcordes> That might apply to the MIT licensed userspace portions..
<dcordes> I want to see the ac100 kernel sources and I don't have the device
<rsalveti> morning
<jo-erlend> rsalveti, good morning! :)
<rsalveti> jo-erlend: hey!
<jo-erlend> rsalveti, I re-dd
<persia> dcordes, Just convince ogra to make a kernel source request, and share it with you :)
<jo-erlend> uh.. I re-dd'd my memorycard and booted it with uInitrd. It did change the partitions, but now I'm stuck. Where do I go from here?
<rsalveti> jo-erlend: cool, you just need to boot it once
<rsalveti> to get the resize, then mount it at your host, and use chroot to install my kernel package
<dcordes> persia: I don't want to have to convince anybody to anything when all I want is to read kernel source
<dcordes> that is GPL licensed
<persia> Why?
<jo-erlend> rsalveti, ah. I just replaced the uImage with the one you sent me. That didn't work.
<persia> There's no requirement for GPL code to be public.
<rsalveti> jo-erlend: it'll break the same way as before, because of missing modules
<persia> There exist licenses that require code to be public, but most folk don't like them, and they fail the desert-island-test of freedom.
<persia> (because if you're on a desert island with no connectivity, you'd be restricted from modifying the code, since you couldn't make the modifications public)
<ogra_cmpc> GPL only7 requires that you give the source to a user you sold the binary to
<dcordes> ok
<ogra_cmpc> no requirement to make it public at all
<ogra_cmpc> at least GPL v2
<jo-erlend> rsalveti, I still have two partitions, but now the second partition contains /boot and has some files in it. Is that the way it's supposed to be?
<ogra_cmpc> i think it changed a bit for v3
<persia> ogra, No, GPL requires you give the source to anyone who has your source or binaries, regardless of whether they use it or whether they paid for it.
<rsalveti> jo-erlend: yep, that's fine
<persia> and there's still no public requirement for GPLv3
<rsalveti> jo-erlend: because u-boot uses the files from the first partition, so it just ignores the /boot
<ogra_cmpc> how would one get the binaries without buying the device ?
<ogra_cmpc> thats a moot point
<rsalveti> jo-erlend: you should have vmlinuz and initrd.img from your kernel
<persia> ogra, Maybe one got a developer sample.  Maybe one downloaded a recovery image.  Maybe someone posted a copy of the kernel on the internet.  Lots of ways.
<dcordes> ogra: 'CONFIG_IKCONFIG_PROC=y' ?
<dcordes> ogra: you have /proc/config.gz file ?
<ogra_cmpc> sure
<dcordes> can you pastebin ?
<dcordes> persia: ogra mentioned they are planning an upgrade to new android version. as android makes many depencies on kernel level this will likely involve new kernel binary
<dcordes> persia: the question is if it will be some OTR thing or also password restricted for the device buyers
<persia> dcordes, So, when that happens, if it's an open download, download that binary.  Once you have it, request source.
<persia> Could be either way.  Doesn't really matter.  the kernel source can be made available as soon as someone posts it.  there's no restriction on posting except motivation of folks.
<persia> Hence the value of convincing folk to do stuff :)
<dcordes> Actually I don't like the fact such things must be discussed.. I am just recovering of the DELL Streak gpl violation thing
<dcordes> persia: so a 'leaked' binary can also be jurisdical base to enforce gpl ?
 * persia refuses to provide a legal opinion
<persia> That said, it probably depends on how the leak happened, etc.  Quite possibly.
<persia> the GPL requires source to be made available to anyone to whom a binary is made available.
<persia> But you'd have to make a GPL claim against the leaker, which may have repurcussions, rather than against the original patch authors whose code was included in the leak.
<persia> So if the leaker was a friend, you might not want to do that.  If the leaker was a whistleblowing organisation, you don't help their cause by making claims against them.
<persia> GPL only gives you the right to request source code from the same folk that provided the binary.
<suihkulokki> yep
<dcordes> how does nokia handle it with n900 and friends ?
<suihkulokki> with a written offer
<dcordes> the whole source-for-device-owner-only thing is new to me
<persia> I believe they offer code for allthe GPL stuff.
<ogra_cmpc> with good lawyers
<rsalveti> they offer in the ftp servers
<rsalveti> easier way
<jo-erlend> rsalveti, I do. They point to vmlinuz-2.6.35-19-omap
<rsalveti> instead of waiting requests from everybody
<persia> dcordes, It's not source-for-device-owner-only!  It's that the source only needs to be made available to folks that receive the binaries.  Most large projects end up with a public repo, but that's just a matter of convenience.
<rsalveti> jo-erlend: sure, the default kernel
<rsalveti> jo-erlend: now just install mine with dpkg -i
<persia> dcordes, once any owner receives the source, they are free to post to the internet anywhere they like.
<rsalveti> you should get new vmlinuz and initrd.img
<ogra_cmpc> i think toshiba plans that too, there is a URL in the license agreement
<rsalveti> then you generate your own uImage and uInitrd from it
<ogra_cmpc> (which doesnt work yet)
<dcordes> persia: yeah that's what I mean. Matter of convenience. I haven't seen that toshiba behaviour before
 * persia has often had such limits in contracts, because the client didn't want their code distributed, and I wanted to write GPL code.
<dcordes> ogra: can you pastebin the /proc/config.gz ?
<ogra_cmpc> dcordes, toshiba hasnt provided android devices before
<dcordes> persia: that's interesting. I once got a contract offering from people who wanted to make shanzai android phone.. it was same story
<persia> dcordes, Not uncommon: lots of companies want to time their releases.  Doesn't make the code less GPL when users get it.
<dcordes> in case of HTC you also see such delays but it's always in an acceptable frame
<suihkulokki> you need to sell early publicing of code as "free QA review from community"
<ogra_cmpc> the ac100 got on the market 10 dys ago or so
 * ogra_cmpc wouldnt see that as inacceptable if it happens at some point soon
<jo-erlend> rsalveti, how do I do that?
<persia> suihkulokki, I think that doing so requires a bit more stature than being able to require GPL which requires more than random coding.
<rsalveti> jo-erlend: what exactly? generate uImage and uInitrd?
<jo-erlend> yes
<rsalveti> with mkimage
<dcordes> ogra_cmpc: if you understood it, I did not mean to compare to toshiba there
<suihkulokki> persia: well yes of course
<jo-erlend> rsalveti, little more details please? :=
<rsalveti> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d initrd.img uInitrd
<rsalveti> mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d vmlinuz uImage
<dcordes> Here that was ridiculous story http://laforge.gnumonks.org/weblog/2010/09/13/#20100913-dell_streak_sources
<dcordes> and it's not over yet.
<rsalveti> jo-erlend: install package uboot-mkimage
<jo-erlend> rsalveti, I have. I used it to create the boot.ini file.
<rsalveti> after installing my package, run these commands with the new initrd.img and vmlinuz
<rsalveti> then you'll have a new uInitrd and uImage
<jo-erlend> they'll be placed in rootfs/boot?
<rsalveti> copy them to the first partition, recreating it first
<rsalveti> jo-erlend: after installing the package you can find them at rootfs/boot, but after generating the uI* files you need to copy them to the first partition
<jo-erlend> right.
<jo-erlend> rsalveti, I got the same error today when installing the package, although on a different file. No space left on device.
<rsalveti> jo-erlend: this is weird, if you got the resize working, you should have enough space
<rsalveti> how much space left do you have at your sd card?
<ogra> GrueMaster, how was the oo.o testing ?
<ogra> (doko just asked)
<jo-erlend> rsalveti, well. Nautilus shows it as a 7.9GB volume, but from within the chroot, df -h displays it as 2.0GB.
<GrueMaster> I didn't get to it.  Swamped with alsa testing.
<ogra> GrueMaster, well
<ogra> the packages are in the archive now
<rsalveti> hm, so it was probably not resized correctly, werid
<GrueMaster> ok
<GrueMaster> I had also downloaded them to my server.  Just never got a chance.
<rsalveti> jo-erlend: did you boot it once with the original uImage and uInitrd, right?
<jo-erlend> yes
<rsalveti> jo-erlend: did you see if you got the reboot? or how long did you wait before turning the device off?
<jo-erlend> rsalveti, I might have made a mistake along the way. It was 6am when I tried the last time, so I was a bit sleepy. I think I'll start over.
<rsalveti> you should wait at least 5 minutes
<jo-erlend> oh, ok.
<jo-erlend> I don't think I waited that long.
<rsalveti> :-)
<jo-erlend> rsalveti, should I use the uImage you sent me for the first boot?
<rsalveti> jo-erlend: use the original one, with original uInitrd
<rsalveti> to be sure we don't face any issues
<rsalveti> just boot and wait for 5,8 minutes
<persia> The original initrd has some extra code to resize the filesystem, etc.
<rsalveti> persia: that's why we're doing this
<berco> does anyone have a beagleboard up and running who can quickly do "cat /proc/asound/cards" and report me the output?
<jo-erlend> rsalveti, this is very strange. I booted the board with the original uImage and uInitrd and left it running for 15-20 minutes. When I mounted it on my laptop, Nautilus reports it as a 7.9GB filesystem, but also reports that is has only 298,7MB of free space.
<rsalveti> jo-erlend: sigh
<rsalveti> jo-erlend: for some reason the resize is not working, I believe
<jo-erlend> can I do it manually?
<rsalveti> probably
<rsalveti> let me try to find the command
<persia> berco, http://paste.ubuntu.com/497723/
<berco> persia, thanks
<berco> persia, I think we are missing the equivalent of that twl4030 field on pandaboard
<berco> this is why my alsa/SDP4030.conf file doesn't get read
<rsalveti> jo-erlend: http://bazaar.launchpad.net/~ogra/jasper-initramfs/trunk/annotate/head:/scripts/local-premount/jasper_growroot#L82
<rsalveti> quite a few steps
<rsalveti> resize_partitions to change the disk size
<persia> berco, What does the pandaboard report?
<rsalveti> then e2fsck and resize2fs
<jo-erlend> rsalveti, the disk size seems to have changed.
<rsalveti> fdisk should show you
<rsalveti> but if you get it right at nautilus, it's probably changed
<berco> persia, pandaboard reports this http://paste.ubuntu.com/497729/
<persia> Yeah, that's missing the machine configuration entirely.
<berco> persia: when I use iwatch I can see the file is not accessed whereas when I do the test on my PC, the .conf is accessed
<jo-erlend> rsalveti, palimpsest shows /dev/sdb2 as a 7.9GB Ext3 filesystem+
<ogra> jo-erlend, what about df -h
<jo-erlend> it shows 2.0GB.
<ogra> right
<mpoirier> rsalveti: in the meeting you talked about "a bug for the kernel and another for u-boot", it this related to sound ?
<rsalveti> mpoirier: nops, LED
<mpoirier> ok.
<ogra> mpoirier, no, to new panda HW
<ogra> oh, that one
<ogra> ignore me :P
<mpoirier> ogra: I can do that !
<GrueMaster> mpoirier: bug 626795
<ubot2> Launchpad bug 626795 in linux-ti-omap4 (Ubuntu) "Missing LED support for Pandaboard (affects: 1) (heat: 8)" [Low,Fix released] https://launchpad.net/bugs/626795
<GrueMaster> Just for clarity.
<persia> mpoirier, Do you have any recommendations for berco?  He's working on a userspace workaround in case you don't find a kernelspace fix, but the kernel isn't reporting enough to dynamically load the right configuration :(
<jo-erlend> fdisk sais it's a 8GB disk...
<ogra> jo-erlend, fdisk and the gnome tool report partition sizes
<ogra> jo-erlend, df shows filesystem size
<rsalveti> so no resize
<mpoirier> persia: berco: I'm just getting started - give me a few days and I'll have an opinion.
<ogra> well, resize_partitions has run
<ogra> but not resize2fs
<rsalveti> yup
<jo-erlend> ah. Then palimpsest was confusing, since it sais "7.9GB ext3"
<rsalveti> weird, but without console and display working, no much to say, unless checking jasper logs
<jo-erlend> rsalveti, I won't have to manually create the /lib/modules directory like I did yesterday?
<rsalveti> jo-erlend: nops, because now you installed by kernel package
<rsalveti> *my
<rsalveti> or, you will install it when you're able to resize it
<jo-erlend> yes, it's being installed.
<ogra> GrueMaster, hmm, do you see update-manager popping up automatically on the images ?
 * ogra juts ran an apt-get update, that should trigger u-m i think 
<GrueMaster> I haven't looked.  Had been focusing on a lot of other issues lately.
<GrueMaster> will look on omap4 now.
<rsalveti> jo-erlend: so, did you resize it by hand?
<GrueMaster> ogra: apt-get update usually will trigger it within a few minutes.  Will let you know if I see any activity.
<GrueMaster> I know it works on Lucid.  It shows up at least weekly on my babbage.
<ogra> k
<ogra> no hurry, was just a question out of interest
 * ogra takes a break
<GrueMaster> ogra: The "Install OMAP4 addons" icon is in "Other" on 20100920, but the cmdline fails.
<jo-erlend> rsalveti, does it matter if I create uInitrd and uImage from the chroot or not?
<rsalveti> jo-erlend: nops
<jo-erlend> rsalveti, I resized by hand, yes.
<rsalveti> cool
<rsalveti> so you should now have enough space to play with it later :-)
<jo-erlend> yes, and the kernel installed properly. :)
<rsalveti> nice :-)
<ogra_ac> GrueMaster, yeah, its partially fixed in 21.1
<GrueMaster> ok.
<ogra_ac> but needs a sw-center fix first
<ogra_ac> which is in the tree but wasnt uploaded
<jo-erlend> rsalveti, I should use initrd.img-2.6.35.4+?
 * ogra_ac wishes he could find an IRC client for android with a lag meter
<GrueMaster> Just so you know, I really have a hard time testing dailys and apps and special requests on a daily basis.
<GrueMaster> I'm getting overwhelmed.
<ogra_ac> why is that ? because your boards are busy doing other stuff ?
<GrueMaster> Boards are slow, and some of the tests can take hours.
<ogra_ac> well, omap4 should be rather fine for quick tests
<ogra_ac> i agee for beagle and dove
<rsalveti> jo-erlend: yep
<GrueMaster> Even just running checkbox with only known supported tests can take a day.
<rsalveti> sorry, seems my notification system is not working properly
<persia> ogra, An 8-way 5Ghz 32Gb system would be slow for some tests.
<ogra_ac> sigh
<GrueMaster> This is part of why I haven't jumped on open office yet.  Install alone will take 20 minutes.
<rsalveti> ogra_ac: what happens with your client?
 * ogra_ac pokes android in the eye
<ogra_ac> client is fine, the wifi is unstable after some time
<ogra_ac> ralink NIC
<ogra_ac> with binary driver it seems
<rsalveti> hm, ok
<ogra_ac> i have to connect to teh Ap with teh worst signal to make it work at all
<ogra_ac> might be my local setup or some channel interference between the tree APs i have
<ogra_ac> seems the card is more fragile than my others
<ogra_ac> the annoying part is that i cant find a client that shows me the lag so i dont even notice i'm disconnected
<ndec> ogra: hi! i have a question for you...
<ogra_ac> ndec, shoot
<ndec> ogra: i want to mount the ext3 partition from the .img in qemu on my laptop... what is the magic command line?
<ndec> ogra: qemu arm i mean
<ogra_ac> i guuess you need to loop mount it, then use /dev/loop* for aemu
<ogra_ac> *qemu
<jo-erlend> rsalveti, I have graphics! Welcome to Ubuntu :)
<ogra_ac> for the -hda option
<GrueMaster> ndec: First, run "file <img file>" to find out the partition info.  Then run "sudo mount <img file> <mount point> -o loop,offset=$((512*<partiotion start sector>))"
<ndec> ogra: GrueMaster: thanks. I will try this. I didn't realize I could a mount point to -hda, i was looking to a way to pass the offset to qemu.
<GrueMaster> ogra_ac: Looks like update-notifier is not working at all.  I also tried it on my netbook running maverick.
<ogra_ac> bah
<ogra_ac> update-manager works though, i just did an update
<ogra_ac> anything in .xsession-errors ?
<ogra_ac> probably the behavior changed and we just dont know
<rsalveti> jo-erlend: nice :-)
<ogra_ac> (the default i mean)
<GrueMaster> ogra_ac: I'm not seeing anything since it's startup note.
<ogra_ac> k
 * ogra_ac will ask mvo in #ubuntu-devel if there are deliberate changes
<rsalveti> jo-erlend: so it did fixed, can you please then update the bug report?
<ogra_ac> GrueMaster, update-notifier --debug-update seems to be the magic to find out whats wrong
<GrueMaster> Looks like the update interval is set ot 7 days in gconf.
<ogra_ac> yes, thats normal
<ogra_ac> was like that in lucid too
<ogra_ac> (and karmic)
<GrueMaster> Ok, so...
<ogra_ac> its just the cron timer, but u-n should run in the session too and pick up changes if you run apt-get update
<GrueMaster> It also says "/usr/lib/update-notifier/apt-check returned 38 (security: 0)"
<ogra_ac> that sounds right, weird that it doesnt pop up
<ogra_ac> 38 normal packages, 0 security updates
<GrueMaster> Yes, that sounds accurate since I ran apt-get update before restarting update-notifier.
<ogra_ac> i would think we miss something on arm in teh efl session, but if you see it too on x86 ...
<GrueMaster> Just restarted on x86-64 desktop (my netbook).  apt-check returns 12 updates (0 security).  No notification there either.
 * GrueMaster grumbles and files yet another bug that should have been picked up elsewhere.
<ogra_ac> gruemaster ... why elsewhere ?
<GrueMaster> If it exists on x86, it should have been tested & reported there.
<ogra_ac> well, its a bug ... we are just the lucky ones having teh idea to test it :)
<jo-erlend> rsalveti, I will. However, I see no signs of networking, either cabled or wireless.
<rsalveti> jo-erlend: hm, then need first to find the chip responsible for networking
<GrueMaster> ogra_ac: Bug 644459 filed.
<ubot2> Launchpad bug 644459 in update-notifier (Ubuntu) "update-notifier not reporting updates available (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/644459
<jo-erlend> rsalveti, and I get a very low resolution, and I can't change it in System > Preferences > Monitors. All the controls are deactivated.
<ogra_ac> GrueMaster, thanks
<rsalveti> jo-erlend: you can't, you need to specify the correct one by giving it to the omapfb parameter
<jo-erlend> oh.
<rsalveti> argh, seems I'm getting random temperatures report from my acpi
<rsalveti> and sometimes my kernel decides to halt to protect me
<rsalveti> but it's not hot, and I'm tracing the temperature, weird
<rsalveti> must be a bios issue...
<jo-erlend> rsalveti, which omapfb mode should I use for 1920x1080?
<rsalveti> jo-erlend: nops, omap 3 doesn't support it
<jo-erlend> hmm?
<jo-erlend> it's supposed to be able to use much higher resolutions than that
<ogra_ac> at 1bit depth ?
<rsalveti> 1280x1024@50 or 1280x720@60 I guess
<ogra_ac> yeah
<jo-erlend> they say it supports up to 2048x2048.
<jcrigby> ogra_ac, who do I ping about build machine weirdness
<rsalveti> you could get more than that, but need to adjust the timings and etc
<ogra_ac> jcrigby, lamont
<rsalveti> jo-erlend: hm, if igepv2 is the same chip we have for beagle, probably not
<ogra_ac> jcrigby, whats wrong ?
<rsalveti> the pixel clock can't get that higher
<rsalveti> jo-erlend: using 16bit
<jcrigby> ogra_ac, we are waiting for a kernel build.  It starts up building, runs for a couple minutes then goes idle.  Seems to keep bouncing between hubbard and hawthorn
<ogra_ac> weird
<jcrigby> I pinged lamont on #is but he is away
<ogra_ac> well, he is the master of arm buildds and knows the queue software
<ogra_ac> not sure whom to ping else on such an issue
<jcrigby> ok, thanks
<jo-erlend> rsalveti, ok. What do I use to get 1280x720?
<rsalveti> jo-erlend: vram=12M omapfb.mode=dvi:1280x720MR-16@60
<jo-erlend> thanks.
<lag> ogra_ac: Stop using my name in vain - jerk
<lag> ;)
 * ogra_ac thinks lag meter is a valid device though
<jo-erlend> rsalveti, hmm. The bootpartition is suddenly empty.
 * lag is |-..........................|
<rsalveti> jo-erlend: ouch, shouldn't be
<jo-erlend> the boot fs, I mean.
 * lag is |-----......................|
 * lag is |---------..................|
 * lag is |-------------..............|
 * lag is |-----------------..........|
<ogra_ac> heh
 * lag is |---------------------......|
<lag> :D
<ogra_ac> how is asia ?
<lag> Hot and sticky
<ogra_ac> heh, nothing new then
<lag> Have you been here?
<ogra_ac> only once on my flight to the second UDS
<ogra_ac> i had a smoke break in singapore
<ogra_ac> lag, btw, ac 100 rooted :)
<lag> Where was the second UDS?
<ogra_ac> and i bricked one already
<lag> Well done
<lag> And not so well done
<ogra_ac> that was in sydney
<lag> How did you do it?
<lag> Cold card?
<ogra_ac> well, got an immediate replacement at the shop
<lag> Wow - when's the next Aus UDS?
<ogra_ac> no, more embarrasing
<lag> Go on?
<ogra_ac> i accidnetially removed /bin/sh
<lag> HA
<lag> Isn't it just a simlink?
<ogra_ac> androids init calls shell scripts
<ogra_ac> yes
<lag> So?
<ogra_ac> i wanted to link it to busybox
<lag> So do it
<ogra_ac> but messed it up
<ogra_ac> it didnt boot anymore
<ogra_ac> no way to access it
<lag> Oh, I see
<lag> That was the first one?
<lag> What about the new one?
<ogra_ac> so i carried it back to the shop "doesnt boot !!"
<ogra_ac> they just handed me a new one
<ogra_ac> without words
<ogra_ac> the new one is rooted and i run an ubuntu chroot on SD now
<ogra_ac> dont want to brick it again so i wait until someone else figures out teh bootloader
<lag> So, how did you root it?
<GrueMaster> Odd that they make it impossible to recover.
<ogra_ac> the chroot is fine for compiling etc
<ogra_ac> there is a tool called rageagainstthecage that uses a kernel exploit by opening endless amounts of file descriptors
<ogra_ac> works quite well
<ogra_ac> you run it, the next shell you open is a rootshell
<ogra_ac> then you can make busybox suid root and use the busybox su command in the future
<ogra_ac> GrueMaster, it apparently has a recovery mode i discovered today
<ogra_ac> but its kind of a blind flight
<GrueMaster> heh
<ogra_ac> and requires a specisl nvflash to access the device
<GrueMaster> What did you expect, a bios prompt & boot menu?
<ogra_ac> which isnt in teh tegr4linux tools
<ogra_ac> i'd lobe to have USB serial, yeah
<ogra_ac> *love
<GrueMaster> What bootloader are they running?
<ogra_ac> fastboot i think
<ogra_ac> its android after all
<ogra_ac> the normal recovery mode can only reset to factory or install update.zip
<ogra_ac> nothing more
<GrueMaster> btw:  linaro call in 3 minutes.
<ogra_ac> and update.zip requires a toshiba kesy
<ogra_ac> oh, thanks i forgot about it
<ogra_ac> as usual
 * ogra_ac goes upstairs
<ogra> bug 642117
<ubot2> Launchpad bug 642117 in pencil (Ubuntu) (and 4 other projects) "[armel] QFloat / double / float confusion (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/642117
<devilhorns> now this is much better: http://www.pastebin.ca/1945897
<devilhorns> tho have to bring the Res down still
<ogra> devilhorns, WOW!
<devilhorns> ogra, hmm ?
<ogra> awesome numbers
<devilhorns> :)
<devilhorns> getting there
<devilhorns> still a bit more work todo ... want to trim that Res down some more
<devilhorns> ideally I'd like to get to <= 10m
<ogra> well, we still run half of gnome ... even these values are awesome
<devilhorns> but already trimmed roughly 10,000 from the Virt, and 1m from the shared
<devilhorns> ogra, half of gnome ? why ? ... wrt this new one, the only thing that will need to be running is a "window manager" to draw borders, handle minimize, etc, etc
<ogra> devilhorns, we need to run the indicator applets and all the other ubuntu stuff
<ogra> everything that hooks into the system needs to work
<ogra> and all the old things are turned into the new indicator things
<ogra> (volume control, network management, time, app indicators etc)
<devilhorns> ahh yea, will still have to run the gnome-panel
<devilhorns> not much I can do about that tho :/
<ndec> ogra: not arm related problem... but I am trying to upgrade my laptop to maverick. i am running a custom lucid (i am running maverick lts backport kernel + a maverick thunderdird), when I try to upgrade the tool refuses to continue with 'E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.'. is it safe to replace lucid by maverick in my source.list and run dist-upgrade? or is the upgrade tool doing more than 
<ogra> its doing more
<ogra> you should talk to mvo in #ubuntu-devel, he maintains the upgrade tools
<ogra> he will surely be intrested in your situation since he loves to cover all corner cases for upgrading
<Neko> guys any clue where the Applications Places System menu is defined in gnome or xfce or whatever config?
<Neko> we have a button size problem here and I'd like to go about hacking in a fix but it seems to be automagically created
<GrueMaster> Neko: What are you referring to?
<GrueMaster> Looks like an Ubuntu Desktop issue.
<GrueMaster> (not armel).
<ogra> yeah, likely a question for #ubuntu-desktop
<Neko> http://launchpadlibrarian.net/55758568/screenshot.png
<Neko> like that
<Neko> it happens on GNOME too just so you know, but some people don't see it
<GrueMaster> Interesting.  I'm not seeing it on my netbook, and it is running Maverick amd64.
<GrueMaster> But you might want to bring it up in #ubuntu-desktop.  They could probably help more on this.
<ogra> right
<Neko> I just did and they said they are in a meeting
<ogra> yeah, they have a silly policy to hold their meetings in their channel instead of using #ubuntu-meeting like all other teams
 * ogra got trapped by that several times already
<ogra_ac> oh, sweet, seems someone found acces to the ac100 bootloader
<davidm> ogra, sweet
<ogra_ac> no way to replace kernel etc yet, but they got access ... so linux is just a step away
 * ogra_ac got careful with his, i dont want to have to replace it again so i'll wait for someone else to figure it out
<davidm> Yep very nice
<prpplague> ogra_ac: ac100?
<ogra_ac> prpplague, yeah, toshiba ac100 ... tegra2 based
<prpplague> ahh
<ogra_ac> sadly it comes with locked down android preinstalled
<ogra_ac> but i rooted mine and use an ubuntu chroot for testbuilding packages for omap already ;)
<ogra_ac> panda is better though ... but less portable
<prpplague> indeed
<prpplague> ogra_ac: hopefully we can remedy the portable portion soon
<ogra_ac> yeah, a nice light netbook based on panda would be awesome
<ogra_ac> (and indeed with ubuntu preinstalled)
<ogra_ac> ;)
<ogra_ac> some stable wlan would be cool though
 * ogra_ac sighs about teh ralink adapter
<fredim> Hi, how can I copy the image ubuntu-4.10-server-armel omap.img for SDcard through the windows?
<GrueMaster> ubuntu-4.10?
<fredim> I can not mount the SDcard from Linux, I need to know the exact modules.
<fredim> or
<fredim> or
<fredim> learn how to copy the image through the windows
<GrueMaster> prpplague: I hadn't had a chance to test it before now, but panda ES2 works on my hdmi switch now.  Way cool.  I might even be able to reduce monitor count back to 5 or 6.
<prpplague> hehe
<prpplague> GrueMaster: yea robclark and i spent some time testing
<Neko> okay here's a question a bit generic but relevant to arm all the same
<Neko> how do I magically invoke the thing that makes an initrd for me
<Neko> seems if I installed a kernel package it'd do it for me but I don't have one yet
<Neko> and I need it
<GrueMaster> update-initramfs I believe.
<GrueMaster> prpplague: Thanks a lot for your efforts.  It really does help me a lot.
<prpplague> :)
<GrueMaster> Uh, oh.  May have spoken too soon.  It just came up in X for oem-config.  Looks aweful on my 1440x900 monitor.
<GrueMaster> Will reboot.  switch had lost focus for a bit.
<prpplague> doh
<GrueMaster> splash looks ok.
<Neko> GrueMaster, with no arguments or so?
<ogra_ac> just use teh right glasses :P
<GrueMaster> prpplague: Ok, non-issue.
<GrueMaster> ogra_ac: I only have one pair.
<ogra_ac> ah, thats the prob then :)
<GrueMaster> Neko: There are only a few parameters.  use update-initramfs -h to list.
<ogra_ac> for initial creation you want -c and -k
<GrueMaster> Now I can effectively test both es2 boards in parallel.  (as if I didn't have enough to do).  :P
<Neko> and in theory it just copies a bunch of stuff from the modules directory into a ramfs plus some userspace stuff?
<Neko> so I can create a ramfs for another system as long as I have the modules around (and it's set to "most" or "all" or something?)
<ogra_ac> hrm
<ogra_ac> Neko, no, initramfs-tools provides a lot of files in /usr/share/initramfs-tools
<ogra_ac> and every package can put scripts or hooks in there
<ogra_ac> they all end up in the initramfs
<dcordes> Hi again
<dcordes> ogra_ac: looked at some more ac100 stuff and the device is really nice. What is the canonical attitude towards adding images for additional machines ?
<ogra_ac> there is none
<dcordes> ogra_ac: So if you would be up to adding ac100 images you could just put them ?
<ogra_ac> i wouldnt
<Neko> .. I just want to know if I can generate an initramfs without booting that particular system
<Neko> I mean all the stuff for an exactly the same userspace should basically be common right?
<Neko> except the modules?
<Neko> and I specify which one it trawls with -k
<ogra_ac> dcordes, such situations were the reason why i wrote rootstock
<ogra_ac> Neko, just chroot into your SD card and run update-initramfs ether
<ogra_ac> *there
<ogra_ac> then you can be sure all scripts and hokks needed by installed packages are in your initrd
<Neko> yes but imagine I am in rootstock and I have a bunch of kernel files there extracted somehow, and I run update-initramfs is it going to work
<Neko> considering this userspace will work on 20 different systems if I only put the right modules in place :D
<Neko> armv7 is armv7 at the end of the day and there are no board-specific stuff required
<Neko> except the modules
<ogra_ac> i think rcn-ee once added an option for rolling initramfses inside rootstock
<GrueMaster> Neko: Do you have an armv7 that you can use to modify SD cards on the fly?  That would be easiest.
<ogra_ac> there might be no HW specific suff, but system specific stuff
<Neko> yeah I do
<ogra_ac> GrueMaster chroot under x86 would be even easier
<Neko> I can boot the fs on my efikamx
<ogra_ac> thats why we have qemu-arm-static
<Neko> but I want to generate the one for the netbook without having to boot it on the netbook too
<Neko> then I can work out how to do it in a chroot on my x86_64 box
<GrueMaster> ogra_ac: I was thinking of something more stable.  Like a babbage or something.
<ogra_ac> apt-get install qemu-arm-static .... mount SD ... copy the qemu-arm-static binary into SD
<ogra_ac> chroot /sd-mountpoint
<ogra_ac> thats it
<GrueMaster> ogra_ac: Thats assuming you are running maverick, which isn't fully stable yet.  Otherwise you get an older version of qemu.
 * ogra_cmpc gibes up on 6teh ac100 wlan
<ogra_cmpc> GrueMaster, no, we have it since karmic
<ogra_ac> works fine without any probs
<ogra_ac> and a lot faster than natively
<ogra_cmpc> and the static chroot part was always stable
<ogra_cmpc> apart from running mono
<GrueMaster> mono is another beast entirely.
<ogra_cmpc> which is why we dont use it for image builds
<ogra_cmpc> update-initramfs is just a script
<ogra_cmpc> using the chroot method your scripts run at host speed
<Neko> no offense but the desktop on ubuntu is a horrible, horrible mess
<ogra_cmpc> compiling runs at qemu speed though... thats why we dont use the chroot method for compiling either
<ogra_cmpc> Neko, ? why
<Neko> I have deep disdain for any system that has to dereference 20 different things to finally get down to a default, and then find that it is called "/usr/share/backgrounds/warty-final-ubuntu.png"
<ogra_ac> lol
<ogra_ac> thats historically based
<Neko> why didn't they just make it called default-backdrop.png
<ogra_ac> file a bug
<ogra_ac> i think nobody ever cared
<Neko> oh god I can't be bothered, nobody fixes this stuff. By the time it gets looked at, it'll be WONTFIX and someone will have posted "does this still happen in Narwhal?"
<ogra_ac> well, you are free to use whatever value for teh gconf key anyway in a custom image
<Neko> what I can't find is what is the canonical (pun intended) place to set that gconf key and how on earth I do it without dicking around as the "gdm" user in a logged in system
<ogra_ac> so just call it ... umm ... default-backdrop.png for example :)
<ogra_ac> you do it as all system wide gconf keys under /usr/share/gconf/default
<Neko> the basic idea is that I can change something in a chroot or just in /mnt/usr/share/gconf or something and the system will be fine when it boots
<ogra_ac> you can
<Neko> and that script is how I do it?
<ogra_ac> thats how we customize images
<Neko> but that is only run when update-gconf-defaults is run
<Neko> I can't run that I can "only" edit text files
<ogra_ac> no, it needs to generate the xml
<ogra_ac> you could probably do that too by hand indeed
<Neko> so if I edit that, where do I edit the xml?
<Neko> to match and so that it works first time and then forever after? :D
<dcordes> is it possible to enable on screen keyboard in oem-config via configuration ? I am looking for a workaround to bug 626055 as it seems it is a 'wontfix'
<ubot2> Launchpad bug 626055 in ubiquity (Ubuntu) "oem-config: make on-screen keyboard available (affects: 1) (heat: 159)" [Low,New] https://launchpad.net/bugs/626055
<ogra_ac> read rthe gconf source ... no idea
<Neko> ughhhhh
<ogra_ac> or do it properly
<ogra_ac> and roll a package
<Neko> I give up for now we'll just ship with the horrible placeholder backdrop :D
<ogra_ac> that carries your defaults
<dcordes> GrueMaster: ping.. can you help with the above ?
<GrueMaster> dcordes: Not really at this time.  I would have to learn how oem-config works, and I am really only a QA guy.
<dcordes> Ok thanks anyway
<Neko> ogra, rsalveti
<Neko> what is this line for in rootstock?
<Neko> rm /usr/lib/ubiquity/plugins/ubi-tasks.py*
<rsalveti> Neko: ogra_ac should know it
<Neko> potentially it's the bit that sorta goes "which desktop do you want, dude?"
<Neko> which is kinda pointless then
<Neko> but then again so is partition management and suchlike
<ogra_ac> it disables tasksel in oem-config
<Neko> because of?
<Neko> a bug?
<ogra_ac> no
<ogra_ac> because you dont want to run tasksel if you already provided your tasks at buildtime
<Neko> oem-config-prepare does not such thing so I would assume that it lets it stay in by default everywhere except a rootstock
<ogra_ac> other images use preseed files
<ogra_ac> so tasksel isnt run
<Neko> ok
<ogra_ac> it might not even be in teh maverick oem-config anymore
<ogra_ac> since ubiquity was nearly completely rewritten
<Neko> that explains why it never f**king works :D
<ogra_ac> it does
<ogra_ac> in lucid and karmic
<Neko> regardless of what I do, if I run oem-config-prepare or just manually touch that /var/lib/oem-config/run thing..
<Neko> all I get is back to the gdm login prompt
<ogra_ac> you shoudnt run -prepare
<ogra_ac> just use teh touch
<Neko> all -prepare does is touch, rm -f persistent net rule, pop up a zenity dialog unless you said quiet
<ogra_ac> iirc it also creates a user
<Neko> and remove the oem-config-prepare-gtk.desktop from /usr/share/applications iirc
<Neko> no not here
<ogra_ac> ah, then thats the bit that runs during teh live env
<ogra_ac> -prepare is in two parts iirc
<ogra_ac> just dont use it
<ogra_ac> touching teh file after creating teh dir should be just fine
<Neko> sigh, it doesn't :(
<ogra_ac> well, works on our aily images
<Neko> it never runs. I have no initramfs but then I don't see how that makes any difference at all
<ogra_ac> *daily
<Neko> the file is not in the ramfs, and what is.. is just shit like cryptsetup
<ogra_ac> udev and dbus .... etc etc
<Neko> if you run rootstock that's not in the system anyway
<Neko> udev is the thing that runs it?
<ogra_ac> right, rootstock never gets you the same as an install
<ogra_ac> no
<ogra_ac> udev is in iniramfs
<Neko> but they're also in the rootfs so udev and dbus don't matter then
<Neko> friggin' thing it's supposed to start this upstart job but it's never run
<Neko> gdm runs before it
<Neko> so since gdm is running.. it seems not to run since the display manager is taken
<Neko> ubuntu hate++
 * ogra_ac gives up ... its no fun to help you if you offed all teh software we work on
<Neko> offed?
<Neko> it's no fun to work on this because everything is undocumented and somehow some internal canonical secret that doesn't exist on any other linux distribution.. all I can say is I am only glad this isn't SuSE because I would have ripped my eyes out before working on YaST plugins to do this :D
<GrueMaster> Neko: Unfortunately, complaining and ranting doesn't help.  While ogra_ac has been trying to help, it is hard to work through all the rants.  And it keeps others from helping or getting help as well.  If you know anything about development cycles, you'd know that 30% is spent on development and 70% is spent on documentation.  We simply can't afford that 70% at the moment.
<GrueMaster> If you would like to help, the wiki is open for adding documentation.  Launchpad is open fir filing bugs.
<GrueMaster> And we would certainly welcome the assistance.
<rsalveti> and it's not a internal canonical secrect
<Neko> I have a good idea oem services charges for the stuff we're trying to do here and I know what you get at the end is a frozen, no security updates repository, with still no documentation for the money paid... I'm not sure what you mean by "afford" here
<GrueMaster> Well, we are not oem services, for one.
<Neko> I don't see what me adding to the wiki solves. I don't know what I am doing, or where I am looking, which is why I ask in here.. if I knew already why would I be looking for support? If I did know you can be sure I'd put it on a wiki or a blog somewhere
<Neko> I don't even know what I'd file a bug against or what the description is besides "nobody knows how this works, but somehow it's broken"
<GrueMaster> We are a small handful of engineers (and one tester) trying to get working images on prerelease hardware.  We spend days trying to fix issues like broken kernels and video corruption.
<GrueMaster> Not much time left in the day for documenting how to roll your own images on unsupported hardware.
<ogra_ac> there is a ton of documentation on th ewiki
<ogra_ac> especially for cutomizing stuff
<Neko> well, where I work, I do all that here too.. that is why I am here asking. We have one guy, which is me, no testers, besides me.. no experience, besides mine, which is admittedly tantamount to zero on this stuff
<Neko> unfortunately the hardware is *retail* and was shipping 4 weeks ago
<Neko> or 8 months ago for the efikamx
<Neko> I don't have the luxury of letting it break for another release, it is soul destroying to run karmic on an mx51
<GrueMaster> So if something is shipping we should arbitrarily just support it?  Intel has been shipping Poulsbo based systems for 2 years, but even they don't support it in Linux.
 * GrueMaster wanders off to do more testing.
<Neko> no I just don't get to spend all my days fixing little issues like video corruption because we can't even get oem-config to work
<Neko> I found a description of what is going on and I'm going to report it
<armin76> feature :D
<Neko> do you think that it is possible that oem-config systems are meant to run tasksel such that gdm is installed after creating a user?
<Neko> bug 644638
<ubot2> Launchpad bug 644638 in ubiquity (Ubuntu) "maverick oem-config gtk frontend does not start on first boot because gdm runs before it (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/644638
<robclark> ogra: I tried the cdimage.. very slick :-)
<robclark> but: mem=460M@0x80000000 mem=256M@0xA0000000
<robclark> is there a reason for omitting the last 256mb?
<GrueMaster> ogra_ac: ^^^
<rsalveti> robclark: the weird mem corruption bug we're facing with highmem
<rsalveti> there's a bug for it, one sec
<rsalveti> bug 633227
<robclark> rsalveti: ahh.. so you are using 768 without highmem?
<ubot2> Launchpad bug 633227 in linux-ti-omap4 (Ubuntu) "instabilities with highmem activated (affects: 2) (heat: 508)" [Undecided,New] https://launchpad.net/bugs/633227
<rsalveti> robclark: we have highmem activated, but not using the last 256mb
<rsalveti> when we use it, we can easily get memory issues
<robclark> hmm.. ok, so it is last 256mb that is the issue?
<rsalveti> just try to build a kernel
<robclark> yeah, I've seen the issues..
<rsalveti> yep..
<rsalveti> we got a patch that improved a little bit, but it's still broken
<robclark> ok, yeah.. I saw that.  I just wasn't expecting skipping last 256m would work around the issue.. interesting
<rsalveti> robclark: any idea if x-loader could be the culprit?
<rsalveti> we wanted to test current upstream, but mmc is broken
<robclark> not sure.. I assumed it was highmem, but I don't know enough about highmem to know why it would make a difference, 768 vs 1024..
<rsalveti> robclark: yep...
<rsalveti> from http://lkml.org/lkml/2010/9/8/425 it shows that this issue was happening with others too
<rsalveti> but then with the proposed fix we're still facing issues
<rsalveti> better, but not yet fixed
 * rsalveti brb
<robclark> rsalveti: w/ the cdimage filesystem (with initrd and all that), are there any special instructions to use my own (cross-compiled) kernel?
<robclark> ie. does the initrd need to be updated w/ new modules or anything like that?
<rsalveti> robclark: I'm not that sure if you'll need a new uInitrd, as I generally get the new generated one when I install my package
<rsalveti> if you're running your board already, just install your new kernel package, that's enough to regenerate the initrd.img
<rsalveti> than I believe flash-kernel could do the work of updating it for you
<rsalveti> if the links are correct at /boot
<robclark> hmm.. and if I'm building the kernel on my laptop?
<robclark> ok..  so scp over my uImage and modules, and then run flash-kernel?
<rsalveti> robclark: that's ok, what I mean is that if you plan to install it at your running panda or planning to mount the sd card at your host and then install the package
<rsalveti> oh, what you're planning? to copy the modules by hand or to install the generated deb file?
<rsalveti> I generally run: make -j 6 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CONFIG_DEBUG_SECTION_MISMATCH=y deb-pkg
<robclark> I could do it either way.. whatever is easier..
<robclark> hmm, ok.. there is a deb-pkg make target?
<rsalveti> then scp the kernel-image, dpkg -i, check the link and flash-kernel
<robclark> I guess that is something on the ubuntu kernel?  Or is that in upstream kernel makefiles?
<rsalveti> robclark: yep :-)
<rsalveti> robclark: upstream
<robclark> oh.. cool
 * robclark learns something new every day
<rsalveti> hm..., raining a lot today, if I get off-line that should be the reason
<GrueMaster> swim faster.
<robclark> weather.com says that we might get some rain tomorrow..   then again, the weather rarely does what the forecast says here
 * GrueMaster gets weather updates from Dr. Quid B. Wong.
 * robclark usually finds out about the weather after the fact
 * rsalveti uses the gnome-weather applet :-)
<persia> devilhorns, Earlier you said we had to run gnome-panel: would it not be possible to host indicators and/or menus somewhere else?
<devilhorns> persia, ideally yes ... gnome-panel is very heavy :(
<devilhorns> tho the only other thing I know if is lxde-panel
<devilhorns> or perhaps xfce-panel
<persia> Those share a common ancestor :)
<devilhorns> yea :/
<devilhorns> persia, I'd like to be able to make an efl panel that would be able to host them ... but that means I'd have to dig into the core applet system and figure out how they are expected to be hosted, etc, etc
<devilhorns> lots of issues there :/
<davidm> persia, devilhorns lets not go too crazy here please
<persia> Indeed.
<devilhorns> davidm, hehe indeed :)
<devilhorns> hence why I was just gonna forget about it for now :)
<davidm> that sounds like a natty thing (if at all) :-)
<persia> davidm, No worries.  Just idly chatting about lean and fast :)
<persia> Maybe even natty+
<persia> Very much not maverick
<davidm> persia, don't forget to remind folks that we need blueprint ideas this week, I've told everyone but ....
<GrueMaster> persia: alsa update.  I am able to play audio on beagle using paplay, but not any of the GUI apps (totem, rhythmbox).  I think it is mainly due to memory limitations.
* persia changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? see http://idlethread.blogspot.com/2010/09/cross-compilation-redux.html | Maverick is frozen: start submitting natty blueprints
<persia> GrueMaster, Heh.  Thanks for testing that with paplay though.
#ubuntu-arm 2010-09-22
<GrueMaster> rsalveti: Where is this script for omap4 audio?
<GrueMaster> It isn't in bug 628217.
<ubot2> Launchpad bug 628217 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "No audio output from analog ports on panda (omap4) (affects: 1) (heat: 252)" [High,Confirmed] https://launchpad.net/bugs/628217
<robclark> GrueMaster: amixer.sh?
<GrueMaster> I guess.  I keep hearing about a script to make audio work on the panda analog ports.
<robclark> if rsalveti doesn't beat me to it, I'll fwd in a couple min
<robclark> GrueMaster: http://paste.ubuntu.com/498061/
<robclark> run amixer.sh -a
<GrueMaster> thanks.
<robclark> np
<rlameiro> evening everyone
<GrueMaster> robclark: Still no audio.  Ran sudo sh amixer.sh -a.  Rebooted.  Now nothing shows up in gnome volume control.
<GrueMaster> am I missing a driver?
<robclark> GrueMaster: oh, ok.. maybe still the updated default.pa is needed?
<robclark> hang on..
<GrueMaster> This is a base image
<robclark> GrueMaster: http://paste.ubuntu.com/498064/ is /etc/pulse/default.pa.. and one more coming
<robclark> GrueMaster: http://paste.ubuntu.com/498068/ is daemon.conf
<GrueMaster> Ok.  Will test then add these to the bug report.
<robclark> there is some TI package, I think, that configures everything..
<robclark> and still I think open point about how to do it without overwriting system files.. but that is a known issue I suppose
<GrueMaster> Well, having these attached to the bug report will give the respective developers something to work with.
<robclark> yup
<rlameiro> audio problems too?
<rlameiro> lol
<rlameiro> they are comming
<rlameiro> Evening GrueMaster  :D
<GrueMaster> hello, and welcome back.
<robclark> there is lot of ongoing work for ASoC..  which is making audio a bit painful right now
<robclark> but should make things better for the future
<GrueMaster> yea, I've seen a flood of traffic on alsa-devel mailing list.
<rlameiro> well, i see that i have some serious bugs on the audio setup on igepv2
<rlameiro> but seems to be the same problem with the beagle
<GrueMaster> rlameiro: On beagle, there are a few steps you can take in alsamixer to get audio working.  Mainly unmute DAC2 Analog, HeadsetL Mixer AudioL2 and HeadsetR Mixer AudioR2, and increase volume for Headset and DAC2 Analog.
<rlameiro> i did that on my igep
<GrueMaster> Does "speaker-test -c 2 -t wav" produce audio with those settings?
<rlameiro> but even like that, the driver seems very buggy, as it cant handle big "WORKLOAD"
<rlameiro> GrueMaster: never tried it out with those settings but it should
<rlameiro> my problem is runnig puredata on it
<persia> GrueMaster, robclark: the daemon.conf changes should not be needed.  default.pa is (unless either we find a way to recognise the chip for berco's conf fragment, or the kernel gets fixed)
<robclark> ahh, ok
<persia> Hrm.  Actually, might be able to do something with udev.
 * persia reads more docs
<GrueMaster> Gah.  death by alsa.  After copying the default.pa and running the amixer.sh script, I am now getting kernel segfaults in alsa.
<persia> \o/
 * GrueMaster bangs head in silence.
<persia> So it's obviously a kernel bug.  The kernel isn't supposed to segfault, regardless of what we do with userspace :)
<GrueMaster> I know.
<GrueMaster> Bug 644828
<ubot2> Launchpad bug 644828 in linux-ti-omap4 (Ubuntu) "BUG: scheduling while atomic: alsa-source/2058/0x00000002 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/644828
<GrueMaster> I think we are going to continue seeing these atomic issues in SOC systems until Cortex A9 is out in force and developers can fix their code.
<GrueMaster> Until now, no SOC was multicore, and some of the SOC specific code got a little free with the atomic stuff.
<GrueMaster> It's kind of the same growing pains that plagued x86 before SMP code was completed, just not as severe due to the lack of specific devices.
<GrueMaster> persia: I can verify that with the changes to default.pa and running amixer.sh from ti, I can now playback music in rhythmbox on panda.  Not bad.
<persia> amixer.sh makes up for the fact that 1) the kernel doesn't actually know what to do with it and 2) doesn't even provide enough information to userspace to use a userspace config file.
<persia> default.pa is because 1) the kernel doesn't actually know what to do with it and 2) there currently exist no udev rules to explain (although this may be impacted by the same 2) as for amixer.sh: this remains to be determined)
<persia> Unfortunately, because of the 2) for amixer.sh, we are forced to fix this in the kernel somehow, as the userspace config trick won't work (unless we expect every single user to manually run amixer.sh)
<persia> pulse is differently complicated, but because of how udev works, it may be possible to have a special "panda-pulse-enable" package that handles that.
<persia> (and. absolutely worst cast, that hack package could run amixer.sh in postinst or something)
<GrueMaster> What I have found is that I have had to run amixer.sh after each reboot.
<GrueMaster> Even running it sudo doesn't save state properly.
<persia> Ugh.  That's too painful for words.
<persia> Right.  Kernel patch!
<robclark> GrueMaster: I noticed same issue.. it used to work (saving settings on shutdown) with older internal fs that I had
<robclark> but now I have to re-run script too :-(
<GrueMaster> well, it is after 6:30pm here.  I could be doing this while drinking a beer. brb
<persia> Bother.  Making pulse's module-udev-detect work requires properly poplating sysfs.
<persia> Could someone with a panda check /sys/class/sound/card.../pcmC...../pcm_class and tell me what it contains?
<GrueMaster> generic for all.
<persia> berco, /lib/udev/rules.d/78-sound-card.rules might be interesting to you (let's hope it isn't)
<persia> That's not helpful :(
<persia> Yeah, I think we just don't have enough information in userspace to detect that we want to do special stuff right now :(
<GrueMaster> Anything else I can do for you tonight?  If not I'm calling it a day.  12 hours is enough.
<robclark> persia: http://paste.ubuntu.com/498132/
<persia> GrueMaster, Have a good night.
<persia> robclark, Yep.  That just doesn't give us the information we want to be able to automatically populate something equivalent to http://paste.ubuntu.com/498064/
<persia> specifically the "load-module module-alsa-{sink,source} device=..." lines
<ajay> hi all, i have IGEP board unfortunately i saved wrong uboot parameter on it,now i am not able to boot from flash,sdcard as well not getting prompt on minicom
<persia> You probably have to perform some sort of reset on uboot.  Check the docs for your specific board for low-level recovery instructions.
<persia> For example, some boards allow you to hold down some special button to boot from an alternate bootloader
<ajay> persia, thanks but this board doesnot have any type of button as input
<ajay> there is no recovery mode inside flash
<persia> No idea then.  If you can't boot anything, and have no input/output (serial or console), I'm not sure if we can help much.
<persia> I really think you'd do better with the IGEP distributors (although I may be mistaken, and there are other folk here who have similar boards)
<ajay> persia,ok
<davidm> ajay, it may require the use of a hardware debugger
<davidm> jtag
<ajay> davidm, i have onle serial port console that is minuicm
<ajay> minicom
<davidm> ajay, if your board is: http://www.igep-platform.com/index.php?option=com_content&view=article&id=46&Itemid=55
<davidm> Then it has holes for a JTAG connector and that with special instructions will allow you to reflash the boot system
<robclark> will IGEP boot off of MMC before NAND?
<robclark> (or are there some DIP switch or jumpers to make that so)
<ajay> robbiew, yes it tryies to boot from mmc first
<ajay> then flash
<robclark> then you should be able to put a good bootloader on an MMC card and recover that way
<ajay> i did that as well for this i am getting white screen in LCD and no message over minicom
<robclark> hmm, is that different behavior than booting without MMC card?
<robclark> if so, then you know MMC comes first..
<robclark> then it is "just" a matter of getting a correctly formatted MMC card with good MLO and u-boot.bin..
<robclark> (there are scripts floating around to correctly format the MMC card under linux..)
<furibondox> have you had a similar problem? http://paste.ubuntu.com/498254/
<persia> I haven't seen that reported previously.
<persia> Please file a bug against qemu-kvm-extras-static (assuming you generated that on an Ubuntu system)
<furibondox> yes I've generated that using rootstock
<persia> Was that error produced as part of a rootstock build?
<hrw> morning
<ogra> dmart_, fyi http://forums.computers.toshiba-europe.com/forums/thread.jspa?threadID=56355&start=30&tstart=0
<ogra> dmart_, so general bootloader access is there it seems, but nobody figured out the details
<furibondox> hi ogra
<furibondox> I'm always working with the boot process... I'm very frustrated with the new upstart mechanism (only few times all works fine, other times no: http://paste.ubuntu.com/498292/).
<persia> I don't think upstart is your issue there.
<furibondox> with this asyncronous method seems that some daemons wait something else but I don't understand when and what
<furibondox> persia... I think so, because some times all the boot process goes ok, sometimes no
<furibondox> and the problem is always similar to the one I reported in the pastebin
<furibondox> when the problem occurrs, all devices in /dev have a wrong datetime (01-01-1970) and ownership (root:root)
<ogra> thats with ubuntu kernel ?
<ogra> and does your system have an rtc battery and/or a network connection ?
<furibondox> the rtc is taken from another processor (a secure processor)
<furibondox> so it's good
<furibondox> the problem seems related to the devices generated by udev during the the initrd and the devices in the real filesystem
<furibondox> but I'm using the same initrd of the ubuntu
<furibondox> http://paste.ubuntu.com/498300/
<furibondox> it seems that udev fails to be killed in the initrd??
<ogra> udev is supposed to be carried over from initrd, how did you generate the initrd assuming you use a different kernel
<ogra> also do your kernel config options match with the ubuntu ones
<ogra> if your devices are all tagged 1970 then your rtc part in the kernel that sets it on kernel bringup doesnt work (default in ubuntu)
<furibondox> I copied the initrd from the rootstock using this kernel: http://rcn-ee.net/deb/lucid/v2.6.35.4-l4/linux-image-2.6.35.4-l4_1.0lucid_armel.deb
<ogra> ubuntu sets the rtc dircetly at unpackaing the kernel, if that doesnt work it falls back to ntpdate ... if *that* doesnt work you can still use the fixrtc cmdline option that sets the clock to last mount time of the disk
<ogra> you should recreate the initrd if you use a different kernel
<furibondox> but I don't use any modules...
<furibondox> so the initrd should be the same except that
 * ogra wonders why people always assume initrd is only for using modules
<ogra> i heard that three times this week
<furibondox> I have read all scripts inside the initrd
<ogra> it wont break but will gain you unexpected results
<persia> ogra, leftovers from embedded development models
<furibondox> and they should work with my configuration
<ogra> like for example udev misbehaving with broken RTC :)
<ogra> what HW is that exactly ?
<persia> furibondox, The key bit is not the scripts *in* the initrd, but rather the scripts used to genreate the scripts in the initrd which hardcode certain things depending on the kernel.
<ogra> a standard beagle ?
<furibondox> no
<furibondox> it's not a standard beagleboard
<furibondox> it's a custom board
<furibondox> with omap 3530
<ogra> but you are trying to use a kernel that was compilde from a beagleboard defconfig ?
<furibondox> no
<furibondox> we use our kernel
<ogra> well, the above one surely is
<ogra> rcn-ee kernels are all beagle kernels afaik
<furibondox> I've only used the kernel I said you above in order to generate the initrd with the rootstock
<ogra> ah
<furibondox> only for that
<ogra> how much ram do you have on your board ?
<furibondox> 256MB
<ogra> the plymouth error is likely the ureadahead OOM
<ogra> yeah, that would fit
<ogra> currently uredahead needs more than 256M else it will OOM and tear down plymouth with it
<ogra> (you should actually see OOM messages for both in dmesg)
<furibondox> yesterday i tried also to disable ureadahead and plymounth but the problems remained
<avinashhm> hi, while booting omap4 sdp i am getting this error .."init: ureadahead main process (487) terminated with status 5" ...  any idea what status 5 suggests ??
<ogra> you cant disable plamouth
<furibondox> ogra: yes I saw ;-)
<ogra> avinashhm, that you are using an SD card which it cant sacn
<ogra> avinashhm, or any other flash device
<ogra> avinashhm, that message is fine, its only info, not an error
<avinashhm> ogra, its not related to network ... ?? it hangs after this .. i do nt get the prompt  ....
<ogra> furibondox, try removing ureadahead
<furibondox> ok
<avinashhm> I have removed all nw options from make menuconfig ...
<ogra> furibondox, which prompt on which console ?
<furibondox> just disable in the /etc/init/ureadahead or aptitude purge ureadahead ?
<ogra> i.e. if you expect something on serial, did you make sure serial was enabled during rootstock with the --serial option ?
<ogra> apt-get purgs
<ogra> *purge
<furibondox> ok
<ogra> (why do people always use aptiture is beyond me)
<furibondox> yes I use --serial ttyS2
<ogra> k
<ogra> and thats also the console you are looking at ?
<furibondox> yes
<alf_> ogra: Hi! For a BB xM with possible memory corruptions issues, is "mem=256M" a reliable workaround?
<furibondox> again... my kernel command line is this: rw console=ttyS2,115200e8 vram=5M omapfb.vram=2560K,2560K root=/dev/mtdblock7 rootfstype=yaffs2 lcdType=QVGA mpurate=600 omap_vout.vid1_static_vrfb_alloc=y mem=227M
<ogra> alf_, yes, according to some testers
 * ogra never had these RAM probs on his XM so i cant tell for sure
<alf_> ogra: Great, thanks. Hopefully this will make my BB xM experience more deterministic :)
<ogra> heh
<ogra> i think ricardo uses that option on his XM too
<furibondox> ok now (w/o ureadahead) I've only this error in the boot.log
<furibondox> init: procps main process (3090) terminated with status 139
<ogra> thats an issue with your kernel config
<furibondox> yes, I'm investigate on this...
 * ogra recommends pulling the ubuntu kernel deb and looking at the config file inside
<ogra> enabling devtmpfs is also helpful
<ogra> and there are a good bunch of other options i guess
<avinashhm> ogra, the next statement after the "init: ureadahead main process (487) terminated with status 5" is "Last login: " ... does this need any n/w support ??
<ogra>  "Last login: " ??
<ogra> that looks like you have some kind of autologin going on
<avinashhm> its tells ... Last login time ... and other things right ??
<ogra> that line comes from motd iirc
<avinashhm> yeah ... ubuntu @ ubuntu is logged by default ...
<ogra> n/w = network ?
<avinashhm> yeah ... network ... :-) .. sorry for confusion.
<ogra> network is only needed if you dont have an rtc battery or dont use the fixrtc cmdline option ... to avoid fsck on boot if your last mount time is worng
<ogra> but apparently you dont get an fsck so it all seems fine to me
<avinashhm> i am on AC supply ... so no rtc battery ... and i don't have fixrtc in my bootargs .. may be this is causing the erro r ...
<ogra> which error ?
 * ogra doesnt see an error in any of your questions above
<avinashhm> not error .. the hang .... it hangs after the print "init: ureadahead main process (487) terminated with status 5" ...
<ogra> i thought it gives you an autologin
<avinashhm> yeah ... it give autologon normally ...but when i disable network in menuconfig, it hangs
<ogra> do you disable the NIC or all network support ?
<ogra> indeed, as any linux system ubuntu needs a loopback device
<ogra> so you should have basic networking enabled
<avinashhm> Networking support  ---> Networking options  ---> TCP/IP networking .... whats NIC ?? and loopback ???
<ogra> ugh, why do you play with these options if you dont know what you do ?
<ogra> NIC = network interface card
<ogra> (your network card driver)
<ogra> and loopback is the lo interface lostening for localhost connections on the virtual 127.0.0.1 address
<ogra> *listening
<avinashhm> there are some stability issues ... like system crashes @ rt_worker_func once in an hour or 2 ... so this funciton was tracked to some network file ... route.c ... so we wanted to disalbe that ...
<ogra> some apps expect loopback networking to be available to properly run
<avinashhm> ogra, so no way to boot ubuntu, with network disabled ???
<ogra> well, i dont know
<ogra> but i know that some apps look for loopback
<ogra> X wont start without it iirc
<ogra> not sure about the low level, we never disable TCP/IP in ubuntu kernels
<ogra> so i cant really tell what would happen then :)
<avinashhm> thanks for hlep ogra ... :) ...let me give some more time on this ... and see what happens ..:-)
<ogra> heh, ok
<ogra> persia, did you work with dyfet on the hdf issues ? where is that at ?
<dmart> dyfet: ping?
 * dmart guesses it may still be too early
<ogra> or to late (in care of persia)
<ogra> *case
<ogra> dmart, btw, did you see my ping this morning ?
<dmart> ogra: hmm, guess not.
<ogra> dmart, http://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=218590&#218590 someone found access to the bootloader on the toshiba
<dmart> ogra: (very faintly) pong
<ogra> heh
<dmart> ooo
<ogra> so it seems to be just a matter of time now :)
 * ogra already bricked one, so i'm waiting for others to do the hard work until someone figures out how to change the boot options
<persia> ogra, A little, but doko just -marm'd it, which makes the issue not visible.  I believe dyfet was working on a test case for the underlying toolchain bug exposed in h5detect.
<ogra> dmart, ^^^
<persia> dmart, If you want to investigate, remove -marm, rebuild, and then look at the detection macros in h5detect.
<ogra> persia, there was discussion about bug #635199 in #linaro (why are you not in there ? :) )
<ubot2> Launchpad bug 635199 in hdf5 (Ubuntu) (and 1 other project) "[armel] the ./H5detect test segfaults when built for armv7 (affects: 1) (heat: 315)" [High,Confirmed] https://launchpad.net/bugs/635199
<persia> The code does some things that end up being very ugly for any architecture that can handle more than one instruction set :)
 * persia doesn't currently have attention to contribute to linaro
<ogra> we have a team wide agreement
<ogra> that everyone will be in both channels
<dmart> persia: well, it's ubuntu too :)
<persia> Yao Qi's comment is correct, and matches what dyfet was telling me.
<persia> I should have some spare attention soon, and will be there more :)
<dmart> Hmmm, the .diff.gz is almost twice as big as .orig.tar.gz for hdf5 :O
<dmart> that's a bit scary
<dmart> persia: yes, it doesn't look like a toolchain issue
<dmart> I'm also wondering whether the kernel does something wrong with respect to alignment fixups.
<dmart> (in addition to reporting them as SIGILL...)
<persia> That's a deeper question than I can answer: best wait for dyfet.
<dmart> sure
<dmart> no problem
<persia> h5detect is a good way to exercise alignment issues though :)
<dmart> :)
<ogra> wow software-center is really a myth
<ogra> i wonder if the design team is aware that they overengineerd a bit here :)
<dmart> how do you mean
<dmart> more than less /var/lib/apt/lists/*Packages ?
<ogra> well, i'm just testing a few things in it
<ogra> and i dont find it very intuitive
<ogra> i.e. trying to install all of OO.o i indeed click on the metapackage
<ogra> which only gets me an "update now" button (that in the backend seems to run apt-get update)
<ogra> you actually have to click on something like "openoffice writer" and then select the metapackage under "addon packages"
<dmart> hmmm, that sounds weird... surely installing the metapackage that ought to suck in everything?
<ogra> yes, it does, but only if you pick one of the sublevel packages and check a box
<dmart> hmmm
<dmart> I would have thought "install it all" would be a sensible default for inexperienced users
<ogra> heh, yeah
<ogra> i'm probably to experienced to understand it though
<ogra> who knows :)
 * dmart shrugs
<ogra> ah, seems to actually be a bug :)
<ogra> phew
<sebjan> ogra: hi! we finally found a problem in the u-boot currently beeing used (we were searching into MLO, but the issue was u-boot). Basically, u-boot overrides the pin-mux settings done in MLO, and miss some recent pin-mux updates. Who shall I speak to for defining the best way to fix this issue and get it integrated? sakoman?
<ogra> sebjan, 1st a bug against u-boot-linaro 2nd yes, sakoman and 3rd we need to talk to slangasek and jcrigby to include the fixes in the package
<sebjan> ok, thanks
<sebjan> sakoman: we have this issue with the linaro u-boot used on omap4: bug 645167
<ubot2> Launchpad bug 645167 in u-boot-linaro "omap4: u-boot overrides pin-muxing settings from x-loader (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/645167
<ogra> eek
<ogra> you filed it in the upstream project :)
 * ogra triages properly
<lool> that's ok
<lool> as long as it indeed affects the git repo  :-)
<ogra> lool, well, both, git and the package :)
<ogra> i do care more about the package in maverick though :)
<ndec> ogra: hi... any chance we could upgrade systemtap to 1.3 for 10.10 or this is way too late? it's in universe.
<ndec> lool: ^^^^
<ogra> ndec, what does maverick have atm ?
<ogra> we can surely try
<ndec> ogra: 1.2
 * ogra hopes 1.3 is in debian
<ogra> it gets tricky if it isnt, should be easy if it is
<ndec> ogra: the 1.3 release notes mention they add support for .35, 1.2 is supposed to work up to .34... i am surprised that was not catched since 10.10 is on .35
<lool> ndec: Given that systemtap is not seeded, it would seem possible
<lool> ndec: We could take it from Debian experimental
<lool> ndec: Did you try the 1.3 as packaged?
<lool> ndec: if you could copy the 1.3 source into some non-virtual PPA and confirm the source built under maverick produces working binaries, that would help
<ogra> lool, oh, it is in experimental ? awesome
<ndec> lool: no... we just realized that 1.2 does not work on omap4 with .35. right now I am still unsure if it's because of systemtap of because of our scripts.
<ogra> that makes it easy
<lool> ndec: Would be nice if you could track this in a bug and report results of your testing of 1.3 as packaged
<ogra> ++
<ndec> lool: ok. will open a bug, and we will do testing today or tomorrow ... so it's still possible to get something in 10.10... wouah.. I thought it was too late.
<lool> ndec: TBH new upstream releases are not the kind of things we're looking for at this point of time, but if you say systemtap is unusable with maverick kernels, it's a good reason to include it; <201009171327.17913.ubuntu@kitterman.com> has the detailed timeline for universe packages not on any media
<ogra> ndec, i would have set the bug to critical, but then i end up in discussions with lool again about bug status :) "high"+milestone means its very important to have it fixed befoire release, critical would mean it affects everyone using ubuntu (which is not true)
<ogra> mpoirier, yo
<mpoirier> ogra: wazup !
<ogra> mpoirier, seems there is another bug with the IEGP2 that affects networking
<ndec> mpoirier: hi... did you get your new wild animal?
<rsalveti> and it seems to be fixed already for linaro's kernel
<mpoirier> ndec: yes, thaming it right now.
<rsalveti> just saw the bug
<ogra> mpoirier, and it seems linaro has a fix for it ... but i have no idea how it would affect other omap3 arches ... see bug 618734
<ubot2> Launchpad bug 618734 in linux-linaro (Ubuntu Maverick) (and 2 other projects) "[omap/igep] No eth0 with Linaro kernel (affects: 1) (heat: 106)" [High,Fix released] https://launchpad.net/bugs/618734
<mpoirier> ogra: hold on.
<ogra> (i guess the main question here is why doesnt it work as a module though)
<rsalveti> ogra: yep, doesn't sound like a correct fix for me
<ogra> ++
<ogra> but seems to be a workaround if it doesnt affect other oamp3 subarches
<rsalveti> yup
<ogra> and i'm not sure about the latter
<rsalveti> ogra: do we have one igepv2 around in our team?
<ogra> nope, only linaro has them
<rsalveti> seems lool has one
<rsalveti> got it
<ogra> right and some other folks in the linaro team
<rsalveti> jo-erlend: maybe you could also help us testing this issue
<rsalveti> jo-erlend: you said at the other bug that you don't have your eth0 working
<jo-erlend> rsalveti, right. I have both wlan and wired on my board, but none of them is working.
<rsalveti> for wireless the cause is probably missing firmware
<rsalveti> for wired it seems that a workaround is to move the config to built-in
<rsalveti> still need to understand why this fixed the issue
<jo-erlend> what does that mean?
<mpoirier> ogra: sorry for the delay - took me a while to find a wrothy tree.
<mpoirier> ogra: It may help with some arch but affect others.
<ogra> yeah, thats what i feared
<mpoirier> ogra: I'd like to have an explanation for what the real effect of turning off CONFIG_FIXED_PHY has.
<mpoirier> ogra: i.e, why it's fixing the problem on some arch and not others.
<ogra> ask on the bug, i just stumbled over the fix in linaro (well, lool pointed me to it)
<mpoirier> ogra: looks like a work around to me.
<ogra> after i had seen the request in the other bug you filed a merge request for
<jo-erlend> rsalveti, "move the config to built-in"?
<ogra> yes, its surely just a workaround
<rsalveti> jo-erlend: currently the kernel is generating a module for your ethernet adapter
<rsalveti> the workaround is to move to built-in
<hrw> I have good news - armel cross compiler 4.5 landed in ubuntu (gcc-4.4 is on a way)
<ogra> hey you didnt post that to #ubuntu-motu (but in every other dev channel)
<jo-erlend> rsalveti, ok.. I have no idea how to do that though. :)
<hrw> ogra: I am not on ubuntu-motu
<hrw> 'd
<ogra> but all universe developers are
<ogra> ;)
<rsalveti> jo-erlend: it's easy, we're just discussing if we're able to have this change to our kernel
<rsalveti> but first we need to understand why it's needed
<jo-erlend> oh, ok. Can you tell me how to do it? :)
<rsalveti> jo-erlend: you'll need to recompile the kernel, not that hard to do it, but takes a while
<ogra> especially on omap3
<rsalveti> if you want, I can easily generate a new uImage for you
<jo-erlend> rsalveti, that'd be nice. Thanks.
<rsalveti> based on the kernel package I sent you
<jo-erlend> perfect.
<ogra> ndec, lol, you commented on the wrong bug :)
 * ogra was wondering which steve you are talking to in the systemtap bug
<sakoman> ogra, sebjan: I will prepare a u-boot patch for the panda pinmux corrections
<ogra> sakoman, yeah, i saw the bug comment, thanks a loit
<ogra> *lot
<sebjan> sakoman: thanks!
<sakoman> I was told that omap4 wasn't a priority, so I've kept all omap4 stuff on the back burner
<ogra> huh ?
<rlameiro> morning/afternoon/evening all
<ogra> its our highes prio in ubuntu
<rlameiro> really?
<ogra> *highest
<sakoman> ogra: from a linaro perpective
<rlameiro> omap4 is the fuzz :D
<ogra> we're not linaro here :)
<ogra> <- ubuntu.arm
<sakoman> understood, but my direction comes from linaro ;-)
<ogra> bah, we should also pay you then :P
<rsalveti> haha :-)
<sakoman> works for me
<sakoman> ogra: patch is basically ready, but there is one pad I need to research a bit more
<ogra> ok
<sakoman> the panda x-load sets a few pins more than once
<sakoman> and not the same each time :-)
<ogra> we'll need to get it into the package too which will add some delay
<sakoman> so I need to look at the schematic and see if that is just a screwup or might be intentional
<rsalveti> sakoman: cool, thanks for working on it :-)
<ogra> ++
<ogra> yeah
<sakoman> you might notice that I have a few other omap patches in my omap4-dev branch
<sakoman> they are still being tested and may be tweaked a bit
<ogra> useful for us ?
<sakoman> some of them
<ogra> (if we need an upload anyway i would indeed like them in the package)
<ogra> oh, and note that we use linaros u-boot in ubuntu :)
<rsalveti> yep, to have all these new patches we would need it first to go to linaro's tree
<rsalveti> then a new release and then a package update
<sakoman> I was just giving a "heads up" that new omap4 stuff was pending
<ndec> ogra: can I remove a comment from launchpad...
<rsalveti> sakoman: cool, will take a look at the tree :-)
<ogra> ndec, nope
<sakoman> mistype above -- omap4-exp brnach is the right one
<sakoman> branch :-)
<ogra> ok, i dont know where jcrigby pulls from currently though
<ogra> for omap4
<sakoman> I don't wither :-)
<sakoman> either! jees I can't type this morning!
 * ogra hands sakoman some good brazilian coffee
<sakoman> 7am is too early
<jcrigby> u-boot stable is just -rc1 plus a few patches for vexpress and mx51
<rlameiro> sakoman: coffe man
<jcrigby> omap is just upstream
<sakoman> I'm drinking a brazilian/guatamalan blend (home roast)
<ogra> jcrigby, omap4 :)
<ogra> jcrigby, we'll need a fix for bug 645167 in your package
<ubot2> Launchpad bug 645167 in u-boot-linaro (Ubuntu Maverick) (and 2 other projects) "omap4: u-boot overrides pin-muxing settings from x-loader (affects: 1) (heat: 10)" [High,New] https://launchpad.net/bugs/645167
<jcrigby> I see that
<ndec> ogra: lool: we tested with systemtap 1.3 from experimental, our scripts compile again... the problem is related to a kernel trace API change that requires systemtap update. even on x86...
<ogra> ndec, can you note that on the bug (especially the successfull test)
<ogra> i'll care for the rest
<ndec> ogra: it's done already!
<ogra> oh, cool, my mail is slow today :)
<ndec> ogra: only tested on OMAP4, but given the problem we have it's very likely that x86 has the same problem
<ndec> ogra: cool ;-) can you please let me know when you pull it in maverick?
<rsalveti> sakoman: cool, some interesting patches
<rsalveti> sakoman: new mmc driver, hm
<rsalveti> saveenv for SDP4430
<sakoman> could work for panda on sd card too
<sakoman> but would require raw partition
<rsalveti> got it
<ogra> right, i guess its mainly for the blaze eMMC
<rsalveti> yup
<ogra> we plan to support that
<ogra> so we shoudl get these patches too
<fredim> Hi, I'm following https: / / wiki.ubuntu.com / ARM / BeagleServerInstall
<fredim> I do the dd command, but nothing is copied to my sdcard
<fredim> mmcblk0 what is?
 * ogra curses ....
<ogra> damned, the panda installs to fast
<ogra> i was testing an oem-config fix and indeed i turned away the second where i should have watched now i need to start over
<ogra> (the preparation takes longer than the install actually)
<ogra> ndec, please build slower boards !
<ndec> ogra: well... this should be easier than the opposite ;-)
<ogra> fredim, you need to adjust the command to match your device name indeed
<ogra> fredim, some MMC controllers name them sdb or sdc or so, some (the real MMC controllers) name them mmcblk
<ogra> easiest is to watch dmesg when you plug in the card
<ogra> that should show the name
<sakoman> argh! git meltdown :-( lost some of my patches in omap4-dev :-(
<sakoman> ogra, rsalveti: while I recover, you can review the pinmux patch here:
<sakoman> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=56b18c5248a1478b6d6263e428ada02af174df77
<rsalveti> ouch
<rsalveti> sure
<lool> sakoman: You might be able to recover them if you can dig into the git repo
<sakoman> lool: yeah, doing that now
<lool> searching for files modified recently in the objects dir for instance
<sakoman> otherwise will need to recreate them
<fredim> 1 - Plug SDcard in my notebook and use "sudo dd if = / part / to / img / file of = / dev/mmcblk0"
<fredim> 2 - take sdcard, place in BeagleBoard
<sakoman> lool:  I build with OE, so I have a copy of the most recent state of the tree.  I would just need to recreate the patch sequence
<fredim> plug in the keyboard and monitor BeagleBoard, then connect the power supply
<fredim> correct?
<ogra> fredim, /path/to/image/file needs to be a real path, /dev/mmcblk0 needs to match the SD card device name in your laptop
<fredim>  / Dev/mmcblk0 symbolics
<fredim>  / Media / disk files sdcard
<rsalveti> sakoman: cool, at least it's setting the same values as x-loader
<fredim> 3 directories are mounted
<rsalveti> sebjan: could you also check at http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=56b18c5248a1478b6d6263e428ada02af174df77 ?
<rsalveti> ndec: ^
<rsalveti> should fix the pin mux at u-boot
<sakoman> rsalveti: that was the intent, right? :-)
<fredim> you recommend me some good howto?
<ogra> fredim, so you are sure your device is /dev/mmcblk0 ?
<rsalveti> yup :-)
<fredim> yes
<ogra> and what is the path to the img file you downloaded ?
<ogra> starting from /
<ndec> sakoman: your patch should apply on top of uboot-linaro-stable which is used by ogra for panda, right?
<ogra> thats the plan, yeah
<sakoman> ndec: I would expect so
<fredim> /home/ubuntu-10.04-server-armel+omap.img
<ndec> sakoman: ok. we will give this a try. sebjan will confirm if it works.
<fredim> sudo dd if=/home/ubuntu-10.04-server-armel+omap.img of=/dev/mmcblk0
<sakoman> ndec: thanks!  I couldn't test becasue my panda is broken at the moment
<fredim> but nothing is copied to SDcard
<rsalveti> sakoman: ouch, your es2?
<sakoman> rsalveti: yes -- the serial port connector broke :-(
<sakoman> I need to do some surgery later today
<ndec> sakoman: what do you mean at the moment ;-)
<rsalveti> ouch, not good for a u-boot/x-loader developer
<sakoman> rsalveti: indeed
<ndec> sakoman: the problem with the wrong pin mux was only affecting bluetooth, not sure if you have the firmware for this. do you?
<sakoman> no, I don't
<sakoman> so all the more reason for you to test :-)
<rsalveti> jo-erlend: could you test http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v3 ?
<ndec> sakoman: rsalveti: so we should cherry pick this patch on top of current uboot-linaro-stable, right? this is a better test, no/
<rsalveti> jo-erlend: i just removed CONFIG_FIXED_PHY from our config
<rsalveti> ndec: yep
<ndec> rsalveti: do you build it native or cross in general?
<rsalveti> currently I'm building most of my things in a native environment
<rsalveti> my panda es2 6 layer is doing a good work, with an usb disk :-)
<ndec> rsalveti: cool. root FS on SD and you build on USB? or root FS on USB?
<ogra> fredim, are you sure ? the command is definitely ok
<ndec> rsalveti: USB flash stick or USB external disk?
<rsalveti> ndec: rootfs on usb
<rsalveti> external disk :-)
<ogra> fredim, oh, you need to make sure the card is not mounted before running dd
<rsalveti> 100gb, 7200 rpm
<ndec> rsalveti: do you have scripts/instructions to install daily .img on USB? it shouldn't be too hard, and we were about to write such instructions... but if they exist already ;-)
<fredim> So, after successfully copying. what is the next path?
<ndec> rsalveti: how long for kernel build? full .deb?
<ogra> ndec, 2.5h
<rsalveti> ndec: usually 2 hours for omap4 and 3 for omap3
<rsalveti> less modules I guess
<ogra> ndec, mount SD, mount USB disk, cp -a ?
<ndec> rsalveti: 2 hours for omap4 means that USB is faster than SD, since we are in the 2.5+ hours range
<ogra> ndec, then add the UUID of the USB disk to boot.scr
<rsalveti> ndec: currently I'm not using the daily img, just a very simple rootfs built with rootstock
<ogra> and modify /boot/boot.script after booting and run flash-kernel
<rsalveti> without X11 and stuff
<ndec> ogra: remember I said instructions would be simple ;-)
<rsalveti> to be just a build machine
<ogra> ndec, that were all instructions :)
<ndec> ogra: can we run the installer from USB. e.g. cp -a everything before running the installer, and then add root=/dev/sda, and let it go?
<ogra> neno
<ogra> ndec, no
<ogra> you need to do the install on SD
<ogra> then do the above
<ndec> ogra: why?
<ogra> because its designed like that currently
<fredim> ogra.. So, after successfully copying. what is the next path?
<ogra> fredim, boot your beagle
<ndec> ogra: if we keep the boot partition on SD, flash-kernel should work as expected. the resize should be able to resize the USB disk too, no. then you should retrieve the UID of the USB and put this in boot.scr. what is missing?
<fredim> sdcard shot the notebook, I put in BeagleBoard, correct?
<ogra> ndec, if we wanted to install to USB we shouldnt have gone with a preinstalled image ... i'll try to either add such functionallity to the exiting preinstalled image in natty or just make the ubuntu installer work
<fredim> orbarron, sdcard shot the notebook, I put in BeagleBoard, correct?
<fredim> sry... orbarron
<ogra> fredim, right
<sebjan> sakoman: looking at your patch, we had not identified a misalignment on PAD1_FREF_CLK3_REQ, but on PAD0_FREF_CLK4_OUT ? Can you please confirm?
<fredim> I connect usb BeagleBoard -> notebook?
<ndec> ogra: well... good point...
<ogra> ndec, the prob is that what you want to do is exactly what ubiquity does, i wouldnt maintain a preinstalled image for that (but for the cost of a 10x slower installation)
<ogra> ndec, we can discuss live images with installer for panda at UDS
<ogra> one way or the other i would like to see USB rootfs support too
<ndec> ogra: by the way what triggers the resizer? are you parsing root= and if there is no UUID, you resize and update boot.scr?
<fredim> ogra, I turn BeagleBoard on the notebook via USB cable?
<ogra> its just not clear yet which way
<ogra> ndec, right
<fredim> ogra, or just turn on my monitor and keyboard in BeagleBoard?
<ogra> fredim, depends how your beagle is configured, if you use the lucid image you will likely need a serial console to tell it the right boot commands
<rsalveti> sebjan: it's different because u-boot is setting it for LED
<ogra> lucid relied on the preinstalled bootloader on the beagle
<ogra> ndec, though boot.scr is updated from a different script than the resizing
<ogra> ndec, we have one srcipt only for configuration, the other one has the dangerous pieces (i.e. resizing)
<fredim> ogra, theoretically BeagleBoard sdcard should ride with, but in my dmesg shows nothing.
<ndec> ogra: ok.. sometimes I boot manually and overide the bootargs and use mmblk0p2... and I could see the resizer was run again!
<ogra> fredim, well, if it boots you should see something on the screen thats attached to the board
<ogra> ndec, then you didnt run the oem-config bit
<jo-erlend> rsalveti, I just have to replace uImage, nothing else?
<ogra> ndec, that removes the resizer (jasper-initramfs) at the end
<fredim> ok
<fredim> thanks
<sebjan> rsalveti: ok, for both pins?
<ndec> ogra: no the installer was run only once. but later on when I want to enable console, I change bootargs by hand, and this is when I used mmcblk...
<ogra> ndec, well, it is definitely gone if you rean the configuration tool (the graphical bit)
<rsalveti> sebjan: yep, FREF_CLK4_REQ is the first led and FREF_CLK4_OUT is the second one
<ogra> there is no way it could start
<ogra> since its not there anymore :)
<ndec> ogra: well, not sure what happens, but if I install the cdimage, then reboot and change root= to mmcblk0p2 by hand, then reboot it fails since UUID has changed.
<ogra> ndec, if you see it after running the graphical installer up to the point where it drops you into a desktop then something is definitely screwed up during your installation
<rsalveti> jo-erlend: please let me know if the newer uImage works for you, because then we can forward the change to our kernel
<ogra> the last bit of the graphical installer removes jasper-initramfs and re-rolls your initrd
<ogra> if you see it resizing something *after* that (while using the newly created initrd), then we have a bug
<ndec> ogra: can you try this on your side? i am pretty sure that I did this. i don't have a setup ready right now. the only thing I did was booting with setenv bootargs console=ttyO2,115200n8 ro elevator=noop vram=32M mem=460M@0x80000000 mem=256M@0xA0000000 root=/dev/mmcblk0p2 fixrtc, and booting without uinitrd.
<jo-erlend> rsalveti, the first partition keeps getting wiped. I copied your new uImage and the boot.ini file, but it won't boot. Do I still need uInitrd?
<ogra> ndec, i need a working install for that, i'm currently testing oem-config patches, but i guarantee you that there is no tecnical possible way that any part of the resizing tool remains after a successful install
<rsalveti> jo-erlend: yep, you just needed to overwrite your uImage with this one
<rsalveti> and you still need to use the uInitrd
<jo-erlend> well, there was nothing to overwrite. All contents of the first partition is deleted every time I reboot the board.
<rsalveti> jo-erlend: ouch
<rsalveti> that's definitely a bug, not sure where
<GrueMaster> jo-erlend: Are you rebooting or are you letting the resize process reboot the system?
<jo-erlend_nb> GrueMaster, I'm rebooting.
<rsalveti> if you still have jasper installed at your system it could be that it's affecting you somehow
<GrueMaster> Let the script run it's course.  Part of what it does is copy off the first partition to ram, reformat for proper CHS allignment, and move everything back.
<ogra> ndec, without uInitrd ?
<ogra> ndec, the resizing happens *from* uInitrd
<ogra> its not possible that you saw any resizing at all without using it
<ndec> ogra: ok.. let me do this again. and I will let you know. i am not 100% sure of what I did
<ogra> ndec, in any case the resizer lives inside the uInitrd :)
<ogra> since we keep a backup of the old initrd around it could possibly happen if you use the uInitrd.bak file for booting
<ogra> but surely not without
<jo-erlend_nb> GrueMaster, that might be the case. After the first boot, I had to manually resize rootfs.
<jo-erlend_nb> rsalveti, I still have no network. It sais "usb0: no such device". I tried setting up eth0, but that gave me the same results.
<GrueMaster> jo-erlend: I would suggest you let it boot and monitor the console.  It should reboot in ~10 minutes depending on the size & speed of your SD card.
<ogra> and CPU :)
<ogra> pnada install just fly by nowadays
<GrueMaster> ogra: Same as beagle.
<rsalveti> jo-erlend: please paste me your lsmod output
<ogra> (apart from tehg SWAP creation)
<jo-erlend_nb> rsalveti, I cannot paste from it since I have no network. Is there anything in particular you're looking for?
<GrueMaster> ogra: Is there any way we can have the swap creaded during image build?  It is a zero filled file, should compress to almost nothing.
<ogra> GrueMaster, yes, but it will require some heavy changes to the build scripts ... i'm scared ...
<rsalveti> jo-erlend_nb: try loading module smc911x
<GrueMaster> I've seen the build scripts.  Fear is justified.
<rsalveti> see if it makes any difference
<jo-erlend_nb> rsalveti, just "modprobe smc911x"?
<rsalveti> jo-erlend_nb: yep
<ogra> GrueMaster, i'm trying to leverage if its better to just live with 2-3min for SWAP creation or risk the build system
<ogra> its very late for such a change
<jo-erlend_nb> rsalveti, no change.
<rsalveti> jo-erlend_nb: ifconfig -a?
<rsalveti> that's weird
<ogra> cat /proc/net/dev
<ogra> (lower level than ifconfig)
<jo-erlend_nb> ogra, that only gives me lo
<ogra> then your kernel definitly doesnt know about other interfaces
<rsalveti> jo-erlend_nb: check dmesg | grep -i smsc9 , see if your kernel says something about it
<jo-erlend_nb> rsalveti, smsc9 or smc9?
<jo-erlend_nb> well. Neither returned any results.
<sakoman> rsalveti, ogra, jcrigby:  I think I've recovered from my git meltdown, omap4-exp branch should be OK now:
<sakoman> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-exp
<sakoman> feedback/test results most welcome
<rsalveti> jo-erlend_nb: http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v4 new kernel, with the same changes from linaro
<jcrigby> sakoman, thanks
<sakoman> jcrigby: I'm sure there will be tweaks this week as I spend some time testing and tracking down a few issues
<rsalveti> sakoman: cool, expansion stuff is now in
<jcrigby> rsalveti, is there sru info for the panda pinmux problem?
<sakoman> rsalveti: it is in, but performance needs improvement and there is an i2c error message that shows up on beagle but not overo
<sakoman> rsalveti: I'll be investigating this week, but let me know if you find fixes :-)
<ogra> everybody who is intrested (and jcrigby indeed) i just switched the oma3 images to linaros u-boot as well
<ogra> *omap3
<jcrigby> sakoman, latest git looks much better, I was wondering why no new mmc for beagle
<ogra> so we sue it on all images now
<ogra> *use
<jcrigby> ogra, so now when I break u-boot everything breaks:)
<ogra> jcrigby, we'll be the first to complain, yeah :)
<rsalveti> jcrigby: bt and wlan doesn't work with current u-boot for omap4, so that should fill the sru
<sakoman> jcrigby: something went wonky while I was pushing the pinmux patch
<rsalveti> ogra: cool
<ogra> test image should be ready soon
<ogra> (its building since a while already)
<GrueMaster> ogra: will this be 20100922.1?
<GrueMaster> or a private test image?
<rsalveti> jo-erlend_nb: smc911x is the wrong module, smsc911x should be the correct one =\
<rsalveti> but the latest uImage should have the correct one as built-in
<rsalveti> if it works for you than we need to understand why the module wasn't loaded by default
<ogra> GrueMaster, 20100922.1 (i only rebuilt omap3, omap4 will just be copied from 20100922)
<GrueMaster> Ok.  I had just finished pulling 0922.  Shouldn't take too much to pull with zsync.
<sakoman> rsalveti, jcrigby, ogra: let me know whe you are happy with the testing of the pinmux patch and I will submit upstream
<sakoman> it would be good to get the fix in this release
<sakoman> (v2010-09)
<rsalveti> sure
<rsalveti> but I guess we're depending on ndec and sebjan, as we don't have the bt and wlan firmware
<ogra> ndec, so fyi, i tried what you proposed (with and without initrd and also by only switching root= from UUID to the device name) and i do not get any resie here
<ogra> *resize
<ogra> you must have done something really weird or the install didnt finish properly before you made that change
<ndec> ogra: ok... i am sure I have seen the UID change at some point. I had to generate a new boot.scr with the new UID which I took when mounting the SD on my pc.
<ndec> ogra: just installed unity on my laptop... and i am lost...
<ogra> well, as i said above there is no techinically possible way resize runs again after a successful install run
<GrueMaster> rsalveti: We should test it anyways to make sure it doesn't break something else.
<ogra> ndec, i havent tried it since UDS :)
<ogra> ndec, i think you are supposed to use the search bar a lot with it
<rsalveti> GrueMaster: sure, I just mean that we're unable to test if it actually fixed what we wanted :-)
<GrueMaster> agreed.
<rsalveti> ogra: http://paste.ubuntu.com/498575/
<rsalveti> I believe this should be enough to get the correct headers for the dkms module
<ogra> yeah
<rsalveti> and I added linaro headers as an alternative
<ogra> right, thats how it should be
<rsalveti> will push & test
<rsalveti> let you know about the result
<rsalveti> then I believe we should be fine
<ogra> ok
<ogra> i'll put uploading them to the archive and filing the bugs on my TODO for tomorrow
<rsalveti> cool
<ogra> with luck we'Re ready by weekend :)
<rsalveti> nice!
<ogra> there are still bits to solve with the sw-center stuff, if thats done you can make up some thoughts about a nice icon for the driver install stuff :)
<ogra> we'll need something on the desktop
<rsalveti> hm, ok
<ogra> oh, and one of the postinsts needs some hack to remove icon and .desktop file
<ogra> (in your packages)
<ogra> ndec, see PM
<rsalveti> sure, that's fine
<sebjan> rsalveti, sakoman, jcrigby: I just tested the patch, on top of the ubuntu u-boot package, and it fixes the BT issue!
<jcrigby> sebjan, thanks
<ogra> perfect !
<rsalveti> sebjan: awesome, thanks!
<jcrigby> rsalveti, bug #607250
<ubot2> Launchpad bug 607250 in linux-linaro (Ubuntu) (and 2 other projects) "omapdss: VDDA_DAC regulator on IGEPv2 (affects: 2) (dups: 1) (heat: 24)" [Undecided,New] https://launchpad.net/bugs/607250
<jcrigby> I need to grab that from ubuntu once it gets there right?
<jcrigby> rsalveti, grab you latest patch I mean
<rsalveti> jcrigby: yep
<ogra> jcrigby, it should be in some tree already
<ogra> there was a pull request on the kernel ML
<rsalveti> you can find it at my tree, the one from the pull request
<jcrigby> ogra, rsalveti, I have link to your tree
<rsalveti> http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/fix-igepv2-display
<rsalveti> jcrigby: do you have an igepv2 around?
<rsalveti> if so then you could also help testing them
<jcrigby> rsalveti, no but some other linaro guys do
<rsalveti> otherwise I'd wait for an answer from our kernel team
<jcrigby> ok, once I see it in a released ubuntu kernel I'll cherry pick it from there
<rsalveti> jcrigby: hm, ok, would be nice to test them on top of linaro's kernel
<jcrigby> rsalveti, I'll see if torez can test it, she has an igep
<rsalveti> nice
<sakoman> sebjan: thanks for confirming your test results!  I will submit the patch to upstream u-boot list today
<sebjan> sakoman: great, thanks!
 * rsalveti out for lunch
<ogra> GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100922.1/ is there
<GrueMaster> Ok, pulling.
<ogra> mpoirier, looking at bug 644828, shouldnt we keep the sound work on bug 637947 ?
<ubot2> Launchpad bug 644828 in linux-ti-omap4 (Ubuntu) "BUG: scheduling while atomic: alsa-source/2058/0x00000002 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/644828
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 432)" [High,Confirmed] https://launchpad.net/bugs/637947
<sakoman> sebjan: I just posted the patch to the u-boot list.  if you could respond with a "Tested-by" it would help move it into mainline more quickly!
<ogra> it really seems we fragment a lot here
<mpoirier> ogra: I'm not *actively* working on 644828.
<ogra> mpoirier, but you research the sound problems on panda
<mpoirier> ogra: i'm concentrating on 637947.  Fixing that one will most likely help fixing the other one.
<mpoirier> yes, that's what I'm doing 12hrs a day.
<ogra> mpoirier, right, i was just wondering if it wouldnt be easier to keep all sound prob info in one bug, i'm not doubting your workhours :)
<ogra> it fells a bit scattered to me
<sebjan> sakoman: sure, can you CC me please?
<mpoirier> ogra: We need several bugs as it is extremely complex to address bugs within other bugs.
<ogra> ok
<mpoirier> ogra: as long as we all know sound on panda is taking care of.
<mpoirier> ogra: to the best of my knowledge, there is no way in lp to file bugs under and umbrella subject, that could be 'sound' in our case.
<mpoirier> ogra: /s/and/an/g
<ogra> you could add a tag but that wont help much
<ogra> what i usually do is just add a comment with a link to the other bugs
<rsalveti> sebjan: and about that weird issue you saw with our x-loader? the one that could be a compiler issue, any time to debug it?
<sebjan> rsalveti: it's the same issue. We were suspecting an issue in x-loader
<sebjan> rsalveti: ... since this is where I expected the pinmux to be done...
<orbarron> hey all is there anyway to get the dailybuild for 20100914?
<rsalveti> hm, ok
<sakoman> sebjan: done
<ogra> orbarron, nope, thats gone
<ogra> orbarron, why would you want such an old build ?
<orbarron> looking for an environment that will be tested thoroughly... will all omap4 stuff :D
<GrueMaster> orbarron: I have a copy for omap4 only.
 * orbarron has a copy but thought the dailybuilds would be archive somewhere :D
<GrueMaster> But I wouldn't go as far as saying "thoroughly tested".
 * orbarron did not want to load up a build on another server
<ogra> orbarron, daylies dont recive much testing and such an old daily will have a lot more bugs than a recent one
<ogra> orbarron, use zsync to keep them up to date :)
<ogra> orbarron, the 14 build is way worse than anything recent
<GrueMaster> iirc, oem-config was borked on it pretty badly.
<ogra> no, that was the one after 14
<ogra> or two of them
<ogra> after that it improved daily
<rlameiro> mpoirier: are you into making a ubuntu-arm-sound group?
<ogra> actually todays is pretty close to being good
<ogra> (not perfect, but good)
 * orbarron is looking for an environment that I can send new users to that will 1. work 2. is available to public 3. is tested with MM, GFX, etc.. so far I believe that will be 20100914? Plz correct me if I am wrong
<mpoirier> rlameiro: what a good idea !
<ogra> orbarron, dailies are movimg targets
<rlameiro> mpoirier: i would glady help on what i can
<ogra> orbarron, and we dont test them much, wait for RC
<mpoirier> rlameiro: but I was wondering if it couldn't be something like linux-omap-sound...
<rlameiro> I have an idea for a project that will greatly benefit from it
<mpoirier> opinion anyone ?
<rlameiro> well, i just have one card to test...
<ogra> orbarron, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100922.1/ this one is really good, but it still has bugs
<ogra> orbarron, and it will be wiped in two days
<rlameiro> if someone is into send me more caqrds i will hapily receive them :D
<ogra> mpoirier, i wouldnt make it arch specific
<ogra> once you have the bugs fixed it will be dead
<ogra> while the team moves on to new HW and has new sound bugs
<mpoirier> ogra is correct - we will work with other processor, ubuntu-sound it is.
<ogra> i think ubuntu-sound exists
<rlameiro> isnt there already a grup like that?>
<ogra> i thought you wanted something arm specific
<rlameiro> crimsums group or something?
<ogra> persia usually knows details about such groups
<mpoirier> ubuntu-sound now exists - go for it.
<ogra> hmm
<ogra> you might clash with an existing group
<ogra> which is probably differently named
<rlameiro> well, the thing its that arm sound is far away from the other archs..
<ogra> right
<mpoirier> ok, i'll fix.
<ogra> thats why it shoudl have arm in its name
<rlameiro> arm is ok, mmaybe not omap just...
<ogra> and we should find out what that general sound group is :)
<rlameiro> but on the description explain that for now is omap oriented
<ogra> to work together, since they mainly maintain the packages (alsa, pulse, jack etc)
<rlameiro> mpoirier: when ogra said to dont lock to archs I think he meant ARM sub archs, like tegra omap, imx5 etc
<mpoirier> how do I delete my own group ?
<ogra> rlameiro, yeah
<ogra> mpoirier, #launchpad might know
<devilhorns> if I install lucid, can I still run a "rootstock" for maverick ?
<GrueMaster> devilhorns: You will need to pull rootstock manually.  The lucid version has issues iirc.
<rlameiro> devilhorns: i did it
<devilhorns> GrueMaster, ok, but it can be done right ?
<GrueMaster> yes.
<rlameiro> just need to put -dist maverick
<rlameiro> *--dist maverick
<devilhorns> ok, looks like I may need todo a reinstall then :/
<devilhorns> GrueMaster, thanks
<mpoirier>  #ubuntu-arm-sound has been created
<rlameiro> persia: ping
<GrueMaster> rlameiro: It is 2am where he's at.
<rlameiro> ahhh, ok
<rlameiro> australia?
<rlameiro> well, someone in here knows how to put an ubuntu bot on a ubuntu related channel?
<GrueMaster> Tokyo.
<ogra> mpoirier, err, an irc channel ?
<ogra> mpoirier, a) we have policies for that, you need to talk to the IRC council ... and b) it would be better to keep the IRC discussion in one place (here)
<davidm> devilhorns, the board powers from USB :-)
<devilhorns> davidm, gotcha :) just figuring that out now w/ ogra :)
<devilhorns> so I pretty much have everything then ... except the powered usb hub, which I can proally pick one up @ a local store here
<davidm> devilhorns, yea, I think most folks with a beagle use a powered hub
<devilhorns> davidm, yea :) he mentioned the power drain from keyboard when using the board via usb-mini ... so I'll have to run out to store today/tonight and grab a powered hub
<devilhorns> not a big deal
<GrueMaster> devilhorns: Eventually you might want to get a cable like this:  https://specialcomp.com/beagleboard/DSCN0401_s.JPG
 * ogra calls it a day
<devilhorns> g'night ogra :) thanks again
<GrueMaster> It costs $8.  Or you can make one.  Real simple.
<devilhorns> GrueMaster, not really into making my own cables ... they always shoot sparks :P
<GrueMaster> heh.
<GrueMaster> If you get a powered hub, make sure the PS is at least 2A.  I have one that is 1000mA and it is just not enough.
<devilhorns> ahhh good to know, thanks :)
<GrueMaster> And if you can find a powered hub with ethernet, it makes life even simpler.
<devilhorns> yea, that certainly would make life easier :)
<GrueMaster> For the serial port, I am using a serial cable that came with a motherboard with an internal port header.
<GrueMaster> At any rate, here is a link for a supplier that has good accessories.  https://specialcomp.com/beagleboard/order.htm
<devilhorns> gotcha ... yea I may have one of those floating around here somewhere ... lord knows I have enough MBs laying around here from previous integration work
<GrueMaster> Mine came from an old 486 before it found the e-Recycling bin.
<devilhorns> hahaha
<Neko> ogra, what exactly do you need from me re the permissions problem, I can get you the passwd stuff, but do you need anything else?
<Neko> I can just drop you the entire archive, or a portion?
<GrueMaster> rsalveti: Have you tried the mini-usb port on the ES2 yet?
<GrueMaster> Nevermind.  It isn't even enabled in the kernel.
 * GrueMaster files a bug.
<Neko> oh neat maverick is frozen frozen??
<rsalveti> devilhorns: cool, got your board?
<devilhorns> rsalveti, yea :) missing some items to actually make it work, but I'll go out tonight and grab em from a local place
<GrueMaster> rsalveti: Can you mark bug 645420 as confirmed?  thanks.
<ubot2> Launchpad bug 645420 in linux-ti-omap4 (Ubuntu) "OTG port not enabled for OMAP4 (affects: 1) (heat: 8)" [Low,New] https://launchpad.net/bugs/645420
<Neko> rsalveti, rcn-ee, have you guys built rootstock images with desktops and had oem-config-gtk run correctly, /var/lib/gdm permissions correct etc.? is it just me that is seeing this??
<rsalveti> argh, my notification system is still broken :-)
<rsalveti> devilhorns: cool, now you can test it on arm :-)
<rsalveti> GrueMaster: let me check
<rsalveti> Neko: last time I tested I used the console oem-config
<rsalveti> Neko: what is the issue you're facing?
<devilhorns> rsalveti, yea, when I get the rest of the stuff I need to be able to run the board :)
<rlameiro> I can i askt for the same IP address, but still have dhcp activated? for instance, only gets a different address if the default cant be given by thr router?
<GrueMaster> devilhorns: Make sure you use a >=4G SD card.  Image is 2.2G atm.
<devilhorns> GrueMaster, indeed :)
 * rlameiro spelling sucks
<GrueMaster> Anything I can tell you before you head to the store?  Want to make sure you have a proper shopping list.
<devilhorns> don't think so ... only thing I am really missing is the usb powered hub
<GrueMaster> rlameiro: I have my DHCP server set to assign the same IP based on mac.
<rlameiro> buy a cheap usb sound device:D
<rlameiro> that small thingies that cost 3 usd
<rlameiro> or something
<rlameiro> GrueMaster: my router isnt so advanced :D
<GrueMaster> rlameiro: Why?  Sound works on beagle.
<rlameiro> GrueMaster: testing :D
<devilhorns> eh, not really needed in my case ... not going to be using it for any games or anything :) just need it to build the efl arm packages really
<GrueMaster> rlameiro: You mean it isn't running linux?
<rlameiro> GrueMaster: i almost sureit runs linux, but i dont want to fiddle with it, it haves a telnet connection...
<ogra_ac2> devilhorns, well, you could play quake, we have it in the archive and rsalveti just packaged the GL drivers *g*
<rsalveti> for sure you could use it for games ;-)
<GrueMaster> Or just run with the aalib drivers.  :P
<devilhorns> ogra_ac2, lmao ... who has time for games ? :)
<ogra_ac2> heh
<armin76> ogra_ac2: bought another ac100? :D
<ogra_ac2> armin76, no, the wlan disconnects often
<GrueMaster> More likely broke another.  :P
<armin76> heh
 * GrueMaster hides.
<ogra_ac2> and that android client just attaches numbers it seems
<ogra_ac2> GrueMaster, nah, i'm waiting for someone to hack teh bootloader
<ogra_ac2> i wont risk that again
<ogra_ac2> though it seems they are close
<ogra_ac2> (someone managed to pull the partitions down via nvflash)
<armin76> replace with omap4? :D
<jayabharath> Does Ubuntu on OMAP have a project registered on launchpad.net -- if so what's the URL... (Somehow I think https://launchpad.net/ubuntu/+source/linux-ti-omap is not the right URL)
<ogra_ac2> jayabharath, no we dont have a project
<ogra_ac2> well, we do, its ubuntu :)
<jayabharath> Mmm.. I see. But, bugs can be logged at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap ??
<ogra_ac2> depends what the bug is
<ogra_ac2> the bugs should be targetd for teh specific package it is in
 * jayabharath is new to launchpad and its confusing...
<ogra_ac2> just use ubuntu-bug to file them
<jayabharath> how will me average joe know where to log omap kernel bugs, bugs on omap ppa pacakges... and also on ubuntu packages... please advice
<ogra_ac2> they wont
<ogra_ac2> the average joe will get an automatic popup if there is an oops
<ogra_ac2> which walks you through
<jayabharath> That presumes board has not reset or network is functional.. :)
<ogra_ac2> a developer will use: ubuntu-bug linux
<ogra_ac2> for omap3
<ogra_ac2> and ubuntu-bug linux-ti-omap4 for panda
<ogra_ac2> even without network it will collect crash info in /var/crash
<ogra_ac2> and tell syou wnt to do with it
<jayabharath> great...
 * jayabharath looks for a wiki page that tells this
<ogra_ac2> i think there is one
<ogra_ac2> persia ususally has the urls up his sleeve
 * ogra_ac2 searches
<jayabharath> no worries.. I will search for it.. I am sure there is something on ubuntu.co
<jayabharath> m
<ogra_ac2> help.ubuntu.com/community/ReportingBugs
 * jayabharath bows to ogra_ac2 and thanks him
<ogra_ac2> heh, just thank google :)
<rsalveti> bug 628029
<ubot2> Launchpad bug 628029 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "[maverick] panda ES1.0 does not suspend on beta image (affects: 1) (heat: 167)" [High,Confirmed] https://launchpad.net/bugs/628029
<rsalveti> lag: ogra: ndec: this bug was created for ES1, but does any of you know if CONFIG_PM works for ES2?
<GrueMaster> rsalveti: I would just try it.  Worst case is that it fails (I hope).
<rsalveti> yep, building a new kernel
<GrueMaster> I think there was mention of work needed to be done for suspend to work properly and it was waiting on ES2.1.
<rsalveti> hm
<pirearadu> hy all
<pirearadu> i can install ubuntu arm on my samsung omnia i900?
<GrueMaster> It would take a lot of work, but you can try.  Bear in mind that Ubuntu is currently working on supporting Arm Netbooks, not cell phones.
<pirearadu> but
<pirearadu> ubuntu for cell phones exists?
<GrueMaster> not that I know of.
<hrw> pirearadu: i900? jaunty (9.04) may work if you have kernel
<pirearadu> yea
<pirearadu> i900
<pirearadu> what kernel hrw?
<armin76> :D
<hrw> pirearadu: ubuntu does not support i900. if you want to run ubuntu on it you need to have kernel which will run on it.
<hrw> pirearadu: if this is still black magic for you then forget about ubuntu on i900
<pirearadu> i know that
<pirearadu> but
<pirearadu> what kernel i need?
<hrw> the one which works on i900 - thats simple
<hrw> how to get it and from where is other thing
<ogra_ac> we should probably also stop suggesting jaunty, given its only supoprted for another 4 weeks
<hrw> ogra_ac: or generally: if you do not have (list of all 4 supported boards) then you out of luck?
<ogra_ac> nah, then rootstock wouldnt make sense
<ogra_ac> but jaunty will be EOL very soon
<persia> NCommander, For qreal issues: isn't it best to instantiate for literals and declare correctly for members?  I'd think casting ought be avoided (potential for precision loss, etc.)
<rlameiro> well, out of the channel :D
<rlameiro> persia: the idea was to make a group really
<rlameiro> not a channel
<persia> Why does it need a group?  What does it do that isn't achieved by ubuntu-audio and ubuntu-arm?
<persia> How does this group increase collaboration and cooperation?
<rlameiro> well, that was the disvution
<rlameiro> discusion
<rlameiro> i think that the problem is that, for now, there are some bugs arm related
<rlameiro> and i dont think there are to much people interested in fix them
<persia> I'll agree with that, which is why I'm against a new team or channel.
<persia> Since there are only a few people currently interested, it makes sense to have the discussion in a broader area, so that knowledgeable folks who aren't especially interested can help share their expertise.
<rlameiro> so, better inter communication beetween ubuntu-sound and ubuntu-arm?
<rlameiro> i shal tag the bugs to ubuntu-sound also then
<persia> I'd rather "more overlap between ubuntu-audio and ubuntu-arm", but better communication may help if that fails.
<persia> Please don't.
<persia> See https://wiki.ubuntu.com/DebuggingSoundProblems for how to triage the sound bugs.
<persia> And be aware that the goal of that team is to address everything in the kernel, so ALSA just works, and everything on top of that just works.
<persia> We may still have some issues with stuff like mad or pd, but it's more likely those will end up being solved by the ARM team or flavour teams, rather than the audio team.
<rlameiro> persia: but i am not using an ubuntu kernel, i am using rcn-ee one
<persia> Ubuntu can only support Ubuntu kernels.  To the best of my knowledge, rcn-ee regularly pushes patches into Ubuntu.
<persia> So, if you want to solve this in an Ubuntu context, the target goal should be to get it working with an Ubuntu kernel.
<rlameiro> persia: is there an easy way to install an ubuntu kernel inside my board?
<persia> Make sure flash-kernel does the right thing for you.
<rlameiro> for instance if i install it where is the uImage and uInitrd
<persia> Then apt-get install linux-omap (or whatever)
<rlameiro> flash-kernel?
<persia> Yep.
<rlameiro> never heard of it..
<rsalveti> rlameiro: you can easily install it by giving apt-get or downloading the deb and giving dpkg -i
<rsalveti> flash-kernel will replace your uImage and uInitrd with the new one
<persia> rsalveti, Do you know this works for IGEPv2?
<rsalveti> at the first partition
 * persia is fairly certain flash-kernel is device-specific
<rlameiro> i have them on my fat partition
<rsalveti> should work, I believe, but nobody tested I guess
<rlameiro> ok
<rlameiro> here i go
<rlameiro> testing freenzy
<rsalveti> if doesn't work, fill a bug :-)
<persia> rlameiro, If you want to check the script first: install the flash-kernel package, and look at /usr/sbin/flash-kernel
<rlameiro> I should make a backup :D
<rsalveti> otherwise install your package, generate the uImage and uInitrd with mkimage and copy them to the first partition
<persia> (shouldn't that really be in /sbin, rather than /usr/sbin ?)
<rlameiro> weird
<rlameiro> flash-kernel isnt neither in sbin or /usr/bin ...
<persia> apt-get install flash-kernel
<persia> rsalveti, Maybe rootstock should encourage people to include flash-kernel?
<rlameiro> persia: i did that already :D
<persia> And you don't have /usr/sbin/flash-kernel?
 * persia is very confused
<rlameiro> no
<rsalveti> depends, as our current support at flash-kernel is not that good
<rlameiro> oops
<persia> rsalveti, Shouldn't we fix that :)
<rlameiro> sorry
<rsalveti> and generally rootstock should be recommended for hardwares that we don't officialy support
<rlameiro> i didnt look at usr/sbin
<rlameiro> just /usr/bin
<rlameiro> its a binary
<persia> rsalveti, Especially as ARM kernels converge, we'll find that the set of supported hardware grows wider than is well-understood.
<persia> Specifically, the set of supported hardware is the set of hardware supported by kernels in Ubuntu plus any bugs anyone wants to fix :)
<persia> rlameiro, From what I've heard, you probably want to install linux-linaro-omap rather than linux-omap for IGEPv2, but you might try each, and see which you like better.
<rsalveti> we have bugs on both
<persia> Not surprising :)
<rsalveti> the only difference is that at linaro's the ethernet is working
<rsalveti> I sent the patches to fix the display, but not applied yet
<persia> Really?  Maybe I should try that: might make the internet on my board work.
<rsalveti> persia: do you have an igepv2?
 * persia decides to stop IRCing until there is enough awakeness to not mistype "ethernet" as "internet"
<persia> rsalveti, Nope: beagleboard
<persia> C4
<rsalveti> but the ethernet fix at linaro's is related with igepv2
<rlameiro> rsalveti: there is comming more work from igepv2 side
<rlameiro> they are to launch their expansion board
<rsalveti> I'd like to get one for testing, but needs to find a way to buy it
<rlameiro> LCD/VGA/compositevideo etc etc
<rlameiro> well, ask them to send 2 or 3 to canonical
<rsalveti> could be :-)
<rlameiro> well, true is that it is on their interest
<rsalveti> sure, will send an email later :-)
 * rsalveti out for while, football game :-)
<rlameiro> persia: flash kernel outputs "unsuported platform....
<persia> rlameiro, It's a shell script: tell it how to store the kernel for your board, and file a bug :)
<persia> (this is how platforms gret supported)
<rlameiro> well, i wish i had the kwoledge
<persia> Which part of the shell script don't you understand?
<rlameiro> just started reading it
<persia> I'm certain you'll be able to figure out most of it, and I suspect that asking here will cause others to help you.
<rlameiro> persia: http://pastebin.ubuntu.com/498796/
<rlameiro> maybe its in here on this case
<rlameiro> i need to add IGEPv2 to it
<rcn-ee> actually the igepv2 will be under omap.. in that script there should be a "beagle" case
<rlameiro> http://pastebin.ubuntu.com/498798/
<rlameiro> it check for proc cpu info
<rcn-ee> there should be "OMAP3 Beagle Board" check (from cat /proc/cpuinfo)
<rlameiro> this is mine
<rlameiro> and in hardware it is not the omap but igep :D
<rlameiro> that is my cpuinfo cat http://pastebin.ubuntu.com/498798/
<rcn-ee> yeap mine is that too... i forget where in flash-iamge it happens..
<rlameiro> but from what i see it copy it to the NAND, is that right?
<rlameiro> because i dont want to mess with the nand
<rlameiro> ...
<rlameiro> i prefer to copy it by hand to the partition
<rcn-ee> in the beagle case (lucid defaulted to nand) and with maverick mmc is first i think...
<rcn-ee> i'd really use mmc, less likely for bricks by new users...
<rlameiro> well I dont know shell script, so i will not mess with it..
<rlameiro> i think i will copy it by hand
<GrueMaster> If you have a fat partition, you can create /etc/kernel-img.conf file and add UBOOT_PART=<fat partition> entry.
<rcn-ee> rlameiro, here you go.. add the IGEVP2 machine id to this list: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/flash-kernel/maverick/annotate/head:/flash-kernel#L306
<GrueMaster> Sorry, /etc/flash-kernel.conf is the file.
<GrueMaster> It contains two lines, one for UBOOT_PART= and one for root=.
<rlameiro> beagle routine
<rlameiro> http://pastebin.ubuntu.com/498802/
<persia> If you set UBOOT_PART, that routine should just work.  The trick would be in ensuring that IGEPv2 boards trigger that routine.
<rcn-ee> rlameiro, this http://pastebin.com/2RWdavzp on top of https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/flash-kernel/maverick
<GrueMaster> The way flash kernel works now, if you are using our kernel and have /etc/flash-kernel.conf created, the script should work fine.  It looks for specific hardware based on grep Hardware /proc/cpuinfo.  Failing that, it uses uname -r.
#ubuntu-arm 2010-09-23
<rlameiro> ok
<rlameiro> i will do that in a moment, girl needs atention...
<persia> rlameiro, So you want to add to the massive case statement near where it says "OMAP3 Beagle Board" an entry for your machine, which calls check_subarch "omap"
<persia> rcn-ee, That alone isn't enough: one should also add something around line 668
<rcn-ee> oh right...
<rcn-ee> http://pastebin.com/JUD5ZQpJ ;)
<GrueMaster> http://paste.ubuntu.com/498807/
<rcn-ee> i almost think for maverick +1 maybe the nand usage in that omap_flash_kernel could be dropped and just default to mmc?
<GrueMaster> rcn-ee: Heh.  Same idea.
<persia> Either one.  Now get someone to test it, and get it attached to a bug :)
<rcn-ee> if rlameiro system is still up, he could manually patch it.. and then try running it. .;)
<persia> rcn-ee, My personal preference is to boot from NAND, and have MMC available for secondary boots for testing, etc.  Mind you, I use USB storage anyway.
<rlameiro> rcn-ee: i came back
<rcn-ee> yeah, it's nice for your own embedded systems, we got tons of rma's with incorrect nand on the beagles. ;)
<rlameiro> going to open second ssh and edit it with nano
<persia> rcn-ee, Oughtn't one be able to just boot off MMC and recreate NAND to work around that?
<persia> rlameiro, Rather than using nano, could you use patch?
<rlameiro> where do i found my partitions
<rlameiro> persia: well i can try, but i am not experienced
<persia> `cd /usr/sbin; sudo patch < /tmp/flash-kernel-patch;`
<persia> Just download one of the patches before you do that.
<rlameiro> so i edit a different version and then patch it?
<rcn-ee> yeap... that's exactly how i fixed most of the returns and sent back to the customers. ;)
<rlameiro> so only this patch?
<persia> rlameiro, You shouldn't have to edit anything at all.
<rlameiro> http://paste.ubuntu.com/498807/
<rcn-ee> yeap, that one is good..
<rlameiro> /usr/sbin/flash-kernel: 671: Syntax error: word unexpected (expecting ")")
<GrueMaster> Oops.  Add a | before \ on line 25 of patch.
<rlameiro> missing a pipe lol
<rcn-ee> actually 671, needs a space.. like; "OMAP3 Beagle Board" | "IGEP v2 board")
<rcn-ee> btw, has anyone tried using rootstock on maverick x86 to build a maverick dist with any xfce4 based packages?  it worked this afternoon for me, so maybe the old qemu bug has fixed it self?
<rlameiro> why the "\"? its to tell that the line continues?
<GrueMaster> yes.  Makes it more readable.
<rlameiro> so it stays "|\" or "| \" ?
<GrueMaster> second option
<GrueMaster> space is good.
<rlameiro> Reversed (or previously applied) patch detected!  Assume -R? [n] -R
<rlameiro> Apply anyway? [n] y
<rlameiro> Hunk #1 FAILED at 149.
<rlameiro> Hunk #2 FAILED at 319.
<rlameiro> Hunk #3 FAILED at 665.
<rlameiro> 3 out of 3 hunks FAILED -- saving rejects to file flash-kernel.rej
<rlameiro> do i need to make a diff?
<GrueMaster> No.  Did you try to edit the patch and apply it to a clean flash-kernel?
<rlameiro> nope
<rlameiro> to the alreday patched one
<GrueMaster> Ok.  edit the flash-kernel script directly.  Fix line 670.
<GrueMaster> You can only apply a patch once.
<rlameiro> is there a way to revert a patch?
<rcn-ee> -R (with same patch)
<rlameiro> ok
<GrueMaster> sudo patch -R < <patchfile>
<rlameiro> U-Boot partition not found, using Nand.
<rlameiro> The Kernel doesn't fit in flash.
<rlameiro> so i need to add the partition to the file?
<rcn-ee> assuming it's mmc add UBOOT_PART=/dev/mmcblk0p1 to /etc/flash-kernel.conf
<GrueMaster> Yes.  create /etc/flash-kernel.conf with two lines:
<GrueMaster> UBOOT_PART=<partiotion for uImage & uInitrd>
<GrueMaster> root=<root partition>
<rcn-ee> GrueMaster, looking thru flash-kernel, what uses root=?
<rcn-ee> or is the boot.scr creater script pulling that..
<GrueMaster> might be.
<GrueMaster> It could also be a hold over.
<rcn-ee> it's new in my book, that's why i wondering.. ;)
<GrueMaster> flash-kernel is something I think was pulled from Debian.
<rlameiro> so what do i put on the root?
<rcn-ee> yeap i remember it well specially when it first came into lucid... (quit touching my flash..)
<rlameiro> /dev/mmcblk0p2?
<rcn-ee> yeah, that looks good..
<rlameiro> fingers cross
<rlameiro> lol
<rlameiro> same error
<rlameiro> do i need to reboot?
<rcn-ee> no...
<rcn-ee> is it the same line?
<rlameiro> where? on the flash-kernel.conf?
<rlameiro> no separated files
<rcn-ee> line 671/2
<rlameiro> rcn-ee: its like this
<rlameiro> rcn-ee: i just made into one line and the output is the same
<rcn-ee> i actually think it's line 671... make sure there is spaces: "OMAP3 Beagle Board" | "IGEP v2 board"
<rlameiro> yes ther is
<rlameiro> check this line
<rlameiro> omap_flash_kernel() {
<rlameiro> 	if [ -n "${UBOOT_PART}" ]; then
<rlameiro> 		echo "Using u-boot partition: ${UBOOT_PART}" >&2
<rlameiro> do i need to pass it as an argument ?
<rcn-ee> it pulls that from /etc/flash-kernel.conf
<rlameiro> like flash-kernel -n /dev/mmcblk0p1?
<rlameiro> where? i dont see where does it loads the variable
<rcn-ee> flash-kernel runs ". /etc/flash-kernel.conf" the variable gets loaded...
<rcn-ee> line 290/295
<rcn-ee> config="/etc/flash-kernel.conf"
<rlameiro> lol
<rlameiro> i was actually editing kernel-info.conmf
<rlameiro> lol
<rlameiro> kernel-img
<rlameiro> yay
<rlameiro> rcn-ee: so now reboot?
<rcn-ee> maybe? did it print out everything okay, and is a new uImage in /boot/(mmc1)
<rlameiro> well it booted
<rlameiro> but now i dont have network
<rlameiro> yep uname-a confirms
<rcn-ee> those should have loaded.. i think ubuntu se them as built -in...
<GrueMaster> Sorry, flash-kernel doesn't change that.
<GrueMaster> :P
<rlameiro> its the linaro kernel 2.6.35.1005-linaro-omap
<rlameiro> GrueMaster: but the kernel does :D
<rlameiro> cant do lspci also
<GrueMaster> At any rate, if you can file a bug on launchpad.net against flash-kernel, I'll attach my (updated) patch and we can roll it in.
<rcn-ee> found my notes.. the igepv2 needs the smsc911x as built-in...
<rlameiro> o mannnnnn
<rlameiro> so i need to reverse this?
<GrueMaster> No.  (not flash kernel at least).
<rlameiro> yeah
<rcn-ee> something about u-boot setting up the pins and ussing it, therefor it can't be used setup as a module?
<rlameiro> but my kernell
<GrueMaster> But if you file a bug on it, I can get my patch rolled into the package.
<rcn-ee> rlameiro, you were using my kernel before right?
<rlameiro> pcilib cannot open /proc/bus/pci
<rlameiro> yes rcn-ee
<rlameiro> GrueMaster: i would like to do so, no network on the device :D
<rcn-ee> first check in your /mm1 there might bee a "uImage_old/bak" "uInitrd_old/bak"
<rlameiro> rcn-ee: flash-kernel said it make a backup
<GrueMaster> flash-kernel should have moved them to uI*.bak
<rlameiro> i also made a backup before doing this :D
<rcn-ee> 2nd you can bypass flash-kernel with adding "FLASH_KERNEL_SKIP=yes" to /etc/flash-kernel.conf (untill upstream has the kernel fix)
<GrueMaster> Or alternatively, you can type "flash-kernel <kernel version>"  (i.e. flash-kernel 2.6.35-22-omap)
<rlameiro> what is the command to rename on the cli?
<GrueMaster> That will move whatever test kernel you are using onto the uboot partition (as long as the kernel is installed in /boot).
<rcn-ee> i just 'mv' to rename...
<GrueMaster> Use mv <old> <new>
<rlameiro> ok
<rlameiro> i think it should be the other way around
<rlameiro> it boot the same kernel
<rlameiro> and maybe i lost the bak...
<rcn-ee> if you did mv uImage uImage.bak you did..
<rcn-ee> does your wifi work?
<rlameiro> no
<rlameiro> i did first the back
<rlameiro> but it actually asked something about permissions
<rlameiro> i just press enter
<rlameiro> my wifi doesnt work, i need to instal the libertas drivers
<rlameiro> well, maybe using sudo mv helps... duh!!!
<rlameiro> so GrueMaster i file the bug and you post the patch?
<GrueMaster> Yes, please.
<rlameiro> lp #645659
<ubot2> Launchpad bug 645659 in flash-kernel (Ubuntu) "flash-kernel doesn't work with the IGEPv2 board (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645659
<rlameiro> do you need some of my files?
<rlameiro> i can send them to you GrueMaster
<rlameiro> dropbox :D
<rcn-ee> "cat /proc/cpuinfo" should be enough..
<GrueMaster> Nope, this is enough.  Now to work my magic.
<GrueMaster> Yes, add /proc/cpuinfo to the comments.
<GrueMaster> Then I can assign it to ogra.  Might even attach the patch before he notices.  :P
<rlameiro> you should attach it
<NCommander> persia: not if you cast up to double. I should have made that clear :-/
<rlameiro> GrueMaster: why wit for ogra ?
<GrueMaster> testing the annoyance factor.  Guess I'll play nice.  :P
<GrueMaster> Patch attached.  If you could now comment that the patch was tested ok, we should be done here.
<rlameiro> GrueMaster: the patch has an error
<rlameiro> it misses 2 spaces around a "|"
<GrueMaster> This is the fixed one.  I tested it already.
<rlameiro> case "$machine" in
<rlameiro> -			"OMAP3 Beagle Board")
<rlameiro> +			"OMAP3 Beagle Board"|"IGEP v2 board")
<rlameiro> I changed it on mine
<rlameiro> maybe they arent needed, it was rcn-ee idea
<GrueMaster> Hmm.  Will check.
<persia> NCommander, In terms of code clarity, for all architectures, why would you want to do that?  Isn't it cleaner to rely on system qreal to be as expected?
<GrueMaster> rlameiro: Ok, fixed (again).
<rlameiro> rcn-ee: so what is needed to put the kernel working with my hardware?
<rlameiro> i cant debug some audio issues withou network
<rlameiro> and i cant file bugs against the kernel/alsa against your kernel...
<GrueMaster> persia: I have received a new XM board.  It works and audio is currently in the same state as the beagle.
 * rlameiro looks at a nice paradox....
<rcn-ee> rlameiro, according to my notes, i had to move CONFIG_SMC911x=m to y and CONFIG_SMSC911X=m to y.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/revision/90  (and haven't changed that config since..)
<rlameiro> GrueMaster: http://launchpadlibrarian.net/56291674/IGEP-add.patch
<rlameiro> it appended the second patch to the other
<GrueMaster> rlameiro: You can always file a bug using apport-cli --save=<PATH> and it will save the bug report to disk for transferring to another system.  Then you can sneaker-net it to your desktop/laptop.
<rlameiro> GrueMaster: not that, i want my ssh
<rlameiro> and also test some configs with GUI over ssh -X
<GrueMaster> grr.
<rlameiro> no network, no gain
<rlameiro> rcn-ee: so its dependent on the kernel team?
<GrueMaster> keyboard issues.  Accidently hit >> instead of > when creating the patch file.
<GrueMaster> phat phingers.
<rlameiro> hihi
<rlameiro> fixed now
<rlameiro> i checked it
<GrueMaster> Well, prepare for a lot of lp-spam.  Sorry about that.
<rcn-ee> yeap, they'll need a bug, i'd ping lag or mpoirier to help get it pushed..
<rlameiro> its on a different mail :D
<rlameiro> rcn-ee: so i need to file another bug?
<rlameiro> lol
<rcn-ee> yeap.. ;)  that's why i have my external tree, i don't really wait for anyone..
<rlameiro> well, i guess i can do the flash-kernel, file the bug withh apport-cli and then reveret the kernel
<persia> GrueMaster, Thanks for the confirmation, as unfortunate as the result is.
<GrueMaster> persia: The only bit is the kernel tweaking for enabling the right channels.
<rcn-ee> and one more board down.. ;)  so who wants to do the devkit8000, it needs some dss2 fixes..
<GrueMaster> I mean unmuting.
<persia> rlameiro, Which kernel are you using?  Have you tried both linux-omap and linux-linaro-omap?
<rlameiro> just linaro
<rlameiro> should i try the not linaro one?
<persia> GrueMaster, Should be easy.  Up for writing a patch? :)
<persia> rlameiro, Since there are two kernels that ought boot on your board, if you try both, you'll know if one works better than the other for you :)
<GrueMaster> Not tonight.  I have a headache.  :P
<GrueMaster> Is this a kernel patch for alsa?
<persia> rcn-ee, In terms of moving from a module to a built-in, shouldn't udev be loading the modules at boot?  I know there's an issue with some storage modules, but those aside.
<persia> GrueMaster, Would be ASoC, but ends up passing through the ALSA tree.
<rcn-ee> persia, i can't find the link... but i believe it has something to do with u-boot setting up and tieing to the device.. so once the kernel loads... well's it's kinda already setup...
<GrueMaster> Hrm.  will have to look at the code.
<persia> rcn-ee, If you're pushing enough patches to the kernel, you could ask for commit access, rather than maintaining an external tree :p
<persia> rcn-ee, Ah, Ugh.  That's an annoying situation :(  My concern is that we might not want it built-in for some omap kernels: can you think of a case where we might not need it?
<rcn-ee> well right now only two little ones are mine, the rest are other beagle users and that big TI sgx thing which i don't have copyright. ;)
<persia> Having copyright isn't important, if you have license to redistribute.  If you don't have license to redistribute, please don't :)
<rcn-ee> (and we are in the omap merge for 2.6.37 i'm submitting those tomorrow..)
<rcn-ee> persia, well what i meant, they are GPL 2.. it's just they are TI's so there is no point in my pushing..
<persia> Depends on to where you push :)  If you were trying to maintain a perfect Ubuntu kernel, you might find it useful to push to Ubuntu.  For pushing to linux-omap proper, indeed, better to just encourage the authors to push there.
<rcn-ee> well the important bits i do ping the ubuntu guys. ;)  some of it is expermental and too risky for ubuntu.. (like dspbridge stuff that just went into 2.6.36)
<rlameiro> persia`404 error W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.35-22-omap_2.6.35-22.32_armel.deb
<rlameiro>   404  Not Found
<rlameiro> cant test it
<persia> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.35-22-omap_2.6.35-22.33_armel.deb replaces it.
<persia> Run apt-get update :p
<rlameiro> well toolate
<rlameiro> filing for the linaro one :D
<rlameiro> how do i see the kernel PID?
<persia> kernel doesn't have a PID.
<rlameiro> even 0?
<persia> PID 1 is init, which is usually upstart.
<persia> I think 0 is undefined, but I don't really understand the specifics.
<rlameiro> ok
<rlameiro> always learning :D
<persia> Yep :)
 * GrueMaster heads out for a bit.
<rlameiro> rcn-ee: lp #645684
<ubot2> Launchpad bug 645684 in linux-linaro (Ubuntu) "linux-linaro kernel, doesnt boot with support for the LAN interface (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645684
<rlameiro> another bug :D
<rlameiro> looking now for the linux-omap one :D
<rsalveti> rlameiro: this bug is a duplicate of 618734
<rsalveti> bug 618734
<ubot2> Launchpad bug 618734 in linux-linaro (Ubuntu Maverick) (and 2 other projects) "[omap/igep] No eth0 with Linaro kernel (affects: 2) (dups: 1) (heat: 108)" [High,Fix released] https://launchpad.net/bugs/618734
<rsalveti> this should be fixed with latest linaro's kernel
<rlameiro> ok, linux omap is going to have another
<rlameiro> or should i not report this?
<persia> rsalveti, Except rlameiro just tested with the latest linaro kernel, and it didn't work...
<rsalveti> persia: not the latest
<persia> rlameiro, Probably not worth having two bugs: you can mark that bug "Also affects" if you can reproduce in the other kernel.
<persia> rsalveti, The "latest" isn't in the repos?
<rsalveti> 2.6.35-1006.11 should be the latest, not 2.6.35-1005.10
<persia> rlameiro, Would you try .11 :)
<rlameiro> well, maybe i should do an update before installing that
<rlameiro> yes i will
<rsalveti> well, the bug was closed by Launchpad Janitor, so I think the deb should be at our repo
<rlameiro> but the last linux omap is not working either
<rlameiro> and this I am sure is the last
<rsalveti> rcn-ee: for me is weird that changing CONFIG_SMC911x=m to y and CONFIG_SMSC911X=m to y fixes the problem
<rsalveti> it should work the same way as module and built-in
<persia> Well, unless uboot does odd things.
<rsalveti> probably a kernel bug
<persia> But, yeah, the kernel has a bug, and ought be able to do bring-up whether u-boot did or not.
<persia> Most certainly a kernel bug.
<rlameiro> rcn-ee's kernel brings the interface up
<rsalveti> because the config is set as built-in
<persia> rlameiro, No it doesn't: it assumes it's up.
<rsalveti> but I first wanted to understand it better before submitting a patch
<persia> rsalveti, You're going to end up buying an IGEPv2 :)
<rsalveti> persia: I'm just sending an email requesting one :-)
<rlameiro> with linaro and linux-omap kernel, lspci brings up an error
<rsalveti> and thanks for the flash-kernel patch :-)
<rlameiro> i didnt made the patch :D
<rlameiro> it was rcn-ee GrueMaster and persia
<rlameiro> i just tested it realtime... almost
 * persia didn't do it :p
<rlameiro> lp #645689
<ubot2> Launchpad bug 645689 in linux (Ubuntu) "linux-omap cant bring up eth0 on igepv2 board, no network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645689
<rlameiro> well, no a break before testing the last linaro kernel
<persia> OK.  That should be a duplicate to 618734, which should have both limux-linaro and linux-omap tasks.
<rlameiro> the kernel source is the same ?
<rlameiro> mine has more info :D
<rlameiro> rsalveti: sorry, but the latest version is linux-image-2.6.35-1005-linaro-omap
<rlameiro> .10 not .11
<rsalveti> hm, that's weird, we should be able to find 2.6.35-1006.11
<rsalveti> let me find the sources from launchpad
<rlameiro> the .11 is not supported by canonical
<rlameiro> it is there, but not supported
<rsalveti> 1006.11
<rlameiro> yeap
<rlameiro> well, i will ty it anyway
<rlameiro> try
<persia> It's supported by Ubuntu, and by Linaro, so it ought be safe.
<rsalveti> https://edge.launchpad.net/ubuntu/maverick/armel/linux-image-2.6.35-1006-linaro-omap/2.6.35-1006.12
<rlameiro> lol
<persia> .12 already.  heh
<rlameiro> now it appears as supported
<rsalveti> http://launchpadlibrarian.net/56232546/linux-image-2.6.35-1006-linaro-omap_2.6.35-1006.12_armel.deb
<rlameiro> forget it... problably some synaptic stuff
<rlameiro> yep
<rlameiro> rsalveti: sorry about crapy feedback... synaptics deceived me....
<rlameiro> :(
<persia> Take care with terminology :)
<rlameiro> rsalveti: one thing i did found interestinf is the size of the images compared to the image of rcn-ee's kernel
<rsalveti> config definitions
<rlameiro> images from ubuntu where quite smaller
<rlameiro> ok, it works on the new one
<rlameiro> at least networking
<rsalveti> cool
<rsalveti> for display fixes they are still waiting the kernel team to review and apply
<rlameiro> rsalveti: do i need to confirm its working? installing it from the repo?
<rsalveti> rlameiro: if you want to test, I have a deb for you
<rlameiro> i tested it :D
<rlameiro> its working
<rlameiro> network, didnt tried display, dont have hdmi tv here
<rsalveti> http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-43_armel.deb should have the display fixes
<rsalveti> http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v4 is this kernel with the config changes
<rsalveti> so if you install my deb and use this uImage, you should be able to have network and display working
<rlameiro> well, for now i dont need display
<rsalveti> so you're fine already with linaro's kernel :-)
<rlameiro> i dont have an WM so its ok for me, what i want is audio working :D
<rsalveti> then it's another issue
<rlameiro> yes I know, one at a time
<rsalveti> :-)
<rlameiro> rsalveti: lp 645689
<ubot2> Launchpad bug 645689 in linux (Ubuntu) "linux-omap cant bring up eth0 on igepv2 board, no network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/645689
<rsalveti> nice
<rsalveti> I'd just like to understand it better, like why using it as module doesn't work
<persia> From what rcn-ee said earlier, I had the impression that uboot is doing bring-up on the device, and hands it off already configured.
<persia> So by building it in, it's easy to notice it's there.
<persia> My (blind) guess is that there isn't an entry in the module detection routine, so there's no coldplug event, so udev doesn't know to load the module.
<persia> That said, I suspect there also aren't the necessary module mappings so that udev would be able to load the right module on detection.
<rlameiro> well, igep is configured to have the device ready for netboot
<rlameiro> maybe it stays configured
<rsalveti> hm, ok, but then driver needs to be initialized correctly
<persia> Separately, if the code isn't written to be hotplug-compatible, modload isn't going to be able to bring it up from scratch (even with coldplug), because the module initialisation routines will be missing the right bits.
<rsalveti> we have platform data for it at the board file, and the kernel should be able to request the module
<persia> rsalveti, Yep.  Precisely.  Cleaning up the initialisation and reporting should enable coldplug.  Once coldplug works, hotplug is trivial.
<rsalveti> still prefer to debug it further than changing the config file
<rsalveti> but, have no board (
<rsalveti> :-(
<rcn-ee> rlameiro, the size difference might be from all the omap4 stuff i have enabled to.. The sgx and dspbridge modules do add a little extra
<rlameiro> hmm
<persia> rsalveti, Isn't there a way to pass a boot option to get extra debug information in dmesg from coldplug initialisation?  Would that be enough to understand the nature of the issue?
<rsalveti> not sure, would first check if we have everything write at the board file
<rsalveti> that's where the platform_data is stored
<rsalveti> and afaik the ethernet chip is deployed with the usb hub
<rsalveti> like we have for xM
<rsalveti> hm, LAN9221i is just an ethernet controller
<rsalveti> rlameiro: where do you get your u-boot?
<rlameiro> stock
<rsalveti> rlameiro: do you have the source's link?
<rlameiro> do you want the version?
<rlameiro> rsalveti: you need to register at their site
<rlameiro> http://www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55
<rlameiro> there should be a link on the left menu where you can go to support or downloads section
<rlameiro> there are all the sources that igep use
<rlameiro> kernels, modules etc
<rsalveti> hm, ok, thanks
<rlameiro> even if i give you the direct link, you will need to be registered...
<rlameiro> sorry
<rsalveti> argh, still need to wait for the administrator to approve my account
<rsalveti> cooloney: hey, morning! :-)
<rsalveti> maybe you can help me
<rsalveti> I believe that the smsc911x module is not automatically loaded simply because this is a platform_driver
<rsalveti> it's not connected to any pci or usb
<rsalveti> what we have at the board file is the platform_data, that's correct registered for igepv2
<rsalveti> but I don't think we have an automatic way to find and load the proper modules while booting the kernel
<rsalveti> that's why it works since boot when you have it as built-in
<rsalveti> then we have a platform_driver_register that matches with a platform_data, the hardware is then initialized correctly
<rsalveti> rlameiro: persia: ^
<rsalveti> so loading the module should do the same, so it's expected to work
<rlameiro> well, so the solution is the driver to be builtin?
<rsalveti> but then we have another issue currently with ubuntu's kernel
<rlameiro> how do you load a module without detecting it?
<rsalveti> that amitk pointed me: http://www.spinics.net/lists/netdev/msg140340.html
<rsalveti> and that's why we have to remove CONFIG_FIXED_PHY
<rsalveti> so, removing CONFIG_FIXED_PHY and loading the kernel by hand should be enough to have the ethernet chip working
<rsalveti> rlameiro: scripts, but should be avoid
<rsalveti> I could be wrong, but I don't know a way to detect the platform devices
<rsalveti> all upstream config files put it as built-in
<cooloney> rsalveti: built-in FIXED_PHY?
<rsalveti> cooloney: currently we have it, and as a side effect we can't make smsc911x to work
<rsalveti> cooloney: http://www.spinics.net/lists/netdev/msg140340.html
<cooloney> rsalveti: yeah, i removed the FIXED_PHY in fsl-imx51 ubuntu kernel before
<rsalveti> cooloney: a question, is there a way to auto detect the platform devices and trigger user space events so udev could load the proper modules?
<cooloney> due to the conflict
<rsalveti> or in this case we should always put it as built-in
<rsalveti> cooloney: cool, we're missing this currently
<rsalveti> will request the linaro's patch to be applied to our tree
<cooloney> rsalveti: i think for our hardware which contains smsc911x needs to built-in smsc911x driver and remove that FIXED_PHY
<rsalveti> cooloney: cool, also think the same
<rsalveti> so I it seems I finally have a proper answer for the issue :-)
<rsalveti> thanks
<rsalveti> will submit the patch
<cooloney> rsalveti: cool, man. that's conflict wasted me some time before
<rsalveti> can imagine, hard to find
<cooloney> rsalveti: i still lost in the mem=1G highmem issue
<cooloney> rsalveti: no clue for that
<rsalveti> comradekingu: me neither
<rsalveti> ouch, sorry
<rsalveti> cooloney: ^
<rsalveti> npitre fixed some highmem issues in the past, maybe he could give us some directions
<rlameiro> I have a doubt
<rlameiro> what is the Alsa drivers used on omap?
<rlameiro> the normal ones that run on my laptop? or the striped down ones?
<cooloney> rsalveti: cool. npitre is master. i need to talk with him
<npitre> I'm here btw ;-)
<npitre> although I WOULDN'T QUALIFY MYSELF AS "MASTER"
<npitre> (especially when hitting capslock by mistake)
<rsalveti> hey
<rsalveti> npitre: we're currently facing a weird bug with highmem on omap4, if we use 1gb the memory some times gets corrupted
<rsalveti> and then the system turns unstable
<rsalveti> we'd like to test upstream, but can't atm as the mmc support is broken
<npitre> rsalveti: what kernel version are you using?
<rsalveti> npitre: one provided by TI, based on 2.6.35: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=shortlog;h=refs/heads/for-ubuntu-2.6.35
<rsalveti> that's why we'd like to try upstream, to avoid all other patches
<npitre> all the highmem fixes I know about are included in 2.6.35
<npitre> can you boot it with only one CPU?
<rsalveti> yep, while looking at 2.6.36 we just noticed one patch that could help: http://lkml.org/lkml/2010/9/7/390
<rsalveti> we can, and we tried it already, but still faced the issue
<npitre> the other thing to try out is to use mem=512m vmalloc=1g in the kernel cmdline string
<rsalveti> with this patch applied things seems to be better, but still breaks
<rsalveti> hm, ok
<npitre> OK that patch might help if the hardware ends up needing bounce buffers (mine didn't)
<cooloney> npitre: hey, man how's going
<npitre> rsalveti: those kernel cmdnline arguments will force 512 mb OF ram ,AND FORCE ALMOST ALL OF IT INTO HIGHMEM, WHICH SHOULD BE A GOOD TEST
<npitre> cooloney: GOOD GOOD
<cooloney> npitre and rsalveti, i think we might need some simple testcase to catch this subtle issue
<npitre> arch damn capslock
<cooloney> npitre: np, heh
<rsalveti> npitre: nice, will test it here
<cooloney> npitre: ok, i will try that cmdline
<cooloney> rsalveti: cool
<rsalveti> cooloney: currently the best test I have is to try to compile the kernel
<rsalveti> it breaks in one or two minutes
<rsalveti> with internal compiler error
<cooloney> rsalveti: yeah, i also got that, if i built kernel in a ssh console, i will got Bad Mode oops in my serial console
<cooloney> Unhandled abort
<rsalveti> yep, that's the error
<cooloney> right, but this test is quite complex. do you guys know any other highmem test SW?
<rsalveti> maybe something to stress the memory
<rsalveti> but it usually takes quite a while before giving any error
<npitre> what if highmem is turned off? does this still fail?
<rsalveti> when setting mem to 716 (460 + 256) with or without highmem we don't face this issue
<npitre> what is the storage device used?
<npitre> does it use DMA?
<rsalveti> the hole is a fixed memory region for decode I guess
<cooloney> npitre: if we don't use mem=1G, there is no such issue
<rsalveti> mmc and usb
<cooloney> yeah, mmc and usb
<cooloney> i tried booting from mmc and rootfs on mmc
<cooloney> but built kernel on NFS or USB
<npitre> does it happen if you use only mmc or usb at once?
<cooloney> got this compiler error every time when mem=1G
<rsalveti> yep, I'm using only USB
<rsalveti> never tested with full mmc, but I believe cooloney tested it already
<cooloney> rsalveti: i think npitre is asking whether we can booting and building kernel only on mmc
<cooloney> rsalveti: oh, no, i just test build kernel on usb and nfs
<cooloney> let me try it
<cooloney> need a big mmc card
<rsalveti> try just on mmc, but I believe people from TI tried it already
<npitre> what I want to know is wether the problem occurs if you use only USB, or only MMC, or only NFS, etc.
<cooloney> npitre: ok, i got it
<rsalveti> ok, got it
<cooloney> rsalveti: can we boot from usb?
<rsalveti> cooloney: do you have a big sd card with you?
<cooloney> i don't think so
<cooloney> rsalveti: i got one 8G SD card
<rsalveti> not directly, I just use the mmc to load the kernel from u-boot
<rsalveti> my rootfs is in a usb disk
<cooloney> rsalveti: ok cool
<rsalveti> then I don't use mmc anymore
<cooloney> so could you try that USB only test?
<cooloney> i will try mmc only test
<npitre> another thing to test is CONFIG_VMSPLIT_2G
<rsalveti> cooloney: yep, this is my usual build environment, and I always face this issue when using 1g
<cooloney> npitre: good point.
<cooloney> rsalveti: ok, let me prepare the 8G SD card
<npitre> another test: just add a flush_dcache_all() at the beginning of dma_cache_maint_page() and see if that makes the issue go away
<npitre> note this is not a fix just a test
<rsalveti> hm, nice test
<npitre> time to go to bed ... just drop me an email with your findings and I might have another clue
<cooloney> npitre, have a nice dream
<rsalveti> npitre: nice, thanks a lot!
<cooloney> we can inception your dream and tell you the result
<rsalveti> :-)
<cooloney> npitre: if you watched the movie inception.
<cooloney> heh
<npitre> I'm rather heavy on TumbleOnThatDamnCapsLockKey tonight
<npitre> that's usually a sign that I should go to bed
<rsalveti> just pull it off, who needs caps lock
<rsalveti> :-)
<rsalveti> cooloney: going to bed now, please let me know if you have any success on this highmem testing
<rsalveti> interested at the flush_dcache_all testing
<rsalveti> can continue tomorrow
<GrueMaster> Bed?  It's only 2am there.
<GrueMaster> Pfft.
 * rsalveti getting old
<GrueMaster> heh.
<GrueMaster> Old is when you forget where you left your coffee mug, while drinking it.
<rsalveti> hm, happens all the time with me
<rsalveti> dammit
<GrueMaster> Yea, but mine is a 20oz silver & black keg.
<rsalveti> haha :-)
<rsalveti> well, time to go, see ya
<GrueMaster> Night
<GrueMaster> persia: about?
 * GrueMaster crawls to bed.  Will pick up in the morning.
<hrw> morning
<persia> GrueMaster, Sorry to have missed you.  Sleep well.
<avinashhm> hi, .. any one knows configuration to control or switch governors ... any sysfs entry ???
<hrw> avinashhm: cd /sys/devices/system/cpu/cpufreq/ and check there
<avinashhm> hrw, i am obseving .. it switchs from performance --> ondemand after some time .. during boot ... any script to do this configuration ...
<avinashhm> i observe the samething isn't there in busybox ... it always stays at performance .. so was curios , is it some script doing this ??
<hrw> probably yes
<avinashhm> hrw, thanks ...
<hrw> I would do grep ondemand /etc -r
<avinashhm> hrw, i will try this  ....
<avinashhm> hrw, .. found bunch of things ... etc/init.d/ondemand ...
<avinashhm> , ... now i wan't configure similar things for my busybox here .. let me try ... thanks again hrw
<ShreeRang> i am working on an ARM based device and when working on the mozilla web browser i am facing a problem...
<ShreeRang> there are number of scroll bars appearing on the screen...
<ShreeRang> i have taken screen shots of the same...
<ShreeRang> please have a look at them at the following link
<ShreeRang> http://picasaweb.google.co.in/patwardhan.shreerang/ARMBasedMozilla?authkey=Gv1sRgCLeMjMPZha67kAE#
<persia> Which release of Ubuntu are you running?
<ShreeRang> has anyone of u faced a similar problem?
<ShreeRang> i m using a customized ubuntu
<persia> Customised from which release?  Also, customised how?
<ShreeRang> ubuntu 9.10
<ShreeRang> by using rootstock
<persia> I'd recommend trying with 10.04.  I think I remember that problem in the past, but I believe it to be solved.
<hrw> 9.10?
<persia> hrw, karmic
<hrw> ShreeRang: which cpu you are using?
<ShreeRang> OMAP 3503
<hrw> ShreeRang: try 10.04 then
<ShreeRang> ok...
<ShreeRang> dats an option...
<ShreeRang> anything else that i can do?
<persia> You might try one of the firefox backports from the mozillateam PPAs, but you'd have to compile it locally.
 * persia wonders if anyone has tried Ubuntu on the Mini6410
<hrw> persia: 6410 is armv6 - right?
<ShreeRang> fine...il try dat n update...
<persia> hrw, Is it?  My quick search misinformed me then.  I'll believe you (and I see 9.10 images of it about)
<hrw> persia: according to samsung datasheet it is arm1176jzf-s
<hrw> so arm11vfp3
<persia> So no support.  Thanks for double-checking.
<ogra> NCommander, getting along with gconf ?
<ogra> ndec, around ?
<ndec> ogra: yep.
<ogra> ndec, i will soon need a list with binary package names to install from the ppa
<ogra> with the next software-center upload the feature will be fully enabled
<ndec> ogra: argh...
<ndec> ogra: can this be just a meta package, something like ubuntu-omap4? then I can manage my dependencies in this pkg?
<persia> Yes.
<ndec> persia: is this 'yes' for me?
<ogra> ndec, indeed ... what we need is one postinst snippet that removes the .desktop file in one of your packages
<ogra> but persia is right, easiest will be a metapackage
<persia> ndec, Yes :)
<ndec> persia: ;-)
<ogra> (and the sprecific postinst bit in there)
<persia> ogra, Might be easier to remove the .desktop file from the source, rather than adding it and removing it.
<ogra> persia, from the source ?
<persia> Yep.
<ogra> its not in any package ...
<ogra> and it cant be
<persia> Then from where does it come?
<persia> No file shouldn't have a package
<ogra> jasper (or if we ever use live images it would have to come from casper)
<persia> (yes, there are exceptions, but they are each special for their own, specific, special reasons, and *NONE* of them are .desktop files)
<persia> Why?
<persia> app-install-data-tippa would be such a better place to put it ...
<ogra> because it has to be dynamically created during first boot/install time unless we want to have even more subarch specific images
<persia> No.  Just have jasper purge app-install-data-tippa if it's not the right subarch
<ogra> hrm
<persia> Unowned files are bad.
<ogra> not for such hacks as PPA enablement for specific subarches
<persia> Yes.
<persia> they are always bad.
<persia> hacks are bad, but bad hacks are extra bad.
<persia> Please avoid extra badness :)
<ogra> i dont really want to jump through all the hoops of paperwork that would involve
<ogra> especially since everything is implemented and works now
<persia> Please talk about the architecture with me beforehand next time :p
<persia> Also, please file a bug to fix this already immediately post-maverick :)
<ogra> sure, we can change all that when we rewrite jasper
<persia> You told me not to do that this cycle back around FF :)
<ndec> ogra: persia: is ubuntu-omap4 a good name? what else would you propose?
<persia> But yeah, that's an OK time.
<ogra> for now jasper will dynamically create the apturl file for omap3 or 4
<ogra> ndec, ubuntu-omap4-addons ?
<persia> ndec, I'd probably use ubuntu-panda-extras
<ogra> i dont think its panda specific
<persia> ogra, "addons" has a special semantic value, and should be avoided.
<ndec> persia: no, i don't want panda since it works on other OMAP4 platforms too
<ogra> will be for blaze too
<persia> ndec, If you're *sure* it's going to be good for all omap4, then "ubuntu-omap4-extras"
<ogra> well, then ubuntu-omap4-extras
<ogra> persia, well, for all *existing* omap4 platforms at least :)
<ndec> some of them are restricted by the way... since I have put some debconf to get clickwrap (like sun java)?
<ogra> thats fine
<ogra> ndec, i also need a text for the "eula" (its not really an eula, but it is shown by sw-center if you want to enable the PPA
<ogra> )
<ndec> well in fact there could be a few bits specific to board. e.g. wlan chip is not the same on panda and blaze. so we could either install both packages, or make different meta packages. I prefer first option.
<ogra> you can try it on todays image to see what i mean
<ogra> (currently it shows some broken html text)
 * ogra prefers both too
<persia> ndec, Would it be possible to have one package that does runtime autodetection to make one or the other work, or has parallel auto-enabled configuration?
<ndec> ogra: so it's a welcome message, right? something like ' you are reading to enable an OMAP PPA and enter a whole new world of improved user experience' ;-)
<persia> Doing it that way will also reduce long-term merge pain.
<ogra> ndec, well, you could also put all eula txts there if you wanted to :)
<persia> let's have a less marketing-friendly message there :p
<ogra> ndec, but that would duplicate the eula stuff i guess
<ndec> especially because EULA are different for our various packages, we don't have 1 EULA overall
<ogra> since they are required to be in the packages too (a user can always enable the ppa without sw-center)
<ogra> ndec, yeah, you could put all of them in ... would be ugly but be possible ... though as i said you will need them in the packages too because you can always manually switch the PPA on on cmdline
<ndec> persia: ideally I should be able to install ti-wlan-127x (panda) and ti-wlan-128x (blaze) package. and have the same root FS work on both. is that okay?
<ogra> so a 2welcome text" would likely be best
<ogra> >The Ubuntu 10.10 TI OMAP4 channel contains applications that are made
<ogra> available for Ubuntu by TI to improve the user experience and hardware
<ogra> support on OMAP4 hardware
<ogra> thats the current text
<ndec> ogra: yes a user can install packages without using the desktop icon... that's an argument against removing the icon in the ubuntu-omap4-extra, no?
<ogra> (i just made that up quickly to have some placeholder text)
<ndec> so, now we need to translate the message too ;-)
<ogra> ndec, no, the icon should be removed as soon as the meta is installed
<ogra> shriek !
<ogra> i didnt think of translations !
<ogra> sigh
<ndec> ogra: can you make the initial ubuntu-omap4-extras package with the postinst and push it in PPA? I will push updates when we are ready.
<persia> Well, we can hit three languages quick-like: the rest will be slower.
<ndec> ogra: i don't care about translation!
<ogra> persia, my prob is that i in no case want to add gettext to jasper
<ogra> that will massively bloat it
 * persia mumbles about architectural integrity and pretends everyone reads English for the next few months
<ogra> well, lets call it a wart we will carry in maverick and do better in natty
<ndec> persia: I think the website where one can order pandaboard will be in english... so we can assume that if someone buys a panda, he understands english ;-)
<persia> When we ignore all prior work and write jasper correctly :)
<persia> I promise I won't be out-of-touch for 10-12 weeks in a row for the next cycle :)
<ogra> well, then we wont have the PPA stuff in it anymore anyway
<ogra> we should switch to packages as you said above
<ogra> and they can then easily be gettextized
 * persia goes off to do less computationally intensive things
<ogra> my prob in maverik is that the cool sw-center stuff only came late ... i threw away all the hacky oemÃ¤-config stuff i had done for PPA enablement just last week
<ogra> in favor of the new apturl feature
<ogra> ndec, what about the discussed split for single features (-omap4-wireless, -omap4-graphics ... etc) should we use these as deps in the toplevel metapackage ?
<ogra> or was that for a different PPA anyway ?
<ogra> (i mean the stuff chris wanted)
<jo-erlend_nb> rsalveti, I have wired networking! :)
<jo-erlend_nb> now for wireless, I only need to install libertas-firmware?
<jo-erlend_nb> except... I can't find it. I find it in apt-cache on my laptop, but not on the igep board.
<jo-erlend_nb> oh, it's in multiverse.
<ogra> ndec, do you think your lawyers would sue me for that ? http://people.canonical.com/~ogra/ti-ppa.svg
<ogra> (th elogo is from wikipedia)
<ogra> *the logo
<persia> ogra, Take care: you'd need a license to use the logo.  Make ndec upload it :)
<ogra> persia, yeah, he shoudl just use it as team logo :)
<ogra> then i can "officially" pull it from LP
<persia> Unfortunately, trademark law requires that every case be prosecuted, or the trademark is lost.
<persia> (at least in some jurisdictions)
<persia> For example, Bayer is the only company that can sell "Aspirin" in some countries, but in others anyone can sell under that name, because of insufficient defense.
<ogra> yep
<jo-erlend_nb> this is looking good! Everything seems to be working nicely on my igepv2 board now, though there are things I haven't had time to test yet.
<jo-erlend_nb> I have a 16GB memory card which I'm installing on now. The image was written to it at 3MB/s. How long should the first boot take, with resizing partitions, etc?
<persia> Maybe 10 minutes.
<persia> But depends on the hardware inside the card as well, really.
<jo-erlend_nb> ok. Does this happen before the welcome screen appears?
<persia> Yes.
<persia> Depending on your configuration, you may get text to console, which may end up on serial or display, during the rebuild.
<jo-erlend_nb> it went too quickly for me to notice, apparently. :)
<persia> That's a good thing :)
<jo-erlend_nb> the difference between those to memory card was rather significant. Using the first one, a normal boot took about 3-4 minutes. Using the other one, it took less than a minute.
<persia> That's the internal hardware differences.
<persia> You will probably notice the system feeling "snappier" as well, as you use it, if you run off that SD.
<jo-erlend_nb> looking forward to testing it. :)
<jo-erlend_nb> persia, I'm not sure I'd use the phrase "snappy", but it's far less sluggish. :)
<jo-erlend_nb> makes me want to try using a usb harddisk, just to see how fast it is when the storage isn't such a bottleneck.
<persia> "snappier" == "less sluggish".
<jo-erlend_nb> hehe, yes, except for the slightly different connotations :)
<lag> Hi mpoirier
<mpoirier> lag: hey good morning !
<lag> Evening :)
<lag> How are you progressing with sound?
<mpoirier> lag: hold on.
<mpoirier> lag: i spent a lot of time in sdp4430.c and twl6040.c
<lag> Okay
<mpoirier> lag: the "dai" (digital audio interface) are key.
<lag> So what do you plan to do?
<mpoirier> lag: still unknown.
 * persia idly notes that the userspace solution turns out not to work with current kernel reporting
<mpoirier> lag: now that I know how the system works, I'll start looking in other files for a possible solution.
<lag> persia: How do you mean?
 * ogra_ac was wondering too
<mpoirier> lag: twl6040.c was written by TI guys, I'll get in touch with them.
<persia> lag, berco put together an alsa configuration fragment that would do what running amixer.sh would do, but ALSA isn't even reporting the card type, so there's no way to load the config fragment.
<mpoirier> lag: ultimately we can do it at the card level, once all the DAIs are registered, but it won't be upstrem'able.
<persia> We also looked at how pulse's module-udev-detect works, and all the values it pulls from /sys/... end up as "unknown", so it can't assign things.
<persia> mpoirier, Why won't it be upstreamable?
<lag> mpoirier: If it's not upstreamable, then it's the wrong way to do it
 * persia agrees
<mpoirier> lag: make no mistake, I don't like it.
 * ogra_ac just notes that the majority of omap4 patches we use isnt upstreamable currently
<persia> ogra, That's different.
<ogra_ac> how ?
<ogra_ac> we use a hackish un-upstreamable kernel in maverick
<lag> Ugly!
<ogra_ac> which will be fixed later
<ogra_ac> so i personally would mind a hackish fix in the sound driver
<ogra_ac> *wouldnt
<lag> mpoirier: What makes you think dai is key?
<persia> ogra, just hardcoding the DAIs is unlikely to result in anything compatible for both Blaze and panda: reports indicate they require slightly different handling.
<ogra_ac> its still better than hacking around in userspace with weird scripts
<persia> We *can't* hack around in userspace: we tried that.
<mpoirier> persia: *if* i hack it, it would be on a board level, not system wide.
<ogra_ac> we obviously can when using the ugly amixer script
<persia> Mind you, it may be possible to use a less-critical hack in the kernel side to enable userspace hacking, but...
<lag> ogra_ac: How is it better
<lag> ?
<persia> mpoirier, Oh, with the machine drivers?  How is that not upstreamable?
<ogra_ac> lag, one change in one place instead of three changes in three places
<lag> I'd say it was less hacky to do it in user space
<lag> It's what amixer was designed for
<persia> ogra, Ah, yeah, the amixer script.  That doesn't have sufficient elegance to even be called "hack" in my book.
<lag> ogra_ac: We only need the script
<ogra_ac> lag, plus the fact that we break all ubuntu policies with it
<lag> Just to turn the thing up!
<ogra_ac> and packaging
<persia> lag, No.  the scipt is unusable.
<persia> lag, *if* the kernel reported the card, we could set mixer policy with userspace config.
<lag> Then that's what we need to do
<lag> Not hack the volume in userspace
<lag> Wrong: kernel
<lag> s/userspace/kernel
<rsalveti> jo-erlend_nb: nice to know, sent both fixes to the kernel team, let's see when they will get applied
<persia> Minimal kernel work would mean passing CARDINFO so we can use a userspace hack for ALSA, and passing something in /sys/... so that udev would be able to identify headset, speakers, etc.
<persia> Better kernel work would be to correctly identify and name the device, and pass the correct naming to userspace policy.
<mpoirier> main problem right now it a misconnection between front and backend DAIs
<persia> Best kernel work would be to correctly identify and name the device, and perform correct basic initialisation on the device (turn on the useful amps, turn off the useless ones, etc.)
<mpoirier> userspace tries to open a stream but can't 'cause kernel returns an error.
<mpoirier> running the scripts fixes the connection between DAIs, hence returning a proper stream to sink to.
<persia> The key bit is that with the current design of ALSA (and yes, there are discussions to move more to userspace), the kernel is responsible for identification, initialisation, and initial configuration.
<berco> persia: mpoirier: I have a kernel change for audio that I need to test
<mpoirier> Getting the DAIs connected properly (on a per card basis) will fix our problems.
<lag> Do we have a working example of how it 'should' work?
<ogra_ac> lag, intel HDA i think
<persia> berco, Excellent!  What does it do?
<persia> Intel HDA is another pile of pain
<lag> 'good example'
<ogra_ac> all other soundcards ?
<lag> And they work in the same way?
<persia> I don't know of one.  I'd really suggest asking in #alsa-soc
<lag> Report all relevant information to userspace?
<persia> ogra, Most soundcards don't use the SoC layer, making them poor examples.
<lag> Good plan
<ogra_ac> ah, right
<berco> persia: it adds long name support in soc
<persia> berco, Cool!  Great find.
<persia> mpoirier, Could you take a look at that?
<mpoirier> persia: sure but what does "long name support" do ?
<berco> persia: trying to get a new kernel with that change in place for testing
<ogra_ac> size matters ?
<ogra_ac> even with sound ?
<persia> Should be reporting of the card name, so that CARDINFO lets us use userspace policy config hacks.
<persia> berco, mpoirier can probably spin you one fairly quickly, if you can point at the patch.
<mpoirier> berco: yes, send me the patch and I'll test this.
<mpoirier> berco: within 30 minutes that is...
<hrw> check how twl4030 does it?
<persia> mpoirier, The userspace config stuff isn't packaged, so you'll want to come back for instructions on how to test :)
<hrw> most omap3 uses twl4030 but has it connected in zyllion ways
<persia> hrw, twl4030 reports CARDINFO, sets amps and volumes, and reports the right parameters to udev?
<ogra_ac> hrw, which obviously breaks it on Xm
<persia> hrw, Ah, yeah, not an ideal example: this is why we don't have working sound on beagle C4/XM
<persia> (well, it kinda works, sorta, on beagle)
<ogra_ac> i think C4 works
<hrw> persia: no idea. I used few omap3 devices with sound. n900/beagleboard b7+c3/bug2
<persia> kinda, sorta, if you don't do anything tricky
<persia> hrw, Making it seem like it works on any of those is trivial: fiddle with alsamixer for 5 minutes, and never think about it again.
<mpoirier> hrw: yes, twl4030 was in my list of things to look at today.
<persia> The trick is having it work perfectly in an autodetected manner on first install.
<ogra_ac> for me "works" = i hear a login sound :P
<persia> ogra, On first boot.
<ogra_ac> sure
<persia> GrueMaster was reporting issues with that for both C4 and XM, I thought.  I may be misremembering.
<hrw> persia: for me "alsactl restore" with prepared asound.conf is fine
<ogra_ac> hrw, thats so broken
<ogra_ac> "prepared asound.conf" ...
<hrw> ogra_ac: kernel people tends to move more and more to userspace anyway
<persia> hrw, That means "not working" to me.
<persia> And moving more to userspace is fine, but it needs to be done right (and that discussion is ongoing in ALSA upstream).
<persia> Just expecting endusers to magically know how to write a config file isn't acceptable user experience.
<hrw> make alsa-config package which will keep asound.conf-boardname + script which will check /proc/cpuinfo?
<ogra_ac> ugh
<persia> We have something like that already.
<persia> It is part of alsa-utils, which you have installed already.
<persia> But it depends on the kernel reporting *which* card is installed.  When the kernel doesn't tell userspace which card is in use, userspace can't do anything at all.
<berco> mpoirier: I'm attaching that patch to the bug 637947
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947
<lag> What EXACTLY does userspace need from the kernel (do you need from me)
<persia> And /proc/cpuinfo is exceedingly unlikely to accurately report the audio interface
<berco> mpoirier: just a min
<mpoirier> berco: fantastic
<lag> persia: It must be reported
<lag> persia: How does ALSA know what to change?
<persia> berco, Could you expand on what was preventing the custom config from loading?
<jo-erlend_nb> rsalveti, you're confident they'll make it in time for maverick?
<rsalveti> jo-erlend_nb: not sure for the release, let's see
<jo-erlend_nb> rsalveti, I did a clean install of todays preinstall on a new memory card, using the new kernel so I could see the process on my screen. It still doesn't setup the filesystems properly.
<rsalveti> if not release, at least as an update
<rsalveti> hm, what do you get on your screen
<rsalveti> ?
<berco> mpoirier: #17 and #18 in the bug 637947 log activity
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947
<jo-erlend_nb> well, everything works nicely, except the rootfs isn't resized. I don't know if bootfs is cleaned with each reboot yet. I'll know that in a little while.
<mpoirier> berco: cool, hold on, checking.
<rsalveti> jo-erlend_nb: ok, would be good to see the messages from the first boot, you should be able to see if it's resizing it or not
<berco> persia: from my understanding in the /proc/asound/cards we only reported "- SDP4430" instead of something like "OMAP4 - SDP4430"
<berco> persia: hence, alsa was not looking for any .conf file
<persia> Aha, so longname should be enough then, right?
<berco> persia: if you have this omap4 field or whatever, you can just name your .conf file the same as this field i.e OMAP4.conf and it would get loaded by alsa
<mpoirier> berco: I'll apply and test - this should be very quick.
<berco> persia: my understanding from the audio guy, is that this fix should be enough, right
<berco> mpoirier: thanks, let me know
<jo-erlend_nb> rsalveti, it went very quickly. I didn't see anything special. Then the welcome screen appeared. I filled out all the details, and it worked for a while, then it rebooted.
<persia> berco, If lrg told you that's what it takes, I'm pretty sure it's correct :)
<berco> mpoirier: I used iwatch to verify my .conf was loaded by alsa. At least we can make sure after this change a .conf file get read and then make this .conf file look good :)
<berco> the .conf should contain all our amixer settings
<persia> Right, which then just leaves pulse
 * persia goes and looks at source again
<rsalveti> jo-erlend_nb: after booting try searching for /var/log/jasper.log
<jo-erlend_nb> rsalveti, I did see a message that Jasper was being removed.
<rsalveti> jo-erlend_nb: but the log should still be there at least
<ogra_ac> whats the prob ?
<jo-erlend_nb> rsalveti, let me install an irc client on it, then it's easier to paste.
<rsalveti> cool
<jo-erlend_nb> it does say it's resizing partitions, at the top of the log file.
<persia> For pulse, the immediately obvious missing bit is missing values for /sys/class/sound/card.../pcmC.../pcm_class
<jo-erlend_nb> oh. And I have no sound.
<persia> But to get a real answer, best to have someone with the hardware to load module-udev-detect with debugging on to track down what's missing.
<rsalveti> jo-erlend_nb: anything else?
<jo-erlend_nb> rsalveti, bluetooth doesn't seem to be recognized.
<persia> That's concerning.  Anything in dmesg at all?
<jo-erlend_nb> rsalveti, but I haven't installed that deb you sent me yet, so perhaps that's causing some problems? I'll do that when I fix the filesystem issues. I have about 50MB free space now. :)
<rsalveti> jo-erlend_nb: sure, np
<rsalveti> with default uImage and uInitrd you should be able to run the resize without issues
<jo-erlend_nb> rsalveti, you mean I should just do it manually?
<jo-erlend_igep> rsalveti, http://paste.ubuntu.com/499149/
<rsalveti> jo-erlend_nb: no, I mean that I believe it should just work
<jo-erlend_igep> that's the jasper log.
<ogra_ac> aha
<rsalveti> first issue with jasper, it expects MLO
<ogra_ac> right
<lool> ogra_ac: hey, I see you committed directly to lp:ubuntu/flash-kernel and not to lp:~ubuntu-core-dev/flash-kernel/ubuntu; do you mind if I completely kill the latter now?
<ogra_ac> and the script is running with set -e
<rsalveti> so yes, jasper is not running the resize
<rsalveti> hm, that'd explain
<lool> ogra_ac: I can help you merge rebase remaining branches based on lp:~ubuntu-core-dev/flash-kernel/ubuntu to lp:ubuntu/flash-kernel if you like
<ogra_ac> lool	go ahead i committed there because i dont want two branches
<ogra_ac> just kill the old one
<jo-erlend_igep> rsalveti, can I just do it myself while the board is running?
<lool> ogra_ac: Done; thanks
<jo-erlend_igep> I mean while rootfs is mounted.
<ogra_ac> i'll do the rebases locally for my personal branches ... if others have probs i'll point them to you though ;)
<rsalveti> jo-erlend_igep: nops, you need to unmount it first
<rsalveti> it works during boot because of uInitrd, that loads a shell in memory
<ogra_ac> no, resize2fs should be able to do an online resize while mounted
<rsalveti> even while mounted?
<rsalveti> never tried
<lool> That's ok; it's basically a matter of updating .bzr/branch/branch.conf to point at the new parent, which can be done when pulling or pushing with --remember
<ogra_ac> but yu miss the bits from jasper_growroot that run afterwards
<ogra_ac> lool	yeah
<ogra_ac> rsalveti yeah, but the fs needs to be clean
<jo-erlend_nb> it keeps deleting everything on my boot partition. How do I fix that?
<rsalveti> I'd say that jasper is running on every boot, as you didn't generate another uInitrd
<ogra_ac2> sigh ... tegra wlan ... sigh
<ogra_ac> whats the content of your boot partition ?
<ogra_ac> can you pastebin the ls output somewhere
<jo-erlend_nb> I have boot.ini, uImage and uInitrd.
<ogra_ac> create an empty file caled MLO
<ogra_ac> *called
<ogra_ac> are you sure the IGEP2 cant read a boot.scr ?
<jo-erlend_nb> I'm currently resizing the rootfs. I'll try that afterwards.
<ogra_ac> thats tricky to add
<jo-erlend_nb> ogra_ac, seems so.
<ogra> lool, i know you use IGEP2 in linaro, how do you handle the fact that it requires a boot.ini instead of a boot.scr by default ?
<ogra> do you just replace u-boot in NAND ?
 * ogra cant imagine that flash-kernel every worked in that scenario
<ogra> *ever
<jo-erlend_nb> rsalveti, can you give me the url to that deb you uploaded? I seem to have misplaced it. :)
<rsalveti> ogra: maybe u-boot upstream uses boot.scr
<ogra> rsalveti, well, i would expect jo-erlend to use the in NAND one
<ogra> and linaro too actually
<ogra> if that requires .ini while its weird, flash-kernel and jasper wont be able to handle that
<GrueMaster> Morning.
<ogra> GrueMaster, morning ... did you have any success with the omap image from yesterday ?
<ogra> (does it still boot with the new u-boot)
<GrueMaster> mpoirier: I was looking at the alsa SOC source yesterday for beagle and had an epiphany.  By looking at soc/omap/omap3pandora.c and comparing it to omap3beagle.c, I think I have an idea of how to make it work.
<GrueMaster> ogra: yes, everything works the same (from what I can tel).
<ogra> \o/
<ogra> awesome
<GrueMaster> back to audio.  Pandora is an opensource handheld using similar hardware to beagle.  But they actually only enable the pins on the codec that are connected in the system.  Beagleboard just maps the entire codec in the dai.
<GrueMaster> I think we can use the pandora as a roadmap to make beagle work properly.
<GrueMaster> No need to look at the twl4030 code, except to get proper channel names for the omap3beagle.c
<mpoirier> berco: got results for you.
<mpoirier> berco: 'cat /proc/asound/cards' indeed reports "TI OMAP4 SDP4430 Board"
<ogra> GrueMaster, pandora ? i thought that was still vaporware ... did they ever actually release something ?
<GrueMaster> Yes.  They are actually shipping.
<berco> mpoirier: cool
<mpoirier> GrueMaster: I'll get back to you.
<ogra> wow
<mpoirier> berco: we are not out of the woods
 * ogra remembers them announcing it in 2007 or so
<berco> mpoirier: is that the only string?
<mpoirier> berco: hummm... good question. you get a kernel message and a user space returned messages.
<ogra> on the daily image it currently reports SDP4430 too fwiw
<mpoirier> berco: I'll use a pastebin - hold on.
<ogra> (not TI OMAP4 in front nor Board in the end though)
<jo-erlend_nb> are imap4 boards already available?
<mpoirier> berco: http://paste.ubuntu.com/499164/
<ogra> jo-erlend_nb, no
<ogra> but soon
<berco> mpoirier: looks better. however asoc string should be replaced to something else to my thinking
<mpoirier> berco: we have a bigger problem - let me explain.
<mpoirier> I did 3 longs days of soul searching in sdp4030.c and twl6040.c.  Know how things get initialized.
<mpoirier> berco: to about 90 % i'd say.  With what you wrote in the scripts, I think you can bridge the last 10% for me.
<mpoirier> so, when the kernel boots all the DAIs are associated to the SDP4030 card.
<mpoirier> things stay still until a user log in.
<mpoirier> when logging in, 'snd_soc_pcm_open' in soc-core.c gets called.
<mpoirier> this is where things go south...
 * berco is still listening
<mpoirier> in there, 'snd_soc_get_backend_dais' is called, which is where I've isolated the problem to.
<mpoirier> I've enable debugging and get the following output: (let me use a pastebin).
<mpoirier> berco: http://paste.ubuntu.com/499170/
<mpoirier> berco, over and over again, which tells me someone in userspace is trying to get information from the card .
<mpoirier> berco, when running the scripts DAIs get resolved and the messages go away (I'll use another pastebin).
<berco> mpoirier: hold on a second please
<mpoirier> ok
<rsalveti> jo-erlend_nb: sorry, got distracted: http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-43_armel.deb
<jo-erlend_nb> thanks.
<berco> mpoirier: ok, just explaining my colleague what we discussed so far as he has a better audio background than me :)
<berco> mpoirier: everything makes sense in your findings
<mpoirier> berco: That's the 10% i get lost and would welcome help from people in the know.
<berco> mpoirier: now, our understanding is that you have a string "AsoC - SDP4430" reported by "cat /proc/asound/cards"
<mpoirier> berco: absolutely
<mpoirier> berco: hold on actually.
<berco> mpoirier: and we should write a "/usr/share/alsa/cards/asoc.conf" file that would include all our amixer script settings
<mpoirier> berco: this is new to me. let me check.
<mpoirier> berco: let me guess, I should find a "SDP4430.conf " in there ?
<berco> mpoirier: I did the test on my PC which as an HDA-Intel audio card
<berco> This HDA-Intel string is reported in /proc/asound/cards on my PC and I can see the HDA-Intel.conf gets read
<berco> mpoirier: no SDP4430.conf is for me a wrong name
<berco> mpoirier: the file name should correspond to the first half of the string before the hyphen character
<berco> mpoirier: "AsoC - SDP4430"
<berco> mpoirier: I can see in the patch that "AsoC" is the card->snd_card_driver name
<jo-erlend_nb> rsalveti, after I installed libertas-firmware, I can see wireless networks in nm-applet. However, I can't seem to connect to my AP. I'm using wpa2+. Do you know any reason why that wouldn't work?
<berco> mpoirier: not a good name but for testing it should be enough
<rsalveti> jo-erlend_nb: hm, don't know, could be a firmware/driver limitation
<mpoirier> berco: let's go back to  http://paste.ubuntu.com/499164/
<berco> mpoirier: do you have mean to share the kernel? And can work on the script file if you want
<berco> mpoirier: ok
<mpoirier> berco: the first line comes from the kernel.
<mpoirier> the second is in user space.
<berco> mpoirier: yes
<berco> mpoirier: all is kernel. AsoC is a generic framework for audio driver. Probably why they chose that name.
<mpoirier> berco: if I follow you properly, it's not reading "ASoc" but "TI OMAP4 SDP4430 Board"
<berco> mpoirier: this driver can manage several sound cards from several companies
<berco> mpoirier: ?
<berco> mpoirier: what is reading "TI ... ?
<mpoirier> berco: brain bug on my side.
<berco> mpoirier: I think it's alsa in user space which is calling the snd_xxx functions...
<mpoirier> I was under the impression the content of /proc/asound/cards was "TI OMAP4 SDP4430" only.
<mpoirier> and 0 [SDP4430        ]: ASoC - SDP4430 was a debug messages coming from the query request.
<mpoirier> it is not the case.
<berco> mpoirier: ok :) I see. No everything comes from it
<mpoirier> berco: let's resume.
<mpoirier> therefore, we should find ASoC.conf under /usr/share/alsa/cards ?
<berco> mpoirier: now, I understand why we disconnected :)
<berco> mpoirier: absolutely
<berco> mpoirier: that's my understanding
<mpoirier> berco: I have a feeling this fine should contains settings that are related to my second pastebin.  Am I correct ?
<mpoirier> s/fine/file
<berco> mpoirier: exactly. This .conf file should contain the amixer settings and that should provide valid audio path to alsa and get rid of your second pastebin error message
<berco> mpoirier: now, an other funny part is the format of this .conf file :)
<berco> mpoirier: I need to fix my cross compile environment to build my own kernel and help you with this testing
<mpoirier> berco: I can accept and test any patches you can give me.
<mpoirier> berco: my turn around is very quick - everything is setup on my side.
<lool> ogra: We currently copy the boot.scr into the boot.ini when writing the image
<mpoirier> berco: it depends on how tedious you think the process will be.
<ogra> lool, but not with flash-kernel
<berco> mpoirier: thanks a lot for your help. I should be able to get back to you tomorrow
<ogra> i.e. when updating the kernel
<lool> ogra: I didn't think flash-kernel had to touch it in our case
<ogra> ah
<ogra> well, we use a /boot/boot.script file as input so we regenerate it on every flash-kernel run
<lrg> mpoirier, berco: fwiw, this file + driver patch is still work in progress.  Should be a newer fix tomorrow.
<ogra> (since we hide the actual vfat partition)
<berco> lrg: are you also preparing this .conf file?
<lrg> berco: yes, the audio team is working on this.
<mpoirier> GrueMaster: I will start looking in omap3-beagle.c and omap3-pandora.c .
<GrueMaster> What I was going to say was that the omap3beagle maps the entire codec in the dai, whereas the omap3pandora only maps the used channels.  The omap3evm should map the entire codec as it is an evaluation board.  Beagle is not.
<GrueMaster> But if ASOC is heading towards a userspace conf file format, that may be the better solution.
<GrueMaster> I only spent about an hour looking at the code.  But we should be able to get a solution fairly quickly.
<GrueMaster> Something happened to the dove image.  It no longer has a partition table in today's image.  Very odd.
<GrueMaster> ogra, NCommander:  ^^^
<ogra_cmpc> GrueMaster, a partition table ?
<ogra_cmpc> in a *dove* image ?
<GrueMaster> Yes.  It should have 1 partition, vfat.
<ogra_cmpc> right but no table
<GrueMaster> If you have a partition, you have a partition table.
<GrueMaster> Otherwise the raw device is one big filessytem.
<GrueMaster> I.e. /dev/sdh vs /dev/sdh1
<ogra_cmpc> ogra@antimony:~/branches/debian-cd$ bzr pull
<ogra_cmpc> No revisions to pull.
<ogra_cmpc> ...
<ogra_cmpc> no changes
<ogra_cmpc> i dont think we ever partitioned dove
<GrueMaster> After running dd if=maverick-netbook-armel+dove.img of=/dev/sdh bs=4M, I should see /dev/sdh1.  I do not with todays image.
<ogra_cmpc> parted -s "$IMAGE" mklabel msdos
<ogra_cmpc> hmm, we apparently do
<ogra_cmpc> well, there are no code changes at all
<ogra_cmpc> GrueMaster, are you 100% sure thats only with todays image ?
<ogra_cmpc> i.e. yesterdays was for sure ok
<GrueMaster> As soon as I am done flashing today's omap image for my beagle, I will double check yesterdays.
<ogra_cmpc> k
<GrueMaster> I know for a fact that 20100920 was good.  No build on 20100921.
<ogra_cmpc> i know antimony was upgraded to lucid but thats a few days ago
<GrueMaster> Should have been done earlier in the cycle.
<ogra_cmpc> yes ...
<ogra_cmpc> but now its there
<ogra_cmpc> checking the partitioning code, its identical for omap, omap4 and dove
<ogra_cmpc> so it cant be a newer parted or some such
<GrueMaster> Gah, flashing images to SD takes forever.
<ogra_cmpc> yeah :(
<GrueMaster> And if I try to flash to two USB devices at the same time, my Core2Quad becomes quite unstable.
<GrueMaster> Even though they are on separate USB busses.
<ogra_cmpc> file a bug ... kernel issue
<ogra_cmpc> or HW
<GrueMaster> No, I think it is hardware related.  Wife's computer has the same issue, and she runs that "other" OS.
<ogra_cmpc> its the CPU !
<GrueMaster> Pffft.
<ogra_cmpc> wrong vendor !
<GrueMaster> I do need to nuke & pave it though.  Running i386 install.  Should run x86_64.
<Neko_> ogra, see ubiquity bug, making real progress on this :]
<Neko_> there is an upstart bug that means it won't "stop" an already running thing, so gdm and ubiquity-dm will just fight it out because it will refuse to quit running gdm just because ubiquity is running
<Neko_> but, I could connect to wireless from in oem-config GUI and apart from how ugly as sin it is, it worked great until it nuked trying to do a symlink :D
<ogra_cmpc> Neko_, well, we use iit daily on our images and never hit such bugs
<ogra_cmpc> i personally also find it quite beautiful
<ogra_cmpc> Neko_, you are using maverick, right ?
<Neko_> yes :)
<Neko_> I think part of it is we're using a fat partition for /boot
<ogra_cmpc> did you ever consider just using the readily produced images ?
<Neko_> what are you using for disks on your systems?
<Neko_> what readily produced images
<ogra_cmpc> the dailies we build
<Neko_> there are the dailies for dove etc. but they're installers
<Neko_> we can't hack in our kernel to those
<Neko_> gimme a URL so I can see what you're talking about? :/
<GrueMaster> Neko_: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
<ogra_cmpc> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
<Neko_> ugh .img?
<ogra_cmpc> Neko_, you need to generate the inird with the rootfs on the second partition but beyond that it shouldnt be difficult to add another kernel
<Neko_> what's the 16MB of difference between the two, just kernel stuff?
<ogra_cmpc> (initrd is essential)
<ogra_cmpc> yes
<Neko_> I mean given the choice they're identical in terms of packages
<Neko_> and it's UNE right
<GrueMaster> yes
<ogra_cmpc> right
<Neko_> but we don't want UNE.
<Neko_> UNE is too touchscreeny and weird
 * ogra_cmpc uses it on a 24" 1920x1280 screen on omap4 ... i dont find it touchscreeny
<Neko_> the scrollbar is backwards like a touchscreen "drag" would be
<Neko_> you drag it up and it scrolls down
<ogra_cmpc> no
<ogra_cmpc> that was a bug that was fixed long ago
<Neko_> have you ever considered that people might just want a normal gnome desktop? ;_;
<ogra_cmpc> the image ships a normal gnome desktop too
<GrueMaster> It is there as well.  You can select it at the gdm login.
<Neko_> ... oem-config first though right? :)
<ogra_cmpc> jasper first
<ogra_cmpc> then oem-config
<Neko_> whats jasper and what is it doing for me
<ogra_cmpc> then netbook UI
<ogra_cmpc> it does the initial system setup
<ogra_cmpc> growing the rootfs to teh full size of the SD ...
<ogra_cmpc> system setup ...
<Neko_> oh fuck that I am going to loop mount the image and make a tarball
<ogra_cmpc> optimization for SD card
<Neko_> the thing is going to be on a 16GB SSD
<ogra_cmpc> jasper lives in the inird
<Neko_> which we don't have :D so... good
<ogra_cmpc> (thats why i said initrd is essential on these images)
<ogra_cmpc> well, its easy to roll one
<Neko_> you'd think..
<ogra_cmpc> install your kernel package in the rootfs and just run update-initramfs
<Neko_> we don't haaave a kernel package
<ogra_cmpc> tr8ivial
<ogra_cmpc> ugh
<ogra_cmpc> how do you apply security updates ?
<Neko_> for some reason the kernel stuff is all reliant on some weirdo 2.6.33+ stuff
<ogra_cmpc> oh
<Neko_> markos is having trouble getting our 2.6.31 to build using the correct packaging
<ogra_cmpc> well, then i see why you have upstart probs
<GrueMaster> ogra_cmpc: Issue with today's omap4 image.  Running oem-config, something has used up my entire 7.2G of root partition.  May be related to encrypted home dir.
<Neko_> oh no, do not blame this on the kernel:D
<Neko_> upstart has absolutely no reliance on any feature of the kernel in that manner
<ogra_cmpc> Neko_, upstart relies on a 2.6.35 kernel
<Neko_> in what way
<ogra_cmpc> ask Keybuk in #ubuntu-devel
<ogra_cmpc> upstart and udev in ubuntu are always tied to the kernel
<Neko_> is this something that got hastily put in after you dropped mx51 support or has it always been that way?
<ogra_cmpc> there are surely more userspace tools that expect certain kernel features
<ogra_cmpc> it has always been that way
<Neko_> christ....
<ogra_cmpc> in some releases more in some less
<ogra_cmpc> ask our kernelteam how much they suffered from backporting changes to the imx kernels :)
<Neko_> oh we had the same troubles here believe me
<Neko_> Freescale keep promising a 2.6.35
<ogra_cmpc> i bet they still do
<Neko_> the last we heard was "we can get you a snapshot maybe october 15th"
<Neko_> then they said "no shapshot just wait for the bsp"
<Neko_> that's probably november 30th
<Neko_> we are pushing it to higher management
<ogra_cmpc> yeah ... enjoy the wait
<ogra_cmpc> get some icecream meanwhile :P
<GrueMaster> Nah.  It would melt too fast.
<ogra_cmpc> no, you eat it and get more :)
<Neko_> they really really want Maverick because they just realised Karmic blows donkey cock.. we explained they had better back us up and then they said "but we have no roadmap we thought you would do it all"
<Neko_> it's really a mess.. Linaro are too focused on mainline, we need BSPs
<ogra_cmpc> well, letting BSPs die is linaros mission
<ogra_cmpc> and a good one imho
<Neko_> it's a 5 year mission
<ogra_cmpc> in any case, if your oem-config issues are upstart related i'd take a look at the kernel
<Neko_> to boldly go where no man has gone before
<Neko_> no doubt, like every other ship that isn't the Enterprise, it will end up as a debris field
<ogra_cmpc> the more people help, the shorter the timefarme will get
<GrueMaster> ogra_cmpc: For some reason, my omap4 image swap file is 5.5G.  Jasper log looks ok, so I doubt it has anything to do with it.
<ogra_cmpc> GrueMaster, the swap file ?
 * ogra_cmpc blames rsalveti 
<ogra_cmpc> :P
<GrueMaster> Why?  Jasper looks ok.
<ogra_cmpc> ogra@panda:~$ ls -lh /SWAP.swap
<ogra_cmpc> -rw-r--r-- 1 root root 512M 2010-09-22 11:38 /SWAP.swap
<ogra_cmpc> its exactly as big as it should be here
<GrueMaster> ls -lh mnt/SWAP.swap
<GrueMaster> -rw-r--r-- 1 root root 5.5G 2010-09-23 11:11 mnt/SWAP.swap
<ogra_cmpc> woah
<GrueMaster> Yea.  bit on the plus side.
<ogra_cmpc> i'll try to reproduce tomorrow
<GrueMaster> I'll continue on it now.  I think it has to do with encrypted home directory.  What would I file this under if I reproduce it?
<ogra_cmpc> hmm
<ogra_cmpc> good question
<GrueMaster> this is why I have a hard time filing some bugs.
<GrueMaster> I can spend hours trying to find the right package.
<ogra_cmpc> ecryptfs-utils probably
<ogra_cmpc> or cryptsetup
<ogra_cmpc> if you reliably can point to the encrypted home
<GrueMaster> I'll pick one.  It will be wrong, but let someone in triage figure it out.
<GrueMaster> :P
<ogra_cmpc> well, they are deps of ubiquity
<ogra_cmpc> one of them is responsible for the homedir stuff
<GrueMaster> First I will try on my 16G SD.  If that gets bloated, I'll go from ther.
<GrueMaster> there
<ogra_cmpc> afaik vstehle uses encrypted home on all his test installs
<ogra_cmpc> i havent heard from him since we enabled swap creation again
<ogra_cmpc> which i'd see as a good sign
<ogra_cmpc> i really wouldnt mind dropping swap on omap4 to be honest
<GrueMaster> Could.  It is not as critical as on beagle.
<ogra_cmpc> well, even there only on C4
<GrueMaster> Might actually speed it up a bit due to SD I/O.
<ogra_cmpc> only if it swaps :)
<GrueMaster> And I meant beagle, not XM.
<ogra_cmpc> heh
<GrueMaster> And apparently mine did swap a little.
<ogra_cmpc> well, it cant swap beyond the size we gave it
<ogra_cmpc> its not some magically autogrowing file
<GrueMaster> Yea, I'll keep that in mind when I look at the 5.5G file again.
<ogra_cmpc> it can actually only have happened at creation time
<GrueMaster> I looked at the jasper log and it looked ok.
<ogra_cmpc> dd if=/dev/zero of=${DIR}/root/SWAP.swap bs=1048576 count=512 >>$LOGFILE 2>&1
<GrueMaster> The size reported in the log was nowhere close to this.
<ogra_cmpc> i dont see how that would create a 5.5G file
<ogra_cmpc> yes, but it cant just grow
<GrueMaster> Theory vs Reality.  I don't know either, but will look at the logs more as soon as I finish flashing the other SD.
<GrueMaster> And XM is fine (although I didn't add encrypted home dir on it).
<rsalveti> ouch, 5.5G of swap?
<rsalveti> makes no sense
<GrueMaster> Yea.  I'm big, but not that big.
<GrueMaster> Also, why am I seeing mtdblock 0 errors during jasper on beagle (not XM).
<Neko_> why don't you just use qualifiers for the dd arguments
<Neko_> bs=1M count=512
<ogra_cmpc> precision :)
<GrueMaster> From the dmesg log:  [    7.045257] Adding 524284k swap on /SWAP.swap.  Priority:-1 extents:137 across:2219040k SS
<GrueMaster> Looks ok so far.
<ogra_cmpc> yes
<ogra_cmpc> do you see 5.5G on the running system too ?
<ogra_cmpc> (with ls)
<GrueMaster> Just booted it.  oem-config now up.
<ogra_cmpc> oem-config ?
<GrueMaster> Yes.  Fresh SD install.
<ogra_cmpc> oh, i meant the one that had the 5.5G file
<GrueMaster> I have two SD cards I use for panda.  One I am looking at, the other is now booting to reproduce the issue.
<GrueMaster> On the SD with 5.5G, oem-install failed with an out of space error.
<GrueMaster> Stopped at that point to debug.
<ogra_cmpc> ah
<GrueMaster> From oem-config.log:  debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: No space left on device
<GrueMaster> Not sure what stage that is.
<ogra_cmpc> relatively to the end
<ogra_cmpc> but doesnt matter
<ogra_cmpc> as long as the user can input stuff debconf is only read afaik
<GrueMaster> Interesting.  After creating the user, there is a message in oem-config that it is wiping swap space for security.
<GrueMaster> That may be doing it.
<ogra_cmpc> only the content though
<ogra_cmpc> the file shouldnt grow
<GrueMaster> depends on how it is trying to wipe it.  If it is just doing "dd if=/dev/zero of=<SWAP Space>".
<GrueMaster> Since we are using a file, it is very possible that this is what is happening.
<ogra_cmpc> oh, that would be a possibiltty
<GrueMaster> It is used to wiping a predefined partition.
<ogra_cmpc> well, kees is busy talking in -devel
<ogra_cmpc> he's the security expert
 * ogra_cmpc gets dinner and will vanish until the call now
<kees> hola
<rsalveti> hey
<GrueMaster> So I am testing our daily images and found that when oem-install creates a new user with home dir encryption, our /SWAP.swp file ends up filling the entire SD card.
<GrueMaster> How is ubiquity zeroing the swap space?
<rsalveti> ouch, interesting bug
<GrueMaster> rsalveti: It's my hidden talent.
<rsalveti> so not caused by me :-)
<rsalveti> GrueMaster: haha :-)
<kees> GrueMaster: well, first of all, oem-install probably shouldn't enable home dir encryption, that's not the default in the other ISOs
<kees> GrueMaster: secondly, it writes zeros to the entire partition, IIRC.
<GrueMaster> It isn't?
<GrueMaster> Seems to me, it is part of user creation, which on preinstalled images would be appropriate for oem-install.
<GrueMaster> As to the zeroing the entire partition, I can see that.
<DanaG> http://www.engadget.com/2010/09/23/marvell-unveils-1-5ghz-triple-core-application-processor-all-cu/#comments
<DanaG> Spiffy.
<mpoirier> GrueMaster: I just had a look at omap3beagle.c and omap3pandora.c
<GrueMaster> ok.  Cool.  I've been swamped with swap issues.
<mpoirier> the scheme set forth in omap3 land is interesting - one card definition per board.
<GrueMaster> Yea, I think that may be the old way of doing it.  I think they are trying to shift towards "expose all - config in userspace".
<GrueMaster> Which would make the most sense.
<mpoirier> if we were to continue this in omap4 land, sdp4430.c *could* become sdp4430panda.c
<GrueMaster> Easier to add a config file on the fly than patch->build->test kernel.
<GrueMaster> I think for now, we want the fastest solution.  We can look for the best solution in Natty.
<mpoirier> Well, hold on - this scheme solves only half the puzzle.
<GrueMaster> What is the other half?  Pulseaudio?
<mpoirier> omap3 land was not as refined as omap4 and therefore cards had to put their cpu_dai in the snd_sod_dai_link definitions.
<mpoirier> in omap4 they have replace the hard coded scheme by a naming convention.
<mpoirier> which is exactly what is being done in twl6040.c with the end result being exactly the same.
<mpoirier> that is, we haven't found a way to push front-end and back-end dai configuration to the kernel.
<mpoirier> without scripts that is.
<mpoirier> Right now the TI audio team is looking at fixing /proc/alsa/cards and giving us a proper ASoC.conf file,
<mpoirier> which will solve the problem.
<mpoirier> Patches are on the way.
<GrueMaster> Ok.  Is that omap4 or all?
<mpoirier> First omap3.
<mpoirier> sorry, omap4, first omap4.
<GrueMaster> So for omap3, we could just tweak omap3beagle.c for now.
<GrueMaster> And pick up the ASoC.conf in Natty.
<mpoirier> hold on, I got an idea...
<mpoirier> I'll get back to you shortly.
<GrueMaster> I'll be here.
<mpoirier> GrueMaster: I **think** I just bridged the gap.
<mpoirier> do you have time to hear it ?
<GrueMaster> Sure.
<mpoirier> Do you have a running beagleboard in front of you ?
<GrueMaster> beagle, XM, and two pandas.
<mpoirier> are they all running ?
<GrueMaster> pandas are finishing oem-install now.
<GrueMaster> all are running otherwise.  Fresh images as of this morning.
<mpoirier> ok sure - in anycase you don't have the proper patch for omap4 so it won't matter.
<mpoirier> It all starts from my little chat with berco this morning.
<GrueMaster> right.
<mpoirier> berco gave me a patch that output  http://paste.ubuntu.com/499164/  in /proc/asound/cards
<mpoirier> the "ASoC" is the important part here.
<GrueMaster> ok
<mpoirier> yes, bare with me, I have a lot of layers to peel.
<DanaG> USB 3.0 ARM... sounds perfect for a NAS.
<mpoirier> GrueMaster: just a sec.
<mpoirier> GrueMaster: sorry, need to organize brain.
<GrueMaster> Take your time.
<mpoirier> GrueMaster: we know from omap3beagle.c and omap3pandora.c that sound card are named per board.
<mpoirier> that is, omap3beagle.c defines the sound card for beagle and omap3pandora.c for pandora.
<mpoirier> that information is exported in /proc/alsa/cards
<mpoirier> from that information /usr/share/alsa/cards/ is search from the right card.
<GrueMaster> Ok, following so far.
<mpoirier> from my conversation with berco this morning, bridge between front and backend dais are made from those files.
<lrg> mpoirier: google for alsa UCM
<GrueMaster> It can be.  It looks like omap3pandora is doing that internally though.
<mpoirier> Irg: good you're on.
<DanaG> Why does omap3beagle have so many extra pins (such as "handsfree" and "predrive") that aren't wired on the board?
<DanaG> If it's per-board, couldn't they hide those?
<rsalveti> probably copy paste
<rsalveti> from other board
<mpoirier> Irg: do you know exactly what field in the .conf file alsa is looking for ?
<lrg> mpoirier: looking for what ?
<GrueMaster> DanaG: It looks simpler than copy/paste.  I would guess that it was just to expose the entire codec.
<mpoirier> the patch that you wrote this morning write ASoC in /proc/alsa/cards
<mpoirier> according to berco, alsa then looks for ASoC.conf under /usr/share/cards/
<lrg> that's changed to card name now
<mpoirier> Irg: yes good idea.
<lrg> fwiw, the alsa conf method is only a stopgap atm
<lrg> UCM is the prefered solution
<rlameiro> evening evryone
<lrg> UCM is currently in the alsa-lib ucm branch
<lrg> and will hopefully be in master soon
<DanaG> What does UCM stand for?
<lrg> Use Case Manager
<mpoirier> Irg: I'll look at UCM as soon as we're done.
<DanaG> ah.
<mpoirier> Irg: for the next 7 days though, we need a way to configure our cards.
<GrueMaster> lrg: It is still very wip.
<lrg> it will be ready for in the next few weeks
<mpoirier> Irg: and from what I gathered in the past couple of days, I *think* we have a clean solution.
<GrueMaster> lrg: We have release on 10/10.
<rlameiro> what is a Use case manager?
<lrg> GrueMaster: I was thinking 4/11
<GrueMaster> Feature freeze was several months ago.
<mpoirier> Irg: for 4/11, I can sure put it in.
<GrueMaster> lrg: Definitely a possibility for 11.04
<lrg> GrueMaster: it will be part of alsa-lib by then (i.e. next alsa-lib release)
<rlameiro> when is the final freeze? like no more stuff until launch?
<GrueMaster> absolute zero is 10/6.
<GrueMaster> Bug fixes with a lot of begging now.
<rlameiro> lol
<rlameiro> so i need to get starting on my USB audio intrface bug
<GrueMaster> rlameiro: if you have a patch and want it fixed, do it quickly.  Still, no guarantees it will make release.  May have to go sru and be added to mav-updates.
<mpoirier> Irg: back to my question: which part of /proc/alsa/cards is alsa looking for to seach configuration file under /usr/share/alsa/cards/ ?
<rlameiro> I even dont know what is wrong...
<rlameiro> I think i am betting for natty
<rlameiro> :(
<rlameiro> I am kinda disapointed with audio stuff on the Arm platform
<GrueMaster> rlameiro: If you can reproduce it on x86, that would make things easier I think.  usb-audio shouldn't change between arch's.
<rlameiro> but changes
<rlameiro> and as far as i know, there are diferent stuff on alsa, between arm/x86
<rlameiro> for instance ASoC
<lrg> mpoirier: the driver name, so in this case SDP4430 (instead of ASoC)
<GrueMaster> Besides the obvious.  arm also doesn't support HD Audio.
<rlameiro> why? to save power?
<GrueMaster> rlameiro: HD Audio is build in to x86 motherboards.  It is a different bus architecture.
<GrueMaster> But usb is usb.
<rlameiro> well, never like hd audio so for me is irrelevant
<DanaG> HD Audio is a bus, just like AC97 is a bus, right?
<DanaG> Like, some Creative cards have had an AC97 bus controller, and an AC97 codec somewhere.
<GrueMaster> The point is that the usb audio driver on x86 is the same code for the usb audio driver on arm.
<rlameiro> yeap usb should work on the 2 sides, unless the code is different or crippled for size concerns
<DanaG> And C-Media has a vaporware USB-Audio thing that has an HD Audio bus controller.
<GrueMaster> DanaG: In it's simplist form, yes.
<mpoirier> Irg: my I suggest...
<DanaG> I just wish somebody would make a freaking ExpressCard C-Media Oxygen (or such) card.
<mpoirier> Irg: to call it something more card related... Something like SDP4430panda ?
<mpoirier> that way, when another card is released, we could call it SDP4430another_card.
<mpoirier> Irg: i'm replicating the scheme put forward in omap3beagle.c and omap3pandora.c
<GrueMaster> I agree with mpoirier's idea.  We should be able to whip it out in minutes, vs trying to figure out what an ASoC.conf file would need.
<rlameiro> GrueMaster: for isntance, my usb audio has an alsa addon to quircks, in order for the device to have its full extended usage
<DanaG> I hope that panda will become available soonish.
<DanaG> My CM106 USB card is silent with default Windows USB-Audio drivers.
<DanaG> And it only supports 7.1-channel -- no 5.1 or stereo!
<mpoirier> Irg: I'm not an expert... I'm just thinking with what I learned lately...
<rlameiro> GrueMaster: and i am not sure if this driver has it, altough midi does apear on alsamixer for my device
<DanaG> In my case, the hardware really is buggy.
<GrueMaster> Ok, not to be picky, but we really need to focus on asoc issues atm.  We are getting too much chatter in the channel.
<lrg> mpoirier: the name will be the same as the mach driver, and SDP4430 is just another development board like panda. Fwiw we may decide to create a separate mach driver for panda if it becomes necessary
<lrg> so maybe omap4panda will be better
<GrueMaster> Sounds reasonable to me.
<rlameiro> where are the packages for arm? for download?
<mpoirier> Irg: it would follow the omap3XYZ scheme already widly known
<lrg> yes
<GrueMaster> rlameiro: http://ports.ubuntu.com
<rlameiro> thanks
<rlameiro> sorry GrueMaster, but i cant find the sources for the kernel I have installed
<GrueMaster> rlameiro: If you type "apt-cache show <package> it will tell you the name of the source package.  It will be in pool/main/ somewhere.
<GrueMaster> what kernel are you running?
<rlameiro> linaro
<rlameiro> well, I need to powerup my board then
<GrueMaster> http://ports.ubuntu.com/pool/main/l/linux-linaro/
<GrueMaster> look there.
<GrueMaster> You will want linux-linaro_2.6.35.orig.tar.gz, linux-linaro_2.6.35-1006.12.diff.gz and  linux-linaro_2.6.35-1006.12.dsc
<rlameiro> no source in ther, just binaries
<GrueMaster> The first file is a compressed tarball of the main source tree.  The second file is their current patchset.  the third is used by debian build utilities.
<GrueMaster> Hmmm.  "NAME = Sheep on Meth".  Interesting.
<Neko_> ogra, would you care to make a blueprint or something for "the perfect storm" of features on an arm system that would make your life easier re uboot configuration and system peripherals and suchlike? :D
<GrueMaster> How about make-arm-poweron-self-programming-to-perfection?
<Neko_> :)
<Neko_> but I mean like "it would be nice if it booted ext4 native" or you know.. that kind of thing.
<GrueMaster> Might increase the footprint of the silicon a bit though.
<Neko_> "has some other storage than f**king SD card"
<Neko_> :D
<GrueMaster> Problem there is that the beagleXM and panda have no nand.
<GrueMaster> So they boot from SD by default.
<GrueMaster> It is in silicon (from what I understand).
<mpoirier> Persia: anyone home ?
<mpoirier> persia ^^^^^
 * persia reads some backscroll, hoping to develop context
<mpoirier> persia: no need...
<persia> mpoirier, What?
<mpoirier> you were talking about a "machine driver" at one point...
<persia> yes.
<mpoirier> would you have an example of its usage (any usage really) somewhere ?
<persia> I have pointers to documentation, but no pointers to code.
<mpoirier> documentation then...
<DanaG> What's the difference between the Ubuntu and Linaro kernels?
<persia> DanaG, All the kernels in the Ubuntu repos are Ubuntu kernels.
<persia> Current kernels come from two upstreams (kernel.org mainline and linaro)
<DanaG> Are there any significantly notable differences between the two?
<DanaG> er, "significantly notable" is a bit redundant.
<persia> mpoirier, /usr/share/doc/linux-doc/sound/alsa/soc/machine.txt
<persia> DanaG, To the limit of my knowledge, Linaro is attempting to unify ARM trees, and so has a bunch of patches that may not yet be mainline from various sources plus a bunch of patches that help unify things.
<persia> Additionally, Linaro has a whole bunch of folk working on enabling stuff, so likely carries those patches.
<GrueMaster> persia: mpoirier:  That would fall back on our earlier discussion re: omap3beagle.c, etc.
<GrueMaster> persia:  cliffnotes version of scrollback:  I discovered last night that omap3pandora.c enables specific ports in the codec, whereas omap3beagle.c enables the entire codec.
<persia> GrueMaster, Thanks!  Yeah, something more targeted makes sense.  That said, it may be that every port is wired to something on the beagle (although it would be nice if they had proper names)
<GrueMaster> No, the beagle just enables every port on the codec, whether it is wired outside the chip or not.
<persia> Did lrg's patches help with omap4?
<GrueMaster> Not sure.  For our immediate useage, probably not.  It also requires hacking together an ASoC.conf in /usr/share/alsa/cards, which itsself is short lived.
<persia> Why?
<persia> Why not /usr/share/alsa/cards/KJH34987.conf (or whatever is appropriate for that specific board)
<GrueMaster> But his patch does enable us to move forward to UCM
<persia> Then we can use the reported card name to configure it.
<persia> UCM?
<GrueMaster> UCM  Usage Case Manager.  Will be in Natty.
<GrueMaster> New to alsa-lib.
<persia> Ah, OK.
<GrueMaster> The idea is to make the driver open all controls and do the system config in userspace.
<persia> I think berco already created the conf file to drop in /usr/share/alsa/cards so it's low-additional-effort to enable that, as much as it's not the right long-term solution.
<GrueMaster> Not sure.
<persia> And ASoC will be doing this also, not just regular ALSA?
<GrueMaster> Won't help with omap3 though.
<GrueMaster> This is all asoc I believe.
<GrueMaster> The rest of alsa may adapt.
<persia> Not having to quirk HDA would make lots of folk jump up and down in joy.
<GrueMaster> I'd have to read the email threads in alsa-devel.  I've seen it come up a few times recently in my mailbox.
<persia> That said, I thought lots of folk were looking forward to devicetree to deal with some of this.
<GrueMaster> Not sure how far out devicetree is, and atm it is PPC & arm specific.
<persia> That's not so helpful :(
<GrueMaster> It would require all arches to support devicetree.
<persia> Indeed.
<persia> Or, conversely, devicetree to support all arches
<mpoirier> persia: currently omap3 (beagle, and I assume pandora) return "twl4030" in /proc/asound/cards
<mpoirier> hence we'd need  /usr/share/alsa/cards/twl4030.conf and we'd be set.
<mpoirier> doesn't offer a solution to differentiate beagle, pandora, gumstix, igep...
<rlameiro> only one question, what could be the reason that my board cant support this tipe of audio format S24_3LE?
<DanaG> device-tree is also used for Microblaze.
<DanaG> Though, last time I tried Microblaze, it was a "bag of hurt" (me using Jobs's words).
<rlameiro> everytime I unplug something from the usb hub, the board stops recognizing when i plug something again
<rlameiro> is there any way of "restarting" the usb detection system?
<rlameiro> or what is called
<rsalveti> vstehle: cool, thanks for the patch at bug 646368, this was the fix I was looking for yesterday
<ubot2> Launchpad bug 646368 in linux (Ubuntu) "smsc911x has no module alias, does not get auto-loaded on OMAP3 EVM (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/646368
<rsalveti> didn't know that just adding the module alias would make the kernel to request the proper module
<ogra> heh
<ogra> i was just about to point that out to you :)
<ogra> perfect timing :)
 * ogra goes to bed ...
<rsalveti> :-)
<rsalveti> see ya
#ubuntu-arm 2010-09-24
<ndec> rsalveti: hi... i was looking at your omap3 sgx packages.. and learn quite a few nice tricks that I didn't know. cool!
<rsalveti> ndec: cool, feel free to copy from it :-)
<ndec> rsalveti: for sure... the thing I didn't know was the xx.udev and xx.upstart... we have such files in our pkgs, but we are handling them in .install... will fix this.
<rsalveti> ndec: yep, nowadays we have debhelpers for everything :-)
<persia> ndec, It's worth checking all the completions of dh_ : most modern rules files don't invoke any of the debhelper scripts manually, but end up using lots of features.
<GrueMaster> persia: still hanging around?  I have questions regarding dove audio.
<persia> GrueMaster, back now.  Please ask.
<GrueMaster> I was looking at the dove audio issue.  We hit this before in bug 451635 early in Lucid & karmic.
<ubot2> Launchpad bug 451635 in pulseaudio (Ubuntu Karmic) (and 8 other projects) "defaults need adjustment on dove X0 for audible audio (affects: 1) (heat: 11)" [Undecided,New] https://launchpad.net/bugs/451635
<GrueMaster> Unfortunately, Marvell has changed codecs since then.
<GrueMaster> It used to be an AD1980 codec.  It is now an RT655.
<GrueMaster> From what I can tell, it only exposes what in HD audio would be the 3 main outputs (front, rear, and center/lfe).
<GrueMaster> No headphone jack.
<persia> Is it the case that those 6 channels are producing audio when one tries?
<GrueMaster> Physically, it has 6 RCA jacks on what would be the back of the board.
<GrueMaster> On the front between VGA and serial are the mic & headphone jacks.
<GrueMaster> From what I can tell in the driver, these are not connected.
<GrueMaster> Not sure about the physical wiring yet.
<GrueMaster> Speaker-test works fine on the RCA plugs.  But no playback from Rhythmbox (pulseaudio actually spikes up to 50% CPU).
<persia> Do you get any input or output from anywhere?
<persia> Ugh.  That usually comes from internal resampling when it's misconfigured.
<GrueMaster> I initially tried the fix we made to pulseaudio in Lucid, but no effect.
<GrueMaster> I can try to muck up the alsa bits, but I really am out of my element on pulseaudio.
<GrueMaster> At least I still have my X0 running Lucid for reference.
<persia> That pulse hack doesn't seem like enough to me.
<GrueMaster> Not that it does much good.
<GrueMaster> The pulse hack is what got the right controls working in Lucid.  I'll have to see if it still works on Maverick on that board.  I doubt that it will, though.
<GrueMaster> I guess I need to figure out how to get the existing audio to go through pa first.  Then I can look into the HP & Mic.
<persia> OK.
<persia> I've just looked through the pulse mapping configuration.
<persia> I think the method you used last time remains the right way to address it: first make sure you have all the outputs in ALSA, then review the mapping in the pulse configuration.
<GrueMaster> Ok
<GrueMaster> I'm looking at alsamixer now and will compare with lucid on X0.
<persia> I think I understand what crimsun was doing, and we can probably replicate that if we need, but I think the more important part is that you aren't seeing the headphones in ALSA.
<persia> (at least for the problem with the mic & headphone jacks)
<persia> For the "it doesn't work in Rhythmbox on the RCA jacks" issue, I have a sense that we'll end up with a slightly different solution if we try to sort that now vs. first getting everything represented in ALSA, and I'd rather only try to do it once.
<GrueMaster> Ok, nothing in alsamixer affects HP jack.  Very odd.
<persia> Not really, if the jack isn't exposed.
<persia> alsamixer can only act on elements exposed by the driver
<GrueMaster> Well, yea.  Just odd that if it isn't used, why is it on the board.
<GrueMaster> I guess I will need to dig for specs on that codec then.  Usually the codec driver exposes all to alsamixer.
<GrueMaster> It currently shows a lot more than the machine dai has defined.
<persia> I expect there is intent to use it eventually, but it wasn't a priority for porting.
<persia> It's not an issue if there is stuff not exposed in the DAI, as long as it's also not wired to anything :)
<rsalveti> cooloney: hey!
<rsalveti> cooloney: third time I'm compiling the kernel and seems to be fine
<rsalveti> will continue stressing the system to see if I still get the bus error
<cooloney> rsalveti: hey, man. do you mean 2G:2G split with npitre's VMALLOC_END patch?
<rsalveti> cooloney: yep
<cooloney> yeah, i think so
<rsalveti> highmem = 0k
<cooloney> that's is workaround for us, if we have to workaround it before 10/10 release
<cooloney> rsalveti: exactly
<rsalveti> will let it running during the night, let's see if it'll go well
<cooloney> cool
<cooloney> i am trying to find out highmem usage when bus errors pop up
<cooloney> any suggestion?
<cooloney> i think we already enabled CONFIG_DEBUG_USER
<rsalveti> cooloney: hm, that's what I was going to ask you
<rsalveti> CONFIG_DEBUG_USER=y
<rsalveti> yep
<cooloney> i enabled CONFIG_DEBUG_PAGEALLOC=y
<npitre> cooloney: just recreate the bus error, then see what dmesg says about it
<rsalveti> also, shouldn't we set user_debug at the cmdline?
<npitre> cooloney: you should get a full register dump and stack trace, etc.
<rsalveti> npitre: Unhandled fault: imprecise external abort (0x1406) at 0x2b805000
<cooloney> rsalveti: yeah, like that.
<rsalveti> and the kernel build: internal compiler error: Bus error
<cooloney> npitre: http://pastebin.ubuntu.com/499410/
<cooloney> something like this
<npitre> hmmmmmm
<npitre> you will have to dig in the OMAP4 and/or the Cortex A9 manual to find out about what may cause an imprecise external abort
<npitre> is it possible to boot this thing with L2 cache disabled?
<npitre> that would be another thing to test
<npitre> also, does the stack backtrace go back to __dabt_svc or __dabt_usr?
<GrueMaster> persia: Sweet.  They are using a Realtek ALC655.   I say that because they always have had excellent documentation online.
<persia> Oh, nice!  This oughtn't be that hard at all.
<cooloney> npitre: let me try to disable L2 cache.
<cooloney> npitre: and it looks like the oops is from __dabt_usr()
 * freeflying 
<npitre> cooloney: strange
<npitre> cooloney: this actually looks like if the external abort occurred while the CPU was already in __dabt_usr
<cooloney> npitre: yeah. i am digging in the Cortex manual.
<cooloney> for imprecise external abort, it looks like no specific root cause.
<cooloney> but there is an errata of Cortex A9 MPCore
<cooloney> npitre: 743626: An imprecise external abort received while the processor enters WFI may cause a processor deadlock
<rsalveti> cooloney: npitre: ouch, got the bug without highmem :-(
<rsalveti> but now a little different: Bad mode in data abort handler detected
<rsalveti> let me paste it
<rsalveti> and now instead of a bus error I got a segfault in gcc
<rsalveti> the only difference is that I'm not building the kernel with -j3
<rsalveti> *now
<rsalveti> this bad mode issue seems worse than the external abort...
<hrw> morning
<jo-erlend> can I use debs for maemo in Maverick?
<jo-erlend> thought I'd try x2goclient on my igepv2 and see if it's a viable thinclient in my environment, but the only ARM packages I can find is for maemo.
<rsalveti> persia: thanks for the review, will go over it later today
<ogra> oh, did he find aynthing ?
 * ogra didnt get any inof about it 
<jo-erlend> just can't get inof? :)
<rsalveti> ogra: sent just for me, will go over the list then and ask you a new review :-)
<rsalveti> if we're fine, we can try to push them
<ogra> rsalveti, awesome
<cwillu_at_work> jo-erlend, if you can get a source package, rebuilding it is probably straightforward;  otherwise, the deb may or may not work, depending on a bunch of stuff
<jo-erlend> I've never created a package before.
<persia> rsalveti, Mind you, it's *very* pedantic: don't worry if some things turn out to be annoying or hard.
<isbric> is there any way to bypass oem-install on first boot?
<persia> isbric, There are a bunch of ways, but that would leave you without a user.  What are you seeking to accomplish?
<isbric> http://elinux.org/BeagleBoardUbuntu#Lucid_10.04.1
<isbric> i dont have a monitor, thats the main problem
<rsalveti> persia: sure, np :-)
<isbric> "Note: On first boot, you must use an DVI/LCD monitor, oem-config seems to force tty0.. 2nd boot you can switch to serial by default.."
<isbric> persia: trying to finish the install with ttyS0
<persia> isbric, Ah.  I understand.  I think there's no way to complete it with the current images.
<persia> I think you'd need to build new images that used the debconf front-end for configuration, but I don't know that anyone defined an oem-config harness for that interface.
<cwillu_at_work> jo-erlend, sorry, went afk
<cwillu_at_work> jo-erlend, that's not what I asked :p
<jo-erlend> cwillu_at_work, did you ask me anything?
<cwillu_at_work> jo-erlend, if you can get a source package for the deb, then there's a good chance that dpkg-buildpackage will Just Work and give you a working binary deb that you can then Just Install.
<cwillu_at_work> jo-erlend, I didn't use a question mark :p
<jo-erlend> really? That'd be nice.
<jo-erlend> I'll have to look into that.
<cwillu_at_work> jo-erlend, you on ubuntu right now?
<jo-erlend> yes.
<cwillu_at_work> jo-erlend, open a terminal, make an empty directory, cd into that directory
<cwillu_at_work> next, apt-get build-dep xsplash
<cwillu_at_work> next, apt-get source xsplash
<jo-erlend> seems they don't make source debs available. They publish tar.gz packages only.
<cwillu_at_work> okay;  that's not impossible to deal with either :p
<cwillu_at_work> generally, unpacking the tar.gz, and then running ./configure, then make, will compile the package
<cwillu_at_work> if one is lazy at that point, a make install will generally install it, or you can use checkinstall to make a deb of questionable quality
<cwillu_at_work> in many cases, that's everything you need
<jo-erlend> checkinstall is new to me.
<cwillu_at_work> !checkinstall
<ubot2> checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
<jo-erlend> thanks. I'll go read now. :)
<cwillu_at_work> more fun to just dive in :)
<jo-erlend> hehe, not when things go wrong and you have to spend a week fixing the problems you wouldn't have had if you spent the ten minutes reading the manual first. :)
<jo-erlend> ok, I've give it a go. Thanks. :)
 * rsalveti lunch
<rlameiro> morning
<rlameiro> are there any know USB bugs on IGEPv2 or Beagle board?
<rlameiro> i searched in launchpad and found nothing, maybe I am doing someting wrong
<ogra> there are known HW bugs with beagle afaik
<ogra> with the pre-C4 boards
<rlameiro> ogra: the problem is that a device only works if pluged on start up
<rlameiro> and if i take it out, and try to put something there again, it will not enumerate
<ogra> what board specifically (nobody here has an IGEP2)
<rlameiro> I have :D
<ogra> well, let me rephrase ... what beagle ? :)
<rlameiro> http://pastebin.ubuntu.com/499799/
<ogra> which revision
<rlameiro> ahh
<rlameiro> IGEPv2 revision 3
<rlameiro> its one of the most recents one
<ogra> since the arm team doesnt have IGEP2 its very likely that we miss bugs there
<ogra> (and very unlikely that we get them fixed in time for maverick this late in the cycle, but you can try)
<ogra> i wouldnt expect more than one kernel upload for omap3 anymore before release though
<ogra> (i know there are already a bunch of IGEP2 fixes, if you can send patches along with the bug they might make it in)
<ogra> s/fixes/pending fixes/
<rlameiro> problem is that i am not a programer
<rlameiro> just user, trying to put the board making sound properly
<lool> rlameiro: That sounds like a bug; I think you should file it against the kernel you're running
<jo-erlend_igep> rlameiro, I have the same board and the same problem.
<rlameiro> I even bought a 30USD hub, bigger than my board to check if it was because i was using to much power on the usb rail...
<devilhorns> ogra, speaking of maverick ... is there anything that you need from me for that release ? (any more bugs, etc, etc) ?
<ogra> devilhorns, no, but i got you access to the upstream tree
<jo-erlend_igep> rlameiro, have you tried rsalvetis recent kernels?
<rlameiro> jo-erlend_igep: ok, so we can join forces :D
<ogra> devilhorns, mail coming with URL
<devilhorns> ogra, w00t ! :) thanks :)
<jo-erlend_igep> rlameiro, gladly. One big problem here, is that those who know what to do, don't have the hardware and we who have the hardware doesn't know what to do. :)
<ogra> lool, does linaro possibly have fixes ubuntu could pull in ?
<rlameiro> jo-erlend_igep: problem is that i Cant file bugs against other kernels that arent from ubunto or linaro
 * devilhorns now has to learn bzr for commits :)
<rlameiro> no one will look at them
<rlameiro> i want to fix ubuntu
<ogra> rlameiro, you should probably talk to the linaro guys, they might have patches for the issue we are just missing in the ubuntu kernel
<jo-erlend_igep> rlameiro, I've been acting as rsalvetis bot for a few days, and now screen and networking is working. Bluetooth and sound is not working and I cannot connect to wpa-protected wifis.
<lool> ogra: I didn't hear of a fix for this specific issue
<ogra> lool, ok
<ogra> but you seem not to see it in linaro
<rlameiro> ogra: why doesnt canonical just order a board, or even ask one for free? its only 145â¬....
<lool> jo-erlend_igep: Oh WPA was working for me with libertas-firmware
<lool> ogra: I didn't say that
<ogra> rlameiro, we'll likely do that for natty ...
<ogra> lool, no, was an assumption i shamelessly made :)
<lool> rlameiro: You're asking weird things  :-)
<rlameiro> free boards?
<lool> rlameiro: In any case, Linaro is also trying to support IGEP in their own OMAP kernels, and we do have some IGEPs
<jo-erlend_igep> lool, really? I have installed libertas-firmware.
<ogra> rlameiro, for maverick our main focus is and was omap4, we also did omap3 but only focusing on beagle C4 and XM
<rlameiro> free board is awesome :P
<ogra> for natty we might add IGEP2 to our list of HW to work with
<lool> rlameiro: You're asking Canonical to spend money and (more importantly) engineering time on IGEP; if you wonder why it's not being done, it's just because of the cost versus other things we could work on   :-)
<rlameiro> ogra: I got that, only problem is that almost no one has omap4, but omap3
<rlameiro> anyway, it is not my bussines anyway
<lool> jo-erlend_igep: I didn't test in the last couple of weeks, but it was the only thing which worked for me, yes
<ogra> omap4 vs omap3 will change quickly as soon as the boards are on the market
<lool> rlameiro: You're looking at the problem from the angle of "what would be the most profitable to the community", but another angle to the question is how to pay the engineers working on bugs
<jo-erlend_igep> I wonder how much faster omap4 will be IRL.
<rlameiro> ogra: true, but that means that the people that already have ompa3 boards need to go for ompa4.....
<rlameiro> lool: I will glady donate for specific things
<rlameiro> not for beagle Xm
<jo-erlend_igep> didn't we use to have "bounties"?
<ogra> rlameiro, well, our team is small we only have so much manpower to support three arches currently
<rlameiro> ogra: I know, and it is nothing against you, really
<lool> rlameiro: This is a nice thing of you; thanks for offering that!  I'm afraid Canonical itself is not setup to receive direct user donations (AFAIK), but perhaps you can offer a bounty to an interested developer/company to fix our pet bugs?
<rlameiro> people have always to much work, and to few people
<ogra> rlameiro, i didnt take it as something against me/us :)
<lool> rlameiro: True
<lool> What would be interesting is whether the bug is also present on other OMAP3 boards like beagles or beagle XMs
<rlameiro> lol, why would it be against you???
<lool> and also whether it's present in the upstream tree or not
<ogra> rlameiro, we like to fix bugs (and as you can see on rsalveti helping jo-erlend, we even do it actively as good as we can)
<lool> It might just be a kernel config being mis-set
<ogra> rlameiro, the main problem is the time of release you approach us
<ogra> a month ago everything was easier
<rlameiro> ogra: I know. my only problem is with the "upper" people
<ogra> the later we get into the cycle the harder it gets to make changes
<ogra> which "upper" people ?
<rlameiro> they market ARM as the big bet , but then puts little engineers on it and then they need to make everything
 * jo-erlend_igep is really grateful for the help rsalveti has given him.
<ogra> we actually can work fine with community members to fix HW we dont have but that requires far more time
<ogra> which measn such things need to show up earlier in the cycle or they will suffer from our focus on HW we actualyl have
<rlameiro> ogra: and I really love to do that to :D
<rlameiro> I filed some bugs already and help debuging some stuff also
<ogra> yes, i saw that
<ogra> and you are doing great :)
<rlameiro> yea early on the cycle i couldnt even boot my board with ubuntu....
<ogra> i also dont want to turn you down in what you do, i'm just trying to explain the situation
<rlameiro> ogra: you dont need to explain, you make a great job in here, believe me.
<lool> rlameiro: Is there a LP bug # for the USB issue you mentioned earlier?
<ogra> if you file a bug it will definitely be taken care of ... its just not clear if it will make it into the release or has to wait for an update or worst case for next release
<rlameiro> lool: no, thats why i felt it was weird, because its a really common thing
<lool> ogra: By whom?
<ogra> lool, for what ?
<lool> rlameiro: Would be good if you could file it, explaining which devices you're testing, on which USB port etc.
<ogra> lool, the SRU or the next release ?
<lool> ogra: You say it will be taken care of
<ogra> by the kernel team or us
<ogra> or linaro
<jo-erlend_igep> rlameiro, the USB issue, as I understand it, is that if you disconnect and reconnect a USB device, then it's not  being recognized? Does this also affect keyboard and mouse?
<lool> ogra: Are you folks committed to fixing OMAP3/IGEP bugs?
<ogra> or a combination of these
<ogra> no
<ogra> but there is interest on our side to have them fixed
<ogra> as there is interest to get all other omap3 HW working
<lool> Oh ok, you were saying "it will definitely be taken care of", so I wondered
<rlameiro> jo-erlend_igep: yes, my mouse isnt reconigzed after I unplug something
<ogra> someone will do it, i'm sure
<jo-erlend_igep> rlameiro, have you tried the new kernel from rsalveti?
<ogra> lool, i know rsalveti cant sleep if bugs exiost in the world :) and i know mpoirier has interest in IGEP2
<jo-erlend_igep> rlameiro, I no longer have that problem, but I remember having it in the beginning.
<rlameiro> no, jo-erlend_igep but as i said, i wanted to help debug stuff in ubuntu, but it seems i will need to use other kernels
<lool> ogra: Ok; I don't want jo-erlend_igep and rlameiro to be disappointed if you say it will definitely be taken care of, but then it might not
<lool> I'm certainly interested in having it in our list of Linaro IGEP bugs if it can be reproduced with Linaro kernels
<ogra> lool, well, given linaro uses that HW i would expect you guys to hit the same bug at some point for example ...
<ogra> so there might be a patch that suits both teams
<rlameiro> lool: I iam runing a linaro kerne
<rlameiro> *kernel
<lool> rlameiro: And you have the same issue?
<rlameiro> lool: yes
<jo-erlend_igep> rlameiro, I'm using rsalvetis kernel. The only thing that doesn't work, is audio, bluetooth, and possible wlan. I haven't had time to really look into the wlan issues yet.
<rlameiro> lool: the most recent linaro kernel on the repos
<armin76> lool: you don't get cool hw anymore? :P
<lool> armin76: ?
<ogra> armin76, IGEP2 isnt cool ?
<armin76> well, its not an omap4
<lool> I don't have OMAP4, no
<rlameiro> jo-erlend_igep: for the wlan, you need to put the libertas firmware in helper by hand, i am not sure if they are opensource
<ogra> its also not a tegra2
<ogra> nor an xscale
<lool> rlameiro: Nope; but the package in multiverse worked forme
<lool> rlameiro, jo-erlend_igep: So would either of you please report the USB issue with the exact kernel version, USB port, and device you folks are using?
<rlameiro> IGEPv2 wat the first dev board to have LAN, wifi, bluetooth 512/512mb on the market
<ogra> GrueMaster, hey, i fixed the "all headers installed" issue :)
<jo-erlend_igep> lool, I no longer have that issue, so that'll be a bit difficult.
<GrueMaster> cool
<ogra> tomorrows images will only ship the actually needed headers
<lool> jo-erlend_igep: Oh you *don't* have the USB issue, so it got solved by a kernel update?
<GrueMaster> Heh.  Promises, promises.  :P
<rlameiro> lool: where do i file it? lp?
<ogra> heh
<lool> rlameiro: Yup
<lool> rlameiro: Ideally, just "ubuntu-bug linux-linaro" or linux if you're running an Ubuntu kernel
<jo-erlend_igep> lool, I _think_ one of salvetis kernels fixed it. That is to say: I think I had the problem, but if I did, I don't anymore. :)
<lool> jo-erlend_igep: hmm ok
<ogra> so there is a patch *somewhere*
<ogra> :)
<ogra> hidden in rsalveti's branch on the ubuntu git server i bet :)
<jo-erlend_igep> lool, not the best comment for a bug: Â«This was maybe fixed by something that somebody might have done.Â»
<lool> jo-erlend_igep: Yeah
<lool> I'm counting on rlameiro to file the bug though, as he is seeing it
<ogra> jo-erlend_igep, "that was fixed with a manual build i got from ... "
<ogra> ;)
<rlameiro> doing it now, plus debbuging
<mpoirier> berco: good morning
<mpoirier> Irg: good morning
<rlameiro> done lp#646985
<rlameiro> done lp #646985
<ubot2> Launchpad bug 646985 in linux-linaro (Ubuntu) "[IGEPv2 board] The USB systems cease to work after an unplug event on linux linaro kernel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/646985
<rlameiro> lool: ping
<rlameiro> jo-erlend_igep: maybe you can comment on this bug saying what kernel you use and that you dont have the problem anymore
<lool> rlameiro: Could you note which of the USB ports you're using?
<lool> rlameiro: Hub/no hub and the like
<rlameiro> ok
<jo-erlend_igep> rlameiro, sure.
<rlameiro> lool: updated
<lool> rlameiro: If you're tempted to compare with the Ubuntu omap kernel, that would be interesting
<rlameiro> lool: it didnt work also
<lool> I'm personally kicking builds of linux and linux-omap with the Linaro OMAP; perhaps these might hint at what's wrong?
<lool> rlameiro: Could you note which version you tried?
<rlameiro> wich version of the ubuntu kernel?
<lool> rlameiro: If that's the latest, then I'll add a task on the Ubuntu omap kernel
<lool> rlameiro: yup
<lool> Grmpf, my vm went down again
<lool> this is tiring
 * rsalveti back
<rlameiro> lool: it was this version linux-image-2.6.35-22-omap
<lool> rlameiro: Do you have the version of the package as well?
<lool> rlameiro: The "version" in the package name is just the ABI
<rlameiro> .33
<jo-erlend_igep> rsalveti, I never installed the linux-firmware-image_2.6.35.4+43_armel.deb package. Should I?
<lool> rlameiro: Ok, that's almost the latest kernel in Ubuntu, and the latest one doesn't seem to touch anything related
<rsalveti> jo-erlend_igep: you could, don't know if it'll make any difference for you
<lool> the only ARM change is "Adding vdd_sdi regulator supply to OMAP3EVM
<lool> "
<rsalveti> depends on what firmwares you actually need
 * rsalveti reading the backlog
 * rlameiro is going to eat something, bugs make him hungry
 * prpplague gives rlameiro some fried beattles and baked crikets
<rsalveti> jo-erlend_igep: are you sure you're using the same hardware rlameiro has?
<jo-erlend_igep> almost.
<jo-erlend_igep> rlameiro, you're using igepv2 rc?
<rlameiro> I am using a IGEPv2 rev 3
<rlameiro> rc 3
<jo-erlend_igep> oh. I'm using rc1.
<rsalveti> hm
<rlameiro> in the back i have RC and a 3 writen by hand
<rlameiro> jo-erlend_igep: can you check yours?
<rlameiro> in the back?
<rsalveti> rlameiro: without the usb-hub, does it also happens when you just use a mouse?
<jo-erlend_igep> rlameiro, I just did. It sais IGEP 0020 RC and then a hand written 1.
<rsalveti> I mean, using the mouse directly, without an usb-hub in the middle
<rlameiro> not sure, i will need to reboot and all the process again, but the mouse is usb 1.1 and the usb host oin the board is just/only 2.0, ence the need of a hub
<rlameiro> ok, more is more recent
<rsalveti> hm
<rlameiro> rsalveti: did you had acces to igep's kernel source?
<rsalveti> got the access to the website, but still didn't download it
<rsalveti> let me take a look on it
<rlameiro> do you want me put it on my dropbox for you?
<rsalveti> rlameiro: it'd be good to test with the stock kernel from igep, maybe they have the patch already but just didn't publish it
<rlameiro> rsalveti: with the mouse directly connected to the USB host on board, nothing
<rsalveti> rlameiro: nothing you mean it wasn't even recognized during boot?
<rlameiro> is there some tool that allows to visualize the diff of 2 kernel folders?
<rlameiro> rsalveti: yes
<rsalveti> diff would be enough, but I'm looking more to a git tree or something like that
<rsalveti> to see the patches
<rlameiro> but as I said, it is a 2.0 port, so it needs a hub to recognise a 1.1 usb
<rlameiro> they have a git repo
<rsalveti> rlameiro: do you have any other usb device that's 2.0?
<rlameiro> rsalveti: i am afraid not, everything is 1.1 compliant
<jo-erlend_igep> rlameiro, may I suggest that you try the rsalvetis kernel and see if that fixes it? At least that would confirm that something has changed in a good way.
<rsalveti> http://git.igep.es/
<rsalveti> the weird thing is that I don't have any usb-related patch...
<rlameiro> jo-erlend_igep: yes, i think i will do that
<jo-erlend_igep> is it possible that I had that problem with the Poky installation that came with the board, come to think of it. I'm just not sure anymore.
<jo-erlend_igep> rlameiro, great, then we will know for sure.
<rlameiro> rebooting...
<rlameiro> rsalveti: happens the same
<rlameiro> with you v4 image
<rsalveti> rlameiro: so this is probably related with your board revision
<rlameiro> weird..
<rsalveti> I'm digging the git tree to see if I see something
<rsalveti> rlameiro: do you have the board changelog between revisions?
<rlameiro> jo-erlend: can you unplug your hub and plug it again to se if it works?
<rsalveti> I'd bet we have a link for it, just didn't find it yet
<rlameiro> rsalveti: i am searching it
<rsalveti> usb: make disconnect and suspend interrupts work again
<rsalveti> from kernel changelog
<rsalveti> let me dig the commit
<rsalveti> rlameiro: ^
<rlameiro> hummm
<rsalveti> http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commitdiff;h=8ea712c38bd5e948d8f2a14d0c5bf4551032fe5b;hp=6fe3e7e1222a3ade418ad8c3b0542686a9a41f30
<rsalveti> but I believe we have this commit already...
 * ogra_ac guesses that will interfer with other omap boards
<rsalveti> we already have it
<ogra_ac> ah
<jo-erlend_igep> rsalveti, I just did. Everything works.
<rsalveti> their tree is based on 2.6.33 =\
<ogra_ac> ugh
<rlameiro> so, it could be because this is a different tree?
<ogra_ac> its three versions behind the current development tree
<ogra_ac> *and* it is a separate tree (linux-omap vs linux)
<rsalveti> good thing is that it seems they are maintaining a tree by rebasing their changes to 2.6.36
<ogra_ac> ah cool
<rsalveti> yup, much easier to get the fixes :-)
<rlameiro> rsalveti: http://dl.dropbox.com/u/1333955/MAN-PR-IGEP.0020.HW_USER_MANUAL.pdf
<rlameiro> page 16 starts talking about revisions, mine is a revision C.
<rlameiro> jo-erlend: can you please confirm you revision, if it is C or not?  if it is a B revision it should have writen on the board in white IGEP0020-RB1
<GrueMaster> Just fyi, I did a hot unplug, wait 10s, plug of my usb hub on my beagle.  Everything (keyboard, mouse, network, and usb drive with test media) came back no problem.
<GrueMaster> Interesting info in the beagle manual on the C3>C4 changes.  *Might* be applicable.  "Uboot:  Turning on VAUX2 for the EHCI fix" and A more advanced fix for the EHCI noise issue on Rev C3 board. This involves a
<GrueMaster> change in the power circuitry for the 1.8V rail supplied to the EHCI PHY interface. The power is now derived from the VAUX2 on the TPS65950 through a
<GrueMaster> filter circuit.
<GrueMaster> I wonder if any of that applies, since the IGEP is based on the beagleboard designs.
<rsalveti> rlameiro: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commitdiff;h=4911716a8b50fa080e613d2005d7d9a81255c0ca;hp=77fd21409771b51a3969da1f1724854901071e3f
<rsalveti> at this patch there's the code to identify the revisions, and set the correct pins for wlan and bt
<rsalveti> not related with usb though, but should also be applied
<rsalveti> I'm fetching the tree but I'm getting 14KiB/s :-(
<rlameiro> rsalveti: they have slow servers
<jo-erlend_igep> rlameiro, as I understand it, mine is revision c rc 1.
<rlameiro> ok, so mine has a 3 writen by hand, so it shouldnt be an hardware change, else they would write it on the board, its just for tracking of lots maybe
<lool> rsalveti: I think they have newer trees than .33
<lool> and at least for the kernel, they are sending some patches upstream
<rsalveti> lool: they have, these links I sent are all target for 2.6.36
<lool> rsalveti: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=shortlog;h=refs/heads/linux-2.6.35.y for instance seems to be their .35 tree
<rsalveti> lool: I'm trying to fetch the tree to see all the patches that could be important for us
<rsalveti> but will take a while, very slow server
<lool> you're pulling from a linux base, right?
<lool> I mean --reference
<rsalveti> lool: this branch is a merge branch from linaro, it seems
<rsalveti> not a rebase one, so need to check the differences comparing trees
<rsalveti> but doesn't seems to have any important fix related to usb
<lool> rsalveti: From linaro really?
<lool> I was expecting from linux-omap
<rsalveti> lool: well, there's a merge from linaro
<rsalveti> http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commitdiff;h=0a500156f2acfe06f270ba02ac004bae548e12d2;hp=27498d7ece6e964b9350aaad1fda1bd3d67e5c25
<rsalveti> rlameiro: lool: maybe this patch could help
<rsalveti> setting gpio for external vbus
<rlameiro> maybe
<rlameiro> its possible that is related to some change on the voltage when its unplugged that shuts down the power to that bus
<rsalveti> rlameiro: once the fetch is completed I'll generate a new deb for you to test
<rsalveti> rlameiro: could be
<lool> rsalveti: I find it really cool that they merge from Linaro
<rlameiro> rsalveti: i just dont get why does it work with jo-erlend_igep ...
<rlameiro> well, there is always the chance of hardware bug
<rlameiro> very unlikely, but possible
<rsalveti> rlameiro: yep, and could also be related with the peripherals he's using
<rsalveti> rlameiro: are you sure your usb hub is not pulling energy from the usb?
<rsalveti> it very common to find usb hubs that doesn't respect that and pulls a lot of energy from the usb
<rlameiro> this one, no, i bought it today on porpuse, beacuse of that
<rsalveti> even the powered ones
<rlameiro> it has is own power supply
<DanaG> I've seen some USB hubs that, when powered, push power back into the upstream port.
<rlameiro> well, that i cant say..
<GrueMaster> rlameiro: What is the ps supplied amperage?
<rsalveti> urgh, that's ugly
<DanaG> Rosewill has some USB hub power-adapters that give well over 5 volts when not heavily loaded.
<rlameiro> GrueMaster: the hub power supply its rated at max 2 Amp
<GrueMaster> Ok.
<GrueMaster> That should be fine then.
<rlameiro> and outputs 5v, so its not regulated inside the board
<rlameiro> well, at least AFAIK.... i didnt opened the hub yet
<rsalveti> you could measure it
<rlameiro> but the power supply is a switching power, so it should be regulated
<rsalveti> let's also wait to see if this patch could make any difference for you
<GrueMaster> I have the same powersupply currently powering my hub on my beagleboard (and my beagleboard is drawing power from it using a USB<>PS connector).
<rlameiro> dont have in here my multimeter
<rlameiro> GrueMaster: I was thinking in doing that :D
<rlameiro> but for now, my igep board uses a palm power supply from my old m515
<rlameiro> max output current is 1 Amp...
<GrueMaster> Hmmm.  I wonder if it is enough?
<rlameiro> well, i dont know, maybe
<rlameiro> let me check the hardware reference
<rlameiro> GrueMaster: 5Vcc / 1A
<rlameiro> it should be enough
<GrueMaster> I see that.  Still, could be wavering.  If you can, try a beefier ps.  The board will only draw what it needs.  Just keep it at 5v.
<rlameiro> typical is 650 mA, Max is 750mA, so it is more than enough
<rlameiro> but i will try with another PS. maybe from an atx ps that i converted to bench PS
<rlameiro> problem is that my electronic materials are at my parents garage....
<rlameiro> no space on the condo..... GRRRRR
<GrueMaster> Just be very careful.  We can't help if you fry your board.
<rlameiro> GrueMaster: dont worry :D I play with electronics for a while :D
<rlameiro> i wonder if this problems happens with the default poky on the nand...
<rsalveti> rlameiro: wait it a bit until I deliver you a new kernel, don't know how secure could be your usb hub
<rsalveti> at least the one I got I could easily fry the usb port
<rlameiro> ok, i wait
<rlameiro> lol
<rlameiro> no prob
<rlameiro> i send it back to ISEE :D
<rsalveti> then I had to remove a resistor from it to avoid pulling from the usb port
<rsalveti> haha :-)
<rlameiro> oh, you say the usb hub gets fried???
<rsalveti> no, the usb port from my computer, or board
<rlameiro> lol, that is not a problem, i just go to the shop and say, hey this port doesnt work!!!
<rlameiro> :)
<rsalveti> rlameiro: http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-5_armel.deb
<rsalveti> with the vbus patch
<rlameiro> rsalveti: thanks :D
<rlameiro> I will test it soon
<rsalveti> rlameiro: cool
<rlameiro> rsalveti: what is linux-firmware-image_2.6.35.4+-5_all.deb for?
<rlameiro> rsalveti: update-initramfs: Generating /boot/initrd.img-2.6.35.4+
<rlameiro> /etc/kernel/postinst.d/update-notifier: 17: gettext: not found
<rlameiro> it output this error
<rsalveti> rlameiro: linux-firmware should be the default firmware pack from the kernel
<rsalveti> you probably don't need it
<rsalveti> rlameiro: hm, try installing gettext and try it again
 * rsalveti brb
<rlameiro> rsalveti: this one has your network driver patch?
<rlameiro> t took alot time to bring it up
<rlameiro> dmesg at 65 seconds from boot
<rlameiro>     8.168334] libertas_sdio: probe of mmc1:0001:1 failed with error -2
<rlameiro> [   68.503753] net eth0: SMSC911x/921x identified at 0xe0808000, IRQ: 336
<rlameiro> rsalveti: same thing
<rlameiro> uInitrd is really needed?
<rlameiro> what does it have inside?
<Neko_> rsalveti, I have a related question, what on earth actually creates the uInitrd and uImage stuff from kernel packages?
<Neko_> I could not find a single line of code or script that uses uboot mkimage
<zumbi> Neko_: flash-kernel
<Neko_> oh okay
<zumbi> it should depend on uboot-mkimage too (at least on debian does)
<Neko_> ah but I installed uboot-mkimage but not flash-kernel
<Neko_> well okay
<rlameiro> is the uInird really needed?
<rcn-ee> rlameiro, pre-lucid that default for my kernels.. more things work better with a uInitrd...
<rlameiro> rcn-ee: ok, but what is inside of it?
<rlameiro> sorry for the newbiness
<Neko_> modules, busybox, some inity stuff
<rlameiro> so, the kernel could boot without it, could it?
<Neko_> it can and it does
<Neko_> but things like the splash screen are in there
<rlameiro> ohhhh
<rlameiro> ok
<rlameiro> lol
<rlameiro> uInird uncompreassing and reading takes half the time of my kernel booting
<Neko_> and maybe some ureadahead stuff? I'm not sure.. it would make sense that the initrd precache from disk
<rlameiro> so i think i will drop it
<Neko_> one thing I do know is without initrd maverick sometimes takes 30 seconds to get to login, but with, it's never more than 15.. sometimes it's 9 ;)
<Neko_> it's important because ubuntu and every other linux distro assumes you've got one and stuff gets shuffled in there
<rlameiro> ok, now you are talking :D
<rlameiro> but it dosnt have driver and stuff inside of it, does it?
<rcn-ee> it's got your modules. ;)
<rlameiro> lol, so i am debugging stuff with other modules...
<rcn-ee> correct, are you just trying to speed things up?
<rlameiro> no, just trying to prove that something is wrong with my usb host
<rlameiro> it doesnt work...
<rcn-ee> igepv2 right? the ehci or otg?
<rlameiro> as last resort, i used the igepv2 kernel
<rlameiro> but they dont have uInitrd
<rlameiro> hence the question
<rcn-ee> you can boot, then generate one. ;)
<rcn-ee> then reboot..
<rcn-ee> you can actually boot with the wrong different uImage/uInitrd's (it won't use it.) generate a new uInitrd and then reboot..
<rlameiro> but if i boot with another kernel, the modules inside uInitrd will not load if they arent build against it, true?
<rlameiro> ah ok
<rlameiro> well, then is confirmed
<rcn-ee> exactly.. so hopefully you extract the modules to your rootfs.. and that rootfs driver (extX) is builtin...
<rlameiro> either it is hardware bug, or some stuff igep needs to add to the kernel :D
<rlameiro> not my fault, not ubuntu fault, not linaro :D
<rcn-ee> btw, is it the ehci or otg port?
<rlameiro> ehci
<rlameiro> host
#ubuntu-arm 2010-09-25
<DanaG> I find that even my AHCI host system needs initrd, since the ahci driver is no longer built-in.
<rcn-ee> rereading bug report... rlameiro does it work if you leave a usb-flash connected when you remove and insert another device?
<rlameiro> rcn-ee: didnt tried
<rlameiro> i will try now
<rlameiro> need to reboot first
<rlameiro> rcn-ee: thats another weird thing
<rcn-ee> okay, no rush.. we had something like that on the beagle.. at one time everything had to be plugged in at boot.. weird things would happen if all devices where removed then added.. so the trick was to leave something connected.. 2.6.29 days..
<rlameiro> i plugged now the hub and it didnt recognied it
<rlameiro> it needs to be connected at boot
<persia> rlameiro, You don't want to not use an initrd: theoretically it works without one, but that path is very poorly tested, and prone to issues.
<rlameiro> rcn-ee: !!!!! WORKS!!!!!!!
<rlameiro> how can i mount my flash drive on the cli
<rcn-ee> mkdir ./tmp ; sudo mount /dev/sdxX ./tmp
<rcn-ee> so it sounds like an ehci bug.. when no devices are connected it turns to a state and new devices don't get it out..
<rlameiro> yeap
<pwnguin>  /win 14
<rlameiro> rcn-ee: how do i know th xX on the sdxX ??
<rlameiro> sorry for the newbiness
<rcn-ee> no problem... "sudo fdisk -l" L.. is easiest
<rcn-ee> thinking out loud and googleing..... isn't there a "debug-usb" option for the bootargs?
<rlameiro> rcn-ee: so, is there a correction for this bug?
<rcn-ee> on the beagle it was: use a newer kernel that worked better... but that was 2.6.27/28/29 days.. so i dont' think that one applies..  I'm looking on google for a way to debug the usb subsystem on bootup, maybe that would show something..
<rcn-ee> rlameiro, does your current kernel have "cat /boot/config-* | grep CONFIG_USB_DEBUG" ?
<persia> I think most of the DEBUG config options aren't used (and `grep CONFIG_USB_DEBUG /boot/config-*` is faster)
<persia> Unless there's a way to change them via boot parameters, might need a special kernel build.
<rcn-ee> yeah it is thanks. ;)  rlameiro does it also happen with my kernel?
<rcn-ee> take me about 3 minute to build one if it does..
<persia> (we had issues in the past with kern.log overflowing the SD cards, and had a firm discussion with the kernel team)
<rcn-ee> yeah, that's way to wear out an SD card quickly. ;)
<rlameiro> rcn-ee: yes it did  happend with you kernel
<rcn-ee> okay, then it'll be a valid test, just take a moment..
<persia> Filled them up back in the early imx51 days when folks were using pre-pre-pre-production hardware.  I ended up writing a syslog.conf fragment so that people could complete the installer.
<rcn-ee> I'm seeing something similar with my hacked up lucid NetInstall, the 2.6.35 kernel's HID input it noisy, the log is unreadable..
<rcn-ee> okay they are up... rlameiro uImage and modules here.. and yes it's about 20kb download. ;) good for beer breaks..  http://rcn-ee.homeip.net:81/testing/lp-646985/CONFIG_USB_DEBUG/
<rlameiro> rcn-ee: what did you put on your kernel?
<rlameiro> its working
 * persia dislikes heisenbugs intensely
<rcn-ee> crap, what? did my previous build work? alli changed was two configs...
<rlameiro> well
<rlameiro> stoped working...
<rlameiro> wow
<rcn-ee> yay! ;) the logs should have more usb stuff..
<rlameiro> where is the log file?
<rcn-ee> it should be in the system log... off the top of my head i don't remeber which one.. but "dmesg > log.txt" then pastebin that log.txt should give us an idea of what's happening..
<persia> /var/log/kern.log most likely
<persia> Oh, and /var/log/dmesg.log may also be interesting, but likely less verbose.
<rcn-ee> so both just incase. .;)
<rlameiro> rcn-ee: http://dl.dropbox.com/u/1333955/usb.txt
<rlameiro> dmesg > ub,txt :D
<rlameiro> i forgot how cool is piping :D
<rcn-ee> humm.. usb: resume on port1, status -19
<persia> Next trick: `pastebinit /var/log/dmesg`
<rlameiro> dont be scared its a 10 port hub
<persia> The one with the extra socket on the end?
<rlameiro> http://pastebin.com/P613QrxR
<rlameiro> persia:  its trust one
<persia> different than mine then :)
<rlameiro> http://www.trust.com/products/product.aspx?artnr=16131
<rcn-ee> humm, i'm stumped. ;)  i'd add that dropbox link to the launchpad bug, we are going to need one of the ti/nokia usb guys to look at it..
<rlameiro> good that you mentioned it
<rlameiro> i could delete it otherwise
<persia> Better to put the original file into the bug, rather than the link to dropbox, just in case.
<rcn-ee> you could upload it too.. then not worry about hosting it..
<rcn-ee> it looks like it's defintelly stuck in suspend mode...
<rlameiro> i can try with a diferent hub
<rlameiro> 4 ports self powered
<rlameiro> will it make diference?
<rcn-ee> it might... if it fails it's just more ammo for a bug..
<rlameiro> ok
<rlameiro> http://pastebin.com/RmnF40NZ
<rlameiro> with the other, this was faster failing
<rlameiro> rcn-ee: http://dl.dropbox.com/u/1333955/usb4.txt
<Neko_> is there a uboot irc channel?
<persia> Neko_, Used to be #u-boot, but has been deregistered.  Dunno to where folks may have migrated (if they did).
<ajay> hi all i have ubuntu 10.04 kernel and Serial controller: Device 4348:3253 but minicom is not working on this
<ajay> i mean no boot message i  am able to get over serial port
<persia> The images we produce don't use serial console by default.
<persia> You'd have to do something special to get one (add it to kernel command line, etc.)
<rcn-ee> hey persia, how frozen is the kernel for new patches? ;)  With the help of some meego guys, we figured out which 11 patches cherrypicked from 2.6.36 make the display work correctly on 2.6.35.. ;)  I'll file a bug and list the patches, so you guys can decide. ;)
<rcn-ee> duh, i should list teh board... devkit8000
<persia> rcn-ee, Which kernel?
<persia> (the answer will be somewhere between jello and cabonite)
<rcn-ee> the 11 patches were merged in the 2.6.36-rc with tony's merge.. they apply cleanly to the 2.6.35 kernel..  They basicly fix the power rails so the display actually gets setup properly...
<persia> I should have asked: "Which kernel source package in Ubuntu?"
<rcn-ee> um.. the combined omap3/x86 tree.. it only touches arch/arm/mach-omap2/board-devkit8000.c
<persia> "linux"?  That would be "carbonite".  We have to show security fault, major regression, user data loss, etc.
<persia> But we can prepare a set of patches to be dropped immediately post-release as an update.
<rcn-ee> right now it'll bootup: omapfb error or something about can not init display....
<rcn-ee> the problem with these boards, not a lot of people have them so it's not a big % (i don't even have one to test)  But i can file a bug link to the patches then if someone tries to run ubuntu with a devkit8000 will have a bug to read and help debug. ;)
<persia> Please do file a bug.  Extra points for shepherding the patches through the SRU process to make them available post-release.
<persia> Folks won't be able to use the display first-boot, but ought be able to update, and use it second boot.
<rcn-ee> true..  and since they are merged, maverick+1 will work out of the box.. (pending some random breakage patch. ;))
<rlameiro> afternoon
<rlameiro> jo-erlend_igep:hey, wasnt you that had a problem with wifi on igep?
<rlameiro> igep is going to launch a 1ghz version with OMAP3730
<rlameiro> saturday its really slow over here...
#ubuntu-arm 2010-09-26
<rlameiro> rsalveti: are you there?
<persia> rlameiro, Just quiet on the weekends, mostly.  I don't believe there are too many hobbyists here yet.
<rlameiro> :)
<rlameiro> well, here I am
<rlameiro> fiddling with it
<persia> Yep :)
<rlameiro> on top of that the video output is shifting completely the image on the tv to the left and overscaning
<rlameiro> ...
<rlameiro> there is something on the ubuntu kernel/uInitrd that bypass the uboot omafbdirectives
<rlameiro> fbcvt
<dcordes> hi
<dcordes> ogra: Any smartbook news ?
<ogra_cmpc> dcordes, http://tosh-ac100.wetpaint.com/thread/4253563/kernel+boot
<dcordes> ogra_cmpc: good stuff
<marvin24_> hi, we also have a channel (another one ;-) -> #ac100
<ogra_cmpc> marvin24, awesome
 * ogra_cmpc joins
<ogra_cmpc> persia, ^^^^
<dcordes> marvin24_: cool
<persia> I'm excited, but don't have the attention for another channel just now.
<ogra_cmpc> persia, i meant the url :)
<persia> the URL looks very promising indeed.
<ogra_cmpc> yes
<ogra_cmpc> i can boot android from a local kernel
<ogra_cmpc> using this reciepe
<persia> Can you boot a useful operating system?
<ogra_cmpc> probably ... the prob is that i cant get any visible console
<dcordes> ah
<dcordes> common androidism
<persia> consoles are overrated :)
<ogra_cmpc> trying the tegra kernel with omap4 rootfs doesnt get me anywhere either
 * ogra_cmpc just tries with a panda SD here 
<dcordes> ogra_cmpc: check if you have framebuffer console (fbcon) enabled in your kernel ( /proc/conf.gz )
<ogra_cmpc> dcordes, its off
<ogra_cmpc> thats the prob :)
<dcordes> ogra_cmpc: ok. did you also request the sources ?
<ogra_cmpc> no
<ogra_cmpc> and i didnt checl the link from the EULA for two weeks either
<ogra_cmpc> ac100 is a weekend project for me
<ogra_cmpc> so i'm very slow on it
<dcordes> to me all of this is a weekend project ;)
<ogra_cmpc> persia, so i have a way to run a full ubuntu netboot session ... but no input devices work at all
<ogra_cmpc> s/netboot/netbook
<ajay> hi all , i have connected usb to serial adapter which is detected as /dev/ttyUSB0 and then i have connected to it a straight null modem cable which i have shorted at 2 and 3 pin number but  i am not able print anything in minicom or getting echo of it
<persia> ogra, Nice progress.  My recommendation would be to start an image that allowed ssh so you can get in there, and then play with input-utils to see where things are wrong: sounds like issues with the HID drivers.
<ogra_cmpc> persia, heh, that would require xinput to work at all
<ogra_cmpc> the system is still chrooted
<ogra_cmpc> no udev, no upstart
<ogra_cmpc> the android system is the most minimal but its still a chrooted android
<persia> Ah, without udev, I have little advice.  But working with ssh/input-utils shouldn't require xinput for a properly constructed image.
<ogra_cmpc> well, the touchpad works with an xorg.conf
<persia> And if input-utils can't deal with a device, the chances that xinput knows what to do are strikingly low (unless, for some reason, one is dealing with non-HID devices)
<ogra_cmpc> the kbd is recognized in the logfile
<ogra_cmpc> but doesnt hand anything through
<ogra_cmpc> [ 11283.000] Generic KBD: dropping event due to full queue!
<ogra_cmpc> thats what i see in the log
<persia> Touchpad can be fixed with some udev properties then: that's trivial.  keyboard probably still requires fiddling with input-utils to make sure there is connectivity, symbol mapping, etc.
<ogra_cmpc> i dont need to ssh ... androids adb shell is running
<persia> If you don't need to ssh, install input-utils, and try to probe the keyboard.  I've locked up a couple systems doing that with exceedingly exotic input devices, (reboot was always clean), but usually they get enough low-level information that one can make the higher levels work.  Might need udev properties.  Might need remapping.  Might need explicit support in the HID driver, etc.
<ogra_cmpc> well,, no udev properties possible without udev :)
<persia> No, but it's possible to determine which properties are required :)
 * persia really ought file some remapping for the Saitek Commander one of these days.
<ogra_cmpc> /dev/input/event0
<ogra_cmpc> protocol version mismatch (expected 65537, got 65536)
<ogra_cmpc> thats what i get for :/# input-kbd /dev/input/event0
<ogra_cmpc> same thing for input-evente
<ogra_cmpc> *input-events
<persia> Bother.  I thought I fixed that.
<ogra_cmpc> well, given the million lines of " Generic KBD: dropping event due to full queue!" in the xorg log ...
<ogra_cmpc> that might not actually be input-utils fault
<ogra_cmpc> i wish we still would build the old kbd driver for x
<ogra_cmpc> so i had actually some alternative to try
<ogra_cmpc> but there is only evdev nowadays
<persia> input-utils queries the kernel directly.  Nothing to do with X.  It makes debugging the new X input scheme *much* easier.  This is all good: don't be nostalgic: it used to take forever for those of us who cared to painstakingly map things in the kernel and then *do it all over again* in an X driver.
<persia> Try `input-kbd 0` rather than /dev/input/event0
<persia> Also, try lsinput to make sure 0 is your keyboard :)
<ogra_cmpc> :/# lsinput
<ogra_cmpc> /dev/input/event0
<ogra_cmpc> protocol version mismatch (expected 65537, got 65536)
<persia> Right.  Kernel bug :)
<ogra_cmpc> well
<ogra_cmpc> [12262.640000] init: untracked pid 20189 exited
<ogra_cmpc> android *is* a kernel bug
<persia> Yep.
 * persia decides to sort out why the W axis isn't working on this mouse another day, and goes in search of food.
<ogra_cmpc> yeah, i'll better finish the day :)
#ubuntu-arm 2011-09-19
<brokencodes> hello...
<brokencodes> still persuing login prompt... http://paste.ubuntu.com/692648/
<brokencodes> it stops RIGHT there, next action suppose to be getty, never gets there
<brokencodes> or
<brokencodes> getty dies?
<brokencodes> it boots fine in qemu-system-arm, with its kernel, but not with the target kernel for this board, and they are the same processor / variant
<brokencodes> only getty seems to fail
<tmzt> qemu won't boot your board's kernel unles you add support to qemu for your hardware
<brokencodes> you thinking backwards
<brokencodes> qemu boots fine
<brokencodes> board stops at getty
<phh> you're sure you're not just doing getty at the wrong place ? :D
<phh> i mean wrong serial port
<brokencodes> how to redirect getty?
<phh> ????
<phh> wat ?
<brokencodes> kernel bootargs includes console=/dev/ttyS0 115200n81
<phh> ah i forgot ubuntu no longer uses inittab for getty ...
<brokencodes> debian does same damn thing
<brokencodes> stops at getty
<phh> brokencodes: well what's the getty command line on debian ?
<brokencodes> I dont know
<phh> OKAY
<mikejf> brokencodes: What does the 'exec' line of '/etc/init/ttyS0.conf' say?
<phh> how do you know if it ever tries to start ?
<brokencodes> I would have to trace the initscripts
<tmzt> it's upstart isn't it?
<brokencodes> give me a min, I go back inside, hook up the devboard, we can investigate it...
<phh> mikejf: /etc/init ? http://doc.ubuntu-fr.org/console_serie is saying /etc/event.d :(
<phh> tmzt: that's why i meant it's easier on debian :p
<phh> good old inittab ..
<brokencodes> ok, then we will stick with debian for now
<phh> brokencodes: mikejf just gave you the path for ubuntu ...
<brokencodes> hooking upthe debian drive,and reloading the kernel image over tftp, saving to nand
<brokencodes> added another line to inittab... waiting to see result
<brokencodes> rebooting
<brokencodes> I have a login prompt!
<brokencodes> YAY
<brokencodes> thank you
<phh> .
<brokencodes> what is " . "
<brokencodes> ?
<ogra_> janimo, the current mx5 images should be fie for testing (ignore the isos next to them)
<janimo> ogra_, cool, I'll download
<ogra_> *fine even
<janimo> ogra_, good the image at least has correct partitions :) flashing it now
 * janimo wishes we had headless images. Easier to test than desktop
<janimo> for common bringup bits
<ogra_> well, i used to build server
<ogra_> but we are already massively interfering with beta builds already
<ogra_> i cant just randomly build stuff anyome at this stage of the release
<ogra_> sorry for that
<utlemming> janimo, orga_: what type of builds do you need?
<ogra_> utlemming, test builds in the datacenter on the builder
<utlemming> I'm making cloud-images daily for ARM images -- one that has a boot loader configured for serial and the other is flat partition
<utlemming> both are in qemu QCOW2 format, so they'll need to be converted
<utlemming> http://uec-images.ubuntu.com/oneiric/current/
<janimo> ogra_, the mx5 image boots up to X fine, resize seems to have gone well too.
<ogra_> awesome
<janimo> Nothing else shows up - no installer - though. Progress anyway.
<janimo> Need to see if omap works first, and mx5 should match it in terms of functionality
<ogra_> hmm, not much time left to fix it though
<ogra_> you need to have all fixes in today
<ogra_> if possible
<janimo> well, need to see if omap works first, as they may not be mx5 related issues at all
<ogra_> so fixing mx5 now broke ac100 :(
<topi1> hi
<topi1> i have a problem with compiling util-linux2.19 on my beagleboard:
<topi1> http://paste.ubuntuusers.de/402767/
<topi1>  with an x86 gcc its all ok
<topi1> can anybody help me?
#ubuntu-arm 2011-09-20
<rsalveti> Dr_Who: infinity, ogra_ and janimo can also help reviewing and sponsoring libjpeg-turbo if needed
<Dr_Who> rsalveti: good idea!
<rsalveti> the FFe is mostly accepted already, as we got an ack from both skaet and slangasek at latest release meeting
<doad>  wired internet its only letting me use wireless and when i go into a terminal and type in a command my eth0 does not show up
<doad> what can i type in my terminal to see if my ethernet port is working
<doad> what can i type in my terminal to see if my ethernet port is working
<ppisati> GrueMaster: since you do a lot of testing, have you ever tried unplugging the sd card after boot? (of course when it's not mounted)
<ppisati> GrueMaster: or have you tried booting entirely off some other media, and when the system is up, have you tried inserting the sd card?
<ogra_> he did some stuff with that on netinstalls iirc
<ppisati> ok
<ogra_> and had funny results
<ppisati> same here
<ppisati> hrw opened a bug about sd being inacceisble if he removes/reinsert the sd card
<ogra_> well, wait until janimo's drop of the vfat mangling show up in the images
<ppisati> no no
<ogra_> though wait, you dont use preinstalled, right ?
<ppisati> i use preinstalled
<ogra_> how can you unplug the rootfs then ?
<janimo> sheer force
<ogra_> yeah
<ogra_> or abuse of the images !
<ppisati> becasue i moved averyrthing to usb
<ogra_> he doesnt use them in their intended environment !
<ogra_> evil guy you :)
<ppisati> i use the sd card just for uImage&c
<ppisati> :)
<ppisati> well
<ogra_> i would recommend using a netinst for such setups
<ogra_> while it should indeed work to copy the rootfs to another device you never know what mistakes you make doing that
<ppisati> but i just found out, that if i boot from another media (no sd card inserted during boot)
<ppisati> the sd slot is dead!
<ogra_> complain to u-boot or x-loader i guess :)
<ppisati> it doesn't recognize any sd insert&c
<ppisati> uhm
<ogra_> smells very much like either of them
<ppisati> that's why i asked GrueMaster, i have to try with some older release
<ogra_> did you try with an older u-boot and x-loader ?
<ppisati> and on xm now
<ppisati> nope
<ppisati> just oneiric/panda for now
<ogra_> i bet a beer that it works fine with nattys
<ppisati> i already own you a beer BTW :)
<ogra_> you can win it back now ;)
<ppisati> asd :)
<ppisati> ok
<ogra_> *g*
<ppisati> coffee and then back testing older releases...
<hrw> ogra_: its not uboot/xloader - kernel rather
<hrw> system booted, replace card = bug
<ogra_> hrw, i think tobin said he doesnt see it when rolling back to an older MLO/u-boot binary
<ppisati> hrw: have you tried the same with beagle?
<hrw> load kernel/initrd in uboot, 'bootm', replace card - bug
<hrw> ppisati: would have to dig out old C3 beagle
<ppisati> hrw: no prob, i'll do that
<ppisati> hrw: another thing that i discovered is that:
<ppisati> 1) if you boot from another media (load everything in memory, remove sd card and bootm)
<ppisati> if you tru later to insert the sd card, the kernel doesn;'t recognize it
<ppisati> 2) enabling MMC_DEBUG i see what it seems "activity" on mmc
<ppisati> even when it's not mounted
<ppisati> i wonder if it's polling
<ppisati> the slot for some reason
 * ogra_ thinks the kgeneral bug is that the kernel leaves to much initialization to x-loader
<ogra_> we ran into bad stuff using a different x-loader through that (the usbboot one) ... you cant use our kernel *at all* if you dont use MLO/u-boot (doesnt work with generic android bootimages for example because the majority of devices stays unintialized)
<ogra_> same would go for kexec
<ogra_> (using a binary kernel instead of u-boot.bin)
<janimo> ogra_, you were right, it is lz compressed. It worked for me before as I figured it out after much trial. But I forgot since :(
<janimo> anyway, going forward
<wookey> )win 21
<ogra_> yeah, i remember banging my head against the same issue a while ago
<janimo> I want every boring task on Earth be done by machines
<janimo> which is most of them
<ogra_> heh
<brandini> hello
<tgall_foo> ogra_, infinity, slangasek : would any of you be will to participate in the review of : http://revu.ubuntuwire.com/p/libjpeg-turbo  ?  Aiming for oneiric, universe, thanks!
<ppisati> hrw: it works on xm!
<hrw> cool
<hrw> but I ahve pandas
<ppisati> :)
<brandini> I just got my pandaboard booting
<brandini> the 11.04 release wouldn't boot properly for me
<GrueMaster> ppisati: I see you are looking at the SD bug I mentioned a while back.  Bug 844099
<ubot2> Launchpad bug 844099 in linux-meta-ti-omap4 "System fails to acknowledge changing of SD when rootfs is on a different device." [Undecided,New] https://launchpad.net/bugs/844099
<GrueMaster> ogra_: Reading the backscroll, what are you talking about on the usbboot not working?  It works fine since rsalveti updated the aboot bootloader.
<ppisati> GrueMaster: never seen that bug, i was working on hrw bug (that is a duplicate of yours actually)
<brandini> the world needs more arm
<brandini> is the natty process the update manager?
<GrueMaster> brandini: ???  That last sentence made no sense.
<brandini> GrueMaster: what is the natty process?
<gildean> in what?
<gildean> you mean update?
<GrueMaster> brandini: What exactly are you trying to do?
<ogra_> GrueMaster, i was referring to the need to fix it ...
<GrueMaster> ogra_: Fix what?  It is already fixed.
<ogra_> pointing out that way to many things are in the bootloader while they should rather (or additionally) be initialized in the kernel
<GrueMaster> Oh.
<ogra_> yes, i wasnt referring to the fix/bug at all
<ogra_> just to the fact that it actually needed to happen
<ogra_> for example theoretically it should be possible to add a hex header to a vmlinuz that can do kexec and use that instead of u-boot/MLO to chainload a kernel
<ogra_> but with the existing design that will never be possible without at least involving MLO
<ogra_> (though i suspect many things u-boot initializes wont be done by the kernel either)
<ogra_> sigh, the images are still building
<ogra_> over 4h already
<GrueMaster> afaik, MLO/aboot just initiallizes the main memory and a few minor other bits (i2c bus).  u-boot/kernel does the bulk.
<ogra_> well, wasnt the fix in the MLO code of aboot ?
<ogra_> now that didnt make sense
<ogra_> well, wasnt the fix in  aboot ?
<ogra_> that is better :P
<GrueMaster> But I also thought u-boot turns off everything it needs just before context switch to kernel.
<ogra_> i dont think it does
<GrueMaster> The fix was in aboot to initialize i2c iirc.
<ogra_> yeah
<brandini> GrueMaster: I'm doing an update to 11.04 using the update manager (which was a silly mistake) and I'm watching the process headless from remote trying to monitor when it finishes
<GrueMaster> Ah.  I usually just run "sudo apt-get update;sudo apt-get dist-upgrade" to pull the updates.
<ogra_> dist upgrade on SD card on an XM ?
<brandini> SD Card :(
<ogra_> oh, not a release->release one
<GrueMaster> Doing a full dist upgrade (Maverick->Natty) is a lesson in patience.
<brandini> I'm stopping by microcenter on the way home to pick up a usb->mSata adapter
<brandini> GrueMaster: it is :)
<ogra_> i thought you upgrade to oneiric, that would indeed be a waste of time
<brandini> really?
<ogra_> yeah
<brandini> 10.10 is better than 11.04?
<brandini> shoot :)
<GrueMaster> No, doing a release upgrade is a waste of time.  Faster to download a new image.
<brandini> yeah
<brandini> ok, that makes more sense
<GrueMaster> Doing an in-release update is however a good idea.  Just time consuming.
<brandini> do I have to do anything special to make the pandaboard boot off a usb device?
<ogra_> in-release is fine you just shouldnt try to do something else as well on the system :)
<brandini> heh, yeah :)
<brandini> the load is like 4
<ogra_> on the ac100 i actually dedicate time to it when i dont work
<GrueMaster> If you want to use your existing image, you will need to do it on a different system.  What I found works best is to attach both USB & SD to your desktop (not mounted) and use gparted to copy the rootfs partition.
<GrueMaster> Then you need to change the uuid of the rootfs partition on the SD and just reboot.
<GrueMaster> The panda will need the SD for boot partition.
<brandini> ok, that makes perfect sense
<ogra_> why wouldnt you just copy qemu-system-statci, chroot and do the dist upgrade that way ?
<ogra_> oh, you meant copying the rootfs
<GrueMaster> You can also try our netinstall for oneiric.  It will allow you to install to the usb drive directly with different filesystems (EXT4, btrfs, etc), use LVM, cryptfs, etc.
<brandini> ogra_: this is my first time goofing with these types of boards... so beginners luck?
<GrueMaster> The gparted copy method is what I used to create a USB drive with Maverick, Natty, and Oneiric all on one USB drive.  Makes SRU testing much easier.
<brandini> I thought this would be a great platform to serve some web stuff up for monitoring and managing my solar/wind power stuff
<GrueMaster> Now that sounds like a fun idea.
<brandini> it is
<ogra_> brandini, http://www.grawert.net:81/
<ogra_> ;)
<GrueMaster> Not sure how well everything for that will run under Natty.  I only did extensive server testing in Oneiric.
<brandini> I've got the web application built in go (#golang) and it serves things up really nicely
<ogra_> though thats runing on an x86 celeron
<ogra_> (simply because i had no beagle back then)
<brandini> hey, that's got solar/thermal :)
<brandini> how hot do your panels get when you're running water behind them?
<brandini> oh, it says right on it
 * ogra_ has a web based room heating control system too, that actually runs off a beagle C4
<brandini> That's exactly what I'm fleshing out!
 * brandini introduces himself to ogra_ 
<ogra_> well, the panel bursted, i havent gotten a replacement yet (condesed water froze inside and blew up one element)
<ogra_> it can get up to 130Â°C
<brandini> sheesh
<brandini> using copper?
<ogra_> the panels are supposed to survive up to 220
<brandini> efficiency drops quickly
<ogra_> yeah, to be honest i would rather have half of the collector replaced by power generating panels
<brandini> I just built a single wind generator using some PVC Pipe and I'm quite pleased with it
<brandini> 3 19" blades and a 30V DC motor... really works nice
<ogra_> cool
<brandini> where you from ogra_?
<ogra_> germany
<brandini> I'm from the states in ohio
<ogra_> hey hey
<Ursinha> :)
<Ursinha> GrueMaster, maybe we need an alarm, loud and red and blinking
<ogra_> soo ...binary  packages often have arch: any and arch: all components
<Ursinha> ogra_, right
<ogra_> the any components usually get built nativelyy
<ogra_> the all components all get built by the x86 builder
<ogra_> now the x86 builders are waaaay faster than the armel ones
<Ursinha> right
<ogra_> so rthey finish the package early ... and publish their stuff
<ogra_> arm simply doesnt have the new bits yet ... but the existing package has a versioned dep on the arch:all package (which was just updated by x86)
<ogra_> so you get uninstallable packages until armel has built
<Ursinha> this is messy...
<ogra_> which in some cases can take a day more
<Ursinha> but I got it now
<Ursinha> right
<ogra_> and that prevents images from building
<ogra_> there are two ways around it ...
<Ursinha> but you said there are no images since Aug 30th
<ogra_> fix soyuz to handle the packages right
<ogra_> or work around the whole issue by running a separate mirror (like linaro does)
<ogra_> we aim for the fix
<Ursinha> ogra_, is there a bug for that? because if that's causing lack of images like this, it's kind of critical
<Ursinha> and you might want to talk to the launchpad stakeholder in Ubuntu to have it fixed
<ogra_> i think there is a bug  (NCommander should remember the number, i'm not subscribed so i dont have bugmail for it)
<ogra_> and its known since quite a while ... even in higher levels ;)
<skaet> Ursinha, its been raised.  https://bugs.launchpad.net/launchpad/+bug/34086
<ubot2> Ubuntu bug 34086 in launchpad "removal of arch-all packages while there are arch-specific packages dependent on it results in uninstallable binaries" [Critical,Triaged]
<GrueMaster> Wow, that is very old.
<Ursinha> indeed
<Ursinha> but awesome that's already escalated :)
<rsalveti> after... 5 years
<Ursinha> rsalveti, better late than even later
<Ursinha> :)
<ogra_> well, its a heavyweight ... pushing it uphill needs many people apparently :)
<rsalveti> sure, just surprised it took so long
<ogra_> took 5 years to get the crowd together ;)
<Ursinha> ogra_, hehe, it's escalated, and people are apparently wrapping up the derived distros feature (which took some time to get completed)
<Ursinha> rsalveti, launchpad touches lots of aspects of ubuntu, it's hard to fix everything relevant in a reasonable time, I believe
<rsalveti> yup, probably
<rsalveti> but I also want the derived distro working properly ;-)
<rsalveti> that reminds me I need to ping some folks at launchpad
<ogra_> GrueMaster, janimo,  does mx5 need flash-kernel.conf ?
 * Ursinha adds #ubuntu-arm to the list of channels-to-lurk-in
<GrueMaster> Aha.  That's the problem.  On mx5, boot.scr, and uI* is on the second partition.
<ogra_> yeah, that shoudl get a flash-kernel.conf then :)
<ogra_> so you can set it
<ogra_> but i wonder if the code uses it yet
<GrueMaster> Trying to run it after manually fixing flash-kernel.conf.
<GrueMaster> We'll see if oem-config still crashes.
<ogra_> yeah, that should tell
<janimo> GrueMaster, I am working on that now
<GrueMaster> cool
<janimo> ogra_, uboot is not on the vfat partition but kernel and initrd are so presumably needs some flash-kernel.conf
<ogra_> yeah
<janimo> I wonder why resizing rootfs on mx5 is done in a blink
<janimo> IIRc on omap it had a progess bar and took a while
<ogra_> and it didnt fail ?
<janimo> maybe it doesn ot happen for some reason - bug to be hunted
<janimo> ogra no error msg, just Done
<GrueMaster> It may not be resizing the correct partition.
<janimo> It is suspicious probably does not happen
<ogra_> and your partition has the expected size ?
<ogra_> GrueMaster, ++
<janimo> will check after
<janimo> still I;d expect e2fsresize to complain if you ask it to resize a vfat
<ogra_> GrueMaster, i bet i added a variable for that too ;)
<infinity> janimo: Small card?
<janimo> infinity, default mx5
<infinity> janimo: On my 1GB card, resize on my Panda is literally instant.
<ogra_> janimo, well, it would, in the jasper log
<GrueMaster> That was changed as part of the ext4 change.
<janimo> resize is supposed to happen from 2g to 4g
<janimo> init: mounted-proc main process (385) terminated with status 1
<janimo> mountall: Event failed
<janimo> I wish I knew why these happen
<ogra_> no plymouth i guess
<ogra_> for the mountall bit
<ogra_> no idea about the upstart one
<janimo> ogra_, when is the next round of respins?
<janimo> and only for mx5 for now is omap done for b2 ?
<ogra_> janimo, well, if you ask GrueMaster i guess he doesnt want one :)
<janimo> great, I agree
<ogra_> janimo, thats not how it works
<ogra_> if you upload jasper we need to re-test all jasper using images
<ogra_> at least up to the jasper part
<GrueMaster> yep.
<janimo> ok, there is a new jasper needed for mx5 of course
<ogra_> we dont cherry pick arches for builds during milestones
<ogra_> yes
 * ogra_ wasnt expecting todays images to be final actually
<GrueMaster> Although I am still pulling, so if a respin is required I am ok.
<ogra_> we also need to fix the missing slideshow still
<ogra_> post beta though
<ogra_> and the missing ti icon
<janimo> ogra_, when are the jasper hooks executed?
<janimo> for the mlabel copying
<GrueMaster> Do we have packages for the ti icon to install?
<ogra_> one in local-premount, one in local-bottom
<ogra_> GrueMaster, no, its a jasper thing, but the handling of the favorites completely changed, so it doesnt show anymore
<ogra_> GrueMaster, iirc persia had the bug assigned to move that into packages
<GrueMaster> I meant when you click on the icon, is there packages in the ppa?
<ogra_> it is there, you just dont see it :)
<ogra_> and no, there is no package atm
<ogra_> i'll add that by release time (if TI doesnt)
<GrueMaster> Yea!  Fixing /etc/flash-kernel.conf fixed the oem-config crash.
<ogra_> awesome !
<GrueMaster> And I have unity.
<ogra_> wow
<GrueMaster> This is on yesterday's image though.
<GrueMaster> Well, unity-2d.
<GrueMaster> And the install icon is still there.  sigh.
<ogra_> ubiquity ?
<ogra_> well, oem-config didnt finish
<ogra_> did you actually see it removing packages ?
<GrueMaster> I wasn't paying attention.  Too many monitors to see all the details on all systems.  But I have seen this before.
<GrueMaster> interesting.  When ubuntu-bug pops up to report a detected crash, it blanks the screen and asks for sudo access.
<ogra_> bug in gksudo i think
<ogra_> thats supposed to be transparent
<ogra_> (teh black bg you see)
<ogra_> poke mvo about it, i did it several times, he said he doesnt need a bug, it would go away anyway
<ogra_> if it didnt go away yet, he might want to know about it :)
<GrueMaster> It appears that the resize worked, but the system thinks the image is using 3.92G on my 4G SD.  Will try again with a 16G SD later today.
<ogra_> weird
<ogra_> well ...
 * ogra_ is off to find some dinner
<infinity> Does it think there's free space anywhere?
<infinity> Cause 4G cards aren't 4G...
<GrueMaster> No, it is a resize issue. du-sh / says it is only using 1.4G
<GrueMaster> df -h shows / as 1.5G with 1.4G used.  Gparted shows mmcblk0p3 as 3.95G
<ogra_> jasper.log ?
<GrueMaster> n/a
<GrueMaster> Found it in /run.  Tried to resize mmcblk0p2.  Fail.
<ogra_> no further info ?
<infinity> Right, because that partition number is hardcoded in jasper.
<GrueMaster> Of course, this is yesterday's image.  Prior to jasper fix for ext4.
<infinity> And p3 is the one you're using.
<ogra_> its not hardcoded
<ogra_> i wish i could have hardcoded it ... but certain people at linaro wanted to use jasper, so it has that weird detectuion code that parses root= for finding the disk
<infinity> ROOTPART="${ROOTDEV}2"
<infinity> ^-- That's not hardcoded?
<ogra_> hmm, that should be dreived from $DISK
<ogra_> ROOTDEV="/dev/${DISK}${SEP}"
<ogra_> and it is
<infinity> Dude.
<infinity> The 2.
<infinity> The partition NUMBER is what's hadcoded.
<infinity> hard*
<ogra_> yeah, sorry
<infinity> And mx5 is using a different layout.
<GrueMaster> Kinda indicates structured fail.
<infinity> Or, so I understand.
<ogra_> yeah, thats definitely a bug
<ogra_> the code should just parse root=
<GrueMaster> mx5 uses a non-fs part1 for u-boot, fat for part2 (kernel, initrd), and rootfs on part 3.
<ogra_> right
<ogra_> but that doesnt need to be hardcoded at all given we set root= at image build time
<infinity> Ironically, if there's a UUID in play, things work correctly later...
<ogra_> yes
<infinity> But only partially correctly.
<infinity> So, yeah, that whole mess needs a bit of a clean up.
<ogra_> a bit ?
<infinity> I should have looked closer where I was in there for the FSTYPE thing. :/
<ogra_> :)
<ogra_> it needs a rewrite
<ogra_> thats why we had discussions about it in dublin
<GrueMaster> This is where my comment on us getting bogged down in last weeks meeting applies.
<ogra_> yup
<infinity> Well, I could fix most of this root-finding mess in jasper right now, but the diff might be a bit unpleasant for a freeze.
<GrueMaster> Not faulting anyone, just that we get tied up with long, difficult tasks, and the simple stuff falls through the cracks.
<ogra_> infinity, do it post beta
<infinity> ogra_: Sure, this just means mx5 gets to be broken for beta.  *shrug*
<ogra_> jasper is initial prototype code that happened to work right ... it was never intended to stay in production in that state for that long
<ogra_> infinity, just add a three liner that checks /proc/cpuinfo and resets the partition number then
<ogra_> another hack for a few days wont harm us ;)
<infinity> Ew.
<infinity> No.
<infinity> I'm either going to fix it right, or postpone it.
<infinity> The latter sounding like a better option.
<ogra_> well, postpone means no mx5 at all
<infinity> Though, we can stage a fix now.
<infinity> "at all"?
<ogra_> this is the critical milestone
<GrueMaster> Looks like it now fails due to fstab.
<infinity> It's a community image, there's no quality requirement.
<ogra_> well
<infinity> It's not like it was going to be on releases.ubuntu.com.
<ogra_> we produce it...
<infinity> It'll always be on cdimage.
<ogra_> i actually have some quality requirement for the work i ship ... at least on the surface :)
<ogra_> infinity, point is that we agreed with the release team that images that arent ready by beta1 (actually) wont be releasable
<infinity> I do too.  I'm just saying that non-release images have no such requirement.
<ogra_> we talked kate into b2
<infinity> Yeah, so we don't "release" it.  We weren't anyway.
<infinity> Sort of my point. :P
<ogra_> if we dont make it i wont step up again for it
<ogra_> so we will miss
<infinity> Wait.  Okay, are we talking past each other, or...
<infinity> Did you actually expect ac100/mx5 to be on releases.ubuntu.com?
<ogra_> we were supposed to release it (opposed to having a daily on cdimage that gets wiped with the first P build)
<infinity> Where, y'know, half our images never go.
<ogra_> no
<infinity> Oh, it can be "released" on cdimage.
<infinity> That's a whole different quality criteria, though.
<ogra_> i expect the tested and QA^ approved release to be on cdimage in the r5eleases subdir of the respective image
<infinity> And I think people get muddied up about that sometimes.
<ogra_> we only rarely have images on releases.u.c
<ogra_> all armel images but one live on cdimage
<ogra_> we had one release where we actually dumped them on r.u.c
<ogra_> anyway, moot point, do you see a fix thats not a horrid diff and that can work around it ?
<infinity> Well, I'd have to see exactly where it's failing to come up with a "hack" instead of a fix.
<GrueMaster> irregardless of the current arguements regarding release, this image is fail.  It actually is mucking up the partitions now to the point where it won't boot.
<infinity> But... Does every preinstalled image have a sane root= on the command line?
<ogra_> up to now they did
<infinity> And is it always a device?  Or sometimes a UUID?
<ogra_> always a device (see jasper code)
<ogra_> jasper expects to not see a UUID
<infinity> Well, the jasper code assumes it might not be a device. :P
<ogra_> (because it actually creates the UUID)
<GrueMaster> On first boot, it is a device.  jasper rewrites boot.scr to use UUID.
<ogra_> right
<infinity> if echo "$root" | grep -q '^UUID='; then
<infinity>     VOLID=$root
<infinity> else
<infinity>     if echo $root| grep -q ^/;then
<infinity>         ROOTPART=$(basename $root)
<infinity>     fi
<infinity> If it's never a UUID, that code's broken.
<ogra_> you look at the wrong script i think
<GrueMaster> Look at premount
<ogra_> there is UUID stuff, but thats unrelated to resize code
<infinity> Right, well same ROOTDEV2 issues there.
<infinity> And both can be solved with the same small amount of code.
<ogra_> right
<ogra_> then go for it
<infinity> But the above that I pasted is also an issue. :P
<infinity> It'll be writing the fstab incorrectly on mx5.
<ogra_> janimo needs an upload anyway
<infinity> So.
<infinity> Yeah.
<infinity> I'll get on this in 30ish minutes, I'm starving. :)
 * ogra_ finishes his dinner
<janimo> infinity, I'll upload my changes now
<ogra_> janimo, wait
<infinity> janimo: Or just commit them, if you don't need an upload/rebuild cycle.
<ogra_> just commit them so we can get along with one upload
<janimo> ogra_, not uploading just committing
<janimo> sure
<ogra_> ah
<infinity> janimo: (And I suspect rebuilding is useless to you without fixing the rootdev stuff)
<ogra_> well, we have a good set for testing atm (beyond mx5 indeed)
<GrueMaster> janimo: Looks good.  Should fix all of our problems.
<janimo> I changed rootpart , uboot_part and boot.scr contents for mx5
<janimo> GrueMaster, what was the flash-config change about?
<ogra_> oh, rootpart too ?
<janimo> I tried with my changes in a modified initrd and it still crashed at the end albeit differently. When I came back to the screen it had restarted ubiquity
<janimo> just like I saw it done for omap previously
<janimo> but var/crash is empty this time so some joy
<janimo> ogra_, well rootpart to be part 3 and vfat part 2
<ogra_> yes
<janimo> as they were hardcoded to 1 and 2 for omap
<ogra_> but see above
<ogra_> infinity just wanted to start working on a general fix for that
<janimo> no problem
<ogra_> oh, geez ! i'm sooo proud !
<janimo> general fix being?
<GrueMaster> janimo: I manually changed /etc/flash-kernel.conf to show UBOOT=/dev/mmcblk0p2.
<ogra_> (its my cats first bday today and he just brought me his first mouse)
<janimo> I had a version that autodetected vfat/root using sfdisk
<GrueMaster> Your jasper mods should fix this automatically.
<janimo> ogra_, cats do not know the customs. Unclear about who needs a present
<ogra_> janimo, well, talk to infinity so you guys dont duplicate work then
<janimo> GrueMaster, good
<ogra_> haha
<janimo> ogra_, I did not do the smartsfdisk based approach so I introduce as little new code as possible
<janimo> even if it looked better
<ogra_> he still doesnt get that he can eat his toy though
<janimo> no need for grepping cpuinfo for instance
<ogra_> how do you know you are on mx5 ?
<janimo> has MX53 in the hardware line
<janimo> oh you mean without cpuinfo
<ogra_> you just said you dont look at cpuinfo
<ogra_> yeah
<janimo> well for the partitions just look at where sfdisk finds vfat and linux
<janimo> and operate on those devices
<ogra_> yeah, that at least works for all images with vfat
<janimo> but for the boot.scr content subarch is still needed
<janimo> so not entirely streamlined without special casings
<ogra_> well, that sounds like you already implemented what adam planned to
<janimo> GrueMaster, but my fixes to jasper need testing with omap just in case I blundered something
<ogra_> or at least something similar
<GrueMaster> Someone going to upload this and trigger a respin, or do I call mx5 a cosmic failure?
<ogra_> not yet :)
<janimo> ogra_, similar, not very elegant, for the same reasons - freeze being close
<ogra_> yeah
<janimo> ogra_, I still need to add the mlabel thingie
<GrueMaster> That can wait post-beta
<janimo> so when is that hook/ copy_exec executed?
<janimo> GrueMaster, fine by me
<ogra_> yeah
<ogra_> leave that for post muilestone
<ogra_> janimo, during update-initramfs
<ogra_> call update-initramfs -v ;)
<ogra_> that shows you every copy_exec it does
<janimo> ogra_, ah so after install
<ogra_> including the list of libs
<ogra_> we call update-initramfs several times during the build too
<ogra_> well, once at least, more depends on the image type
<infinity> janimo: We already know rootpart from root=, the sfdisk thing feels like overkill.
<janimo> infinity, ok
<janimo> but vfat needs to be detected too
<janimo> anyway, for now the case with MX53 works
<infinity> Is that in another commit? (the vfat thing)
 * janimo tries again with logging to the screen
<janimo> infinity, I commited all I have
<janimo> UBOOT_PART
<janimo> 2 or 3 commits I think
<infinity> Ahh, that's not autodetected, though, just hardcoded for the subarch.  Check.
<GrueMaster> Should be on rev 165 now.
<infinity> Yeah.
<GrueMaster> er, 167
<infinity> 165..167 are his changes. :P
<infinity> But yeah.  I just understood the mentioning of "have to detect vfat" as meaning he'd done so. :)
<ogra_> well, if its sufficient to get mx5 through
<infinity> Sec.
<GrueMaster> So, I still need to know if we are respinning with this.
<infinity> We will.
<ogra_> yep
<GrueMaster> We'll have to respin server and kubuntu/kubuntu-mobile as well.  All images except netboot & core.
<infinity> However, if we're sure that we'll always have a correct root=/dev/blah, then we can scrap that whole bit in _setup.
<infinity> ROOTPART="${ROOTDEV}2"
<infinity> #iMX53 has rootfs on part 3
<infinity> grep MX53 /proc/cpuinfo >/dev/null && ROOTPART="${ROOTDEV}"3
<ogra_> well, we control what goes into the images
<infinity> ^-- Unnecessary because of:
<infinity> if echo "$root" | grep -q '^UUID='; then
<infinity>     VOLID=$root
<infinity> else
<infinity>     if echo $root| grep -q ^/;then
<infinity>         ROOTPART=$(basename $root)
<ogra_> we could as well make jasper read /etc/subarch and wipe it afterwards
<GrueMaster> where is that?
<ogra_> adding a full AI to have disk detection seems overkill
<infinity> jasper_setup
<GrueMaster> No, the /etc/subarch part.
<infinity> Nowhere.
<infinity> He was saying we could create it.
<ogra_> right
<GrueMaster> So another added failure point.  Lets not.
<ogra_> to remove all subarch detection code
<infinity> Yeah, not worth it for now.
<ogra_> well, its 20 lines of subarch detection by parsing /proc/cupinfo ... vs SUBARCH=$(cat /etc/subarch)
<ogra_> heh, no, surely not for now
<ogra_> i'm just thinking aloud
<infinity> janimo: If your changes work, they seem low impact for now, I just hate committing hacks unless we also commit to fix them later. :/
<ogra_> infinity, well, jasper is a lost case ... somewhat
<GrueMaster> The right thing to do is to make jasper detect the correct partitions.  This way, it will work with other platforms and also with linaro images on existing platforms.
<infinity> ogra_: Indeed.
<ogra_> it is a hack consisting of hacks
<infinity> GrueMaster: Well, yes.
<ogra_> GrueMaster, linaro has no interest in using or helping with jasper
<ogra_> they pretty clearly told me so
<GrueMaster> Only because it breaks their current model.
<ogra_> they had no model when jasper stzarted
<GrueMaster> They have a master partition on P1.
<janimo> also because they presumable wish to keep their sanity
<ogra_> and asac worked quite hard to try to convince people
<janimo> GrueMaster, for mx5 I copied their part layout
<janimo> or uboot would not work
<ogra_> janimo, jasper isnt a bad thing ... its just that we are still using the proof of concept prototype
<GrueMaster> I wonder if the same layout could be used for omap/omap4.
<infinity> Well, jasper shouldn't exist.
<janimo> ogra_, the idea is not bad, but the hacks and the maintainability are
<infinity> The growroot concept should be rolled back into ubiquity, and we'd be done with it.
<ogra_> infinity, what would do the resizing then ?
<infinity> That's the only thing it does different from ubiquity.  It resizes in place instead of copying.
<infinity> Other than that, we WANT ubiquity.
<ogra_> why would we
<ogra_> we *use* ubiquity
<infinity> Why wouldn't we?
<ogra_> we only dont use the partman bits
<ogra_> and pkgsel
<infinity> Sure, but if it was all in one place, you could use one installer to install in-place OR to another drive.
<GrueMaster> This debate really should be brought up at UDS.  Too late for major changes now.
<infinity> And yes, not helpful now.
<ogra_> haha
<infinity> janimo: If your hacks DTRT, upload.
<ogra_> infinity, fix the copying speed and i'll happily be with you on live images
<infinity> ogra_: The current way to install to external drives on a Panda are either netboot (that's fine), or install with jasper and then cp -a to another partition.  That second case is just wrong. :P
 * GrueMaster toddles off to play with the netinstall images while waiting for respins.
<ogra_> preinstalled images mainly exist because the linaro guysw complained to me it takes to long to install
<ogra_> that was way before they started to do their own
<infinity> ogra_: And this has nothing to do with copying speed.  I'm saying the growroot (install in-place) option should be added to d-i proper.
<ogra_> actually its all amitkÃs fault !
<infinity> ogra_: So you could EITHER copy, OR do the in-place thing we do now.
<ogra_> hmm
<ogra_> yeah, that sounds sane
<janimo> infinity, I am still testing a bit the fs resize
<infinity> janimo: Mmkay.
<GrueMaster> infinity: Growroot needs to happen before the rootfs is mounted. EXT4 doesn't allow grow while mounted.
<ogra_> i think it does
<ogra_> ext3 doesnt
<infinity> janimo: It's not how I would have solved it, but it's definitely low-impact your way, and I'd rather push something in and have working images than rewrite things right now, so...
<ogra_> and i think its a lot faster when mounted
<GrueMaster> No, I tested it during my EXT4 testing.
<janimo> infinity, out of curiosity how would you have done it?
<GrueMaster> It actually produces an error.  Even when mounted RO.
<infinity> janimo: Well, as above, I'd remove some redundant code, I'd use root= instead of sfdisk, I'd remove more redundant code... And more...
<ogra_> janimo, i guess a udeb that brings that functionallity (using parted or partman)
<infinity> janimo: But my changes have a regression potential if things don't work exactly as I'm told they do. :P
<infinity> janimo: Yours should Just Work, for now.
<ogra_> which then can be used by d-i and ubiquity/oem-config
<janimo> infinity, ah indeed. Seeing I removed some code for the VFAT formatting because it was the right thing, introduced a regression (label) I thought I resist the urge to clean up things
<ogra_> janimo, just look at the jasper buglist, 90% of jasper wouldnt exist anymore if they were all fixed
<ogra_> it would mainly boild down to growroot
<ogra_> u-boot setup shoudl be done by flash-kernel-installer buit that needs a re-write to accept being run in non d-i envs
<ogra_> and all the other setup bits should go elsewhere too
<ogra_> we have a re-occuring jasper rewrite spec since we have preinstalled
 * ogra_ looks at infinity ...
<infinity> Heh.
<ogra_> we should wprobabls have a jasper slaying spec this time :)
<ogra_> *probably
<infinity> I'm inclined to agree.
<ogra_> add it to the spec page ;)
<ogra_> and dont let me implement it ... you might end up with jasper-ng :P
<infinity> Chris Jones shouldn't be near installers.
<infinity> We'd end up with multiple installer windows.
<ogra_> heh
<janimo> ogra_, I remember, I took the notes at the meeting and filed most of those bugs in Dublin
 * ogra_ has a slight prob with chris' nick since it took him quite a while to make out that the guy who asked about "angie" from canonical IS actually meant chris :)
<janimo> infinity, ogra, uploaded jasper
<ogra_> janimo, yeah, they are still there :D
<janimo> ogra_, closed the VFAT reformat one
<ogra_> heh, cool
<ogra_> i think you own a WI from my plate as well (or was it infinity) for the ext4 changes in jasper
<ogra_> (i'll make sure to re-assign when i close it)
<infinity> janimo: Accepted.
<janimo> infinity, thanks
 * ogra_ calls it a day 
<infinity> 'Night.
<brandini> night
<brandini> ogra_: I hope you don't mind I shared that link with my wife because I wanted to share what I'm trying to accomplish
<janimo> ogra_, bye
<janimo> hmm, resize does not happen apparently. mount fails and the script quits
<janimo> mount: can't read '/etc/fstab': No such file or directory
<janimo> triggered by mount ${ROOTPART} /root >>${LOG} 2>&1 apparently
<infinity> Is that you stepping through manually, or?
<infinity> Cause at that point, on "proper" install media, /etc/fstab exists (albeit empty), and mount should be fine.
<janimo> infinity, no, running yesteday's image patched with a modified initrd to test my jasper changes
<janimo> I'll wait for proper images could be an artifact of something I did
<janimo> anyway resize is the last step in that file
<janimo> so the rootfs stays at 2G
<janimo> maybe that is why it crashes, no space for installed packages
<janimo> I test it on the mx53
<GrueMaster> janimo: yesterday's image worked for me once I modified /etc/flash-kernel.conf.
<janimo> GrueMaster, resized ext3 even?
<GrueMaster> May be something with the ext4 stuff.
<janimo> maybe because ARM boards love you
<janimo> you are much closer to them than I am
<infinity> It can't have resized correctly.
<GrueMaster> It didn't resize properly (rewrote the partitions but that was it).
<janimo> you cultivate a proper relationship with them
<janimo> ok
<janimo> so part resize is good, fs resize not
<GrueMaster> Yea, I'm all touchy feely with them.
<GrueMaster> This was yesterday's image prior to ext4 changes and everything else.
<infinity> Yeah, partition resizing would have always worked, because it just expanded "the Linux partition", it didn't use numbers.
<infinity> That would fail pretty entertainingly if anyone tried to use jasper in an image with multiple partitions.
<infinity> Thankfully, no one would do such a thing. :P
<amitk> ogra_: hehe :) I still think anybody thinking of installing ubuntu on ARM devices needs some introduction to the real world :-p
<amitk> ogra_: (as opposed to pre-installed images, that is)
<infinity> amitk: Well, depends on how you define "ARM devices" too.
<infinity> amitk: I think most of the madness we do with flash is, well, madness.
<infinity> amitk: But with devices that can actually use external storage, things (finally) change a bit.
<brandini> flash?
<infinity> brandini: Flash, SD, MMC, nvram, whatever you want to call it.  "slow, unreliable storage that belongs in watches, not desktop computers".
<brandini> :)
<brandini> the choice to rely/depend on that for booting seems odd to me
<amitk> infinity: right, and when I complained a year ago, the only HW we had access to had flash storage and slow usb storage. Over one year later, we still don't have enough devices/boards in Linaro that can do SATA
<brandini> so I'm going to start updating openbsd's armish arch to support the pandaboard
<brandini> and the deeper I dig the more I wonder what I've gotten myself into
<infinity> brandini: Pain.
<brandini> Sure seems like it
<brandini> the current install guide for openbsd doesn't start actually talking about the install until about half way through the document
<GrueMaster> infinity: Ouch (from the builders status page):  armel 	18 	283 jobs (22 hours)
<infinity> GrueMaster: That't the rebuild test.  And a huge improvement over when it said "12 weeks".
<GrueMaster> ah
<GrueMaster> infinity: Has the jasper update been published and accepted?  No sense respinning without it.
<infinity> GrueMaster: Yes.
<GrueMaster> ok.  I knew we were waiting on ubiquity.  Wanted to make sure jasper was also updated.
<infinity> Yeah, jasper builds in a matter of seconds. ;)
<GrueMaster> Doesn't necessarily mean it is accepted during a freeze.
<infinity> (I accpted it)
<GrueMaster> Ah.
<infinity> 13:31 < infinity> janimo: Accepted.
<infinity> 13:31 < janimo> infinity, thanks
<GrueMaster> I was monitoring #u-release.  Thought it would get an honorable mention there.
<GrueMaster> But no matter.
<infinity> Nah, I reviewed it and slipped it under the radar somewhat intentionally.
<infinity> Not that it's a "secret" (obviously), just didn't feel the need for fuss, since we were waiting on ubiquity. ;)
<GrueMaster> No problem.  I just wanted to make sure.  When I'm not keeping everyone on their toes, things slip by (like daily builds).
<brandini> Ok, I've procured my external usb enclosure
<brandini> it's shiny and black, but that wasn't part of the instructions :)
<infinity> brandini: Still seems important.
<brandini> it is
<brandini> man, I'm kinda bummed that I'm going to power off my pandaboard half way through this update from 10.10 to 11.04
<brandini> :(
<brandini> is there something different I need to do when I install the 11.04 preinstalled image to a CF and SSD?
<GrueMaster> With that image, you just dd to the SD card same as 10.10 and boot.  After going through the oem-config and getting to a working image (before installing updates), shut down.  Then you can transfer the rootfs to the USB drive using your desktop system.
<brandini> ok
<brandini> I should use 11.04 release or daily?
<GrueMaster> If you want to start with Oneiric (11.10) on your USB drive, you can do a netboot install directly to it, but it takes a little bit of working.
<brandini> would I always have to netboot or just for the install?
<GrueMaster> Essentially, there is a bug in the netboot install that fails to repartition the SD properly for normal booting.  But it is easy to work around.  See bug 806751 for info.
<ubot2> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Medium,New] https://launchpad.net/bugs/806751
<GrueMaster> Just the install.
<GrueMaster> This will pull the latest packages.  Once the system is installed, you can just pull updates as normal.
#ubuntu-arm 2011-09-21
<GrueMaster> The only problem is that it pulls only from ports.ubuntu.com (no mirrors).  You can get around it if you have a local mirror, but that takes a large amount of drive space.
<brandini> maybe I'll stick with trying the headless daily
<infinity> s/headless/server/
<brandini> server?
<brandini> I only see netbook and headless
<infinity> Not for oneiric.
<infinity> We're now more in line with the rest of the distro, with desktop and server.
<infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/
<GrueMaster> Oneiric changes the names.  Netbook>Desktop (daily-preinstalled).  headless>Server
<GrueMaster> brandini: If you want the netboot installer, it is at a different location.  http://ports.ubuntu.com/dists/oneiric/main/installer-armel/current/images/omap4/netboot/
<brandini> naw, I think I'll stick with server
<brandini> how come cdimage is so slow?
<GrueMaster> infinity: Does this certificate thing invalidate the current images that were just rebuilt?
<GrueMaster> For armel?
<infinity> GrueMaster: Almost certainly.
<infinity> GrueMaster: I think we ship that package on pretty much every image.
<infinity> Task: standard
<infinity> Yeah.
<infinity> Every image except core.
 * GrueMaster mutters a few choice words that get stuck in the irc filters.
<GrueMaster> Well, may as well fix jasper (yet again).  FS resize is failing.  Testing server images now.
<infinity> It's failing on the server images?
<GrueMaster> yes.  It runs way too quickly (1-2 seconds) on a 16G SD.
<GrueMaster> Waiting for the rest of the install to see what it is doing (or not doing as the case may be).
<GrueMaster> heh.  This is a definite indicator of fail:  /usr/sbin/oem-config-firstboot: line 98: cannot create temp file for here-document: No space left on device
<GrueMaster> 16G SD.
<infinity> Not promising...
<GrueMaster> Considering installed we use ~1.9G max...
<infinity> Not entirely sure how the changes would have made it fail.  A log would be nice.
<GrueMaster> Working on it as fast as these turbo systems will go.
<GrueMaster> What is the kernel cmdline to break in init during initrd?
<GrueMaster> Hate to say "I told you so", but this is kind of why I was against ext4 switch this late in the game.
<GrueMaster> infinity: What is the proper way to break in init prior to premount?  I can't see what is going on with jasper.
<infinity> We can switch back to ext3 with almost no effort.  I can do it right now, if you think the failure is the filesystem.
<infinity> But if it's not the filesystem, you get to blame all the mx5 changes, and not me. :P
<infinity> And the init break would be something like "break=top"
<infinity> Or similar.
<infinity> Depending on which step you want to break into.
<infinity> break=premount, I would assume.
<infinity> Unless that happens after premount.
 * infinity hasn't hacked initramfs-tools in a while.
<twb`> You can just put "break" and it stops just before the pivot_root
<infinity> twb`: That's too early.
<infinity> Err, late.
<infinity> Brain bleeding.
<twb`> If you grep for maybe_break over /usr/share/initramfs-tools you can see all the break points
<infinity> Yeah.  Just did. :P
<twb`> infinity: I hack the shit out of casper to make it work on diskless thin clients -- I know all about initramfs :P
<infinity> GrueMaster: You want break=premount
<GrueMaster> got it.  Trying.
<GrueMaster> export ROOTDEV=/dev/mmcblk0p
<GrueMaster> Looks wrong
<infinity> Nah, that's right, just unneeded now with jani's changes.
<infinity> Since rootpart used to be rootdev+n
<GrueMaster> I can't see where it is failing.
<infinity> If ROOTPART is correct, then the only place it really could fail is just because resize2fs doesn't work on ext4 (which we know it does, but could be a bug or something)
<infinity> Or just a grumpy SD.  My testing worked on one, and not another.
<infinity> PS: I hate flash memory.
<infinity> Let me grab a copy of this image and flash it.
<GrueMaster> fails on both beagleXM and panda.  different cards (4 now).
<infinity> I'm perfectly willing to believe there's a bug with resize2fs and ext4 on arm (or in general), just going to look here quickly as well and see if I can see how or why it fails.
<infinity> Like I said, switching back is easy (one small diff on antimony), now that jasper itself doesn't hardcode fs types.
<GrueMaster> I don't think that is the problem.
<GrueMaster> resize works fine manually from init.
<infinity> Running the script, or just typing resize2fs manually?
<GrueMaster> running resize2fs manually.
<infinity> Also, is there a sane way to do kernel command line editing on these things, or do I have to mangle the image?
<infinity> Well, I guess, mangle boot.whatever on the card.
<GrueMaster> That's what I do.  You could interrupt u-boot also and do it manually.
<GrueMaster> The filesystem on /dev/mmcblk0p2 is now 15589376 blocks long.
<GrueMaster> I call that a success.
<infinity> And ext4?
<infinity> In that case, I don't think you get to blame me. :P
<infinity> But I'll see if I can figure out WTF *is* going wrong.
<GrueMaster> exit
<GrueMaster> grr.
<GrueMaster> Ok, it seems to be booting through after manually massaging the partitions.
<GrueMaster> jasper-growroot has issues.
 * infinity goes to meet a woman, get married, and have a few kids, while he waits for this image to flash.
<stgraber> infinity: didn't realize flashing images is taking that long now ;)
<GrueMaster> Doh!.  Looks like jasper-growroot is mounting the filesystem before resizing.
<GrueMaster> It would be nice if these derived variables were also in the log.  Not a single log entry has the variable output.
<infinity> GrueMaster: It mounts and the umounts, doesn't it?
<GrueMaster> Yes, but who knows if the umount actually happens before it tries to check the drive.
<GrueMaster> flash-kernel has timing issues with this.
<infinity> I wonder if this is begging for an icky sync solution and we're just racing...
<GrueMaster> probably.
 * GrueMaster is approaching the 12 hour mark w/o glasses.  Everything is getting real fuzzy.
<infinity> Oh, ffs, that image doesn't fit on a 1G card.
 * infinity tries his sketchy 16G card that fails half the time.
<infinity> This script makes me sad...
<infinity> How was $MYECHO deemed less typing than "echo "?
<GrueMaster> MYECHO feeds plymouth
<infinity> Oh, I missed the if plymouth bit.
<GrueMaster> what is this frigging initrd format this week?  I have stripped the uboot crap off, but non of my unpack scripts work.
<infinity> Same as it's been for the last several years...
<infinity> A cpio archive, compressed with the compression flavour of the month. :P
<infinity> gzip still, looks like.
<GrueMaster> gzip: initrd.img: not in gzip format
<GrueMaster> lzcat: Decoder error
<GrueMaster> Those are the two I work with the most.
<GrueMaster> xz?  (from mkinitramfs)
<infinity> Really?  Mine claim to be gzipped.
<GrueMaster> I'm talking about the one on the boot image.
<GrueMaster> Stripped first 64 bytes, nothing.
<infinity> Ahh, lzma.
<infinity> Well, the ones from live-build are.
<infinity> Of course, your lzcat still says no to that.
<GrueMaster> ARRRGGGG
<GrueMaster> file just comes back as data.
<GrueMaster> I'm leaving the jasper debug to you.  My head really hurts.  No glasses doesn't help.
<infinity> I hate flash media.  So.  Much.
<infinity> Wait...
<infinity> bad geometry: block count 897024 exceeds size of device (897008 blocks)
<infinity> That seems like a bad thing.
<infinity> How are we 16 off?
<twb`> nand flash itself isn't that bad, it's just the dancing that you have to go through when there's no FTL
<infinity> twb`: nand is pretty bad, I have a ton of dead and dying cards.
<twb`> Shrug
<twb`> I could say the same about HDD or optical media
<infinity> Hard drives die a tad more slowly. :P
<infinity> (Or, rather, after a lot more use)
<infinity> As a write-once (or write-infrequently) medium, nand is great.
<twb`> Meh.
<twb`> That's partly just that HDDs are more mature technology
<twb`> As long as I get 3-5 years of life out of a unit, I'm happy.
<infinity> GrueMaster: I'm now wondering if this is a bug we've had for ages, and we only trigger it sometimes...
<infinity> GrueMaster: I think we're occasionally creating an image that's one block short.
<GrueMaster> What, sync?  I hit it quite often.  Just kept getting told it is only affecting me.
<GrueMaster> That bug too.
<infinity> The 1 block short thing causes the mount and umount to fail.
<infinity> Cause it's a bad FS.
<infinity> But resizing works.
<GrueMaster> And reflashing over the same SD will occasionally work fine.
 * GrueMaster sometimes wishes he could have a developer stand next to him and sucker-punch him for every bug that flies by.
<twb`> That sounds like a job for an automaton, not a developer :P
<infinity> You have a live-in one, don't you?
<GrueMaster> Only when he's awake.
<GrueMaster> And he rarely enters my office anymore.  guess he is learning.  :P
<dash> howdy. I would like to install ubuntu on an ARM machine for hacking/server usage
<twb`> dash: what kind of ARM machine
<dash> but I don't know if a machine suitable for that exists :)
<dash> twb`: that is my question! where can I find an ARM box that has, like, SATA connections
<dash> and a non-tiny amount of RAM
<infinity> "box", it's not, but the Freescale i.MX53 QuickStart has SATA.
<twb`> Whatever Debian's armel porter boxes run (efikamx?) are probably good for that role
<dash> yeah i was looking at the efika smarttop
<twb`> Which is a motorol^W freescale underneath
<infinity> The quickstart's definitely faster.
<infinity> (And Debian's new buildds are those)
<twb`> infinity: who do you buy one from?
<infinity> I got mine from DigiKey.
<twb`> I mean presumably they're BGA so you need to get a mobo+soc combination
<infinity> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB
<twb`> Huh, I never heard of them but they sound big
<infinity> It's about 4 inches square...
<twb`> I meant the company
<twb`> "Digi-Key is the fourth largest electronic component distributor in North America"
<infinity> Oh.  Yeah.
<infinity> http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2621773&k=mx53
<infinity> Assuming that works without my cookie... Their catalog can be annoying.
<twb`> That gives me: (Download)Save file to: dksus.dll
<infinity> Yeah, figured it might.  Useful.
<twb`> This is why I avoid .com domains
<infinity> Just searching for mx53 and clicking on General Embedded Dev Boards will bring it up.
<infinity> GrueMaster: Grr.  Despite this fs size bug, everything still works fine on one of my cards. :/
<dash> infinity: that looks nice.
<dash> 1GB RAM and sata connector means you could use it for something real :)
<dash> pity it's the A8 instead of the A9, but whatever
<infinity> Yeah, A8 is its only failing, really.  Well, that and being a dev board. :P
<dash> meh, i've got gaffer tape :)
<dash> i'm just looking for a dinky home server that i can build some software on
<dash> to replace my thinkpad t42 whose fan just died
<infinity> dash: My MX53 is my Debian and Ubuntu mirror, among other things, when it's not busy rebooting for dev work.
<infinity> dash: Works fairly solidly.
<dash> nice
<dash> well i could always turn my old athlon back on
<dash> but that's loud and hot :)
<infinity> Yeah, same reason most of my POWER systems aren't on. :/
<dash> hmm, welp
<dash> this is the first piece of kit i've wanted this year that fry's hasn't had :D
<infinity> DigiKey is next day FedEx for 8 bucks (or maybe less in the US?), free for orders over 200.
<infinity> So, not the end of the world.
<infinity> At least, that's what they do for Canadians.  Maybe they're more cruel to locals. :P
<twb> Note to self: next time doing a dist-upgrade within a chroot on a foreign architecture, do --download-only
 * twb watches dpkg chug along from within a qemu userspace emulation
<ogra_> janimo, no updated mx5 images ?
<janimo> ogra_, apparently none with the newer jasper
<janimo> still at .60
<ogra_> why didnt infinity start a rebuild, do you know ?
<ogra_> jasper should be long done
<janimo> no idea, I was asleep
<ogra_> ok, there were issues with ca-certificates and a mozilla update
<ogra_> seems new builds were started around 6am UTC by pitti
<ogra_> so we should have them this afternoon (about 6h for one build)
<ogra_> janimo, within the next 2h we should have them
<janimo> ok
<ogra_> so let me find that silly wlan debug setting
<huge> hello, I'd like to use ubuntu 10.10 without desktop ... the question is ... how disinstall gnome?
<brandini> morning
<ogra_> janimo, phy0 -> rt2800usb_txdone_entry_check: Warning - TX status report missed for queue 2 entry 47 ... thats the message in dmesg you get thanks to it ... one every few mins
<huge> then i will want to start my own QT/QML ... based on Qt 4.7.4
<janimo> ogra_, ah, so not _that _ spammy - I thought it was flooding dmesg
<ogra_> janimo, CONFIG_RT2X00_DEBUG
<janimo> it can actually be a good debugging clue
<huge> is available a debian package for qt4.7.4 for arm with prebuilded libraries?
<ogra_> well, spammy enough that you cant read the actual dmesg messages because of it at times
<ogra_> its not as bad as one line per second, but still annoying and nothing for a release :)
<janimo> huge, I know there are qt 4.7.4 libs in Ubuntu Oneiric, technically debian packages but not sure it's what you're after
<ogra_> sigh, but 6h for one desktop image build run is pretty bad, we will need way more livefs builders next release
<brandini> I put my usb SSD in and my CF And booted the daily server and things seem to have gone better
<brandini> but right now it's stopped at "Waiting for network configuration"
<janimo> ogra_, why does a debootstrap take that long?
<janimo> what else is happening there?
<ogra_> janimo, i think for Qt they package upstream and dont sync
<ogra_> (i might be wrong, but i think i remember something like that)
<ogra_> janimo, which debootstrap ?
<janimo> ogra_, no idea, how do live images get built?
<ogra_> you mean running it locally ?
<ogra_> ah
<janimo> not by debostrapping initially?
<ogra_> well, there si debootstrap involved
<ogra_> did you ever use rootstock ?
<janimo> yes
<ogra_> it functions pretty much the same
<xranby> huge: debian currently have 4.6.5 in testing/unstable.         the quickest way to remove gnome are    apt-get remove  gdm       and then apt-get install kdm
<janimo> but that did never take close to 6 hours here
<janimo> an hour at most maybe
<ogra_> debootstrap -> apt-get install ubuntu-desktop^
<ogra_> then configure some stuff
<janimo> ah they happen natively that's why it is slow?
<ogra_> and roll the whole into a filesystem image of any kind
<ogra_> they have to
<ogra_> while we dont really require fast disks for normal buildds (usually CUP and RAM are more important there), livefs builds totally depend on disk speed
<ogra_> and thats something we heavily miss (even with fast USB disks you are limited to the bus speed)
<ogra_> we shoudl consider an mx5 cluster for livefs builders, so we can use SATA
<huge> hello, i've problems with ubuntu-omap4-extras, after installation ubuntu (10.10) does not work fine any more
<huge> graphics does not work properly
<huge> how to fix this issues??
<huge> some help?
<xranby> huge: are xorg running?
<xranby> huge: did graphics stop after you installed the package?
<huge> yes ... after reboot ubuntu is starting in graphics mode but it is not usable
<huge> xorg is running.
<huge> my HW is pandaboard
<xranby> huge: fist check that your pandaboard gets enough power..   how many A can your powersupply deliver?
<xranby> huge: try reduce powerconsumption from the board by connecting keyboard and mouse to a self powered usb hub instead of directly connecting them to the board
<huge> power supply is +5V
<xranby> huge: how many A at 5V can your powersupply deliver   i want to know how many Watt   (A *V)
<huge> ah ... sorry
<huge> 2.4 A
<xranby> huge: ok thats a bit on the low side
<xranby> huge: do you have a watt meter?
<huge> yes
<huge> what to do?
<xranby> huge: check that you do not use more than 12W or else you risk  a brownout when using the board
<xranby> huge: since you powersupply can only deliver 12W
<xranby> huge: a brownout will manifest itself like random crashes and segfaults
<xranby> huge: since the board will not get enough power
<ogra_> janimo, did you care for mx5 vto be on the iso tracker ?
<xranby> huge: if you exceed 12W or are close to using 12W then buy a better powersupply
<ogra_> pitti just asks in #ubuntu-release
<xranby> huge: that can deliver say 4A 5V+
<janimo> ogra_, no idea.  I know too little about the iso tracker and what the implications are for an image to be there
<janimo> we want to have the image usable so probably yes i'd say
<ogra_> can you tell pitti you want mx5 (and where on the tracker it should go)
<huge> so i have need a 20W powersupply??
<xranby> huge: remember that one usb device connected to the panda can consume up to 2.5w       so if you connect two usb devices you allready use   5W of the 12W
<xranby> leaving only 7w left for the board itself
<ogra_> you really only need the 4A if you drive a lot of USB devices on the pand
<ogra_> a
<ogra_> 2.5 to 3.0 should be fine for normal operations off an SD card
<xranby> ogra_: huge's powersupply are 2.4A
<ogra_> yes, i saw that
<ogra_> for bare SD card installation that should still be ok
<xranby> huge: still you have not mentioned why your graphics mode is not usable
<xranby> huge: is it stalled ?
<huge> no is it not stalled ... the mouse pointer is evil ... when i start application i see only green windows
<huge> how can i'm sure that is not an sw problem?
<huge> now i've downloaded SGX with Demo Package from http://neuvoo.org/neuvoo/distfiles/SGX-3.01.00.07-SDK.tar.gz ./OGLESEvilSkull Does not start
<xranby> huge: can you paste any error message?
<huge> libGLES_CM.so is missing
 * ogra_ would recommend waiting for rsalveti or robclark 
<ogra_> they maintain the sgx drivers (one for TI, one for linaro/ubuntu)
<ogra_> they are both on US timezones and should show up soon
<huge> maybe can be a reason ... becouse i donÃ¬t have libgles2-sgx-omap4-dev installed
<rsalveti> huge: install -dev package
<xranby> huge: try sudo apt-get install libegl1-sgx-omap4 libgles1-sgx-omap4 libgles2-sgx-omap4
<huge> i've installed libgles2-sgx-omap4-dev ... but nothing changed
<huge> now i've solved ... was missing a simbolic link for libGLES_CM.so ... but to start ./OGLESEvilSkull i need to have X up ... but in graphics mode ubuntu is not utilizable
<huge> also on startx i've: startx (EE) AIGLX error: dlopen of /usr/lib/dri/pvr_dri.so failed (/usr/lib/dri/pvr_dri.so: cannot open shared object file: No such file or directory)
<huge> xrandy tried with usb hub ... same problems
 * ogra_ runs an ac100 test install ... brb
<huge> xrandy what i don't understand ... is that X start, gnome start ... and seems fast ... then when i try to open a simple terminal (in graphic mode) i've white screen
<xranby> huge: sounds like a gfx driver bug
<xranby> huge: did you check your board powerusage witht he watt meter?
<xranby> just to rule out that source of error
<huge> i'm going to do ... i need to reboot
<huge> just 5 minutes
<huge> done
<huge> it is max 5 W
<huge> so we can exclude problems about powerusage
<xranby> huge: great, hopefully robclark here and rsalveti know hot to debug the sgx drivers and can come up with an idea why you get a white screen when you launch the terminal
<huge> thank you, robclark/rsalveti could you help me?
<brandini> it looks as though the install runs into issues if you don't have your CF card zero'd out before you start your install
<huge> hello hello
<robclark> huge, umm, ok, what is the issue then?
<huge> issues is that after omap4-extra installation, I can't use ubuntu in graphics mode
<xranby> robclark: (15.09.06) huge: xrandy what i don't understand ... is that X start, gnome start ... and seems fast ... then when i try to open a simple terminal (in graphic mode) i've white screen
<robclark> xterm?  Or gnome-terminal?
<robclark> dmesg or /var/log/Xorg.0.log have anything interesting?
<huge> gnome-terminal
<robclark> is this compiz, or metacity?
<huge> and
<huge> sgxCopy PVR2DBlt3D with error code -7
<huge> sgxComposite: failed  to do composition
<robclark> k.. can you pastebin the xorg log?
<robclark> (and also check dmesg.. maybe we crashed sgx somehow)
<huge> ok, i will ...
<huge> i need to install telnetd and to reboot
<robclark> (or sshd)
<huge> http://pastebin.com/JUd5dwwD
<huge> var/log/Xorg
<huge> dmesg seems ok
 * robclark looks
<robclark> error 0x00000003 is INVALID_PARAMS...
<robclark> I'm guessing something is fubar in the package..
<robclark> maybe some patch merged badly or something like that?
<robclark> but sgxCopy shouldn't really fail like that.. it is a pretty basic operation
<rsalveti> huge: are you using the sgx packages from stable or trunk ppa?
<huge> http://pastebin.com/RMDXYdng
<robclark> huge, yeah, kernel level stuff looks ok..
<huge> yes yes
<huge> i don't understand really ...
<huge> i've used this: sudo add-apt-repository ppa:tiomap-dev/omap-trunk
<huge> and followed this guide
<huge> http://www.omappedia.org/wiki/Ubuntu_OMAP_trunk
<ogra_> GrueMaster, respin in progress, enjoy your morning coffee and relax :)
<GrueMaster> planned on it.
<ogra_> seems pitti didnt think that Ã¼preinstalled needs ubiquity at all
<ogra_> so we have a broken oem-config still
<ogra_> (crashing very badly if you do a non networked install)
<GrueMaster> sigh
<huge>  robclack ... some help ? :)
<huge> rsalveti : do you suggest to use sudo add-apt-repository ppa:tiomap-dev/release ??
<huge> instead of trunk?
<rsalveti> huge: trunk in theory works
<rsalveti> unless something else changed and broke the ppa
<huge> so how to solve my isuess? :(
<GrueMaster> ogra_: jasper is still broken.
<ogra_> GrueMaster, on mx5 ?
<ogra_> janimo, ^^^
<GrueMaster> ogra_: nevermind.  Appears my mirror sync was not sync'd.  It gets confused when we start triggering builds manually.
<ogra_> .oO( would really be helpful if that was discussed here and not in teh other channel )
<ogra_> ;)
<ogra_> GrueMaster, thanks for notifying here :)
<GrueMaster> I tend to go where the people that can fix things pop their heads up.  Kind of like whack-a-dev.
<GrueMaster> (since so few of you guys seem to use windowed IRC systems and only hover over one channel at a time).
<ogra_> i dont :)
<infinity> Ew?
<infinity> Err, "Eh".
<infinity> I get lovely annoyances when people correctly nick highlight me. :P
<infinity> And I blissfully ignore even the window I'm "watching" when they don't.
<GrueMaster> infinity: This is based on years of conditioning on this team.  Not everyone is the same, however I tend to follow best practices for all.
<GrueMaster> And when I see a critical release-stopping issue, I go hunting for immediate assistance.  You should have seen the flack a few releases ago when I didn't.
<ogra_> well, stop making up excuses we all fail in that regard (including me) and use the wrong channel to often
<GrueMaster> infinity: I still don't see a 0.62 tag in jasper bzr.
<ogra_> infinity, so there are people poking me about a partitioner in the ac100 installer ... which i refuse to write ... i'm wondering, since you wanted to move the jasper bits into d-i, we could probably also have a tarball installer udeb
<GrueMaster> I do see your patch to fix partition detection.
<infinity> GrueMaster: That would be because I didn't tag it. :P
<infinity> GrueMaster: There.  Happy? ;)
<GrueMaster> Like I said yesterday, I am just keeping everyone on their toes.
<infinity> ogra_: Yeah, it should all be in d-i somehow or other.
 * ogra_ whacks infinity 
<ogra_> use debcommit !
<ogra_> it auto tags if the changelog is right
<infinity> Meh.
<infinity> I'm actally completely opposed to people trying to switch source packages to bzr repositories, I might be avoiding tagging as a subconscious protest. :P
<ogra_> oh, i fyou actuvely do it i will join in
 * ogra_ prefers source debs too, but gave up on fighting for it 
<ogra_> it doesnt look like it has much chance
<infinity> I have no problems with package collaboration in a VCS, I have huge issues with building directly from that VCS.  Maemo did that, and it wasn't an improvement over the old skool Debian way in any way.  It just made people feel like they were more "cutting edge" or some crap.
<ogra_> well, i still also prefer apt-get source ... edit, dpkg-buildpackage ... upload
<ogra_> and theoretically UDD should DTRT with that and push it into the bzr branch
<infinity> ogra_: And some day, it might.  I hope.
<infinity> ogra_: I dislike the idea that one person's workflow needs to be imposed on another.  So, if that can all Just Work, cool.
<ogra_> heh
<brandini> so I just took the time to zero out both SD cards and flash the preinstalled server image
<brandini> lets hope it works this time :(
<infinity> GrueMaster: Phew.
<infinity> GrueMaster: Resize works here. :P
<infinity> GrueMaster: Your stale mirror has me scared. :)
<infinity> s/has/had/
<GrueMaster> ok.  Still pulling updated images here.
<infinity> So, who's good at partition math?
 * ogra_ hides
<GrueMaster> It's as if zsync completely fell over for all the images I pull.  Each one is taking ~15 minutes to pull.
<infinity> I suspect this is a bug we've had for months/years, but I think we're generating images that are a block short around 50% of the time.
<GrueMaster> And my link light on my DSL router is blinking faster than my eyes can refresh.
<infinity> Which means losing a bit of random data off the end of the ext* filesystem.
<ogra_> you mean it woulod try to write there ?
<infinity> I mean the partition is shorter than the filesystem.
<brandini> infinity: on the dailies?
<ogra_> hmpf
<infinity> brandini: Mmhmm.
<ogra_> after resize or at build time ?
<infinity> EXT4-fs (sdb2): bad geometry: block count 897024 exceeds size of device (897008 blocks)
<infinity> Build time.
<ogra_> bah
<infinity> After resize, it's "fine".
<GrueMaster> I notice it more with 16G SD.  Not sure but could be layout related.
<infinity> Because it re-fits it.
<brandini> that's why all my daily attempts fail :(
<infinity> But that still means it's missing a tiny bit of data, and we have no idea what. :)
<brandini> me too, my 32GB SD works and my 16 doesnt :(
<ogra_> infinity, given that we add 50M spare space ....
<infinity> ogra_: Err, where?
<ogra_> chances are good its just empty space
<GrueMaster> brandini: If you are trying daily-preinstalled this week, it fails for a whole lot of reasons.  Next build "should" be better.
<ogra_> infinity, in the TI contract :)
<infinity> ogra_: Oh, you mean on the livefs itself.
<ogra_> infinity, i originally added 50M to the post-boot scripts, if thats not there anymore, ask who removed it
<infinity> ogra_: Still, the partition being short for the FS is broken. :P
<ogra_> sure
<infinity> ogra_: Wait.  No, I'm confused.  You're adding 50M padding to the partition, or to the filesystems?
<ogra_> but if the overlap is for empty space and the partitioning is fine after install, thats not a biggie
<infinity> ogra_: Cause I see no padding on the partitions.
<ogra_> to the fs indeed
<infinity> Which is sort of the problem..
<brandini> GrueMaster: :(
<ogra_> so TI can modify the panda images for blaze
<ogra_> well, the 50M are added before the partitions are created
<ogra_> iirc we are creating an img file with 50M more than the chroo occupies
<infinity> ogra_: I must be missing where that happens.
<ogra_> *chroot
<infinity> ogra_: Or it doesn't anymore. :P
<ogra_> should be in post-boot
<infinity> I've been staring at post-boot for the last day.
<ogra_> that might be, i havent touched the omap/omap4 script in a release
<infinity> Though, mostly that one block of shell arithmetic.
<GrueMaster> sounds like more craknschpiel.
<infinity> That I think is off by a block.
<ogra_> i think only NCommander did
<ogra_> the 50M are essential though
<brandini> so I should use the 11.04 release instead?
<infinity> Current oneiric server images seem fine.
<infinity> Keep in mind that some cards will just hate you, too. :P
<brandini> :)
<brandini> they all do!
<ogra_> infinity, oh, might be that we did it in livefs.sh, not in post-processing code
 * ogra_ chaks livecd-rootfs
<infinity> ogra_: That would make more sense, if the goal is to have a bigger FS.
<infinity> ogra_: Since a bigger partition doesn't actually give you a bigger filesystem. :)
<ogra_> yes
<brandini> I really wish I could boot off my usb drive
<ogra_> livefs_ext2()
<ogra_> {
<ogra_>   # Add 1024MiB extra free space for first boot + ext3 journal + swapfile
<ogra_>   size=$(($(du -ks ${ROOT} | cut -f1) + (1024000)))
<ogra_> there it is
<ogra_> no idea why thats not 50M anymore
<ogra_> infinity, oh, btw, are we still properly creating the swapfile in live-build ? else beagle C4 wont work anymore
 * ogra_ just noticed we moved that into livecd.sh
<infinity> I doubt it.
<ogra_> (C4 will OOM if you try to run desktop and have no swap)
<infinity> But nothing there was turning it on either...
<ogra_> jasper does
<infinity> Then jasper can create it too?
<ogra_> it also used to create the file
<ogra_> but that adds 10.15 min to the jasper run
<ogra_> 10-15
<infinity> Eh?
<infinity> It should be instant.
<ogra_> no
<ogra_> you have to dd 512MB
<infinity> You can dd it sparse.
<ogra_> sawpfiles cant have zeros
<ogra_> or holes
<ogra_> mkswap will refuse to use it, try it
<ogra_> (ignore that i said zeros above :) )
<infinity> root@vishnu:~# time dd if=/dev/zero of=test.swp bs=512 count=0 seek=1048576
<infinity> 0+0 records in
<infinity> 0+0 records out
<infinity> 0 bytes (0 B) copied, 6.2626e-05 s, 0.0 kB/s
<infinity> real	0m0.011s
<infinity> user	0m0.000s
<infinity> sys	0m0.000s
<infinity> root@vishnu:~# time mkswap test.swp
<infinity> mkswap: test.swp: warning: don't erase bootbits sectors on whole disk. Use -f to force.
<infinity> Setting up swapspace version 1, size = 524284 KiB
<infinity> no label, UUID=87833675-2023-43d1-83a8-63afbd948484
<infinity> real	0m1.531s
<infinity> user	0m0.000s
<infinity> sys	0m0.010s
<infinity> ogra_: ^--- Not seeing a problem.
<ogra_> swapon ?
<infinity> Oh. :P
<infinity> You said mkswap would refuse to use it. ;)
 * ogra_ would have been surprised :)
<ogra_> sorry, its a year ago i had to do with it ...
<ogra_> so it was swapon
<ogra_> i just know it doesnt work
<infinity> That's a bit silly, given that I can create files on a filesystem on a loopback device with holes.
<infinity> In fact, I could create a swapfile on a filesystem on a loopback with holes, and it would work!
<ogra_> well, swapon would refuse too in that case i bet
<infinity> Nope.
<infinity> (Hint: Our SD card image has "holes")
<ogra_> sure
<ogra_> the swapfile itself doesnt
<ogra_> not sure how that gets handled on fs level if your fs has holes though
<infinity> Well, holes are a temporary inconvenience.
<infinity> The VFS layer masks around sparse files.
<infinity> I can only assume that VMM is doing nasty things to VFS, and they should sit down for a timeout.
<ogra_> might be ...
<infinity> Anyhow.  That whole swap creation thing has been broken/nonexistant for months (ever since the live-build switch), and no one has complained. :P
<ogra_> well, in any case we need to look into that for post beta
<ogra_> likely because not even GrueMaster tests desktop on C4 anymore :)
<infinity> That was sort of my point.
<GrueMaster> I haven't tested desktop on much of anything in the last few weeks.
<infinity> I suspect no one tests or uses it.
<infinity> (On that hardware)
<ogra_> well, but if we offer images for it, it has to work
<ogra_> or we restrict what we support
<ogra_> or drop the image
<infinity> We offer images for "omap", we don't specify which boards...
 * ogra_ wouldnt mind to drop C4 support
<GrueMaster> Can't drop the image.  It still supports XM
<infinity> That's like saying Ubuntu Desktop works on every x86 machine (it doesn't).
<ogra_> infinity, we offer omap3 images for beagleboards
<infinity> ogra_: Yes, there are lots of beagles that it works on.
<ogra_> we need to make clear ^that we dont support C4 imho
<GrueMaster> We can limit what we support, and leave other systems to user discression.
<ogra_> especially since the C4 was our only supported TI board for a while
<GrueMaster> XM in, C4 out for desktop.
<ogra_> right
<infinity> ogra_: Well, the other option is to have jasper take that 10 minutes to dd a swapfile if (and only if) you're on a C4.
<ogra_> needs to go into the release notes
 * ogra_ will happily see the swapfile crap die 
<GrueMaster> infinity: Anything on C4 takes a lot longer than on other platforms.
<ogra_> infinity, well, i didnt like that hack when i added it, i dont like it more today :)
<infinity> Heh.
<infinity> I will say I was pretty effin' shocked to discover a swapfile on my SD card when I first set up the Panda.
<GrueMaster> As to my beagle, I honestly do not have any room for that atm.  I am out of desk space/network drops/power cords.
<infinity> Cause swapping to nand flash is about as smart as shaving your scrotum with a cheese grater.
<ogra_> that i'm the guy who writes most of the scary weired hacks doesnt mean that i particulary admire what i hack together :)
<ogra_> *weird
<GrueMaster> done that.
<ogra_> infinity, as you mantioned above, swapfiles sit on top of the VFS layer ... they should be less harmful than a swap partiton
<ogra_> i wonder where all these typos come from today
<infinity> ogra_: It's pretty harmful.  But so it almost everything a modern system can do to flash.
<infinity> (I've killed a card here just with /var/log)
<infinity> s/so it/so is/
<ogra_> well, you have a stack of FTL->VFS->swapfile
<ogra_> at least on SD
<infinity> But I wasn't just referring to the destruction of the flash, I was also just talking the speed.  I'd probably rather invoke the OOM killer than swap to monkeys with pencils.
 * ogra_ hasnt killed a card in 4 years ... i had some dead USB keays from my classmate times
<ogra_> OOM will tear your app down
<infinity> Yup!
<ogra_> swapping will come back after the IO is done
<ogra_> so you can still save your document
<infinity> From the C4 perspective (that couldn't run desktop at all), the swapfile made sense.
<ogra_> even if it takes 1h
<infinity> On my Panda, it made less sense. :P
<infinity> S'all I'm saying.
<ogra_> swapfile makes always sense on systems where you potentially can hit OOM imho
<ogra_> just because of the above
<infinity> That's every system in the world.
<infinity> But you'll still OOM when you fill swap.
<infinity> So.
<ogra_> well, chances on my 4G intel are less than on my 512M XM
<infinity> Eventually, you hit a point where you're saying "this is how much memory I have".
<Neko> happy medium: use zram to cache swap pages in compressed memory, and reduce soujourns to disk until it's absolutely necessary?
<infinity> (Unless you do the dynamic swap thing, then your wall is just disk space)
<ogra_> Neko, yes, we used to use compcache in the past
<ogra_> i was planning to have a spec on it for UDS
<GrueMaster> What is going on with cdimage?  My zsync is extremely slow.  Been updaing one image now for almost an hour.
<infinity> Honestly, I think we're hitting a point where we don't care anymore about that sort of thing.  Or shouldn't.
<ogra_> GrueMaster, many people download ?
<infinity> Modern ARM systems (at least the ones we target) have RAM, can have more, and can swap to storage that isn't flash.
 * GrueMaster hates release week.
<ogra_> infinity, well, zram/compcache can easily add another 50% of ram for no costs
<ogra_> and its a good first level swap
<infinity> ogra_: The cost is CPU time.  That never mattered on ARM, where memory I/O was shit, and CPU was free as a result, but that's changing.
<ogra_> the cup time cost isnt really noticeable
<infinity> ogra_: When we become cycle-bound instead of i/o bound, we need to watch our solutions.
<Neko> big problem though, you have to make sure it is added first. When we ran the init scripts they came up far, far after disk swap was enabled, and without specifically bumping priority to 0 (since disk swap came in at -1) it wouldn't use it
<ogra_> we did experiment with compcache in the past on the C4 and older
<ogra_> and there wasnt a noticeable hit on CPU back then
<Neko> then of course, if you use prelink, running firefox with a few tabs, leaving a system on for days and days, your compressed swap fills with discarded linker data
<ogra_> ubuntu will never use prelink i think
<infinity> ogra_: Yes, I know the CPU time wasn't noticeable (and, in fact, it probably made things faster), but like I said, all ARM systems until now have been I/O bound.
<ogra_> sure
<infinity> ogra_: When your CPU is idle half the time, waiting on RAM, compressing RAM is a huge win.
<ogra_> and they will stay that way for more releases :)
<Neko> efika isn't so i/o bound :)
<infinity> Its memory bandwidth isn't that exciting.
<ogra_> its CPU neither :)
<Neko> it isn't on most ARM boxes
<infinity> Thank you for restating my point?
<ogra_> tegra has a pretty decent memory bandwith
<ogra_> faster than panda
<Neko> you can have all the memory bandwidth in the world but running off a USB disk or SD card is basically negating everything there
<infinity> Eh?
<infinity> Are you from the "I benchmark applications by cold-cache starting them?" camp?
<infinity> How fast Firefox starts != how fast it runs.
<Neko> well, let's put it this way; it took 4 hours to compile a kernel on pandaboard. I can do it in 70 minutes on an Efika with -j3.
<infinity> And memory I/O is hugely important.
<infinity> Neko: Odd, I have both here, and the Panda nearly always wins compile races.
<ogra_> definitely
<infinity> Neko: Was that when you were getting 5MB/s off a Panda's USB?
<Neko> it's purely down to the SD card in use.. and it's a good SD card
<ogra_> ac100 wins over both though :)
<Neko> no I don't use USB on the Panda
<infinity> Neko: Oh, if you're compiling on SD, that's a lost cause.  And a pointless comparison.
<Neko> just a UHS SD card.. which isn't so ultra-high-speed since the bus seems limited to about 10MB/s
<ogra_> thats bad
<Neko> booting over USB on Panda helps but for some reason it doesn't help all that much.  it still loses the kernel compile race, even building on another disk.. there is some very strange stuff there, I think combined with the extremely poor SD and USB performance, even when that's fixed, SMP slows things down.. it builds faster on -j1 than it does on -j2
<GrueMaster> Neko, what is the performance on the efika with the same SD card doing the same job?
<Neko> I can't say I've attemped it in about 3 weeks though
<Neko> GrueMaster, about the same, the point would be that no matter how good you think your SD card is, it's actually not.
<GrueMaster> kernel patch fixed usb performance last week.  Retest, then talk about it.
<Neko> and USB disks don't solve anything...
<steev_> Neko: don't talk bad about the pandaboard
<infinity> They do if they work. :P
<Neko> I like my pandaboard
<GrueMaster> The point is, when you spout performance benchmarks on two different systems, that you are actually reducing as many variables in the test setup.  Comparing Sd vs Sata is blindingly stupid and invalid.
<Neko> btw USB disk in question was an A-Data MLC SSD.. the bus limits it's performance over USB (but it's topping out somewhere else).
<Neko> nobody ships a SATA system except Quickstart
<GrueMaster> Again, update kernel & retest.
<infinity> Neko: About 7 times now, people have mentioned that your USB disk tests were getting about 5MB/s, and that's fixed.
<dash> Neko: i just found out about trimslice
<infinity> Neko: And yes, when your I/O is throttled that low, -jN will make it worse, since concurent reads just block hard.
<Neko> trimslice is USB to SATA
<dash> !
<dash> well that's no good
<dash> glad i bought an mx53 instead then
<Neko> the only chip out there with a native sata controller is the mx53.. it's sad to say, it really is
<dash> soon i will have my first web server with an accelerometer
<ogra_> trimslisce has the fill PCIe bus available (unlige other tegra implementations) you can easily use a miniPCI SATA card
<ogra_> s7fill/full/
<Neko> infinity, I tried a bunch of things, there were questions about SMP causing it, which turned into that write buffer flush patch.. I disabled SMP a long while back and it gave me back my performance, but it still lost. Perhaps the CPU itself, or some power management was in the way, or just USB being the worst possible protocol with too much overhead and zero possibility for DMA
<NCommander> infinity: the post-boot scripts for armel are made otu of cheap gum and duct tape
<dash> oh, i take it back, that thinkpad had an accelerometer.
<GrueMaster> infinity: The current respin, what was affected?  oem-config?
<GrueMaster> Wow.  Lots more chatter from the kernel in dmesg.  Mostly audio and wifi.  There will be bug reports.
<brandini> :)
 * GrueMaster stares at the beaglexm screen and silently wonders why oem-config restarted a second time.
<GrueMaster> So, we no longer are doing swap files on omap images?  System is real slow.
<infinity> We haven't been for months.
<GrueMaster> Why not?  This is very slow with only 512M.
<GrueMaster> Had I been able to do daily image testing, I would have raised a flag a long time ago.
<infinity> Because that code was in livecd-rootfs, and it never got moved to live-build, and no one noticed until today.
<infinity> I swear we just had this conversation this morning.  That was the context of "dropping C4 support".
<infinity> And not to question what you're seeing, but the speed issues could be elsewhere.  I refuse to believe that swapping to flash could make anything *faster*, just less prone to OOMing.
<GrueMaster> Well, may as well drop all armel support without it.  Even the panda daily is very slow, with all of the cruft added by DX.
<GrueMaster> crap.  panda hung.
<GrueMaster> Hard hang while oem-config was configuring locales.
<GrueMaster> As to swap, not sure what is going on, but my loadavg just dropped after creating a 1G swapfile and enabling it.
<infinity> GrueMaster: I'm happy to hack swapfiles into live-build to resurrect the functionality.  It's just not happening for B2.
<GrueMaster> Wasn't talking about B2 required.  But it would be nice to know about these changes before release.
<infinity> They do drastically infalte the size of the image, though (not the zipped size, since the swap is empty, but the real size).
<infinity> Yeah, no one seemed to be aware until, like I said, today. :P
<infinity> But it's been like this since the switch.
<GrueMaster> And yes, I am seeing a huge amount of swapper errors in dmesg on beaglexm.
<infinity> Like..?
<infinity> You can't reall have swap errors without swap.
<infinity> s/reall/really/
<GrueMaster> Can't?  Tell that to my system.
<infinity> Oh, wait.  You mean a page allocation error?
<infinity> If so, then yeah, that's just OOMing.
<infinity> I find it a bit sick that we can't boot with 512M of RAM.  But whatever. :P
<infinity> We'll fix it.
<GrueMaster> Yea, I've heard that line a lot this cycle.  :P
<GrueMaster> BTW:  Installer is still on the unity menu bar after login.
<infinity> Lovely.
<GrueMaster> Rebooted beaglexm with /SWAP.swp, desktop looks much different.
<GrueMaster> I have a top indicator bar, for example.
<infinity> Picky, picky. ;)
<infinity> Yeah, fuck omap3 for now, then.  If it boots at all, ship it, realising that the underlying software is identical to omap4.  And light a fire under my ass post-B2 to get you swapfiles back.
<GrueMaster> Bah.  ENONETWORK again on my beaglexm.
<brandini> is there a new daily image that is worth downloading?
<brandini> also, is there any way to make the serial console actually display useful output ?
<infinity> Define useful?
<brandini> well right now when I connect and the installer comes up it's so jumbled I can't even tell what it says
<brandini> using the default terminal app in ubuntu, export TERM=vt220 minicom and no dice :(
<infinity> brandini: Oh, minicom's just crap.
<brandini> I also tried screen, cu and gtkterm
<infinity> brandini: "screen /dev/ttyUSB0 115200" is your friend.
<infinity> (Or whatever your serial device is)
<infinity> At least, it always DTRT here.
<brandini> I did try that... not looking good
<infinity> Not sure what to suggest, then.  That always works for me.  It's not perfect, but it's certainly usable.
<infinity> I think terminal emulation became a lost art when BBSes died.  I miss Telemate and Telix.
<GrueMaster> brandini: Do you have a null modem cable attached?  If so, remove it.
<GrueMaster> What image are you trying?
<brandini> GrueMaster: I have a usb to serial adapter
<GrueMaster> Ok, plug that straight into the panda.
<brandini> oneiric-preinstalled-server
<brandini> does the preinstalled from today have the partition/packaging issue fixed?
<GrueMaster> Today's?  20110921 is the one you want.
<brandini> ok
<GrueMaster> Seems to.
<brandini> this mirror is SO SLOW
<brandini> an hour to grab 500mb?
<brandini> I don't need the manifest or zsync right?
<GrueMaster> Yea, having same issue here and I use zsync (which in theory only pulls binary differences).
<infinity> No, but if you have the old image, you could just "zsync http://path/to/zsyncfile"
<brandini> oh really...
 * brandini tries
<GrueMaster> Once you have the img.gz, you can update it with zsync.
<infinity> The old image needs to be in your CWD.
<brandini> I can handle that much:)
<GrueMaster> not nessarily. Use "zsync -i <old image> http://cdimage....<new image>"
<infinity> Well, yes.  But no need for -i if you just want to update it in place. :)
<GrueMaster> The "old image" can even be a different name (or even subarch, which is kind of interesting).
<brandini> 88% complete
<brandini> nice!
<brandini> I didn't know about zsync
<brandini> this pandaboard seems like it will be absolutely great as a webserver
<GrueMaster> I've tested it.  As long as you don't expect high (as in slashdot.org) traffic, it is pretty nice.
<brandini> no, I don't
<brandini> what are your apps written in?
<GrueMaster> Part of my testing included the entire lamp stack.
<brandini> or just static html
<GrueMaster> More install and run some prepackaged website.
<GrueMaster> Then nuke and run some other test.
<brandini> I'm using go
<GrueMaster> Let me know how it works out.
<brandini> even on my atom proc it does thousands of reqs/sec
<GrueMaster> I just hope to get an arm based server in the near future.  Testing the server stacks on what is essentially a cell phone is not pleasant.
<GrueMaster> (although running 6 pandas in a filesystem cluster makes me giggle).
<brandini> :)
<brandini> I wouldn't mind a panda farm
<dash> mmm, panda farm
<dash> of course. how else would we get those delicious panda steaks
<brandini> :)
<brandini> GrueMaster: I did have go built on the arm on 10.10... decided I wanted 11.x and didn't build any of my apps on the pandaboard
<GrueMaster> Do you have a link?
 * GrueMaster is always interested in using new apps as test suites.
<brandini> www.golang.org
<brandini> it's the new python, ruby, java :)
<GrueMaster> sigh.  yet another language for me to learn.
<dash> eh
<dash> go isn't all that.
<dash> it's a bunch of old ideas thrown together, some of them good, some of them dumb
<GrueMaster> I'm self taught in C, C++, JAVA, Perl, Atari-basic, x86 assembly, to name a few.  Adding to the stack heap is getting painful.
<GrueMaster> No formal programming training.
<infinity> GrueMaster: You didn't see Gustavo's Go presentation in Dublin?
 * GrueMaster was teaching more than learning in the University of Phoenix course.
<infinity> GrueMaster: And the company-wide challenge to go (re)write random crap in Go for kicks?
<GrueMaster> infinity: I may have missed it.
<GrueMaster> (and when have I had spare time to go programming for kicks?)
<infinity> Apparently, there are prizes at stake.
<GrueMaster> in any language.
<infinity> This hasn't motivated me, mind you.
<GrueMaster> hmm, prizes you say.
<dash> heh
<dash> go! it's so great, they have to bribe people to use it.
 * GrueMaster wonders how many engineers and managers he could piss off by rewriting all of the qa tests in go?
<brandini> if you rewrite a C program in Go you have to use Go conventions rather than your C conventions
<brandini> or it's not worth the effort
<brandini> even this new images says "If you created or changed a DOS partition, /dev/(1) to zero the first 512 bytes: dd if=/dev/zero...
<brandini> oh, it says partition 2 does not end at a cylinder boundary
<GrueMaster> Ignore it (unless it has actually failed).
<brandini> still resizing
<brandini> 95/100
<GrueMaster> What size SD?
<brandini> 32GB
<GrueMaster> Whoa.  If you run into issues, please let me know.  I don't have anything that big.
<brandini> ok
<brandini> if that fails should I try a 16GB?
<GrueMaster> I have a few 16G, and a lot of 8G.  Nothing bigger.
<GrueMaster> Well, it hasn't been tested (by me) on 32G.
<GrueMaster> I'm on a 16G right now.  No problems yet.
<infinity> My Panda runs on a 32G, but I haven't tested that since early oneiric.
<infinity> I see no reason why it would have stopped working, though.
<brandini> it hit 100/100 and the lights are still blinken
<infinity> I have a stupidly high miss rate for bad media in general though. :/
<brandini> Kingston?
<infinity> All over the map.
<infinity> Kingston, Patrio, non-name junk, Lexar.
<brandini> the one I'm using now has the rainbow on the front
<GrueMaster> brandini: That is normal.  The counter is just a shell script routine.  resize does a litlle post-processing.
<infinity> Actually, the Lexar cards are the only ones that have never acted up, but I doubt that's a quality thing, and suspect it's just random statistical luck.
<brandini> woot, creating bootloade
<brandini> just restarted
#ubuntu-arm 2011-09-22
<brandini> I sure hope the defaults are good cause I still can't read this console :)
<GrueMaster> Serial console?
<brandini> yeah
<GrueMaster> I wonder if you have a bad connection or possibly a bad port on the panda.
<brandini> it IS going to a usb hub first
<GrueMaster> Shouldn't matter.  I have 8 usb serial cables on a hub for all my systems.
<GrueMaster> And my serial port monitoring system is an older Atom based system in a mini itx case that I remote to.
<brandini> is the primary network interface during install the wireless or the lan?
<GrueMaster> On server, lan.
<GrueMaster> I don't think we have all the packages installed for wifi on the server image.  Will check.
<brandini> I need the lan one I just couldn't read it
<GrueMaster> top default option.
<infinity> GrueMaster: The server image will do wifi in the clear or with WEP, but I suspect WPA will fail.  Haven't tested.
<infinity> (I always used to have a WEP fallback just for d-i testing, but maybe it does WPA properly now)
<brandini> will bad things happen if I reset in the middle of this install?
<GrueMaster> infinity: The firmware used to be missing from the image.  Haven't tested it recently.
<GrueMaster> brandini: Is it at a prompt or doing something?
<brandini> prompting for network configuration
<GrueMaster> You can restart.  Main thing is to not reboot during a write process.
 * infinity takes off for the evening.
<brandini> anyone use a macbook to do the serial connection?
<brandini> I've not been able to figure it out on the mac :)
<GrueMaster> Not me.  never owned one.
<brandini> you're not missing anything
<brandini> ;)
 * GrueMaster wanders off the grid for a while until the kubuntu images finish downloading.
<brandini> sweet, I finally got the serial cable working on my mac and the display is much better :)
<brandini> are oem-config-firstboot errors trying to write to /var/log/oem-config.log because of a read-only filesystem normal?
<GrueMaster> No.  You should not have a read-only filesystem
<GrueMaster> You may need to reflash and restart.
<brandini> done and done
<brandini> GrueMaster: nope, same thing happened... "Running post-installation trigger man-db" 100% /usr/sbin/oem-config-firstboot: line 58: /var/log/oem-config.log: Read-only file system
<GrueMaster> Hmm.  I would suggest trying a smaller SD card.
<brandini> ext4_mb_generate_buddy:736: group 160, 4045 blocks in bitmap, 4096 in gd
<twb> Could that be coming from errors=remount-ro ?
<brandini> looks like it is
<brandini> let me paste it all...
<twb> In that case get a card that isn't buggered
<brandini> http://pastebin.com/S8e7CXGH
<GrueMaster> brandini: Need to see why journal aborted.  Is there any messages before the first line?
<brandini> not that I can see
<brandini> Im' trying another card
<GrueMaster> Everything worked fine here with the latest image. But as I have not tested on anything bigger than 16G, I suspect your card (or the system may not like your card).
<brandini> I've never had any luck with CF
<GrueMaster> CF?
<GrueMaster> These are SD.  Not nearly as fast.
<brokencodes> Class 20 SD cards will be mainstream in a few months
 * GrueMaster uses CF cards in Sata adapters for rootfs on 2 servers and a firewall.
<GrueMaster> Oddly, I have found that the lower the class, the more reliable and better overall performance.
<brandini> with the 16GB card it's been at Resizing, pass: 1 [100/100] for a few minutes...
<GrueMaster> The higher class are great for sustained sequential reads/writes (like video cameras).
<GrueMaster> brandini: any activity on the LEDs?
<brokencodes> brandini, you need fsck the partition, bro...
<brandini> the one closest to the SD card is solid and the other is blinken lots
<brokencodes> the journal is in status (ABRT)
<brandini> power off and fsck the card?
<brokencodes> do sudo fsck /dev/mmcblk0p2 -c -y
<brokencodes> yes
<brandini> in another machine right?
<brokencodes> yes
<brokencodes> also, I would suggest not using a journalling file system on an SD card
<brokencodes> EXT2 is best
<brandini> I didn't format it before flashing this image
<GrueMaster> Actually, I have benchmarked and found ext4 to be very fast.  But we are just now (like Monday) in the process of switching on the SD preinstalled images.
<brandini> I didn't know I was supposed to format the preinstalled image?
<GrueMaster> Shouldn't matter.  The dd process will overwrite the first 1.6G.  Resize will clear the rest.
<brokencodes> its is very fast, but is designed for magnetic media, not FLASH based media, such as the NOR flash in SD cards
<brandini> ok, it fixed things
<brandini> now lets hope it boots :)
<brokencodes> the journal is constantly rewritten, even if just for a read, making it burn the Flash media in the journals blocks
<GrueMaster> Actually, ext4 is designed for SSD, which is based on the same tech as SD.
<brokencodes> GrueMaster, you are mistaken
<GrueMaster> btrfs is supposed to be even better, but it isn't stable yet.
<brokencodes> SSD's have wear leveling, SD cards have bit shifting for wear leveling (poor for repeated writes)
<brandini> it's resizing again :)
<brokencodes> the wear leveling in SSD's is much more robust than the wear leveling in SD cards
<brokencodes> I can destroy an SD card in a matter of hours, with sparsewriting routines, from EXT4, or ReiserFS
<brandini> 92/100
<brokencodes> EXT2 is much more suited to older lessstable media, with SD fits into
<brokencodes> sorry, my spacebar is failing
<brandini> too much pepsi ;)
<brokencodes> brandini, you getting jitters?
 * GrueMaster is being called to dinner.  Biab.
<brandini> I don't think this is going to work
<brokencodes> brandini, did you do what I asked you to?
<brandini> yup, only sudo fsck /dev/sdc2 -c y
<brokencodes> sudo fsck /dev/mmcblk0p2 -c -y?
<brokencodes> ok
<brokencodes> did it write a new error block?
<brandini> bad block inode
<brokencodes> yes
<brandini> yup
<brokencodes> did it write a new bad block inode?
<brokencodes> you have a failing SD card, then...
<brandini> oh fun!
<brandini> it's new!
<brokencodes> brand name?
<brandini> /dev/sdc2: Updating bad block inode.
<twb> It could also be something like he is writing the partition smaller than the filesystem, right?
<brandini> it's a kingston class 10
<brandini> but I'm seeing the same error on my transcend
<brokencodes> I would zero the card
<brandini> ugh, ok
<twb> brandini: hey, do you know what kind of FTLs (micro) SD cards have?  I couldn't find *any* documentation in wikipedia or google
<twb> Sorry, s/brandini/brokencodes/
<brokencodes> dd if=/dev/zero of=/dev/sdb bs=8192
<brokencodes> FTL?
<twb> flash translation layer
<brandini> brokencodes: I did that this morning but I flashed the previous daily and then todays daily
<brokencodes> you mean Mean Write before failure?
<twb> The thing that makes it look like a /dev/sda instead of /dev/mmc
<brokencodes> its usually in the SD card interface
<twb> As in the reader?
<brokencodes> si, the reader
<twb> Thanks, I kinda suspected that.
<brokencodes> crappy reader == crappy sd card performance / reliability
<twb> So what I should do is the equivalent of lspci -nn for whatever bus I have instead of PCI, and then look up what kind of FTL I have
<brokencodes> I would say yes
<brokencodes> most emulate ata / atapi
<twb> Also, are micro SD to SD adapters passive (i.e. just changing the physical shape), or do they have active components?
<brokencodes> no, just wires
<brokencodes> passive
<brokencodes> if your SD card reader is plugged into usb, you would do lsusb instead, but you prolly knew that already
<twb> It'd be nice if SD readers had a ioctl you could issue to bypass their FTLs, and just use jffs2/logfs or something :-P
<brokencodes> you can
<brokencodes> its just a block device
<brokencodes> yoyu can make a link, and write as normal NOR flash
<twb> Not if the kernel tells me "hey, here's /dev/sda"
<twb> surely
<brokencodes> ln /dev/sda /dev/mmcblk0
<twb> wow, really
<brokencodes> ln /dev/sdb2 /dev/mmcblk0p2
<brokencodes> yep
<twb> No, that can't be right
 * infinity does a whois and suddenly wonders if brokencodes == thebroken, or if it's just odd coincidence.
<twb> The kernel doesn't care what the name is, only the major/minor
<brokencodes> yes
<brokencodes> I'm thebroken
<brokencodes> some utilities wont allow certain functions on certain device names
<twb> They're wrong, then.  But I mean stuff like dd and mkfs
<twb> https://secure.wikimedia.org/wikipedia/en/wiki/Memory_Technology_Device <-- what I'm thinking of, where you bypass the FTL
<twb> *bypass, or there isn't an FTL to begin with
<twb> http://paste.debian.net/131503/ <-- they show up as character devices, not block devices
<twb> Or a mix.  Or something.  I guess I don't know what I'm talking about
<twb> I guess a better question would be: if I have a micro SD card that presents as /dev/sda or /dev/mmcblk0, would it be better to use LogFS rather than ext[234] ?
<brokencodes> you could also mknod on the device, and chage to the type of device you want, could work, might not
<twb> I think both sda and mmc are going via the FTL
<twb> Whereas MTD bypasses the hardware FTL and implements on inside the Linux kernel -- mtdblock (b) is mtd (c) + kernel FTL
<brokencodes> Thats what I was referring to also
<brandini> I sure hope zeroing makes it work :)
<phh> twb: yup that's it
<phh> well mtd doesn't bypass ftl, it's more that there is no ftl :p
<twb> phh: right
<phh> twb: logfs is theorically better than ext*
<phh> i don't need how it goes in real world
<phh> nilfs2 is indeed faster than ext*
<twb> phh: I'm saying "gee, it'd be nice if I could bypass the crappy hardware FTL when there *is* one, and use jffs2 or whatever on the mtd character device" -- brokencodes says it might work, but I think he's wrong.
<phh> but hum logfs is more for mtd than for FTLed device
<twb> Unless it's some developer board-type SD card reader
<phh> twb: he is wrong
<twb> Thanks, I feel better now :-)
<phh> the thing is that the MMC """api""" doesn't make it easy to make a FTL-less (or FTL bypassed) device
<phh> well afaik
<twb> And since I can't bypass the hardware FTL, I am screwed by it regardless and I might as well use a fs designed for block devices
<phh> twb: na
<phh> twb: on MMCs, hardware FTL sucks
<phh> so a (real) logged FS is way better
<twb> Even on top of the crappy hardware FTL?
<phh> yes
<twb> OK, so I have an 32GB eMMC /dev/mmcblk0p1 that will have the root filesystem, and a 16GB micro SD /dev/sda that will have /home on it.  What's the best filesystem to use?
<phh> (ogra_ is going to kill me.)
<twb> Oh, and this is with 2.6.38
<phh> twb: basically, nilfs2 is the best FS i've found for MMC and friends, now the devs are saying it's unstable, so you might not want to rely on it for your data
<twb> Well I'm using btrfs on my SSD in my old netbook :-P
<twb> Incidentally, stupid SD card reader doesn't handle ext4 -o discard :-/
<phh> and sdcard does ? :p
<twb> I don't know
<twb> I magical imagination land where everything DWIMs, yes :-)
<phh> DWIMs ?
<twb> Does What I Mean
<phh> :)
<twb> phh: that's where all my hardware has OpenFirmware too :P
<phh> twb: i've been through some specs about it, and trim/erase/whatever it is called is only in some eMMC docs
<phh> (yes eMMC/SD/uSD/MMC/whatever are using the same protocol, and yes it seems there are different specs for them, why ? :D)
<twb> Because as long as it boots windows they will sell it :P
<brandini> I really hope this zero'ing pays off... I'm doubtful
<phh> brandini: it depends on how clever FTLs are
<phh> so yes i'm kind of doubtful too :D
<brandini> :)
<twb> About as clever as a five year old on PCP cut with draino
<brandini> well seeing as I've got two brand new SD cards that were both rated to work well and they completely don't work I don't know where to turn
<brandini> can the pandaboard boot off usb?
<twb> It's using u-boot?  Can you get into the u-boot serial console?
<brandini> hrmmm, maybe
<GrueMaster> infinity: I need to file a bug on this lack of swap so that it can be added to the release notes and because I may need to fail kubuntu desktop as a result.  What should I file against?
<infinity> GrueMaster: livecd-rootfs, I suppose.  We can wiggle it around if we have to.
 * ogra_ runs an ac100 install
<ogra_> bbl
<ndec> ogra_: lool: ping
<ndec> i think we found a bug in dkms, how do you recommend that we report it?
<ndec> i sure can report in launchpad, but isn't that better if i report upstream directly?
<xranby> lool: hi. do linaro have access to the secret java tck tests that checks if the arm jvm follows the java specification?
<lool> ndec: pong
<lool> ndec: it's best if you report it upstream directly if it affects upstream, yep
<lool> ndec: you can file it on launchpad as well as a meta-bug tracker to track it upstream, in ubuntu, in your project etc.
<ndec> lool: do you want a LP as well once (if) it's confirmed
<lool> xranby: no
<ndec> argh..
<lool> xranby: at least not that I know of  ;-)
<xranby> lool: ok, it would be good if someone with access to it could test the current armel and armhf packages
<lool> ndec: I don't strongly care about having a LP bug for DKMS personally, up to you  :-)
<xranby> lool: jamvm work on armhf..   so its simply up to ubuntu and debian to enable and package it
<lool> xranby: armel and armhf packages of what?
<xranby> lool: openjdk6 and openjdk7
<ndec> lool: the problem is that dkms status does not work if the module name has 'kernel' in the name. it was working with 10.10. it's broken in oneric. dkms add, build and install work fine though. but since CDBS will do add, build check with status if build was ok and then install. in 11.10 the module is built but not installed.
<lool> xranby: so currently openjdk 6 uses jamvm, but it wouldn't work with openjdk 7; this is going to make it a real pain  :-/
<xranby> lool: jamvm can bootstrap itself using openjdk7
<lool> xranby: apparently some new opcode and API are missing
<xranby> lool: so everything that work using openjdk6 + jamvm work using openjdk7 + jamvm       robert are working on adding the new bytecode that are used by some dynamic languages so we will get support for those as well
<lool> xranby: Ok; I actually tried contacting Robert a couple of times on this topic, but I didn't manage to reach him
<sniperjo_> hey guys, I've been trying to get ubuntu on a arm board for the last 2 days and had no luck with anything. there is a precompiled version of angstrom that comes with it. Is there anyway of installing / compiling ubuntu on that ?
<ogra_> define "a arm board"
<ogra_> :)
<sniperjo_> a Technexion Thunderpack
<ogra_> what cup is on there ? we only support certain cpu types in ubuntu
<ogra_> s/cup/cpu/
<sniperjo_> OMAP 3530
<ogra_> well, theoretically we have omap3 images
<ogra_> but they are built and tested for beagleboard only
<ogra_> you could try one of them and see if it works
<sniperjo_> will i have to change the uboot settings ?
<sniperjo_> ogra_: the standard beagle image doesn't work
<GrueMaster> sniperjo_: Try the beagle image with the MLO & u-boot from your system.  See if that works.
<sniperjo_> GrueMaster: how do i use my u-boot ? just simply copy it across?
<sniperjo_> I've just tried the standard beagle image and got http://pastebin.com/xGSa9rL4 , couldn't read uImage
<GrueMaster> What you should do is backup the first partition of the SD, reformat (mkfs.vfat -F 32 <dev>), then copy IN ORDER:  Your MLO, your u-boot, uImage, uInitrd, boot.scr.
<GrueMaster> That's odd.
<GrueMaster> I'm in a meeting atm.  Hang tight and I should be able to help more in ~15-20 minutes.
<sniperjo_> GrueMaster: amazing, thanks !
<brendand> hi everyone. i want to do some research into querying hardware on arm devices in the absence of lspci
<brendand> is udev still usable?
<XorA> ls /sys
<GrueMaster> sniperjo_: Any progress?
<sniperjo_> GrueMaster: i was sort of waiting your return, but someone in the linux channel had what seemed to me a pretty good idea, put my original linux back onto NAND and then chroot into the sd card to try it
<infinity> janimo: Do you have a comprehensive list of timeout builds for me to shove on to pandas?
<GrueMaster> That works too.  If you want to do that, the easiest thing to do would be to pull a copy of ubuntu-core for armel from http://cdimage.ubuntu.com
<GrueMaster> Use that as a base for your chroot.  After chrooting to it, run apt-get update and apt-get install tasksel to pull in major package seeds (desktop, etc).
<sniperjo_> ok, i was just following the manual trying to get it back on, i flashed my u boot off a well, how do i get that back on ? at the moment i am just cp -rfa /* /mnt/nand
<GrueMaster> I have no idea.  Never used that particular device.
<sniperjo_> thats what the ins ructions say but I'm getting "cp: recursion detected, omitting directory "  http://pastebin.com/2mQAEJDX
<janimo> infinity, I have an old list which may be not up to date but I can get you a new one
<infinity> janimo: That would be shiny.
<janimo> the old list in the meantime https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-build-timeout
<janimo> washngo and ants definitely are still there
<janimo> the haskell one is building ATM
<janimo> infinity, yep, all on that list are still valid timeouts
<janimo> just checked
<janimo> since the haskell-src-ext package was given back on gourd which is an old builder it too will fail in about 10 h
<janimo> GrueMaster, does the beagle work with the same power cord as the panda? I do not remember having separate cables for it, but I am being extra careful now in light of recent....events
<janimo> it sure fits in the jack :D
<GrueMaster> yes.  Both work off the same power, as does the mx5 (conveniently).
<infinity> janimo: Also, is there a bug for the mx5 kernel issue?
<janimo> infinity, yes, jcrigby is on it
<infinity> janimo: (I was looking for a bug number)
<jcrigby> https://bugs.launchpad.net/ubuntu/+source/linux-linaro-lt-mx5/+bug/856432
<ubot2> Ubuntu bug 856432 in linux-linaro-lt-mx5 "FFE: Enable CONFIG_LBDAF so mx5 image boots fine on EXT4 rootfs" [Undecided,New]
<infinity> janimo: Danke.
<janimo> jcrigby, infinity says thanks
<janimo> :)
<ogra_> janimo, all TI boards use the same plug and 5v (different amps for different models though)
<janimo> 5 v  == 5 v
 * janimo betrays his deep understanding of all things electronic
 * ogra_ remembers that with babbage they even changed within one production line
<infinity> jcrigby / janimo: You people need nicks with different first characters.
<ogra_> and its fun if you plug your 19v into a 12v board
<ogra_> infinity, at least with different colors
<janimo> ogra_, I had my share of such fun for this dev cycle
<ogra_> yeah, i saw
<ogra_> :(
<janimo> I saw _and_ smelled
<ogra_> last time we had such a disaster it was jamie bennett
<janimo> beginning with a j too
<ogra_> who did exactly what i wrote above
<ogra_> (19V inot a 12V board)
<ogra_> the bad thing was that the PSUs looked all the same you could only tell them apart by reading the fineprint on the sticker
<janimo> smart boards would use 12 of that for powering and 7 v for fancy effects on the leds
<infinity> Thankfully, my ac100 and S10-3 seem to not mind me accidentall confusing their 19V and 20V PSUs (which makes sense, I'm sure their tolerance is wider than that), cause I do that constantly.
<ogra_> heh
<prpplague> ogra_: hey, you got a url link to ubuntu console image for panda?
<ogra_> prpplague, natty  headless you mean ?
<prpplague> ogra_: yea
<infinity> Down with headless, up with server!
<ogra_> http://cdimage.ubuntu.com/releases/natty/release/
<ogra_> prpplague, ^^
<ogra_> infinity, ++
<prpplague> thanks
<ogra_> infinity, though for panda having minimal headless might make sense once we have real server HW and dont need to abuse pandas
<infinity> ogra_: Other than the pool, they're pretty much the same thing anyway.  So, it's just a bit of wasted disk space.  That doesn't hurt my feelings.
<prpplague> ogra_: just need something to do a quick test with
<ogra_> if we get extra headcount or so
<infinity> ogra_: But once we have "real server hardware", we could just blank the pool on the cell phone subarches, and a -server build on, say, omap4 or mx5 would end up being "headless".
<ogra_> yeah
<ogra_> well, what people asked for (which resulted in headless) was a tiny dev image you could download quickly
<infinity> I'm sort of dreaming of a day when we stop shipping for cell phone dev boards, but what are the odds that will ever happen?
<ogra_> so dropping the pool on the non server arches sounds like a good idea if we actually want to keep that image type at all for these boards
<infinity> ogra_: With any luck, a combination of ubuntu-core and a quick tutorial on applying hwpacks should satisfy the need for "tiny".
<infinity> ogra_: I'm hoping.
<ogra_> well, we have one netbook arch too :)
<prpplague> is there a posted schedule for 11.10 ?
 * ogra_ hasnt seen tegra cellphones yet 
<infinity> ogra_: My phone is a Tegra2.
<ogra_> prpplague, http://wiki.ubuntu.com/ReleaseSchedule
<ogra_> pick your release :)
<ogra_> infinity, oh, really ?
<infinity> ogra_: http://www.lg.com/us/mobile-phones/LG-P999.jsp
<ogra_> you got one of these hybrid motorolas ?
<ogra_> ah
<ogra_> that quite new
 * prpplague is totally frustrated with trying to keep up with android and ubuntu for panda
<GrueMaster> Motorola Atrix has been out for quite a while now with the Tegra 2.
<ogra_> i guess i'm behind :)
<ogra_> prpplague, drop android, nobody uses it anyway :P
<GrueMaster> Droid 3 has the omap4 processor.
<ogra_> GrueMaster, well, thats a pocket-desktop ... not a phone
<sniperjo_> now I'm getting a kernel panic "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"
<GrueMaster> It's a smart phone with a clamshell docing station.
<GrueMaster> *docking
<ogra_> well, you said the same just differently phrased :)
<GrueMaster> sniperjo_: Is this with your stock image?
 * prpplague wonders why this schedule info is not posted on pandaboard.org and omapedia.org
<sniperjo_> GrueMaster: yes, http://pastebin.com/LsQe2D85 if you have a look near the end it i asking me to correct the boot option
<sniperjo_> GrueMaster: and I'm confused!
<ogra_> prpplague, yeah, at least until 2014 ...
<ogra_> then we need new schedules :)
<prpplague> ogra_: yea, well as you are aware, i normally do board bringup and validation, lately i've been getting hammered on the lists and channels about ubuntu and android support
<ogra_> well, point them here or to the ubuntu-devel ML
<ogra_> if you cant handle the load
<GrueMaster> sniperjo_: I am not sure how much I can help as I don't have that hw or image.  If you followed all the steps to get it back to stock, it should work.
<sniperjo_> GrueMaster: ill give it all another go, you think this is the best way to get ubuntu running on it ? instead of changing the beagle settings
<prpplague> ogra_: not only can i not handle the load, it isn't my area of expertise
<GrueMaster> I honestly don't know.  I haven't had much of a chance to work on ubuntu on non-supported systems.  It should work though.
<GrueMaster> prpplague: By all means, pass all ubuntu related questions to us.  I regularly monitor the pandaboard mailing list, and respond where I can.
<prpplague> GrueMaster: is there anyone that can update the omapedia.org wiki pages for ubuntu related stuff?
<ogra_> prpplague, someone from omappedia i guess :)
<prpplague> ogra_: hehe which means no one
<GrueMaster> I suppose I can help (as time allows), but I don't know if I have write access.
<prpplague> GrueMaster: public wiki
<prpplague> http://omapedia.org/wiki/OMAP_Ubuntu_Main
<GrueMaster> Ok.  Will add to my never-ending todo list.
<prpplague> GrueMaster: main issues are people are confused about which versions are supported, which ones have PPA's , which ones have wifi support, and what the future releases are going to have
<prpplague> GrueMaster: i'd be willing to spring for a pandaboard to someone who would keep the ubuntu stuff uptodate on omapedia.org
<ogra_> usually all the same versions as all other arches modulo LTS are supported
<ogra_> thats why we are ubuntu-arm and not linaro ;)
<GrueMaster> Right, ok.  I can help clarify that.  Part of the problem we have is making releases work with new board changes, but we have been proactively trying to stay on top of that.
<prpplague> GrueMaster: yea it is more of a communication issue
<GrueMaster> So having new boards that change stuff would be nice.
<GrueMaster> I just got an A3 last Friday for example.  No issues with Oneiric, but haven't tested the other releases yet.
<prpplague> GrueMaster: yea, all of the A1 to A3 should be pretty much the same, the A4's will have a few tweaks
<prpplague> GrueMaster: ahh
<ogra_> a4 has the next gen SoC ?
<ogra_> 4460 or so ?
<GrueMaster> A4 tweaks?  We need to know how that affects us asap for Oneiric release support.
<prpplague> ogra_: ES2.3 of the 4430
<ogra_> ah
<ogra_> GrueMaster, didnt we just discuss that in the meeting ?
<ogra_> in the linaro topic
<prpplague> only major item is the pullup resistors on the edid signals
<GrueMaster> not sure if prpplague was in the meeting.
<ogra_> no
<janimo> can the beagle board with the extension board (RS232, eth) output uboot/kernel boot messages on said serial console
<janimo> ?
<ogra_> GrueMaster, he surely wasnt ... only people paid to get up that early come
<ogra_> :)
<GrueMaster> janimo: You mean the zippy board?
<prpplague> janimo: the standard uart on the beagleboard cna be used for kernel output
<ogra_> prpplague, and on the zippy ?
<janimo> prpplague, standard uart needs some type of connector I don't have. I have null modem cable only
<janimo> GrueMaster, BeagleBuddy Zippy rev-A
<prpplague> janimo: the zippy can not be used as the console without modifying the code, you need to get the correct cable
<GrueMaster> I have one, but haven't tested it yet.  Need to add a header to my beagle for it to mount.
<janimo> prpplague, so there's no kernel cmdline option to switch to that?
<ogra_> hahaha
<prpplague> janimo: no
<janimo> this is how I got my beagle
<janimo> that is sad. How is that port used then?
<prpplague> janimo: http://tincantools.com/product.php?productid=16144&cat=0&page=1&featured
<janimo> I hope the hdmi output works at least
<janimo> prpplague, I am not buying more cables :)
<GrueMaster> hdmi?  on a zippy?
<janimo> I have enough cruft already that confuses me :)
<janimo> GrueMaster, on the beagle
<janimo> DVI on a HDMI slot
<GrueMaster> On the beagle it works fine.
<GrueMaster> I can bring you a serial cable for your beagle to UDS.
<prpplague> janimo: well without the cable you have very little chance of actually getting things working proplery
<ogra_> at least if you dont have a zippy connected :)
<janimo> ok, thanks. bye bye people, I am plugging this monitor into the beagle to test daily :)
 * janimo hopes desktop image starts up on the monitoe fine
<GrueMaster> janimo: daily desktop will fail misserably due to no swap file.
<GrueMaster> Lots of oom errors (showing up as pager errors).
<ogra_> yeah, we had that before
 * ogra_ remembers fiddling with compcache like crazy to get plars some working images back in the days
<ogra_> that was before we dicided for a swap file
<janimo> GrueMaster, hmm thanks. I'll try something else the now
<GrueMaster> I'll fire mine up shortly.  I can swap it in place of the mx5 for now.
<prpplague> FYI: for anyone interested, i am willing to provide a free pandaboard to anyone who will spend some time updating the omapedia.org wiki pages for ubuntu support
<XorA> prpplague: sweet :-)
<GrueMaster> I think for ease of documenting, it would be better to have omappedia point to wiki.ubuntu.com as we have to keep our own set of documentation and I try to keep it uptodate with current release info.
<janimo> +1
<GrueMaster> Otherwise there are two sets of docs that can get out of sync really fast.
<XorA> what good is a wiki if it isnt 90% falsehood and lies :-)
<XorA> but that does basically mean a free pandaboard for some deletes and a link :-)
<GrueMaster> We have wiki.ubuntu.com for that.  :P
<plars> ogra_: hmm, yeah I vaguely remember that
<prpplague> GrueMaster: is the documentation there panda specific?
<GrueMaster> https://wiki.ubuntu.com/ARM/OMAP
<GrueMaster> Covers both beagle & panda
<GrueMaster> And a few others
<prpplague> GrueMaster: hmm, i'll have to check with jay
<prpplague> GrueMaster: i am almost tempted to change the link to your wiki pages for now
<GrueMaster> Give in to temptation.
<GrueMaster> janimo: Booting preinst-server on my beagle.  No problems so far (other than lack of network).
<GrueMaster> Could be that it doesn't care for my zippy or I missed a few pins while soldering.  Or the kernel just doesn't know about it (u-boot detected it).
<prpplague> GrueMaster: most likely it doesn't know about it
<GrueMaster> Not sure.  Have to seen my soldering skills?  :P
<infinity> I've never seen you solder, but I've seen you, in general.  I'm not sure you'd be my first choice to perform delicate work.
<infinity> Just sayin'. :P
<prpplague> hehe
<GrueMaster> Just because I had a role in Disney's Fantasia in a previous life...
<infinity> GrueMaster: As the wave chasing Mickey?
<GrueMaster> More the hippo in the pink tutu.
<infinity> Oh god, the mental image.
<infinity> Get it out.
<infinity> Is noon too early to start drinking heavily?
<GrueMaster> Why wait til noon?
<infinity> Cause that's what time it is. :P
<infinity> If could go back in time and be drunk before you made that comment, I would.
<prpplague> GrueMaster: hmm there isn;t a link for the 10.10 download
<prpplague> GrueMaster: found it, but it isn't on the page
<GrueMaster> grmbl.  Must have been deleted.
 * GrueMaster fixes.
<GrueMaster> There.  Fixed that link.
<sniperjo_> I've copied my sd / to a mount with mount -t jffs2 /dev/mtdblock4, so i can boot off NAND, so i should be trying to do something like setenv bootargs root=/dev/mtdblock4 in u-boot right ?
<GrueMaster> sniperjo_: I really do not know how that system comes preconfigured or how to revert to stock.  I did find documentation at http://www.technexion.com/index.php/support-center/downloads/ti-cpu-modules/tao-3530/549-tao-3530-userguide-0953
<prpplague> GrueMaster: i am just going to go ahead and change the omapedia pages to point ubuntu
<GrueMaster> Without hardware, our support is limited to ubuntu pool issues.
<GrueMaster> prpplague: Ok.  I still need to copy the Maverick Known Issues over to our wiki.  Will work on that now.
<sniperjo_> GrueMaster: yeah, Im following that documentation now, from what it looks like, couldn't this just be u-boot not having the proper root ? seeing as it boots the kernal
<GrueMaster> It appears to be a cmdline issue or maybe rootfs on the wrong nand partition.  Not sure.
<sniperjo_> GrueMaster: I've followed the instructions, putting it in the correct NAND actâ¦ or at least i am pretty sure i have
<Dr_Who> are there some folks about that would be willing to sponsor / comment on http://revu.ubuntuwire.com/p/libjpeg-turbo  ? would like to get this into universe for oneiric
<prpplague> GrueMaster: lucid isn't listed on that page, are we not doing direct support for that?
<GrueMaster> prpplague: Lucid was a tech preview for beagle only.  Not supported.
<GrueMaster> First officially supported image for omap was Maverick.
<prpplague> GrueMaster: ahh ok
<prpplague> GrueMaster: nitpick time, since the headless download is on the same page as the netbook, shouldn't the url point to the same location on both?
<prpplague> GrueMaster: http://cdimage.ubuntu.com/releases/11.04/release/
<GrueMaster> I can't move the images around on cdimage, but I can add the link to the wiki.
<infinity> GrueMaster: He means that the headless link on ARM/OMAP doesn't have the /release/ bit at the end.
<infinity> Thankfully, it's a wiki. :P
<infinity> prpplague: Fixed.
<sniperjo_> GrueMaster: ok, so I'm going to drop the put the old back into NAND and chroot, when i try to use the beagle image i get an error , Unsupported machine 0x0000060a, supported machines : 00000b14, would i be able to change those two values somewhere and give the beagle sdcard a go ?
<infinity> prpplague: You should be able to fix such minor things yourself too (and, please do!)
<prpplague> infinity: i @#$^% up enough stuff.......
<infinity> Heh.
<prpplague> 11.04 and 10.10 need to do anything for wifi support, i.e. install a ppa?
<infinity> Sadly, none of us are (even remotely) technical writers, so this stuff only gets written through sheer force of will.  More community involvement in that is always nice.
<GrueMaster> sniperjo_: Where is this error?  u-boot or kernel?
<prpplague> infinity: indeed, same issue here
<sniperjo_> GrueMaster: it appears after "Starting Kernelâ¦."
<GrueMaster> prpplague: Not sure on 10.10.  May be ppa.  11.04 just works (on desktop images).
<prpplague> infinity: i have begged TI to hire wmat on to do some of this stuff
<GrueMaster> sniperjo_: So our kernel doesn't support your system.  Use your kernel and our rootfs.
<infinity> prpplague: I would kill to have a tech writer at my beck and call.
<prpplague> infinity: wmat is awesome
<infinity> prpplague: People don't seem to grasp the concept that programmers may know how to explain things to other technical people, but we often lack the skills (and almost always lack the motivation) to explain it to others.
<sniperjo_> GrueMaster: ok how ? can you send me in the right direction ?
<prpplague> infinity: indeed
<GrueMaster> I thought I had earlier.  Use the ubuntu-core-armel image as your rootfs.
<GrueMaster> I'm not sure if we have instructions for working on non-supported systems.
<GrueMaster> And it really is a bit beyond my area of expertise.
<sniperjo_> GrueMaster: you were telling me earlier how to download it and chroot in after, but i can't do that now
<GrueMaster> sniperjo_: Follow the instructions for your system on buuting from SD, except use our ubuntu-core-armel tarball for your rootfs.
<GrueMaster> *booting
<prpplague> http://omapedia.org/wiki/Ubuntu_Pre-built_Binaries_Guide
<sniperjo_> GrueMaster: can i just copy across the files in the boot from my stock to the beagle boot sd ?
<GrueMaster> Not easily, as our image does a lot of first boot stuff that is in the initramfs.
<GrueMaster> And it is really a process for me to try to walk you through mucking that whole mess together.
<GrueMaster> Best to start with ubuntu-core and build from there.
<sniperjo_> ok will do
<infinity> prpplague: http://omapedia.org/wiki/Prebuilt_ubuntu_binaries might want to point to dailies for both desktop (the link you have there) and server ( http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/ )
<prpplague> infinity: will do
<GrueMaster> prpplague: I'm going to have to bow out of more wiki editing this week as I have no glasses (broke last week).  I'll have replacements next week and can happily wiki away then.
<infinity> prpplague: You could probably also replace the very complex minicom setup page with "install screen and type 'screen /dev/ttyUSB0 115200'"
<infinity> prpplague: screen's terminal emulation seems to agree slightly more with debian-installer than minicom (and it's a ton easier)
<prpplague> GrueMaster: np
<prpplague> infinity: is that already documented on the ubuntu wiki?
<infinity> prpplague: Dunno.
<infinity> GrueMaster: ^?
<infinity> Yeah, it is.
<infinity> https://wiki.ubuntu.com/ARM/OMAPHeadlessInstall#Booting_the_image
<infinity> Man, I'd give good money for the omap4 kernel to be about 99% less spammy in dmesg.
<prpplague> hehe
<prpplague> infinity: funny, i usually change the default message level to be as noisy as possible, hehe
<infinity> GrueMaster: Oh, datapoint for you, jasper (and the images in general) still work great on my 32G card.
<infinity> GrueMaster: So, people having issues with "large cards" earlier were having issues with specific ones, not largeness in general.
<GrueMaster> k
<infinity> (Just re-installed server on my 32G Lexar)
<GrueMaster> Being a large guy, I didn't think the issue was general.
<infinity> ;)
<infinity> Okay, so the last time ogra tested this whole "make a swapfile from jasper" thing, he must have been using some seriously bad media.
<infinity> He said it took 10-20 minutes?
<infinity> 536870912 bytes (537 MB) copied, 28.4706 s, 18.9 MB/s
<infinity> 30 seconds seems reasonable to me.
<infinity> Maybe this is due to the ext4 bump.
<infinity> I'm reminded of the bizarre benchmarks that showed ext4 being nearly 4x faster than ext3 for many/most write patterns on SD/MMC.
<GrueMaster> But do we really want to add it to jasper?
<infinity> I dunno.  Creating swap is something installers should do, not something we should ship in the image.
<GrueMaster> I thought the idea was to kill it with a titanium spork
<infinity> The only reason we shipped it in the image was because it was apparently "too slow" to do it real-time.
<GrueMaster> True, but we have no installer.
<infinity> When we kill jasper (or, rather, move it to d-i proper), d-i itself can and does make swap.
<infinity> For now, our "installer" is jasper.
<infinity> That is, installer-type hacks have to go there.
<infinity> When you do netinstalls, you get swap.
<GrueMaster> Right, but we also found that a swap partition on SD is worse than a swap file.
<infinity> Or, you get offered, anyway.
<infinity> d-i can do files too.
<GrueMaster> It can?  Cool.
<infinity> Yeah.  it's just not the default option.
<infinity> We could certainly hack those bits to suggest a file if you're on MMC.
<infinity> Though I'm really curious about those benchmarks, and how they came to be.
<infinity> On a journalling FS, swapping to files should, generally, be slower than partitions.
<GrueMaster> I don't think performance was the issue.  Not sure.
<infinity> Anyhow.  I view pretty much all of this as evil PoC hacks anyway.
<infinity> Running a full-featured distro on SD/MMC is just silly.
<janimo> GrueMaster, is the beagle supposed to support the zippy ethernet in natty?
<janimo> all my hw is broken for one reason or another :(
<infinity> janimo: Set it on fire, that seemed to help your Panda.
<GrueMaster> janimo: Not sure, never tested.  I just got a zippy when NCommander cleaned out his car.
<janimo> while I am sure it will help the beagle - but not my situation
<janimo> did I mention I hate hardware?
<infinity> It's come up.
<janimo> I am really wondering if I am in the right team
<infinity> To be fair, it seems mutual.
<janimo> my microsoft keybaord loves me and that too is mutual
<infinity> janimo: Apply for the next desktop opening? :)
<GrueMaster> It isn't part of the default hardware, so I am less inclined to care.
<janimo> but all this crazy SoCs, brrr
<janimo> I woulnd't care either - I even proposed taking my beagle to one of the conferences this year to give it to someone who can use it.
<janimo> and now when I need it, the first time since I have it, it does not have ethernet
<janimo> oh well
<GrueMaster> Not saying it isn't a useful product, I just don't have the resources to test all addon hardware as well as the base systems.
<GrueMaster> I use usb ethernet to test with on it.
<janimo> I am not expecting are asking you to test it, just that you are the default go-to source with ubuntu on arm suppott questions
<janimo> having the largest number of ARM SoCs per ft^2 in your house or something
<davidm> Cakk
<davidm> Call in 6 or so
<infinity> davidm: -ECHAN
<davidm> yep my bad
<janimo> infinity, desktop team does to much packaging and fighting with autoconf. That I hate more than broken hw
<infinity> janimo: Perhapsa lovely new career in botany?
<janimo> actually gardening was on my mind after writing that last sentence
<janimo> too bad I don't really like flowers
<janimo> I need to listen to some good music to cheer me up. I know a good source of elevator music
 * janimo exits stage right
<sniperjo_> GrueMaster:  so when i have downloaded the headless image and dd'd it to the sdcard, what am i supposed to do after ? copy my /boot from the sd card that boots?
<sauerbraten> I run Ubuntu 10.10 on pandaboard. freshly installed, added ppa:tiomap-dev then apt-get update and apt-get dist-upgrade
<sauerbraten> however, I can't install the ubuntu-omap4-extras package, because ubuntu-omap4-extras-multimedia and ...-extras-connectivity "are not going to be installed"
<sauerbraten> why that? what's wrong with the system?
<prpplague> GrueMaster: here is one of those items ----> sauerbraten
<sauerbraten> see prpplague ? :P
<GrueMaster> sauerbraten: I'll take a look in a bit (maybe tomorrow).  I am still wrapped up with oneiric Beta 2 release testing.
<sauerbraten> take a look in where?
<GrueMaster> Can you try Natty (11.04) instead?  I recommend it over Maverick.
<sauerbraten> GrueMaster, the TI video drivers don't work there
<sauerbraten> no 720p/1080p :(
<GrueMaster> sauerbraten: I will try to reproduce the issue here and see why it fails.
<prpplague> GrueMaster: is that the cause that the TI sgx doesn't work for 11.04?
<GrueMaster> It worked before.  Not sure what chaned, unless someone at TI deleted files in the ppa.
<GrueMaster> on maverick.
<sauerbraten> the strange thing is, just yesterday I was said to use maverick and it should be fine. The guy used 10.10 at a demo just couple of days ago :/
<GrueMaster> On natty, I'm not sure.  I have been wrapped up in server stack pipe cleaning since May.
 * GrueMaster desparately needs to find lunch and resume beta testing.  Will look at tomorrow.
<sauerbraten> well, I tracked the error of extras-multimedia down to libmp4v2-0 I believe. Though there is no such package in my repos
<sauerbraten> alright GrueMaster take your time ;)
<sniperjo_> GrueMaster: by the way, the headless image was the same, diddnt like it because it wasn't a beagle
<prpplague> sauerbraten: ppa's and updates are pushed all the time, so breakage happens
<sauerbraten> btw, is it important to use the panda A2 specific MLO and u-boot.bin? I don't use them atm
<sauerbraten> what exactly do they change? RAM usage?
<prpplague> sauerbraten: are you seeing some instructions that tell you about an a2 panda mlo and u-boot?
<sauerbraten> yes, https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<prpplague> sauerbraten: that is strickly to update some items for the board id and cpu id
<prpplague> sauerbraten: no major changes per se
<sauerbraten> prpplague, ok so I'll stick with this version
<prpplague> sauerbraten: do you have an a1 board?
<sauerbraten> no, A2
<prpplague> sauerbraten: right, so make sure you use the a2 mlo and u-boot
<sauerbraten> so, is it important now or not?
<sauerbraten> np major changes per se --> not so important
<sauerbraten> *no
<prpplague> sauerbraten: yes you need to use the correct mlo and u-boot for the board revision
<prpplague> hence the instructions
<sauerbraten> aaaalright
<sauerbraten> let me copy the files
<sniperjo_> ok so I've added my uImage to the roots files of the 11.4 headless image, when i boot i get "uncompressing linux â¦â¦, booting, done " but nothing seems to happen! any ideas, hade i forgotten something ?
<GrueMaster> sniperjo_: I can't help you.  Our preintalled netbook and headless images are not designed for modification on other non-supported platforms.  Please, follow the instructions for creating a bootable SD for your system, and maybe use ubuntu-core for the root filesystem.  Headless, server, netbook, and desktop are for the platforms we support and are too difficult to modify over irc.
<sniperjo_> GrueMaster: ok i thought the headless might be bare enough, is the Oneiric Ocelot the only release available for core?
<GrueMaster> Yes.  it is new this release, with systems like yours in mind.
<prpplague> GrueMaster: would we have to perform upgrades on some of the packages for the current omap extras to install properly?
<GrueMaster> prpplague: I don't know.  I'll look at it when I get a chance.  They should just install.
<prpplague> GrueMaster: ok thanks
<prpplague> GrueMaster: no worries, just doing some testing myself
<brandini> woot!
<brandini> so I picked up a san disk ultra 8GB on the way home from work and I'm SCREAMING along now!
<brandini> bad disk all long
<brandini> *along
<brandini> IT WORKED!!!!!!!!!
<GrueMaster> Sweet!
<brandini> this thing is FLYING!
<prpplague> brandini: which ubuntu release are you using?
<brandini> yesterday's daily
<brandini> 9/21
<GrueMaster> yep.  That is slated to be officially Beta 2.
<prpplague> brandini: ahh
<brandini> it's solid so far :)
<brandini> how can I see the temps and voltages on this board?
#ubuntu-arm 2011-09-23
<greghaynes> When I dd the natty headless omap4 image to an sd card and boot on panda board I get this: http://pastebin.pandaboard.org/index.php/view/7402008 Im running out of ideas on what could be causing this...anyone know?
<chihchun> cooloney: hi
<twb> Graah
<twb> Looks like my TF101 was somehow on last week, and ran itself out of battery completely -- to the point where I couldn't even turn it on with the power plugged in via the dock, I had to plug the power directly into the tablet part
<cooloney> chihchun: hi
<chihchun> is omap3 porting also included in ti-oamp4 branch of natty kernel tree (2.6.38) ?
<twb> lilstevie: I'm looking at u-boot/include/configs/tegra2_common.h:CONFIG_NETBOOT_SETTINGS, and I can't see where it loads the ramdisk.
<twb> From the CrOS kernel config you're using, it looks like you make everything =y, so I guess you don't HAVE a ramdisk, but I'd kinda like one, if only so I can use it for rescue when root won't mount
<twb> (yay busybox)
<twb> Oh, I just realized the FAT version is loading a *u-boot script*, not a kernel directly from FAT
<twb> Ah, OK, so fatload/ext2load copy a file into RAM at a specified address, and then source/bootm actually DO something with it.
<twb> lilstevie: stupid question, but when you said that u-boot interactivity wasn't working -- did you try just removing the u-boot line that tells it to set console=ttyS0 ?
<twb> nm, that would be the kernel, not u-boot.  I can see further down that stdin=serial,tegra-kbc and so on
<twb> 15:05 <twb> I manually run "kbdrate -d 250 -r 30" and it is still set to 0
<twb> lilstevie: can you show me an MBR-based nvflash flash.cfg?
<lilstevie> when I wake up
<twb> Sure thing
<lilstevie> I am out of it :/
<twb> Are you about to get up, or go to bed? ;-P
<lilstevie> I have been napping
<twb> afk for half an hour, beer
<lilstevie> kk
<Neko> is Unity3D all OpenGLES ready right now for Oneiric?
<twb> back
<twb> lilstevie: ^
<twb> lilstevie: I was hoping you'd have made me a pastebin :P
<rOxx> hello, iÂ´m using beagleboard xm with an rtc battery and now i want to change the time epoch from 1970 to 2010, but with "sudo hwclock --setepoch --epoch=2010" i get the message "The kernel keeps an epoch value for the hardweare clock only on alpha machine. This copy of hwclock was build for a maschine other than alpha. No action taken."  someone can help me to change the epoch ?
<twb> Why do you want to set the epoch?
<twb> Everything else on unix uses an epoch of 1970
<twb> If you just want to set the hw clock, you want hwclock -w
<greghaynes> s/unix/known universe
<rOxx> im using socketcan and the timestamps are calculated from the time epoch in seconds
<rOxx> and now i want to change the time epoch, because the timestamps are to huge
<greghaynes> too huge for what?
<greghaynes> They should be <32bit
<twb> signed, 32-bit time_t goes until 2038, right?
<greghaynes> Somewhere around then
<twb> I guess socketcan isn't using time_t then
<twb> (https://secure.wikimedia.org/wikipedia/en/wiki/SocketCAN)
<Neko> it uses timestamp
<Neko> dsjfbdfkb
<Neko> timeval :D
<rOxx> yes but the timestamp i get from the sockets have the format struct timeval with time_t      tv_sec and suseconds_t tv_usec
<rOxx> and time_t is count from epoch ?
<Neko> sure
<Neko> are you sure the time on your board is set right?
<Neko> because when the rtc dies on some of my arm boxes, the time is 1969 and time_t values have wrapped around...
<Neko> -1 time_t is just the same as 2 billion and it causes trouble..
<rOxx> yes the time i set correct, i^m using init.d script to load the time from rtc with "hwclock -s"
<twb> lilstevie: ping, did you fall asleep again :-(
<twb> Should I be worried that file says uImage is a "u-boot legacy image", when I'm AFAIK using this new FIT/dtc stuff?
<Neko> twb, yes..
<Neko> it should print a bitchload of info too
<twb> what, file?
<twb> rootfs/boot/vmlinux.uimg: u-boot legacy uImage, Linux-2.6.38.3+, Linux/ARM, OS Kernel Image (Not compressed), 3135112 bytes, Fri Sep 23 19:17:03 2011, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0x246D6351, Data CRC: 0x94ACEAFB
<Neko> no, u-boot.. it should say something like "detected fit image" and then stuff going from there (lots and lots of lines)
<twb> I haven't put u-boot in place yet
<twb> And when I do, it won't have a working keyboard or screen, so I won't see that
<lilstevie> they are legacy images
<Neko> oh okay.. I wouldn't expect "file" to know the difference right now
<lilstevie> it has screen
<lilstevie> it prints out the same info that mkimage does if you tell it to read the information
<twb> lilstevie: so I'm doing the right thing?
<lilstevie> yes
<Neko> therefore you're not using the fit/dtc stuff :)
<lilstevie> yep :)
<lilstevie> u-boot needs fit/dtc stuff to compile
<twb> Neko: I sure needed to install dtc to get u-boot to build...
<lilstevie> kernel isn't using it though
<twb> Oh, OK
<Neko> twb, yeah, u-boot always wants it to build, but it doesn't necessarily NEED it.
<twb> lilstevie: is it u-boot.img or u-boot, that I write to the EBT partition?
<lilstevie> u-boot.bin
<lilstevie> I will pastie my config soon
<lilstevie> it took me a bit to get the right location for MBR
<lilstevie> so probably easier for me just to give that to you p
<lilstevie> :p
<twb> I hope so
<twb> btw is the "no support for micro SD" because it's actually not supported, or just because the script doesn't try to use mmc device 2, but only usb, mmc1, mmc0
<lilstevie> because there is no support for it
<twb> OK, just checking :-)
<twb> If I make an ext4 filesystem, can u-boot's ext2load read files from it, or will it freak out because of extents or something?
<twb> BTW, should I be worried that u-boot.bin is like one-sixth the size of the original asus/android bootloader?
<lilstevie> no
<ndec> ogra_: hi. does banshee work for you?
<lilstevie> because it is a different bootloader
<ndec> the window opens, but it's all white for me
<twb> And a substantially less bloated one :-P
<lilstevie> also I have an ext2 fs for my u-boot partition
<lilstevie> with a boot.scr kernel and initrd
<twb> lilstevie: hm, can you also give me your CONFIG_EXTRA_ENV_SETTINGS for u-boot?  I wasn't sure what to put for e.g. the ramdisk's load address
<twb> That is pastebin tegra2-common.h or so
<ogra_> ndec, havent tried yet, file a bug :)
<lilstevie> I read it to a location in my boot.scr
<lilstevie> :p
 * twb waits impatiently for MBR flash.cfg and uboot scripts
 * twb pokes lilstevie
<ndec> ogra_: LP#857299
<ogra_> bug 857299
<ubot2> Launchpad bug 857299 in banshee "banshee window remain white on startup on pandaboard" [Undecided,New] https://launchpad.net/bugs/857299
<ogra_> NCommander will love this :)
<ndec> ogra_: i always forget how to trigger ubot2 ;-)
<ogra_> :)
<ndec> ogra_: on my panda, the link vmlinuz and initrd.gz in /boot are wrong. is that normal?
<ndec> they exist but point to non existing kernel
<ogra_> upgrade ?
<ogra_> or fresh install ?
<ndec> upgrade
<lilstevie> twb: http://pastebin.com/3SVrZ1PZ
<twb> Yay
<ndec> ogra_: vmlinuz is in / now?
<lilstevie> env is because I have env_is_mmc
<lilstevie> and offset to that specific location
<ogra_> ndec, not really, no
<lilstevie> UIM is my u-boot ext2 part
<lilstevie> as for where I load my initrd that is ${loadaddr}+kernel_size+500kb to be safe
<twb> Hm, OK.
<twb> After the pivot_root, does the ramdisk space get GC'd?
<twb> Because if so you could just always load it at 8MB or 16MB or something, to allow for huge kernels
<lilstevie> no idea
<lilstevie> thats why I do it close :p
<twb> You set MBR type=data -- does that mean I have to write the MBR myself?
<lilstevie> no
<twb> Or does nvflash still do it based on the name or something
<lilstevie> that is just nvflash being odd
<twb> k
<twb> You set allocation_attribute=8 instead of 0x808 -- does that mean "fill to end of disk, with no exceptions" ?
<twb> lilstevie: also, why doesn't MPT have file_system_attribute=0 ?
<lilstevie> don't ask me, ask nvidia :p
<lilstevie> this is based off the ventana flash.cfg in the LDK
<twb> I bet its because the nvidia engineer forgot
<lilstevie> none of it is documented
<twb> And they stripped the executable, so no debugging
<lilstevie> if you are a hw partner you can get the BSP stuff, which includes the source code for nvflash
<lilstevie> but even then, there is a lot that are PCHs
<twb> only under NDA though, I expect, which defeats the purpose of getting it
<lilstevie> so I hear anyway
<lilstevie> yeah
<twb> Well, here we go.
<twb> Am I right in thinking that nvflash -bl needs to be given the original bootloader, not u-boot?
<lilstevie> for flashing, yes
<lilstevie> u-boot does not implement the flashing program
<twb> Hmm, it didn't like me
<twb> Maybe it doesn't like four-letter partition names
<lilstevie> no
<lilstevie> 3 only
<lilstevie> less ok more not
<twb> If you pass TERM=dumb, it disables that progress shit
<twb> I think
<twb> Never mind, it's still doing its mkfs-type step before copying to actual fs across
<twb> But passing TERM=dumb did make it generate a lot less output during the upload step I think.
<twb> Hm, no, it must be *just* screen that doesn't like its output.  Probably a funny termcap thing.
<twb> Nearly done...
<twb> lilstevie: OK, once I reboot, when I hit the power button do I still get the Nvidia Tegra splash screen?
<lilstevie> no
<twb> Hm, screen isn't turning on at all
<lilstevie> that is in the asus bootloader
<twb> I probably fucked up the u-boot configuration somehow... I built it this way:
<twb> make ventana_config DEV_SRC_TREE=tegra-tf101; PATH=/usr/src/dtc:$PATH make -j
<twb> (I figured before fucking with its config I should make sure it was gonna work at all)
<twb> I can't get it to turn on at all
<lilstevie> I build with make ARCH=arm ventana CROSS_COMPILE=arm-linux-gnueabi- DEV_TREE_SRC="tegra2-tf101"
<twb> Now, I did get an error *after* repartitioning and uploading all the images, from "./nvflash -r --sync --go"
<lilstevie> what error
<twb> I was compiling from a native chroot
<lilstevie> ok so drop CROSS_COMPILE
<twb> I just realized I did tegra-tf101 and you did tegra2-tf101
<twb> Error was: [resume mode] \n failed executing command 25 NvError 0x8 \n command failure: sync failed
<lilstevie> hm
<twb> And then I saw the nvidia splash screen, which I think means the --go worked
<twb> Then I just powered it off by holding to power button, since it was (understandably) not finding anything via the asus bootloader
<twb> I'm not panicing yet, but this is sure acting like a brick
<twb> The other thing I probably did different from you, was I was running dtc from git
<twb> v1.3.0-6-g83df28b
<lilstevie> yeah well you know you can go back into apx :p
<twb> Well, that's a nice theory except it's not showing up in lsusb
<lilstevie> press volup then hold power
<lilstevie> monitor your lsusb it will show up very soon
<lilstevie> unless your batt is flat
<twb> I suppose that's possible
<twb> The dock's battery is green
<twb> OK, APX is back
<twb> So now to work out what went wrong
<twb> I think the problem is that I forgot the 2 in tegra2-tf101, so I built the wrong dtc
<twb> Er, dts
<twb> I'm surprised it didn't give an error at compile-time, though...
<lilstevie> well personally I am going after serial
<twb> haha, there is a dropbear.id.au
<twb> (*.id.au names are supposed to be .au fauna)
<lilstevie> lol
<twb> The downside is that recompiling u-boot is gonna take a while, because until the tf boots again I'm doing it via qemu
<twb> (Cross-compiling is too hard.)
<lilstevie> just use the linaro compiler
<lilstevie> cross compiling is easy
<twb> Then I have to compile that, since its binaries aren't signed by Debian
<twb> That or trust linaro, I mean.  Plus I have no idea what additional stuff is in linaro that isn't in Debian, and part of the goal here is to be as close to stock Debian as possible -- including bootstrapping everything
<twb> lilstevie: how do I tell nvflash not to rewrite all the other partitions, since I'm only going to be uploading a new u-boot?
<twb> lilstevie: do I just omit the --create option?
<twb> ./nvflash --bct BCT.img --setbct --configfile flash.cfg --bl bl.img --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --download 4 u-boot.bin
<lilstevie> you cant
<lilstevie> not for bootloader
<twb> Well that's lame
<lilstevie> it is nvflash being a pain
<twb> In that case I guess you run a normal --create command, but on a flash.cfg that has all the file= lines removed?
<twb> And all the type=ext[23] changed to type=data, to prevent it overwriting the existing filesystem with an empty one
<lilstevie> nope
<twb> I'm not gonna like the right answer, am i?
<lilstevie> because it does format_all
<lilstevie> well more to the point
<lilstevie> it deletes all partitions
<lilstevie> then creates and formats
<twb> always?
<lilstevie> yes
<twb> You'd think with NAND flash they'd want to avoid a big bag of pointless writes
<twb> So just to be absolutely clear: there's *no* way to upload a new u-boot, without also having to upload the entire root filesystem again?
<brandini> hello all
<siji> hello
 * twb uploads a new, hopefully correct, u-boot
<twb> OK, I uploaded a new u-boot, but skipped uploading the OS.img root filesystem, on the basis that I should at least be able to see u-boot on the screen even if u-boot can't find a kernel
<twb> But it's still not turning the screen on...
<brandini> :)
<twb> I can't see what I did wrong
<lilstevie> you know you can upload it as -bl to test
<lilstevie> rather than writing every time
<twb> No I didn't :-/
<lilstevie> did you add ARCH=arm in the make command
<twb> No, because I wasn't cross-compiling
<twb> http://paste.debian.net/131770/
<twb> That's the end of the compile run
<lilstevie> file u-boot.bin
<twb> http://paste.debian.net/131771/ managed to get the whole thing
<twb> lilstevie: /usr/src/u-boot/u-boot.bin: ERROR: vasprintf failed (Invalid or incomplete multibyte or wide character)
<lilstevie> file u-boot
<twb> ELF 32-bit LSB shared object, ARM, version 1 (SYSV), statically linked, not stripped
<lilstevie> hm
<lilstevie> gcc vers?
<twb> gcc (Debian 4.6.1-11) 4.6.1
<lilstevie> hm
<twb> If I ask Debian about it they will probably tell me to do the whole thing again from the ground up, on armel
<lilstevie> some of the newer toolchains are broken for tegra
<lilstevie> some hardware errata bs AFAIK
 * twb carefully refrains from chucking tf101 through a window
<twb> lilstevie: do you know which chains, or how I can test if a chain is broken?
<twb> After all if debian's gcc is broken, then the userland is gonna be screwed even if I build the bootloader and kernel with something else
<lilstevie> nah kernel works around this stuff
<twb> So I should try building u-boot using an older gcc?
<twb> 4.4 and 4.5 should be apt-gettable
<lilstevie> well I use 4.4
<twb> okey dokey
<dmart> twb: this is a long shot, but have you tried exporting LC_ALL=C in the environment and rebuilding?
<twb> Hm, LANG probably doesn't make it through chroot(8), lemme look
<dmart> "multibyte character" sounds like locale-related encoding problems
<twb> dmart: oh, you mean for file(1)
<twb> dmart: nice one: /mnt/bar/rootfs/usr/src/u-boot/u-boot.bin:  Spectrum .TAP data "\024\237\024\237\024"
<lilstevie> fuck this board
<lilstevie> er
<lilstevie> wrong chan
<twb> haha
<lilstevie> and excuse my language
<twb> We were all thinking it
<dmart> Of course, if the build itself is bad it doesn't solve that problem
<lilstevie> the uart is burried in the JTAG port :/
<lilstevie> well the only one I can trace
<lilstevie> but don't know much more
<twb> OK, off we go using gcc-4.4
<twb> Donkey balls
<twb> /usr/src/u-boot/lib/sha1.c: In function âsha1_processâ:
<twb> /usr/src/u-boot/lib/sha1.c:228:1: internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:845
<twb> So qemu won't let me compile u-boot using gcc-4.4
<twb> At this point I am thinking instead of using userspace emulation on my netbook, I should just use qemu host emulation on one of the chunky buildds in the office
<twb> Same problem in gcc-4.5
<twb> So until I either get qemu up or reflash this with ubuntu, I'm at an imp-arse.
<twb> a.k.a. bed time for twb
<brandini>  try and fix this golang test failing
<brandini> ok, I've forgotten to install the OMAP4 stuff from TI and I wonder if I should do that to
<brandini>  try and fix this golang test failing
<brandini> phew
<sniperjo> I'm running angstrom, a beagle board version. Should i in theory be able to use an ubuntu beagle board version ?
<GrueMaster> sniperjo: angstrom is more generic, but you may have some luck with the oneiric omap images as thy are more mainstream.  Just remember that not all of angstrom's kernel bits are upstream, whereas ubuntu pulls the kernel directly from upstream.
<sniperjo> GrueMaster: ok thanks, I'm desperate here
<jkridner> GrueMaster: ubuntu also patches the upstream kernel.  we are always trying to reduce the patches in both Angstrom and Ubuntu by moving more stuff upstream.
<rsalveti> jkridner: do you know about the pm/smartreflex support at upstream? want to have my xm working at 1ghz :-)
<rsalveti> have a bug for ubuntu, bug 771537
<ubot2> Launchpad bug 771537 in linux "Beagle XM lacks proper 1Ghz support" [Medium,In progress] https://launchpad.net/bugs/771537
<rsalveti> don't know yet if we're already able to have it working with upstream properly, didn't have time to look around for the patches still
<GrueMaster> jkridner: What I meant was that unless a system is in our hands, we only support what the upstream kernel supports.  If support for the system that sniperjo is using isn't in the main kernel tree, we really have no way to support it directly.
<sniperjo> GrueMaster: Texnexion is also on the beagle board website
<sniperjo> not sure what that has to do with anythingâ¦ but i just though i would put it out there
<GrueMaster> That doesn't mean I have one here to test with.  My hardware budget is semi-limited and I already blew it on multiple pandas (and support hardware) for server testing.  Now, if you want to supply me with one...
<sniperjo> GrueMaster: If you have it up and running for me, consider it done
<sniperjo> it has been done http://www.youtube.com/watch?v=vWYHk15QOTo
<GrueMaster> Not that I would be able to get to it this cycle.  I really am overloaded at the moment.
<GrueMaster> I have a Nook Color that was my pet project to get running.  So far, I have barely had time to root it (since May).
<sniperjo> GrueMaster: I am getting to the stage, where paying for someone to get it working, could be a viable option
<GrueMaster> That video has a link to our RootFromScratch page, which indicates to me they built their own chroot environment (similar to ubuntu-core), which is what I suggested to you twice now.
<GrueMaster> And I know getting Ubuntu running on non-supported hardware can be done.  I did it using Natty Alpha on a Tegra 2 development platform using their boot loader & kernel.
<sniperjo> GrueMaster: i have managed to chroot into a card, but i diddnt have internet connectivity
<jkridner> rsalveti mike turquette is supposed to be sending an updated ABB patch.  PM patches are rebased on Kevin's branch on Tony's tree, but more work is required before going upstream.  We pull in the last patch set into OE.
<GrueMaster> That may be a kernel issue.  Make sure the ethernet module for your system is loaded.
<jkridner> rsalveti: I believe rcn-ee has an ubuntu-style kernel.  I'm sure you must watch it.
<jkridner> rsalveti: rcn-ee is pretty good at tracking whatever koen hacks on (and koen follows khilman and tmlind).
<rsalveti> jcrigby: cool, would like to check that patch set
<rsalveti> yeah
<rsalveti> even to enable it properly at linaro
 * rsalveti updating his oe tree
<jkridner> rsalveti I saw khilman sending arnd patches yesterday for PM.  I don't think it included the ABB support for 1GHz xM, but you can probably set the 1GHz OPP without it and not have too many headaches.
<rsalveti> jcrigby: which kernel version are you using as base?
<rsalveti> jcrigby: yeah, cool
<sniperjo> GrueMaster: how would i find out what my ethernet module was ?
<GrueMaster> sniperjo: There are a lot of things to check as to why you don't have networking.  First, look at dmesg to see if the kernel detects the network device.  Second, read the documentation to determine what type of device it is.  If it is usb, lsusb should see it.
<GrueMaster> If it is seen, the driver loaded, and dmesg indicates link detected, then maybe you just need to run dhclient eth0.
<jkridner> rsalveti: I'd be happy to point you to my 3.0.4 kernel (from koen) that supports 1GHz.
<sniperjo> i do have libertas: wlan0: Marvell WLAN 802.11 adapter
<rsalveti> jkridner: cool, want to have a look at that
<rsalveti> having 1ghz support for our 11.09 would be awesome
<jkridner> rsalveti http://gitorious.org/beagleboard-validation/linux/commit/c8f49b6a6cbcb3b2627388cee438096381b41913
<rsalveti> jkridner: great
<rsalveti> jcrigby: which branch is that, still cloning the tree
<jcrigby> rsalveti, is you tab completion expanding to jcrigby when you mean jkridner ?
<rsalveti> hahah :-)
<rsalveti> that was for jkridner :-)
<rsalveti> jcrigby: sorry ;-)
<jcrigby> np, my brain is in a fog so I just wanted to make sure
 * rsalveti needs food, out for lunch
<jkridner> rsalveti I think it is ulcd-android-20110917b
<jkridner> there actually aren't any android patches on it...
<jkridner> but, I was looking at pulling in the Linaro android patches and this tree was at the base point where I was going to apply the patches
<jkridner> I got held up on TLS incompatibilities.
<jkridner> I was able to cherry-pick a bunch of the Linaro Android patches, but the Android file system I have has an emulated TLS.
<jkridner> :(
<gildean> ogra_: tested yesterdays image, installation goes through without a hitch, even with selecting keyboard-layout etc.
<gildean> on the ac100 that is
<prpplague> GrueMaster: ping
<GrueMaster> prpplague: pong
<gildean> ogra_: also did it by the wiki with another computer with clean ubuntu install, with installing nvflash from .deb etc.
<gildean> so the installation-guide is also tested to be accurate
<prpplague> GrueMaster: hey, we need to look into the ppa stuff for the 10.10 release
<prpplague> GrueMaster: i along with about 5 others have been trying with no success on installing them
<GrueMaster> Yep, I'm working on that now.  Have to flash a new SD with the image.  Should be ready in 20-30 minutes.
<GrueMaster> It may be that universe and multiverse need to be enabled iirc.  But I want to verify that first.
<prpplague> GrueMaster: yea tried enabling those
<GrueMaster> prpplague: I am booting up now.  Will let you know what I find soon.
<prpplague> GrueMaster: ok thanks
<brandini> w00t, I had to comment out that one test for go in order to get go installed
<GrueMaster> prpplague: I just finished booting into maverick (I got distracted a little).  When I initially tried to install the extras, it failed due to gstreamer & faac packages.  Adding universe and multiverse to /etc/apt/sources.list fixes that.
<GrueMaster> Will document on wiki.
<prpplague> GrueMaster: which instructions were you using ?
<prpplague> GrueMaster: are you adding the univer and multiverse from the gui?
<GrueMaster> I didn't.  I just logged into the maverick image and tried the link for the ti extras.  When it failed, I opened a terminal and tried "sudp apt-get install ubuntu-omap4-extras-multimedia".  Then figured it out from there.
<GrueMaster> No, but I will document it in the release notes.
<GrueMaster> This was a known issue for maverick (missing universe & multiverse).
<prpplague> GrueMaster: ok, document what you got and i will try to replicate
<prpplague> GrueMaster: the instructions we have on omapedia are for using the GUI
<brandini> HAH! Anyone want to see how fast the pandaboard serves up requests?
<brandini> mind you my BW is limited to 768 outbound
<brandini> http://eutonian.ath.cx
<cospan> hello, I have a beagleboard XM with ubuntu desktop on it. I want to understand how to trigger events from the user button. I thought all I had to do was build a new kernel after modifying the <kernel base>/arch/arm/omap/mach-omap2/board-omap3beagle.c, compile the kernel and copy the vmlinuz into ubuntu's /boot directory and adjusting the symbolic link to run it, but I looked for the events, and inputs within the sysfs director
#ubuntu-arm 2011-09-24
<sven_> hi everybody. i am having prouble with the audio on pandaboard a2 running ubuntu 10.10. could anyone help me?
<sniperjo_> hello, anyone know if there are there any repos for mplayer ?
<afm> anyone in here playing with the [h,j]acked up ubuntu on the motorola bionic?
<sniperjo_> where is the best place to get mplayer?
<infinity> sniperjo_: apt-get install mplayer?
<infinity> sniperjo_: It's in universe.
<sniperjo_> infinity: i couldn't find it
<infinity> Do you have only main enabled?
<infinity> cat /etc/apt/sources.list
<sniperjo_> yeah i do
<infinity> If it only lists main, or main+restricted, add universe and multiverse to that, apt-get update, and enjoy.
<sniperjo_> i ended up putting a debian source in to find it, but its not working great!
<infinity> Yeah, don't do that. :/
<infinity> Debian and Ubuntu are source-compatible, not binary-compatible (this is true on all arches, not just ARM).
<sniperjo_> infinity: ah great thanks, i guess i should apt-get remove --purge them before i install it again
<infinity> It probably pulled in a bunch of dependencies too.
<infinity> You can learn about apt pinning to forcefully sidegrade out of the packages from Debian, or look at /var/log/dpkg.log to sort out what new stuff you got when, and remove those.
<sniperjo_> but if i know what packages i installed after adding debian, i suppose i can just remove them with dependancies ?
<infinity> If you know all the packages you installed, yes.
<infinity> Hence my dpkg.log suggestion.
<infinity> Though, if you still have a terminal with apt saying "will install X Y Z", that's the simplest. :P
<sniperjo_> infinity: ok great, and just out of interest, I have angstrom on a device which i have chroot'ed with ubuntu, is there any way to automatically chroot into ubuntu and run something, (as I've been unsuccessful in installing ubuntu straight out )
<infinity> Not sure precisely what you mean.
<infinity> You can certainly do command line things like "chroot /chroot/ubuntu /path/to/command", but if those things require DISPLAY to be set, or sockets in the root filesystem, you need to do some clever tricks to futz with your environment or bind-mount files.
<sniperjo_> infinity: yeah i have managed to do that, i was just wondering if i had to chroot and run stuff manually!
<sniperjo_> infinity: still no mplayer,  I'm on deb http://ports.ubuntu.com/ubuntu-ports lucid main universe multiverse , gave me a notice about unmet dependancies
<infinity> I'm using oneiric here, not lucid.  It's definitely installable in oneiric.  I'd be surprised if it wasn't in lucid, though.
<infinity> Do you still have Debian sources in your list?
<infinity> (It's also possible you still have Debian packages installed that are causing unresolvable conflicts)
<sniperjo_> infinity: ive just just added the maverick to the sources and its there now
<infinity> FWIW, I just debootstrapped a lucid chroot and mplayer installs fine.
<infinity> So, yeah, you probably had some newer libraries or something (from Debian) that were causing a bit of a dependency issue.
<infinity> But if maverick solves it for you, whatever. :P
<sniperjo_> hmmmmmm
<infinity> Anyhow, I'm off to do weekendy things.  Have fun fiddling.
<sniperjo_> infinity: out of interest, what video driver do you use ?
<sniperjo_> infinity: ok!
<sniperjo_> infinity: thanks for your help
<brandini> is there a mongodb build for ubuntu on armel?
<infinity> Seems to be only on x86.  Though I'm not sure why.
<brandini> :(
<brandini> I did find one bug report just now though it seems to be resolved
<brandini> https://jira.mongodb.org/browse/SERVER-2883
<brandini> this pandaboard makes a great webserver for webapps written in go :)
<infinity> The mongodb server depends on both little-endianness and unaligned
<infinity> memory access, which I believe means it can only work on i386 and
<infinity> amd64, so yes, we're not portable beyond those.  (It has compiled for
<infinity> me in the past on powerpc, but it won't run there.)
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570076
<ubot2> Debian bug 570076 in mongodb "mongodb - Arbitrary architecture specification" [Serious,Fixed]
<brandini> ok
<brandini> I'll have to use a real live database :)
<infinity> Or sqlite.
<infinity> Or BDB.
<infinity> Or any number of file-based approaches that aren't an annoyingly large RDBMS.
#ubuntu-arm 2011-09-25
<rsavoye> Does Oneiric run on the Genesi SmartBook yet ?
<steev_> rsavoye: i have an sd card running it
<steev_> no official release of it though
<rsavoye> of oneiric ?
<brandini> I think there is something goofy with the timing on my pandaboard
<brandini> I saw it in the test results when I was building go and just now when I was looking at ping times
<infinity> ?
<brandini> 64 bytes from 10.15.32.1: icmp_req=7 ttl=255 time=1.58 ms
<brandini> 64 bytes from 10.15.32.1: icmp_req=8 ttl=255 time=0.000 ms
<brandini> 64 bytes from 10.15.32.1: icmp_req=9 ttl=255 time=1.67 ms
<brandini> 64 bytes from 74.125.225.48: icmp_req=2 ttl=54 time=18.3 ms
<infinity> Running on the Panda, or another host?
<brandini> 64 bytes from 74.125.225.48: icmp_req=3 ttl=54 time=0.092 ms
<brandini> 64 bytes from 74.125.225.48: icmp_req=4 ttl=54 time=20.1 ms
<brandini> on the panda
<brandini> from the panda to the gateway and then to google
<infinity> I see fluctuations, as I do from any host, but I don't see any 0s. :P
<brandini> yeah
<brandini> must be superfast!
<infinity> 64 bytes from 10.0.0.1: icmp_req=4 ttl=64 time=0.153 ms
<infinity> 64 bytes from 10.0.0.1: icmp_req=5 ttl=64 time=0.855 ms
<infinity> 64 bytes from 10.0.0.1: icmp_req=6 ttl=64 time=0.488 ms
<infinity> 64 bytes from 10.0.0.1: icmp_req=7 ttl=64 time=0.092 ms
<infinity> 64 bytes from 10.0.0.1: icmp_req=8 ttl=64 time=0.580 ms
<brandini> but when I was building go all the /test/time results were failures
<infinity> For example.
<brandini> Yup
<brandini> here's the other thing http://pastebin.com/f26HKCJq
<brandini> those are counting clock ticks I think an it's getting done faster than is possible I think
<infinity> Possibly.
<infinity> Which kernel?
<brandini> I did not see this behavior either with ping or on the go test on 10.10
<brandini> Linux localhost 3.0.0-1204-omap4 #9-Ubuntu SMP PREEMPT Mon Sep 5 19:29:18 UTC 2011 armv7l armv7l armv7l GNU/Linux
<infinity> I wouldn't be terribly shocked if we still have a ton of lingering SMP bugs on ARM.
<brandini> ok
<infinity> You could try booting with 'nosmp' on the command line and see if it magically clears up.
<brandini> I will do that after I eat and report back, thanks :)
<infinity> Food sounds like a stellar idea.
<infinity> As does a weekend in general. :)
<brandini> infinity: how do I set that nosmp?
<infinity> brandini: Kernel command line.
<infinity> brandini: So, either hand-craft a command line in uBoot (irksome), or edit /boot/boot.srcipt and re-run flash-kernel
<brandini> I did edit /boot/boot.script
<brandini> xA0000000 root=UUID=5e7fa157-723c-4bd5-9a0c-d76ff1f07c64 fixrtc nosmp quiet spla
<brandini> is that the right place for it?
<infinity> Should do.
<infinity> But then you need to re-run flash-kernel.
<brandini> done
<brandini> testing now
<infinity> Check after you reboot that you only have one CPU. :)
<brandini> how do I see that?
<infinity> cat /proc/cpuinfo would be a good indicator.
<infinity> Processor	: ARMv7 Processor rev 2 (v7l)
<infinity> processor	: 0
<infinity> BogoMIPS	: 1576.53
<infinity> processor	: 1
<infinity> BogoMIPS	: 1539.77
<infinity> ^-- Two cores.
<brandini> ahhh yes, only one and the error still occurs
<infinity> Kay.
<brandini> sorry... I'm a BSD guy so linux isn't my primary system
<Jack87> http://www.webos-internals.org/wiki/Application:Xapps
<Jack87> ubuntu runnin in chroot of hp touchpad ^
#ubuntu-arm 2012-09-17
<orated> Hello! I'm using Beagleboard XM running Canonical Ubuntu 12.04 3.2.0-30-omap. Even with the latest kernel where sound issue is fixed, I'm not able to get audio output. $ cat /proc/asound/cards lists 0 [omap3beagle    ]. Can anyone help me out with this?
<orated>  Hello! I'm using Beagleboard XM running Canonical Ubuntu 12.04 3.2.0-30-omap. Even with the latest kernel where sound issue is fixed, I'm not able to get audio output. $ cat /proc/asound/cards lists 0 [omap3beagle ]. Can anyone help me out with this?
<nasrullah> hi
<nasrullah> i do have an efika smartbook but i cannot upgrade the ubuntu os
<ogra_> how is it failing ?
<nasrullah> i do get error
<nasrullah> server error
<nasrullah> i have tried many times the same thing
<ogra_> (note that the images for this device were built by genesi, its unlikely that we can easily work out a fix here)
<ogra_> server error ?
<ogra_> thats the exact text you get ?
<nasrullah> fail to get packages
<nasrullah> i do want to install another os  on it
<ogra_> can you check with "lsb_release -a" what version of ubuntu you are actually running there ?
<nasrullah> 10.10
<nasrullah> it came with it
<ogra_> and what server does it try to connect ?
<ogra_> 10.10 is definitely still available in the repos
<nasrullah> egypt
<ogra_> egypt ?
<nasrullah> as my os is in arabic
<ogra_> ???
<nasrullah> ubuntu egypt
<ogra_> do you have the server address it tries to connect to ?
<nasrullah> the outcome error server not found
<nasrullah> or if i want to install a fresh os on it
<nasrullah> how to proceed
<ogra_> ask genesi ?
<ogra_> there might be linaro images, not sure ...
<nasrullah> ok i will do e-mail genesi
<ogra_> we have never officially supported this device with ubuntu so its hard to tell
<nasrullah> ok
<ogra_> the userspace shoudl be upgradeable though, not sure why genesi made yours point to an egyptian server
<ogra_> since all arm packages are stored on ports.ubuntu.com and usually not mirrored
<steev> ogra_: we didn't
<steev> anything pointing to anything other than ports.ubuntu.com is a user customization
<ogra_> ah, good
<ogra_> sadly he is gone now
<steev> ftr we're working on a precise image currently
<steev> it works fine with the 2.6.31 kernel but we're working on getting mainline kernel up to snuff
<ogra_> neat
<steev> ogra_: happen to know if there is a uclibc cross compiler for arm (as in, runs on an arm glibc host) ?
<ogra_> not in ubuntu afaik
<steev> :/
<ogra_> there might be some oout of archive stuff enbdebian has
<steev> i have a trimslice here that runs natty
<ogra_> well, i'm typing on an ac100 netbook running precise :)
<steev> i'll poke konstantinos
<ogra_> (nearly the same ting as the trimslice just with a nice shell)
<steev> yeah
<GrueMaster> ogra_: Not dogfooding???
<steev> the trimslice is "nice" but man does it get hot
<steev> GrueMaster: dogfooding is crazy talk (that said, i use the hell out of my smartbook)
<ogra_> GrueMaster, waiting for nvidia to release a binary driver for xorg abi 13
<satellit> +1  cooler if use powered hub for keyboard and mouse
<steev> ogra_: there is one i thought
<ogra_> so for now i stay with precise
<steev> in the tegra dev zone or whatever, the latest hardfloat drivers I *thought* had one
<ogra_> GrueMaster, apart from that i'm not such a big fan of lubuntu or xubuntu ... and ubuntu-desktop is no more for arm :)
<steev> but it may be ventana only
<steev> ogra_: hm? where did it go?
<ogra_> well ... it is but you wont run it without binary drivers
<ogra_> steev, ubuntu-desktop requires GLES acceleration
<ogra_> from quantal on
<GrueMaster> Sadly, I am currently forced into a sort of dog fooding experience.  Very hot slow Intel processors running Windows 7.  Ick.
<steev> nothing wrong with that
<ogra_> and there is no working llvmpipe for arm yet
<ogra_> GrueMaster, great, take them home, winder is near !
<ogra_> *winter
<ogra_> steev, no, nothing worng with that apart from the fact that you need drivers for GLES :)
<GrueMaster> I wish.  Of course, i would have to reimage them first to a more stable OS.
<steev> GrueMaster: crazy talk
<steev> windows is stable as long as you don't run anything on it!
<ogra_> yu mean like a mousepointer ?
<steev> heh
<GrueMaster> On my netbook, Windows 7 Home Starter (most useless version available) takes ~2 minutes to boot on my Intel 520 series SSD.  Ubuntu, booting off a partition on the same device takes ~12 seconds.
<ogra_> you should try LennartOS^Wfedora ... systemd will make it boot in -12 seconds
<GrueMaster> Nah.  I prefer WORKING linux distributions, not some Mega corp's litterbox distro.
<steev> hey now, it's not THAT bad
<steev_> xorg abi for oneiric is still 10? or is it 11?
<NekoXP> it's one louder.
 * RoyK mumbles something about google
<NekoXP> http://packages.ubuntu.com/oneiric/xorg-video-abi-10
<NekoXP> :)
<steev_> chromium was being a pita wrt mem usage so i didn't have a browser available
<steev_> apologies for wasting your time RoyK
<cnanakos> Hi all. Can someone please have a look at this bug?
<cnanakos> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687182
<ubot2> Debian bug 687182 in mpg321 "program seg faults on armhs" [Normal,Open]
<cnanakos> the solution has been recorded here https://igw.tuwien.ac.at/ceat/node/2#comment-162
<cnanakos> Is this a hardfp ABI incompatibility??
<cnanakos> by disabling architecture specific optimizations seems to work fine
#ubuntu-arm 2012-09-18
<ogra_> ppisati, ddi you include the fix for bug 746137 in your last upload ?
<ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on Pandaboard and Beagle XM" [High,Confirmed] https://launchpad.net/bugs/746137
<ogra_> seems QA is seeing it recently on the bamboo-feeder http://pastebin.ubuntu.com/1212016/
<ppisati> ogra_: AFAIK there's no fix
<ogra_> err, cooloney worked one out weeks agai
<ogra_> *ago
<ppisati> then i'm not aware of it
<ppisati> i know there's a systcl to workaround it
<ppisati> but IMO all the fixes proposed so far
<ppisati> are not working
<ogra_> GFP_ATOMIC vs GFP_KERNEL i think
<ppisati> cooloney: ^
<cooloney> ogra_: i saw patches for Panda was merged by ppisati
<cooloney> the patch is a hack from Andy Green
<ogra_> oh, he merged it without knowing ?
<ogra_> haha
<ogra_> k, as long as its in ...
<cooloney> that's for panda, not for Beagle
<ogra_> ah
<ogra_> well, would be good to have it in beagle too
 * ppisati is schizophrenic then
<ppisati> well guys
<ogra_> since we have no way to apply userspace hacks anymore like we did with preinstalled images
<ppisati> but if we still have that problem even with the supposed fix
<cooloney> ogra_: i tried a patch MingLei gave to me from upstream some maintainer.
<ppisati> it's clearly not working
<cooloney> ogra_: but it doesn't work.
<ogra_> ppisati, how would you know ?
<ogra_> your upload is in the archive but we have no new images with it yet
<ppisati> ogra_: but it's not there for sure
<ppisati> i mean
<ppisati> cooloney: which patch were you referring?
<ppisati> ogra_: in the last upload there's the video/unity flickering fix
<ogra_> hmpf, i had the impression that was long fixed
<ppisati> ogra_: and a rebase on origin/master (latest 3.5 stable)
<cooloney> ppisati: a patch not in public, it is for smsc95xx usb net driver
<ogra_> ah, if its driver specific that should work for beagle too then
<cooloney> ppisati: the patch from Andy is in your ti-omap4, so it should be workarounded
<ogra_> they use the same chip
<cooloney> but for beagle it is in master.
<ppisati> ogra_: iirc, conrad approached me weeks ago and told they have the same problem on builders
<cooloney> the hack will touch other flavors.
<ogra_> conrad ?
<ppisati> ogra_: adam
<ogra_> do you mean infinity ?
<ppisati> yes
<cooloney> infinity: ^^
<ogra_> ah, conrad adam ... the evil twin of adam conrad *g*
<ppisati> :)
<ogra_> i dont think the builders run quantal, so thats not a surprise
<ogra_> and they dont use preinstalled images to set them up (which would get them the fix) but use ubuntu-core with manual config or some such
<ppisati> ogra_: yep
<ppisati> ogra_: what i meant was that we never really fixed it
<ogra_> s/get them the fix/get them the userspace fix/
<ppisati> ogra_: and if we have a supposed workaround in
<ppisati> ogra_: but we still experience it
<ogra_> well, i lost the opportunity to work around it in userspace ...
<ppisati> ogra_: then we should a) investigate the problem b) back out the workaround
<ogra_> and i havent seen it in ages here in my tests
<ogra_> so i personally had the impression it was long fixed
<infinity> ogra_: The buildds use d-i over PXE on precise, but they have the userspace hack in puppet.
<ogra_> until hggdh pinged me over night today
<ppisati> infinity: and do they suffer the problem?
<infinity> ppisati: No.
<ppisati> uhm
<ogra_> and funnily the saem thing is discussed on #beagle today too
<ogra_> ppisati, the userspace hack always worked
<infinity> ppisati: But any machine installing from an installer that doesn't put the userspace hack in place will have the issue.
<ppisati> the userspace stuff was the sysctl config, right?
<infinity> Right.
<ogra_> right
<ogra_> worst case we should just bump it at build time for certain arches
<ogra_> in the kernel code ... if thats possible
<ogra_> so we would just move the userspace hack into the kernel
<ppisati> i wonder if can pass it via cmdline
<ogra_> well you can definitely just create the sysctl.d file ... its a one liner
<ogra_> not susre sysctl values are read from cmdline
<ppisati> right
<infinity> If it should always start at a certain value, and it's not, passing it on the cmdline (or sysctl) is the wrong answer.
<infinity> The initial value should be correct.
<infinity> I think we've been over this a few dozen times.
<ppisati> but they are kernel variables
<ogra_> heh, yeah
<infinity> ppisati: Yes, it's a variable, but variables should have sane defaults.  This one clearly isn't sane for ARM.
<ppisati> vm.min_free_kbytes = 8192
<infinity> Anyhow, I should sleep.
<ppisati> uhm
<infinity> If I recall, apw was deeply involved in the last round of this conversation.
<cooloney> ppisati: i suggest we instroduce a config option in master branch like CONFIG_VM_MIN_FREE_KBYTES
<ppisati> sleep well
<infinity> And he doesn't seem to be in the channel.
<infinity> So you might want to take this to #-kernel.
<cooloney> which should be 8192 by default for x86, powerpc
<cooloney> and 32768 for ARM
<ppisati> vm.min_free_kbytes = 32768
<ppisati> on my Q/omap4
<cooloney> and porting Andy's hacking patch to master
<cooloney> ppisati: yeah, it should be 32768 for ARM since it was forced to be that in mm/page_alloc.c
<ppisati> so we are "already "good"
<ppisati> ?
<infinity> Oh, kay, so we HAVE worked around it in the kernel?
<cooloney> yeah, but beagle is omap3, which is master kernel
<ogra_> on omap4, but not on omap (which uses the same driver)
<cooloney> not on your branch,
<infinity> Ahh, not in master.  Check.
<ppisati> wait
<cooloney> we need put such similar patch in master
<infinity> Couldn't you just wrap it in #ifdef __ARM__ and commit to master?
<ppisati> ogra_: didn't you say we hit this problem on omap4 tonight?
<cooloney> if you put the same patch in master, it will set it to 32768 for all the flavors
<cooloney> like x86 and powerpc
<infinity> I guess highbank and armadaxp would pick it up too, then, but that's not world-ending.
<ogra_> ppisati, i was notified by hggdh in #ubuntu-bugs tonight with the pastebin i gave above ... havent talked to him yet
<infinity> cooloney: Hence why I said wrap it in an ifdef.
<ppisati> ogra_: oh
<infinity> cooloney: Though, obviously a CONFIG_ is better.
<ogra_> (since he is asleep like every sane person on that american continent atm)
<ppisati> so, even with the fix
<ppisati> we hit the problem
<infinity> cooloney: And the CONFIG_ change would be upstreamable even.
<cooloney> infinity: yeah, that should be ok for just local hacking, heh
<ogra_> ppisati, well, lets see what exactly he tested there
<ppisati> ok
<ogra_> i need to talk to him first
<cooloney> infinity: i don't think we need such hacking for highbank and amadaxp
<ppisati> ok
<ppisati> wait a sec
<ogra_> in any case people in #beagle are seeing it and have discussed it today
<cooloney> because they don't use usb ethernet controller
<infinity> cooloney: Right, hence why a CONFIG_ would be better.
<ppisati> qait wait
<ppisati> i just noticed one thing
<cooloney> only beagle
<cooloney> infinity: CONFIG_ can be set as different value for different flavor
<infinity> ogra_: That pastebin is an ancient kernel.
<ppisati> tight
<ppisati> rigjt
<ppisati> ah
<ppisati> it's a 3.4.x
<ogra_> i have heard many reports that people on intel have seen it too btw
<infinity> cooloney: Yes, I know. :P
<ppisati> we have the fix in 3.5
<ogra_> it isnt arch specific but USB related
<cooloney> or just use #ifdef USB_NET SMSC95XX
<cooloney> like this kind of hacking
<cooloney> ppisati: what's kind of fix in 3.5?
<ppisati> 86b83747713545234c28e5347c6f0e5efb652332
<ppisati> HACK force min_free_kbytes set by proc to min 32K to workaround smsc problems
<ppisati> Signed-off-by: Andy Green <andy.green@linaro.org>
<ppisati> actually even this one
<ppisati> 89b16e837180b215b667affdd4227220827f8bb4
<ppisati> HACK force min_free_kbytes to 32K to workaround smsc problems
<ppisati> both are needed
<ppisati> the second one is a safe belt
<ppisati> the first one is the real one
<ogra_> ppisati, did you put the LP bug number for the flickering in the changelog ? (i didnt see it in teh pull request mail)
<ogra_> Laney, ^^^
<cooloney> ppisati: i didn't see that patch in the real code. can you see that code in the mm/page_alloc.c?
<cooloney> ppisati: although i can git show that patches you posted
<ppisati> ogra_: i didn't know there was a bug opened for it
<ogra_> bug 1045491
<ubot2> Launchpad bug 1045491 in linux-ti-omap4 "Moving mouse messes up the desktop" [High,Confirmed] https://launchpad.net/bugs/1045491
<ppisati> ah ok
<ppisati> ok
<ppisati> i'll close it manually
<ogra_> well, let me take care
<ogra_> i'll close it if it has been tested with the images :)
<ogra_> (if i dont, kate will hunt me down anyway)
<ppisati> ogra_: where is the template for preEnv.txt? or, how do i make it look as i like? or how do i make flash-kernel NOT replace its content at every run?
<ogra_> ppisati, /etc/default/flash-kernel
<ppisati> ogra_: ack
<sveinse> As a part of a custom/proprietary first-boot system, I need to run a series of disk partitioning operations prior to mounting the real root. What would be preferred: a dash script with the required support tools (sfdisk, awk, grep, etc.) or to pull in python into initramfs?
<ogra_> sveinse, have a look at the jasper-initramfs code
<sveinse> ogra_, voila. Thanks
<ogra_> specifically at the jasper_growroot script
 * sveinse discoveres that the wheel has already been invented
<ogra_> and obsoleted too :)
<sveinse> I'm not there yet :P
<sveinse> Any of you people the author(s) of jasper-initramfs?
<ogra_> yes
<sveinse> Why do you reboot after resizing root?
<ogra_> any of me are :)
<ogra_> because i'm a coward :)
<ogra_> and want to make sure it actually worked before moving on with the install
<ogra_> its not actually necessary if you are sure its all fine
<ogra_> (i.e. if you dont have people with random SD cards as media)
<sveinse> its just that there any isn't more you can do with a reboot compared to just continue. But I get the point
<sveinse> Except that you know that the bootloader is still intact after altering the parttables
<ogra_> you do test if the UUID and partitioning is still  right and if the bootloader still does the right thing on a fresh boot
<sveinse> yup
<ogra_> jasper_growroot also isnt the only script there ... jasper modifies other things too and sets them up
<sveinse> i also noticed a loop around resize2fs. Doesn't it do enough in one iteration?
<sveinse> (not that I've deciphered the sed and char logic in there)
<ogra_> thats for plymouth
<sveinse> ah. of course
<ogra_> resize2fs runs through several iterations, the loop just picks up the output and dumps it to plymouth or the text console
<ogra_> its not resize2fs itself thats gets looped over ... only the output
<sveinse> you mean resize2fs does NOT run in loop, yes, I see that now
<ogra_> right
<ogra_> the while sits after the pipe
<sveinse> and I also found some nice sysctl settings for having root on sd-cards. Are there any more goodies like this I should be aware of?
<lilstevie> I need to start using that :p
<lilstevie> I often get users of my transformer images complaining about it just stopping when resize2fs is running
<ogra_> sveinse, the zram-conf package is helpful if your kernel supports it (speeds up swapping a lot)
<ogra_> and here on my ac100 i just experiment with a journal-less ext4 ... thats classes faster than any FS i have tried yet
<ogra_> though with that you should force an fsck on every boot
<ogra_> ogra@horus:~$ cat /etc/security/limits.d/90-stack.conf
<ogra_> * soft stack 256
<ogra_> thats also pretty helpful when being low on ram
<lilstevie> what is required for zram anyway
<ogra_> (default is 8k per thread stack, makes your apps use less ram (and since its soft they can just ask for more if needed))
<ogra_> lilstevie, that you enable it in your kernel config
<lilstevie> I have no idea if I included the right bits
<lilstevie> :p
<ogra_> i think there is only one option (or probably two)
<lilstevie> config_cramfs?
<lilstevie> I guess I should just try it lol
<ogra_> no, thats a filesystem
<lilstevie> ah right
<ogra_> search for zram
<ogra_> (hit / in menuconfig)
<lilstevie> yeah I know how to search :p
<lilstevie> ok yeah CONFIG_ZRAM
<lilstevie> and it is enabled
<ogra_> great
<lilstevie> I have double the ram of the ac100, but IMO 1GB is far from enough
<ogra_> yeah, imho zram should become a default as staging swap
<ogra_> so that you first swap into compressed ram before actually writing to disk
<lilstevie> yeah
<lilstevie> I will have to give it a go, see how much of a performance increase it gets
<ogra_> you will only note it when swapping
<lilstevie> so the moment I open chromium then :p
<ogra_> yeah, firefox uses lots less ram in its recent versions ...
<sveinse> What's the deal with CHS geometry on omap3 and bootloader? I haven't been able to find any other combination other than H=255, S=63 that works. But I see H=128, S=32 is used in jasper
<sveinse> so I guess that also works
<ogra_> the ROM needs to find the first stage loader at a certain point on a vfat to boot
<sveinse> (I have to admit I'm confused about CHS vs LBA and how they interact)
<ogra_> thats omap specific
<ogra_> i doubt you need CHS on tegra
<lilstevie> ogra_, tegra scans until it finds the bct
<ogra_> right
<sveinse> from what I understand, there partition table contains both CHS and LBA fields. And Linux uses only LBA, right.
<sveinse> So given that you're able to boot, when sfdisk complains about partitions not on cylinder boundaries is just a warning, but it does not affect anything
<sveinse> ogra_, A proposal: You dont strictly need to use fdisk to determine the size of the disk. sfdisk can do that as well. So you can spare a binary in initramfs
<ogra_> sveinse, well, jasper is pretty much dead beef
<sveinse> ok, just saying
<ogra_> we only keep it in the archive in case we will actually spin preinstalleds once again
<ogra_> over time it will vanish from the arhcive though, i wont put any work into it
<ogra_> and yeah, i know that sfdisk can do this
 * ogra_ looks at bug 1044709 and wonders what got infinity the honor to be the new unity slave
<ubot2> Launchpad bug 1044709 in unity/6.0 "unity-6.4.0 from quantal-proposed crashed with SIGSEGV on omap4" [Critical,Fix committed] https://launchpad.net/bugs/1044709
<ogra_> oh you actually commited that to their tree
<jimerickson> omap4+armhf: it works. enough said.
<GrueMaster> jimerickson: Erm, when didn't it?
<jimerickson> was have some flashing screen problems with the last kernel. but this latest update has resolved it.
<GrueMaster> Ah.
<Deformati> Anyone here know about performance counters?
<GrueMaster> I do, sort of.
<GrueMaster> At least from the Pentium Pro days.
<Deformati> GrueMaster, For some reason on omap4 devices the performance counters are disabled and there doesn't seem to be documentation for enabling them.
<Deformati> So I suppose pentium pro isn't relevant.
<GrueMaster> Yea, propably not.  :P
<GrueMaster> You might ask on #pandaboard though.  They can probably help, if it is harder than simply rebuilding the kernel.
<GrueMaster> It should be fairly straight-forward though.  Looks like it can be done by downloading the kernel source package for the kernel you are using, then modify the config to enable perf counters.
<GrueMaster> And rebuild.
<GrueMaster> Documentation is at http://help.ubuntu.com/community/Kernel/Compile
<Deformati> GrueMaster, I tried that.
<Deformati> There is a bug report on launchpad.
<GrueMaster> And the new custom kernel didn't work?
<Deformati> The existing kernel has it enabled.
<GrueMaster> ah, ok.
<Deformati> But warmcat says on the launchpad bug report that it is intentionally disabled, i cannot find what they disabled or where.
<Deformati> I just get errors every time I try to use the PMU.
<GrueMaster> Sounds like possibly a #linaro or #pandaboard issue.
<Deformati> Ok.
<GrueMaster> I seem to remember some discussion on this a while back (like 11.10 timeframe).
#ubuntu-arm 2012-09-19
<xnox> ogra_: as per "Documentation, firmware and drivers" section in http://www.ubuntu.com/project/about-ubuntu/licensing I see no problem with keeping panda images as "Ubuntu Desktop"
<xnox> it has been re-inforced by TB in the past that on case-by-case we do include firmware and drivers provided that they "do not restrict our ability to make Ubuntu available free of charge, and that you can continue to redistribute Ubuntu."
<ogra_> xnox, right, and the TB decision that pitti referred to explicitly stated the deriver exception
<ogra_> *driver
<xnox> yes.
<ogra_> but we still should make users aware of the fact that there are binary drivers included
<xnox> https://bugs.launchpad.net/ayatana-design/+bug/723831/comments/19
<ubot2> Launchpad bug 723831 in ubiquity "Installer â The option to 'install third-party software' when installing Ubuntu should be selected by default (aka "make Youtube work")" [Wishlist,Won't fix]
<xnox> he even wrote the comment himself =)
<ogra_> (not only to warn them but also because they will love us for that ;) )
<xnox> I can totally see "love" comming our way
<ogra_> :)
<ogra_> stgraber, so playingg with the zatab i can see it initializes the LCD backlight when u-boot comes up (still fiddling with the kernel) so something is definitely working right here
<ogra_> i wonder if the kernel just defaults to HDMI ;)
<stgraber> ogra_: AFAIK getting a working kernel framebuffer before X is quite tricky, maybe rbelem managed it now. My initial try was to mess with my setup until I'd get something to appear in the logs on the microsd, though without much success.
<ogra_> well, zareason shows pics of ubuntu running on the tab on their facebook page
<ogra_> but thats attached via hdmi
<ogra_> they should just make the images available they have ...
<ogra_> even if they are crappy
<ogra_> oh, btw, there is no /proc/config.gz in the default android ... seems they disabled that :/
<ogra_> stgraber, hmm, seems *everything* related to graphics output is a module in the defconfig
<ogra_> stgraber, where did you get the script and bootscr from again ?
<stgraber> ogra_: script.fex is a clear text version of script.bin from /dev/nand1. On our model it's: http://paste.ubuntu.com/1214832/
<ogra_> thx
<stgraber> ogra_: the boot.cmd is a fairly standard: http://paste.ubuntu.com/1214835/
<ogra_> ok, this kernel is definitely doing something
<ogra_> heh, framebuffer console is disabled by default
<ogra_> grmbl, so i'm pretty sure the kernel comes up fine
<ogra_> the backlight level changes definitely after a few seconds when booting
<ogra_> (which doesnt happen if i remove uImage)
<zumbi> hi!
<zumbi> do you know what are default user/passwd for precise armhf images?
<ogra_> ??
<ogra_> the same as on official debian images (read: there are none)
<ogra_> we expect the initial user to be created by the installer :)
<ogra_> zumbi, what images are you trying
<zumbi> http://cdimage.ubuntu.com/releases/12.04/release/
<ogra_> what arch ?
<zumbi> ogra_: on VGA monitor it brings you to desktop and asks questions, but I got a login on serial tty, after enabling it
<zumbi> ogra_: armhf
<zumbi> ogra_: for mx5
<ogra_> well, normally it should run oem-config (subset of ubiquity) and create a user
<zumbi> ogra_: right, it does that, I just dont have USB keyboard around to enter the details
<ogra_> after all that is done that user should exist on the system and you should be able to log in with these credentials
<ogra_> beyond that, there is no user at that point, the rootfs is competely virgin
<zumbi> not even for root?
<ogra_> ubuntu doesnt make use of root ;)
<ogra_> sudo by default
<ogra_> so the root account is always locked
<zumbi> right.. that's a bit crazy
<ogra_> i would suggest using a server image ...
<ogra_> they default to serial for everything
<zumbi> there are no server images for mx5
<ogra_> (and tasksel offers ubuntu-desktop too if you want it)
<zumbi> ogra_: well, thanks, I think I'll hack a user/pass with qemu
<ogra_> hmm, i thought we had them
<ogra_> zumbi, non need for qemu ...
<ogra_> just sedit /etc/shadow on the SD
 * GrueMaster had suggested netboot images as a bare minimum for all hardware, but ....
<ogra_> but be aware that you miss configuration indeed
<zumbi> ogra_: what do i need to change in /etc/shadow?
<ogra_> the exclamation mark for the root pw
<ogra_> just remove it
<zumbi> root:*:15453:0:99999:7:::
<zumbi> there is no !
<ogra_> then the *
<ogra_> should end up like a debian install where you set no rootpw
<xnox> booting panda desktop image....
<RoyK> should work...
<xnox> ogra_: can you boot desktop panda sd card for installation.... but do not attach any other hard-drives
<xnox> what is your expectation from ubiquity?
<xnox> currently it goes straight from wifi setup -> manual partitioning screen
<xnox> and finish button can be clicked dispite not doing anything useful (well crash)
<ogra_> xnox, hmm, it should pop up the notice about installing to source media and let you do it
<xnox> ogra_: well installing back on to the sd card should be supported.
<xnox> ogra_: and stgraber said on #-release that why did it not get stuck at the prepare page - not enough disk space
<xnox> ogra_: and if it didn't get stuck there, why didn't d-i offer auto-partitioning
<xnox> ogra_: see bug 1053030
<ubot2> Launchpad bug 1053030 in ubiquity "highly confusing UI on desktop when installation media is big enough and no external storage is attached" [High,Confirmed] https://launchpad.net/bugs/1053030
<ogra_> xnox, i think simply because mmc support in d-i is really not across the board
<ogra_> when we started with arm it didnt have any at all
<ogra_> and we only implemented bits on the go where we needed them ... the partitioner never was among these
<ogra_> since we never used Sd as target before
<xnox> yeah, only in the pre-installed case.
<xnox> but no ubiquity in pre-installed case.
<infinity> sd wasn't a "target" in preinstalled, either.  It was just, well, pre-installed. :P
<xnox> =))))) lolz
<infinity> (And it totally used ubiquity)
<ogra_> yeah
<xnox> infinity: ok, no partman =)))))
<infinity> Right.
<ogra_> ac100 images still work that way today
<infinity> Because no installing.
<ogra_> right
<xnox> right. So who wants to implement partman-auto support for mmc
<xnox> in particular biggest_free should be doable.
<infinity> I don't honestly see why it should be different in any way from the /dev/sdX support.
<ogra_> right
<infinity> Except that the device nodes are named differently.
<infinity> Otherwise, the partition tables are the same, the high level interfaces to talk to it all is the same.
<ogra_> and its likely just some kind of case statement )or equivalent) that needs to be enhanced
<xnox> for some reason it is. I will poke it a bit.
<xnox> For some reason it none of the autopartitioning recipes qualify and it drops into manual partitioning, e.g. partman/choose_partition
<xnox> which breaks ubiquity's state-machine =)
<infinity> (Maybe a bit of sauce to make /dev/mmc* device filesystems be mounted with flash-friendly options would be nice, but that's actually a more widespread problem that also affect installing to USB sticks on /dev/sd* as well)
<ogra_> there are several bugs about that
<ogra_> TRIM support etc
#ubuntu-arm 2012-09-20
<TheMuso> c/
<ogra_> oh, ah !
<ogra_> stgraber, while concentrating on getting the framebuffer to work i didnt actually notice that tablet is already booting fine
 * ogra_ is just reading /var/log/dmesg from the SD
<ogra_> [    17.361] 	ABI class: X.Org Video Driver, version 13.0
<ogra_> [    17.361] (EE) open /dev/fb0: No such file or directory
<ogra_> [    17.361] (EE) No devices detected.
<ogra_> [    17.361]
<ogra_> HA !
<stgraber> ogra_: yay!
<stgraber> ogra_: what did you end up doing to have it boot?
<ogra_> damned, but that was an older boot, not the kernel i'm currently trying
<ogra_> stgraber, dunno, i'm wildly poking kernel config opts mainly to get some kind of console (HDMI, USB serial or LCD)
<ogra_> so if i can get back to that working kernel i should be able to set up wlan in /e/n/i and use ssh
<stgraber> ogra_: that'd be great!
 * ogra_ goes back to the defconfig and starts over
<ogra_> luckily cross  building only takes a few seconds :)
<stgraber> ogra_: yeah, once you get through the initial 30-45min build, rebuilding with different options is really quick :)
<ogra_> 30-40 min ?
<ogra_> what kind of desktop do you have ?
<ogra_> i think building it with modules took under 5 min initially here
<ogra_> (though i run my development folders in a ramdisk....)
<zenx> Hi, i am failing to compile latest ti-omap kernel because of a "implicit function declaration" warning. Should I try and disable this or actually instantiate the function?
<ogra_> sigh, and now i cant get a single working boot anymore
<ogra_> fun
<ogra_> i should have checked /var/log eariler
<zenx> ogra_: When u use a ramdisk do u have a local repo to commit the changes or is this unversioned development?
<ogra_> unversioned
<zenx> ok
<ogra_> i have the git tree on disk though ... and copy it into the ramdisk as needed
<highvoltage> ogra_: so I hear you have something booting? that's awesome :)
<ogra_> i had
<ogra_> and i'm not at all sure which kernel that was
<ogra_> the timestamps on the logs are 4h old
<GrueMaster> ogra_: What system are you working on?
<ogra_> zatab
<ogra_> sigh, i really would like to know how it booted the last time
<ogra_> i think i went throuh all combos of u-boot and uImae now
<ogra_> *uImage
<GrueMaster> So, why not just run Ubunto on Android?
<ogra_> why would i do such insanity ? :)
 * ogra_ doesnt really want to carry a monitor with the tablet all the time to make it run ubuntu :)
<GrueMaster> I'd better just not comment.  May not bode well for future relations.
<ogra_> i want to run native ubuntu :)
<GrueMaster> Is that even possible on arm still?
<GrueMaster> (yea, I went there).
<ogra_> hmm ?
<ogra_> sure it is
<gildean> we're on a channel called ubuntu-arm, hint hint
<gildean> :D
<GrueMaster> gildean: If you knew me and my background, you would better understand my reference.
<gildean> i was just joking, don't take it too seriously
 * GrueMaster takes nothing seriously on these channels anymore.
<geotec> hallo pple! I am trying to compile kernel armel from scratch... cause i need to have CONFIG_AEABI=y and CONFIG_OABI_COMPAT=Y and CONFIG_ARM_THUMB=y (in order to get and older etch ARM(not armel!) chroot working with a needed toolchaing glibc 2.3.2) - Question: Why i fail compiling inside scratchbox with "/scratchbox/compilers/cs2007q3-glibc2.5-arm7/bin/sbox-arm-none-linux-gnueabi-strip: Unable to recognise the format of the input f
<geotec> here is the output http://pastebin.com/e0uETWfg    ... it seems to do its job, but it stops on 'debbing' the headers
<ogra_> i doubt anyone in ubuntu land has ever used scratchbox
<geotec> well, me
<geotec> ;D
<LetoThe2nd> was just about to say the same - why not use the standard toolchain?
<geotec> LetoThe2nd: tell me more
<LetoThe2nd> geotec: apt-cache search gnueabi ;)
<ogra_> right, just a std cross compiler or a plain chroot with qemu-arm-static
<geotec> it has to be armel
<LetoThe2nd> geotec: so whats the problem?
<LetoThe2nd> geotec: just check what arm toolchains are in the repo and pick what ever you like.
<geotec> interesting.. approach..
<geotec> but i need a toolchaing like emdebian?
<LetoThe2nd> no, why should you?
<LetoThe2nd> the kernel is one of the things you can compile with mostly just the bare compiler (and some accesory tools)
<LetoThe2nd> (plus, emdebian is not really what i would call a "toolchain")
<geotec> yeah right. But how do i make a kernel package of it
<geotec> ?
<geotec> i mean, a debian kernel package
<LetoThe2nd> hmh, easiest is if the source is debianzied.
<geotec> the source is debianized
<LetoThe2nd> \o/ for hrw then:
<LetoThe2nd> http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/
<ogra_> yeah
<geotec> it gots all its rules and staff goes it way to the kernel package .. ok tnx i'll have a look
<geotec> we should be more precise on arm architectures.. there are so many differences oabi legacy abi eabi and now hard eabi
<ogra_> ubuntu only supports one :)
<LetoThe2nd> "one architecture to run them all" :P
<ogra_> (well, there is technically a rotting armv5 port in the archive nobody uses ... but thats not officially supported)
<geotec> LetoThe2nd: thaz my problem, i am working with an arm binary which is linked to  2.3.2 glibc
<geotec> but my kernel is armel and has no old eabi supporto
<geotec> o_O this is drivin'me crazy
<LetoThe2nd> geotec: i still do not see the problem. enable OABI and recompile the kernel.
<geotec> yeah trying to do that, i am working on your tip
<geotec> dpkg-buildpackage -b -aarmhf (this armhf toolchaing frightens me .. still gonna give it a try)
<geotec> toolchain* sorry for the tuple errors
<LetoThe2nd> well what ubuntu are you running?
<LetoThe2nd> if you're running a hf one, better stick to it. if not, then... not.
<infinity> geotec: I'd suggest that if you're trying to make OABI binaries work, there's probably something going fundamentally wrong in your life, and you might want to reexamine the choices that led here. :P
<ogra_> lol
<infinity> geotec: (Also, OABI support will likely drop out of the kernel very soon, we've already torn it out of glibc)
 * ogra_ curses this tablet
<ogra_> it definitely loads the kernel
<LetoThe2nd> ogra_: shamanic curse?
<ogra_> (the LCD brightens up if the kernel initializes it)
<ogra_> but all my kernels dont seem to get thruh to booting a rootfs
<infinity> ogra_: I'm guessing you can't pop the back off and slap a JTAG in?
<infinity> Pretty hard to debug early kernel failures without some sort of serial love. :/
<ogra_> infinity, well, i just know that stgraber broke his display when opening his device ....
<ogra_> i dont really want to do that, the HW is fragile enough
<infinity> Get stgraber to send you his broken one to attach a JTAG to? ;)
<ogra_> infinity, well, i did it on the ac100 and succeeded
<GrueMaster> Does the device enable any serial ports on the host when usb is plugged in?
<ogra_> its not rocket science, just a matter of luck and time
<stgraber> infinity, ogra_: you can actually get a serial port on the emmc connector, the problem is that it's the same port you're booting from :)
<infinity> GrueMaster: If it did, that would almost certainly be a kernel driver that does that kind of magic, not firmware, so it would be useless for debugging the kernel itself.
<ogra_> stgraber, yeah, i'm experimenting with g_serial compiled in
<GrueMaster> infinity: Blaze had that feature w/o kernel booting.
<infinity> stgraber: Oh, that's a special "design".
<LetoThe2nd> sounds like that thing is totally braindead. apart from the fact that they obviously have been forced to admit right on their webpage that hdmi out is disfunctional.
<ogra_> GrueMaster, yeah, TI is lovely, isnt it :)
<infinity> GrueMaster: Blaze was also wildly overengineered for, like, engineers.  I've never seen a consumer device nearly as cool.
<geotec> infinity: i need to run an old arm binary linked against glibc <=2.3.2
<ogra_> infinity, well, the kernel uses some kind of pre DT devicetree feature, you can re-route any HW you like in a textfile :)
<infinity> geotec: Yeah, see above about "poor life decisions". :P
<infinity> geotec: Seriously, why would one need to do such a thing?
<geotec> cauz the arm binary is worth one year work?
<infinity> geotec: (But sure, if you do need to, and there's no way around it, recompiling a kernel with OABI flipped on and running an ancient Debian chroot seems "sane")
<ogra_> sadly the only documentation for this file format i can find is a chinese PDF :)
<ogra_> though i already found out how to switch displays etc
<geotec> infinity: what i am doing actually
<geotec> ;)
<infinity> geotec: It's a binary you have no source to, and no one knows where it came from? :/
<ogra_> (which doesnt help if the kernel doesnt make any use of fbcon)
<geotec> i need a kernel with old eabi support to run a etch chroot :D inside an arm device
<infinity> geotec: It's not "old eabi", just "old abi".  EABI was what replaced OABI.
<infinity> (Just nitpicking)
<geotec> otherwize i am doomed, what other choice do i have? Kill who came before me for choosing closed binaries from the heck, out of the world?
<ogra_> old eabi is probably the ganddad of both of them :)
<LetoThe2nd> "never touch a running system"? what kept netware alive?
<infinity> geotec: Or find something else that does the job.  Or find the people who produced the original binary?
<geotec> yeah right. Kinda stole the binary ;s
<geotec> not really stole, but almost
 * infinity covers his ears.
<infinity> LA LA LA CAN'T HEAR YOU.
<infinity> GOING AWAY NOW.
<geotec> lol
 * LetoThe2nd hands infinity some iron maiden cds
<LetoThe2nd> anyways, time to leave ;)
 * geotec wonders what was that thing about 'poor life decisions'.. :S
<geotec> you know, steal is something very strange to define on the web. Is getting something sincerly offered, you should not take a steal? Is like leaving donuts to indians saying: keep it there for me, i'll be back in a min
<geotec> whell i am morally way below indians... i admit
<geotec> for loggers: dont worry is just an update to an embedded device, which included this binary. They do not let the package without their hardware. I just grabbed the update and took what i needed
 * geotec wonders where is everyone.. o_O 
<ogra_> oha
<ogra_> stgraber, ...
<ogra_> booting off USB key works flawless
<ogra_> i even have a mouse pinter now
<ogra_> using my panda USB key
<stgraber> oh, I never tried usb boot ;)
<ogra_> me neither, but it was clear the the kernel comes up fine
<GrueMaster> For which platform, zatab?
<ogra_> so it could only be a panic or issues mounting the rootfs
<ogra_> yes
<stgraber> ok, so the problem is that booting from emmc is that the kernel can't find the rootfs...
<ogra_> apparently, i now have a runningg system so i can start inspecing that part :)
<GrueMaster> sweet.
<stgraber> nice!
 * ogra_ goes to find an usb hub so i can attach a kbd
<ogra_> hmm, and i better create an .xsession file so that it doesnt try to boot into unity all the time :)
<stgraber> ogra_: once you figure out the right kernel config to get emmc boot, can you try and add that to the script (maybe create a zatab branch on LP with the needed kernel/uboot/script.bin/...)?
<ogra_> stgraber, sure
<GrueMaster> But unity works everywhere, right?
<GrueMaster> :P
<ogra_> bah
<ogra_> adding a hub doesnt work :/(
<GrueMaster> You probably need a usb gadget host cable.
<ogra_> yes, the device only has micro USB ports
<ogra_> (read: i'm already using one)
<GrueMaster> Kernel probably not configured for it.  I know it kept going out of cycle on omap/omap4 images.
<ogra_> https://plus.google.com/107109423598372241322/posts
<ogra_> dunno if i have shared it the right way
 * ogra_ isnt such a big g+ user
<stgraber> ogra_: "Oliver hasn't shared anything with you."
<ogra_> heck, how do i just publish something on g+ ?
<ogra_> unrestircted etc
<stgraber> ogra_: you need to make sure it's shared with "public"
<ogra_> if i click share i can only select groups or individuals
<ogra_> ah, found it
<ogra_> intuitive is something else though
<ogra_> stgraber, try again
<stgraber> yay, login screen on a tablet!
<stgraber> highvoltage: ^
<ogra_> right
<ogra_> no touch yet
<ogra_> and i cant attach a uhub, i think that draws to much power
<ogra_> so no mouse/kbd yet
<ogra_> bah and now DPMS kicked in
<stgraber> getting it to connect to wifi shouldn't be too difficult
<ogra_> oh, indeed, i was just wondering why it didnt
<ogra_> i should probably copy the modules onto the panda image :)
<stgraber> ajmitch managed to get wifi working pretty easily
<ogra_> well, i bet he had modules ;)
<stgraber> yeah :)
<ogra_> hmm, intresting, doesnt finish booting with the modules in place
 * ogra_ removes them again
<ogra_> heh
<ogra_> boots fine
<stgraber> that's odd
<ogra_> well, some module or some firmware being evil here
<ogra_> ah, awesome, my USB 1.1 hub seems to work
<ogra_> hmm, or not
<ogra_> seems it goes into constant reboots now
<GrueMaster> Maybe it needs some QA?
<ogra_> no, power
<ogra_> i found a powered hub, lets see
<ogra_> yeah, mouse and kbd
<ogra_> and you can actually use ctrl-alt+t even on non GL systems to get a terminal up ... great
<ogra_> aha !
<ogra_> init: failed to open system console
<ogra_> all over dmesg
<ogra_> stgraber, insmodding the wlan driver gives me a hard hang
<ogra_> :/
<ogra_> so that device might have changed between pre-prod and today
<ogra_> next i'll try the fbcon module
<ogra_> ugh, these modules are also out of date
<ogra_> sigh
<ogra_> no woder wlan hangs it
<highvoltage> stgraber: omg
<ogra_> yeah, i know, i need to clean my desk
<ogra_> :)
<highvoltage> heh
<ogra_> oh cooool !
<ogra_> pressing the power button actually gets me a shutdown dialog, nice
<highvoltage> stgraber: I suddenly find it weird that we never considered trying USB
<stgraber> highvoltage: I don't have usb sticks
<ogra_> well, i dont think its actually USB vs MMC
<ogra_> i guess there is really something weird with the modules
<highvoltage> stgraber: yeah but they're $4 across the street :)
<ogra_> ok,. freshly built modules ...
 * ogra_ starts over
<ogra_> hmm, hangs again ...
<ogra_> even though i should have the matching symbols now
<ogra_> thats wried
<ogra_> hmm, unbelivable
<ogra_> ok, so its definitely fbcon that kills it
<geotec> arm-linux-ld: unrecognized option '-Wl,-Bsymbolic-functions' .. this is tricky :S
<TypoNAM> tried removing the comma ,  I don't think its suppose to be there
<geotec> i think is a bug cauz ld shouldnt be passed -Wl
<geotec> gcc is
<TypoNAM> hmmm, based off of some googling it should be -Wl,-B,symbolic-functions  so needs another comma ;)
<ogra_> hah, it helps to also disable android network crap isf you want network :P
<ogra_> silly stuff
<ogra_> grumble
<ogra_> so my /e/n/i network config doesnt get picked up and NM doesnt work in lightdm
<highvoltage> still on the zatab ogra_?
<ogra_> ogra@zatab:~$ uname -a
<ogra_> Linux zatab 3.0.38+ #29 PREEMPT Thu Sep 20 21:11:35 CEST 2012 armv7l armv7l armv7l GNU/Linux
<ogra_> ogra@zatab:~$
<ogra_> ;)
<ogra_> got ssh :)
<ajmitch> ogra_: so you're making progress with yours? I'd love to see what's different & work out why mine booted so easily :)
<ogra_> stgraber, hmm, i thought the a10 was a dual core
<ogra_> i dont see any second core here
<ogra_> oh, and i only have 400M
<ogra_> hmm, no, 325M
<ogra_> and a constant system load of 3.00
<ogra_> uh
<ogra_> bad plymouth
<stgraber> ogra_: nope, a10 isn't dual-core, it's a single core Cortex A8
<ogra_> wow, its pretty speedy for that
<stgraber> yeah, it's surprisingly good for an a8
<infinity> Is it remarkably speedier than, say, an mx53 (also a single-core A8)?
<ogra_> dunno
<ogra_> i have never touched an mx53
<infinity> Ahh.  Well, they're pretty speedy for what they are. :P
<ogra_> it feels a lot speedier than an XM
<infinity> And my guess is that the A10 is just a stock design from ARM, I somehow doubt that, at that pricepoint, they're employing brilliant engineers to tweak it.
<infinity> (Or it could be a relicensed part from another ARM licensee, like Freescale, just to confuse matters more)
<NekoXP> infinity, it's not speedier than an MX53.. except it's easy to find an A10 1.2GHz, you have to special order 1.2GHz MX53
<ogra_> well, no idea, it comes from deepeds china
<infinity> NekoXP: Indeed, getting parts out of Freescale is vaguely like pulling teeth.
<ogra_> might have stolen designs at fsl or developed something themselves
<NekoXP> it's also definitely not even close to i.MX or OMAP. An ARM reference design with some IP cores they generated themselves seems like the best bet, but a really fast turnaround and very little "optimization"
<NekoXP> as far as the docs I've seen it's about as far from i.MX as you can get, either they randomly changed every register or the IP is just different
<infinity> Heh.
<infinity> Yeah, I've not looked at one at all.
<ogra_> ogra@zatab:~$ cat /proc/meminfo |grep MemTotal
<ogra_> MemTotal:         331520 kB
<ogra_> thats definitely not right
<infinity> Though, I did say "relicensed from some licensee 'like Freescale'", I didn't imply it would have been Freescale.  Tons of people design A8-alike parts.
<NekoXP> a lot of IP comes out of China though. There's probably some dirty little video codec supplier around there that gave them a video decoder.. the display unit is a very reasonable and boring design.
<infinity> Just seems unlikely that, if pushing for volume and low cost, they'd employ any in-house engineering to reinvent any wheels.
<ogra_> infinity, its china, why would they relicense, they just take it :)
<infinity> ogra_: That only works as long as they don't want to sell into IP-whiney markets (like Europe and North America).
<ogra_> lol
<infinity> ogra_: If their goal was world domination, they have to play by our bizarre rules.
<ogra_> well, go to fairs in europe and find all the gucci and rolex made in china
<infinity> Yeahp, and Gucci tried to shut them down as they pop up.
<ogra_> didnt they even copy a complete BMW once ?
<NekoXP> Gucci probably makes all their stuff in china anyway
<infinity> But most of them are much harder to find than AllWinner, who's made themselves a large target.
<infinity> So, here's hoping they're playing nicely.
<ogra_> yeah, i'm indeed not serious here :)
<NekoXP> it's no wonder all that stuff gets Shanzhai treatment
<ogra_> anyway, enough tabletting for a day ...
 * ogra_ wonders off to the TV
<infinity> Any day with tabletting is a bad day, IMO.
<highvoltage> thanks for doing it ogra_
<infinity> I'm still so not the target market for those things.
<highvoltage> ogra_: so does booting from USB make a difference?
<ogra_> highvoltage, well, now that i have it, i want to use it :)
 * infinity goes back to arguing with clang.
<NekoXP> it could be that the IP in use is some standard FPGA library stuff. Some of it looks a lot like the things you'd find on opensource websites for Altera or Xilinx FPGAs
<ogra_> highvoltage, yeah, still cant boot from MMC
<infinity> I swear, I develop a new brain bleed every time I dive into this codebase.
<infinity> And it boggled the mind every time someone else claims it's "clean and well-written" or, my favourite "has great ARM support".
<ajmitch> ogra_: I didn't think mine was too different (got it from zareason at UDS), as it boots from MMC just fine
<infinity> s/boggled/boggles/
<ajmitch> infinity: their definition of 'great' might be that it compiles sometimes
<highvoltage> ajmitch: yeah there's definitely some difference between the two
<ogra_> ajmitch, well, might be pre-production
<infinity> ajmitch: Yeah, well.  There are some things about the llvm architecture that are pretty neat, and if we could go back in time a few decades, GCC could learn some lessons.
<infinity> ajmitch: But overall, the project is painful to work with, especially with their haphazard support for multiple architectures.
<infinity> And every small mistake llvm makes is magnified about four thousand times by clang's clunky interface on top.
<infinity> BUT I'M NOT BITTER.
<infinity> llvm as a backend to gcc might actually be easier to support than clang is.
<ajmitch> gcc's architecture has been driven by the fsf philosophy, not always in a good way
<infinity> Nope, GCC has a lot of warts, and a lot of things that are almost literally unfixable at this point.
<infinity> But llvm's hardly a utopia of software design either.
<XorA|gone> you should know by now open source devs just jump from cool eTLA to cool eTLA :-D
<infinity> Whatever.  Perl 4 lyfe, yo.
<TypoNAM> lol
<infinity> Anyhow.  Let's see if this hacked-up clang actually (A) builds, and (B) produces binaries that look kinda like armhf ones.
 * infinity crosses his fingers.
<micahg> infinity: abiword keeps aborting on armel
<infinity> micahg: Yes, this is known.  Stop giving it back. :P
<micahg> infinity: I figured I wasn't running into the wall fast enough :P
<micahg> any idea when things might return to normalish?
<infinity> Not sure.  It's a catch-22 where hacking around this breaks other things.
<infinity> And fixing it properly is real effort.
<David7> Has anyone here built the kernel.org kernel using Ubuntu arm-linux-gnueabihf-gcc?
#ubuntu-arm 2012-09-21
<tansell> Hi guys, are there instructions for porting ubuntu arm to another arm based system? I know my device is supported by recent kernels and works with debian but I'd strongly prefer to use ubuntu
<LetoThe2nd> tansell: well if your system is armv7+x, basically just create a fitting kernel+initrd and use the ubuntu userland from there on as a first start
<Heradon> good morning
<Heradon> i need a little help, to flash my gooseberry ;) i need to use ubuntu ^^
<lilstevie> gooseberry?
<Heradon> yes it is a Allwinner A10 board
<lilstevie> yeah, just looked it up
<Heradon> but the newer version of the board does not boot from MMC
<Heradon> i think i need a newer uboot
<Heradon> but i dont know :(
<LetoThe2nd> if you "don't" know, better do not touch the uboot as you are prone to brick the thing.
<Heradon> good but i need a ubuntu on this board ^^
<LetoThe2nd> well i need 100kâ¬, but the world does not care either.
<LetoThe2nd> if you a) do not know what you are doing b) risk bricking the board c) have no means to unbrick it - do not do it.
<Heradon> good, i can do this board into trash
<Heradon> android on my TV is ....
<LetoThe2nd> sorry, but do not complain if you bought things that are not made for endusers, if you are an enduser.
<LetoThe2nd> plus, their documentation is totally poor. or should i say "cheap"?
<Heradon> the doku is crap
<Heradon> I bought the board as ubuntu was still running from the MMC, but the delivery has been delayed and it hies then suddenly it will not boot from the MMC and now I'm looking for someone who can help me
<LetoThe2nd> well if u-.boot is actually the reason, then the standard procedure is: get source, find bug, patch it, compile, flash
<Heradon> need for flash anyone other hardware of the USB?
<LetoThe2nd> but if even the manufacturer is to lazy/dumb to do that properly, and you are a mere enduser, then - well, you're whacked.
<LetoThe2nd> usually u-boot can re-flash itself, unless it is bricked. so you need uboot access.
<Heradon> the uboot access i become only with UART right?
<LetoThe2nd> and you need a memory map, or the knowledge to read/interpret what uboot is telling you.
<LetoThe2nd> well there uarts over usb too.
<LetoThe2nd> these are things that you have to know if you want to tinker with something
<Heradon> good i have no uart.. perfect
<Heradon> i sell my gooseberry and buy a odroid-x
<LetoThe2nd> do not complain to us if you have bought literally "cheap" hardware that you do not understand ;)
<LetoThe2nd> they even say "only android ATM", which reads as "anything else only if you really know your stuff"
<Heradon> i have 3 raspis, no problem i compile my own system. But the goosebery is ARG
<LetoThe2nd> i really doubt that you compiled ubuntu for raspi ;)
<Heradon> no i compile archlinux for raspi :>
<LetoThe2nd> ah yes. *impressed*
<Heradon> on my first computer i have gentoo, on my second pc ubuntu ^^ laptop lubuntu and netbook archlinux :O
<LetoThe2nd> sorry to burst your bubble, but running neither gentoo nor archlinux makes you automatically someone who understands compiling or the inner workings. it just makes you someone who either is successfull in reading or experimenting.
<LetoThe2nd> so coming back to the initial topic: running ubuntu on thath thing is probably doable. but judging from the pretty much non-existent documentation/source from the manufacturer, it boils down to considerable barin/time effort, and not some 1-2-3 type this, click here guide.
<Heradon> i know, i work on the board since 2 weeks
<LetoThe2nd> hence, if you're willing to go that route - provide information as precise as possible, and people will probably try to help and give pointers. but the most of the work will certainly be up to you.
<Heradon> i know
<LetoThe2nd> (if you're "working on" something since 2 weeks and do not even know how to access u-boot,.... well thats no good sign.)
<Heradon> stop stop
<Heradon> you are german? ^^
<LetoThe2nd> i am, but i will neither do query support nor change to german here as the official channel language is english.
<Heradon> ok, no problem but my english is very bad ^^ this is my first touch with uboot. i read the time dokumentations and boards on internet
<LetoThe2nd> so back again: topic 1) for you is: get u-boot access. if you have that, come back and present the informations that one can get from that.
<Heradon> can you give me a link to buy a uart interface?
<LetoThe2nd> no, because i have absolutely no clue what you need. you have to find out where the manufacture has wired the A10s uart to.
<Heradon> i sell the board
<LetoThe2nd> if it comes out on a header, or a sub-d, or maybe it even is an additional usb endpoint.
<LetoThe2nd> like i said: you have to invest your own brain power.
<Heradon> i have an uboot log
<LetoThe2nd> coming from where? if it magically appears on some sd card, that provides no information.
<Heradon> https://gist.github.com/3364042 here an bootup
<LetoThe2nd> like i said: how did you get that log?
<Heradon> google ^^
<LetoThe2nd> meh.
<Heradon> i have all informations from google
<LetoThe2nd> sorry, but this is becoming totally ridiculous.
<LetoThe2nd> sell the board.
<Heradon> ich hau mit dem hammer auf den scheissdreck -.-
<lilstevie> most A10 devices are hard to brick fwiw cause of fex/livesuite
<LetoThe2nd> lilstevie: doesn't make them easier to flash if you do not even know how to access the console ;)
<lilstevie> heh
<lilstevie> LetoThe2nd, fex/livesuite is over usb
<Heradon> i have flashed 4 times alternatives androids to the board
<lilstevie> bootrom recovery like nvflash
<lilstevie> :p
<LetoThe2nd> i already stated several times that finding out how to access u-boot must be topic #1. i really am getting tired a bit.
<lilstevie> but yes
<lilstevie> if you cannot interact with u-boot there is no point trying to debug it
<lilstevie> "[
<lilstevie> :p
<LetoThe2nd> and repeatedly suggesting us that you have knowledge because you "flashed something" or "compiled something", but then asking very basic questions is also... lets say not very reassuring that we are spending effort for good here.
<LetoThe2nd> </$.02>
<Heradon> so das board bootet nie wieder
<RoyK> LetoThe2nd++
<tirumal> Hi, new to this forum. Is screen rotation possible using SGX pvr driver for ubuntu 12.04 on pandaboard(Rev A4)?
<tirumal> I have tried with ubuntu 11.04 by changing the bootargs parameters in boot.scr and it didn't work
<sveinse> As previously discussed, plymouth is unable to show splash and show console on serial terminal simultaneously. This is something I must fix. I can do it in one of two ways: 1) I can set plymouth to textmode and implement my own framebuffer displayer 2) I can alter plymouth to show framebuffer splash _and_ show text on serial console. Which do you think is less work and most trivial?
<tirumal> I want to rotate my screen by 90 degree. Is it possible using omapdrm driver?
<ogra_> tirumal, did you try xrandr ?
<tirumal> ogra_: No i didn't try. How can I do it with xrandr?
<ogra_> sveinse, hard to tell, and definitely nothing upstream will take either way, they consider a system where the console= arg appears a system that doesnt want a splash, i guess there is some code to catch that arg that parses the dmclie, did you try to just comment that ?
<ogra_> s/dmclie/cmdline/
<sveinse> ogra_, I can select between textmode and a gfx theme with the second console= option. However the gfx theme supresses console output, which is the bad thing here
<ogra_> well, find the code caring for console= and comment it ;)
<sveinse> So perhaps it's possible to write a gfx theme which accepts the console texts and diverts it to the serial console
<ogra_> that should give you  2)
<sveinse> I notice I have to specify console= twice for it to set plymouth. why is that? the first is for the kernel, the second for ply?
<ogra_> usually the first is for kernel and the second for userspace
<ogra_> it should switch to the scond once some kind of rootfs is available
<ogra_> (i.e. an initrd)
<sveinse> if using one console=ttyO2, what does ply consider console to be (since kernel now uses console ttyO2)? /dev/fb0? /dev/tty1 perhaps
<sveinse> (i.e. it's userspace which sets up /dev/console, not kernel, right)
<ogra_> ply simply shuts down in that case
<ogra_> well, setting up /dev/console was theoretically done in userspace in the past. yeah, the kernel just attaches the default console to it once there is a /dev ... though nowadays we use devtmpfs everywhere which the kernel creaates ... i guess that area got blurry due to that
<sveinse> No it does not. We're run on this for a while. We have one console=ttyO2 in commandline, the kernel boots and output kernel output on serial port, and then it drops silent when displaying png on fb0.
<ogra_> well, i should have said it shuts down all display actions
<sveinse> The "only" problem is that it drops slient between kernel and getty
<ogra_> it still provides that dbus like interface for apps (encryption etc) but doesnt provide any frontend anymore
<sveinse> yes. to be honest, since our device is very specialized, we'd hoped on purging plymouth alltogether. But its very interwowen with everything
<sveinse> ..in an attempt to save boottime
<ogra_> well, you need libplymouth at least
<sveinse> yes, I've accepted that fact that plymouth is unremovable, so thus the effort to get the console output to the serialport
<ogra_> did you consider using something like feh from the initrd to just throw a static picture on the framebuffer ?
<ogra_> (or any other minimal image viewer that can talk to fb0)
<ogra_> err, fbi, not feh
<ogra_> (no idea how much that bloats your initrd in size though)
<ogra_> ogra@zatab:~$ ls -l /dev/|grep mmc
<ogra_> ogra@zatab:~$
<ogra_> hmm, that might be the reason why i cant boot that thing from mmc
<sveinse> ogra_: Yes. But fbi is large and bloated, so I've stripped down fbi to the bare metal to do exactly that. However, I can't rid myself of dependency on libm (via libpng), so it's larger that I'd like.
<sveinse> But I notice now that plymouth in initramfs is also depending on libm, so its already there I guess
<ogra_> yep
<ogra_> well, it might go away if you remove the graphical themes
<ogra_> not sure plymouoth itself will pull it into initrd for a text theme
<sveinse> i'll figure it out. In all cases I need a hook for my mini-fbi anyways, so I will pull in libm from there
<tirumal> ogra_: thanx for the hint, it works well on desktop pc but not my target platform with omap4
<ogra_> well, it should, at least in quantal where we install the pvr driver by default
<tirumal> when i try with command: xrandr -o left it fails with X Error : Bad Match
<ogra_> xrandr itself gives oyu proper ouput (if you run it without any options) ?
<tirumal> ogra_ : it says: HDMI-1 is connected with 1280x1024 with 60 freq
<ogra_> k, so xrandr support is generally working
<tirumal> yes
<ogra_> any more info in Xorg.0.lo ?
<ogra_> *log
<tirumal> one more interesting  thing: I have tried the same command on variscite omap4 board, where it works
<ndec> tirumal: with the same kernel?
<ndec> rotation support was added lately, but it could be flaky at times...
<tirumal> where I have patched Mr. Clarks drm/omap: add rotation properties
<tirumal> ndec: no with different kernel. It works with 3.4.0-1486-omap4 kernel
<ndec> yeah, we did some bug fixes/rework for rotation, so that might explain.
<ndec> i would generally recommend to stick to 3.4 kernel for OMAP4, this is what we (TI) support.
<tirumal> ndec: to be more clear on this rotation issue: I have understood that with SGX pvr driver, one should be able to rotate the screen by 0, 90, 180, 270 + graphical acceleration
<tirumal> ndec: Is that pvr driver already integrated in 3.4 TI kernel?
<tirumal> ndec: by providing kernel boot with omapfb.rotation=1 for 90 degree rotation, what i need
<ogra_> stgraber, highvoltage, so we have a massive issue with the mmc controller in our kernel for the zatab ... and we seem to be missing this touchscreen driver https://groups.google.com/forum/#!topic/android-x86/vEKSSKdUfi8
<ndec> tirumal: yes, we have rotation support with GFX with 3.4 kernel. I don't know if it's working or not with 12.10 kernel...
<ndec> omapfb has been deprecated.
<ogra_> the -omap xserver should support it even withjout pvr installed afaik
<ndec> ogra_: yes, this is correct.
<ndec> you don't need PVR for xrandr (resize nor rotate)
<ogra_> but that indeed needs 12.10
<ogra_> (i dont think 12.04 even had that recent -omap xserver package)
<ndec> right, it didn't
<ndec> ogra_: what's the pkg src name for -omap?
<ndec> ok, found...https://launchpad.net/ubuntu/+source/xf86-video-omap
<ogra_> xf86-video-omap
<ogra_> yeah
<ogra_> before quantal that was just xfbdev with some sauce added i think
<ndec> ogra_: we seem to have an extra patch in our -omap (    - xrandr-rotation.patch). not sure if you have that one.
<ogra_> i think we have the latest upstream and would trust rob to keep that updated
<ndec> i don't think rotation is upstream
<tirumal> ndec, ogra_ thanx for the impt info regarding pvr & rotation features
<ndec> np
<tirumal> we are using a Phytec omap4 module, which has Pengutronix distribution with kernel 3.3 and that explains the behaviour
<highvoltage> ogra_: ah. that's a bummer. I'll try a 3.4 kernel tonight if you haven't beaten me to it yet
<tirumal> I am intrested to know: where would be the pvr driver located so that I can integrate it on my target
<deffrag> Hi! I have a code prepared and compiled on x86_64 architecture which I moved to and compiled on ARM(Beagleboard XM). And, it worked without errors exactly as it would on x86_64. Same commands were executed to compile and run. I'd like to know what made it happend, how does it work?
<stgraber> ogra_: but didn't you manage to boot from mmc once?
<hrw> deffrag: pure magic
<ndec> ;-)
<deffrag> hrw: Bah.
<deffrag> Isn't it related to cross-compilation or such? gcc for arm configured for the platform ...
<hrw> deffrag: you compiled natively
<hrw> deffrag: cross is when you are on HOST (arch1) compiling for TARGET (arch2)
<hrw> there is also canadian cross when you are on BUILD (arch1) compiling compiler for HOST (arch2) to build for TARGET (arch3) - but thats crazy
 * hrw -> lunch
<deffrag> Ok, natively compiled. Compiled on the architecture  running. So, what is making that possible? What is the difference made in gcc for arm
<deffrag> Otherwise, could anyone link me to some resource for the same?
<ogra_> stgraber, yeah, but not with this kernel, i tried random uImages from different prebuilt images
<ogra_> hmm, seems there is also a sun4i-ts driver, i wonder if that one would work
<ogra_> seems the other one from above needs a binary blob
<suihkulokki> allwinner hacking going on?
<ogra_> yep
<hrw> deffrag: it is same gcc
<hrw> deffrag: gcc supports wide range of archs
<ogra_> highvoltage, there is a 3.4 tree ?
<highvoltage> ogra_: ah no, there isn't :-/
<ogra_> sad, you just had me hoping :)
<ogra_> aha
<ogra_> https://github.com/zareason/linux-allwinner/commit/c5ce10353d48a704540cd8fa0c5d2e90e380aaf8
<ogra_> seems the zareason tree has the touchscreen driver
<highvoltage> ogra_: how's the transformer doing these days? is there a tablet ubuntu is known to run well on?
<ogra_> no idea, my transformer only runs android :)
<deffrag> hrw: Ok, thanks.
<deffrag> Secondly, how can I use/enable DSP? I followed - http://elinux.org/BeagleBoardUbuntu#gst-dsp - but it says module bridgedriver not found. I searched for its .ko file, its not present.
<ogra_> highvoltage, asl lilstevie
<ogra_> *ask even
<highvoltage> good, because I wasn't going to ask him a/s/l.
<lilstevie> thats good cause I wasn't going to respond :p
<ogra_> i have the slight feeling that https://github.com/zareason/linux-allwinner might be the better suited kernel tree
<highvoltage> lilstevie: do you run ubuntu on your transformer?
<lilstevie> highvoltage, absolutely
<lilstevie> transformer or transformer prime
<highvoltage> I guess transformer prime, ideally
<highvoltage> does it run ok?
<lilstevie> it runs fine, just not really prime time ready
<lilstevie> still things that don't work as expected
<ogra_> highvoltage, stgraber ... hmmm ... i guess someone should package http://linux-sunxi.org/Mali400#Mali-400_X11_DRI2_drivers
<ogra_> http://limadriver.org/ doesnt seem to be ready yet
<stgraber> yeah, hopefully we can get a kernel and the mali driver in 13.04, assuming there's no redistribution problems with the blob
<ogra_> well, linaro seems to provide allwinner images with it included
<ogra_> or hwpacks
<ogra_> so it must be redistributable i guess
<ogra_> if we want images in 13.04 we should start building stuff in ppas (in fact i'd like 12.10 images even if the are handrolled, but close to what 13.04 will have)
<ogra_> wow, my fingers always want to type 13.03 :)
<highvoltage> hopefully it will want to follow the same pattern for 14.04 :)
<highvoltage> (maybe by then you're fingers will have been trained to type 14.05 by then)
<ogra_> who cares about 14.04 ...
<ogra_> we'll all be old an grey by then
<ogra_> :)
<highvoltage> I'll have to copy and paste that to quote in a few months ;)
<ogra_> heh
<stgraber> yeah, getting what's needed in a PPA would be good, for Edubuntu we'll probably just grab our armhf (omap4) squashfs, remove the kernel, install the PPA, pull the new kernel and install the X driver, then do a bit of repacking to work on the mmc. Writing a script doing that should be trivial once we have the bits in place.
<ogra_> well, i would actually propose a proper preinstalled image
<ogra_> for later we can have live or so to do an actual install to flash if people want it
<tirumal> ndec,ogra_: Regarding the pvr driver for omap4. where would be pvr driver located? I am asking  this because later I have to  integrate it in my distribution and use graphics acceleration
<ogra_> tirumal, well, pvr is usually only working with a certain kernel version ...
<ogra_> so you need both
<ogra_> i would recommend the versions from quantal here
<tirumal> ogra_:Agree but at the end I want to use them on my target omap4 platform, which uses pengutronix dist
<ogra_> https://launchpad.net/ubuntu/+source/pvr-omap4/ has the driver packages
<ogra_> the omap4 kernel is on the kernel.ubuntu.com git ... look for ppisati's name there :)
<tirumal> ogra_: ok got it
<ogra_> rsalveti, hackin on a zatab here, do you know if the binary blobs for mali are redistributable (and coudl we perhaps get he xserver that linaro seems to have in a ppa into the archive) ?
<rsalveti> ogra_: I think so, we just need to test first if the xorg driver we have works with whatever binary you're trying out
<ogra_> great
<ogra_> (just dipping my toe in the water here to find out about all the bits and pieces)
<deffrag> Hi! Why in the image used - http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-server-armhf+omap.img.gz - for Beagleboard xm, it is not possible to have DSP working? Why 12.04 has no dsp bridge?
<deffrag> Hi infinity
<GrueMaster> deffrag: Are you referring to audio?
<GrueMaster> See bug 925094 for some possible solutions.
<ubot2> Launchpad bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed] https://launchpad.net/bugs/925094
<deffrag> GrueMaster: Hi! No, I've sound working. I would like to attempt something related to image processing on this platform for which DSP are good. I'm curious how would one use them. For http://elinux.org/BeagleBoardUbuntu#gst-dsp it assumes using rcn image. When I tried those instructions, it gave bridgedriver missing. I'm not sure what is the proper method of engaging DSP
<GrueMaster> Ah.  Sorry, can't help there.
#ubuntu-arm 2012-09-22
<denisw> hi
<denisw> i would like to install ubuntu arm on a compulab trimslice, has somebody done this before?
<denisw> (nvidia tegra 2)
<omac> Good day :)  I have an advent vega that I installed ubuntu1204fullimage using linuxonandroid app.  very cool.  openssh works, unity takes 10-20 minutes to show up and the colors aren't displaying correctly.
<omac> when I do lsusb nothing gets listed.  It's a tricky tablet to play with because in order to use a usb keyboard/mouse with it I needed to use usb host mode through the shuttle tools available only in the VEGACOMB3.2.  The other cyanogenmod latest version for the advent vega doesn't have usb host-mode gui tools and the tricks about holding the back button while powering up didn't bring it up in host mode.  I have been flashing roms a lot on this
<omac> tablet as a result of this usb host mode issue.
<omac> Advent VEGA == P10AN01 == Viewsonic ViewPad 10
<omac> Advent VEGA requires a Type A to Type A USB cable to connect it to the computer.  Here is the one config file you need for the tablet to speak usb to ubuntu http://pastebin.com/VeMDKnja
<omac> Under windows, there is a similar file that needs to be used with the latest android dev kit's google usb driver.  Tweak it with the above config file and you're up and running in windows 7.
#ubuntu-arm 2012-09-23
<omac> rsalveti: good evening
<omac> i noticed the ubuntu full image available for arm uses the linaro stuff.
<infinity> omac: Uses "the linaro stuff"?
<omac> well from what I understand there is a linuxonandroid installer.  It refers to an ubuntu1204-v4-full.zip
<infinity> Oh, the linuxandroid stuff.  I thought you meant the official Ubuntu images.
<infinity> And was confused. :P
<omac> that zip when launched spews out information...I saw linaro mentioned in the boot messages
<infinity> Well, if "Linaro" was mentioned in the kernel version, that's because it's in our compiler version stamp.
<omac> infinity I have an advent vega and tried some different roms out there, but source for them is confusingly everywhere with different branches.
<omac> cyanogenmod's version for the vega seems broken because I can't get usb-host-mode working so that I can use a mouse and keyboard with it.
<omac> I have vegacomb3.2 installed, but it's a binary but it works and has shuttle gui tools to go into host mode.
<omac> the odd thing is once I boot up the ubuntu1204-v4-full.zip within it, when I do an lsusb in it, it doesn't list any devices.
<omac> infinity: you made a distinction about official ubuntu images.  They don't mention anything about advent vega.  ubuntu only mention a few other arm devices.
<lilstevie> omac, not every arm device out there is supported officially by ubuntu
<lilstevie> there are a few devices though that are supported by third parties
<omac> pandaboard and pi and some other cool stuff I've seen.
<omac> I don't own those yet though.  I would love to simply use what I have.  I thought owning an android device gave me digital liberties I was used to having with ubuntu.  I was wrong.
<lilstevie> I don't think the pi has an official image 0.o
<omac> pandaboard has a lot of stuff out there and you can build a cluster with those.  VERY COOL.
<ogra_> lilstevie, i doub even an inofficial one :)
<omac> I saw arm based ubuntu laptop available, but the image on it is ubuntu 10.10
<omac> pandaboards are running 12.04...that's an edge for these.
<omac> I currently can connect my Advent Vega with VegaComb3.2 Rom to my ubuntu Quantal Quetzal via usb and run/debug from eclipse ADT(android plugin), but I would have liked to see the ubuntu gui on the Advent Vega.  I have not succeeded in seeing Unity displayed on the Advent Vega yet.
<omac> any way for me to get ubuntu arm debug messages spewed back to my ubuntu quantal quetzal computer?
<omac> It would help me to understand why unity takes so long to boot up on the advent vega tablet.  The other concern is memory/cpu cycles.  android is still running while ubuntu is running.  I would love a way to simply halt the cpu cycles on the android side and place all the priority on the ubuntu side.
<ogra_> stgraber, highvoltage, just FYI i have proper console (after initrd) now on the zatab .... still no MMC and still only 350MB
<ogra_> (and still no touchscreen ... and wrt driver it looks pretty bad atm (proprietary blob apparently)
<ogra_> but with the initrd we can at least see if it fails mounting /
<stgraber> nice!
<ogra_> yay
 * ogra_ has plymouth fsck in front f him
<highvoltage> ogra_: how do I get it? do you have an image up somewhere?
<ogra_> so the trick is to build *all* display related parts as modules
<ogra_> as long as "disp" is a module it will init a framebuffer console
<ogra_> (do not compire fbcon, not even as a module)
<highvoltage> heh, and here I thought it's always less problematic to do it the other way around
<ogra_> indeed having it as a module you better want an initrd :)
<ogra_> i wonder if making the mmc stuff modular would fix that too :P
<stgraber> well, at least you could try to change load time options (assuming the mmc module has any)
<zenx> is anyone able to compile 3.5.0-211.18 for omap4 pandaboard?
<zenx> wow, lxde is so light it doesn't even come with a mouse cursor
<zenx> :D
#ubuntu-arm 2013-09-16
<snkt> hello
<IamTrying> http://beagleboard.org/Products/BeagleBoard-xM - I have tihs board. How can i install Ubuntu 13.10 kernel 3.11 on it?
<infinity> IamTrying: http://ports.ubuntu.com/ubuntu-ports/dists/saucy/main/installer-armhf/current/images/omap/netboot/boot.img-fb.gz
<infinity> IamTrying: Write that to an SD card, boot, and install.
<infinity> IamTrying: (Ideally, install to external media, like a USB hard drive)
<IamTrying> infinity, Can i just make the boot.img.fb.gz int my USB stick? and install it via USB ?
<infinity> IamTrying: Been a while since I played with one, but unless it has a burned in SPI that lets you slect a boot device, it almost certainly only boots from SD.
<infinity> IamTrying: So, you'll need an SD card both for the installer, and for the kernel/bootloader to live on in the final setup (same card, of course, the installer will reformat it).
<IamTrying> infinity, I have less trust in Flash card u know. They fail for long run. So was thinking to use USB Stick with higher speed.
<IamTrying> infinity, SD card i wanted to avoid if possible
<infinity> IamTrying: No, no.  You only have to BOOT from the SD card.  Like I said, you should INSTALL the system to an external USB device.
<IamTrying> OK - infinity
<infinity> IamTrying: The SD isn't likely to fail if you never write anything to it other than a bootloader and kernel once in a while.
<infinity> (Which will all happen automatically)
<IamTrying> OK - infinity, so i have one 16GB SD card and one 120GB USB Disk. Now i write the boot.img-fb.gz in my 16GB SD card? And then while install i choose 120GB USB stick right?
<infinity> IamTrying: Right.
<IamTrying> OK - Excellent, thank you so much infinity, will let you know after installation, have a nice day.
<infinity> IamTrying: Also, that -fb image is if you have a monitor and keyboard attached.  If you're doing it via a serial console, you want this instead:
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/saucy/main/installer-armhf/current/images/omap/netboot/boot.img-serial.gz
#ubuntu-arm 2013-09-18
<TempUser> Do you have any estimates on how many (relatively) of the software packages of Ubuntu 12.04 AMD64 are available also for the ARM version? For example, are JDK and Scala available for Ubunut on ARM?
<rbasak> TempUser: almost everything is available on ARM.
<TempUser> rbasak: Thanks. What is your impression of what is _not_ available?
 * ogra would say between 80-95% 
<rbasak> TempUser: mostly obscure packages that few people use. When I look at them, I generally don't recognise any of them.
<ogra> things that are hard to port ... like freepascal ... and packages depending on it for example
<ogra> they are usually the rare cornercase ones
<TempUser> Do you know where I can get a list of what packages are available?
<rbasak> TempUser: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/binary-armhf/Packages.gz
<rbasak> Also s/main/universe/
<k1l> TempUser: packages.ubuntu.com
<rbasak> k1l: unfortunately packages.u.c doesn't include arm for some reason
<ogra> k1l, doesnt have ports arches
<k1l> rbasak: you are right. i didnt look in which channel that question was raised.
<rbasak> TempUser: don't forget universe, otherwise you'll miss many packages
<k1l> but overall: what % do you think is available for arm from the x86 packages?
<rbasak> * ogra would say between 80-95%
<ogra> with a tendency to the higher value :)
<Tassadar> does that include nonfree?
<rbasak> I don't think a % is a fair representation anyway. It's the long tail. There are extremely few packages not covered that the majority care about.
<k1l> ok, i would have guessed 75%+
<ogra> yeah, as i said before most of them are corner cases
<rbasak> I don't use much nonfree. Flash is noticeably absent.
<ogra> stuff nobody regulary uses anyway
<ogra> right, binary stuff is indeed rare
<rbasak> Generally with nonfree ARM support is an exception. That's why free is awesome. Generally recompile and you're done.
<ogra> ++
<TempUser> (Thanks for answers)
<day> does ubuntu-arm has native/permanent samba support?
<infinity> day: Yes.  "ubuntu-arm" is just Ubuntu, it has all the same software, with the exception of a few x86-specific things.
<day> infinity: 'of a few x86...' thats why i wasnt sure :p
<day> im kinda tired of this android u cant do that you cant do this bullshit...
<infinity> day: When I say x86-specific, I mean it.  Like binary drivers and such.
<infinity> day: 99% of the Ubuntu archive is built for all the architectures we have.
<day> infinity: y i got it. I just thought that maybe they werent ported etc..
<day> infinity: sweet
<day> what exactly is the difference between ubuntu-arm and touch. the ui aside
<infinity> day: Well, the UI, and all the bits the UI depends on (Mir, Unity8, Qt5, etc).
<infinity> day: Ubuntu Touch can also be seen as a tech preview for where Ubuntu Desktop will be heading, as we plan to converge on Mir and Unity8 on all platforms $later... Just not yet.
<prpplague> infinity: anyone word on finding someone to take my money?
<day> infinity: thanks for helping me out
<day> gn8
<infinity> prpplague: Say, are you still in New Orleans?
<prpplague> yea, leaving in the morning
<infinity> prpplague: Coming to the thing tonight?
<prpplague> yea, planning to
<infinity> prpplague: Anyhow, we could meet downstairs and have this conversation in person. :P
<prpplague> ahh didin't realize you were here
<infinity> I am.
<infinity> Meet me by the LF registration desk in 5?  That's a pretty empty area.
<prpplague> yep will do
<prpplague> you mean 6?
<prpplague> hehe
<prpplague> heading down now
<prp_plague> infinity at the lf booth on the 3rd floor
#ubuntu-arm 2013-09-19
<Vanfanel> hi there
<Vanfanel> I'm trying to install Ubuntu Core on an OMAP board, following these instructions here:
<Vanfanel> http://www.omappedia.com/wiki/OMAP_Ubuntu_Core
<Vanfanel> what are the repositories to add for 13.04, please??
<Vanfanel> Hi, is the Pandaboard binary-based 3D system (EGL, GLES) supported on Ubuntu 13.x?
<ogra> yes, it should be installed and set up by default
<Vanfanel> ogra: and what about setting up the system from Ubuntu-core?
<Vanfanel> is it possible to setup 3D on ubuntu-core 13.x?
<ogra> ubuntu core isnt for endusers .... it is supposed ot be a base for image designers and the like (you can also abuse it as cheap chroot for building things)
<ogra> use the desktop install if you want working GLES out of the box
<Vanfanel> I have setup ubuntu-core already on 12.04 and could install TI's kernel and 3D support
<Vanfanel> so I'm up to the task... with the proper PPA
<Vanfanel> because I'm following this guide: http://www.omappedia.com/wiki/OMAP_Ubuntu_Core
<Vanfanel> and it seems impossible to add the PPA on 13.04
<Vanfanel> I also tried "add-apt-repository ppa:tiomap-dev/release"
<Vanfanel> but it only works on 12.04
<Vanfanel> So, how could I add the "binary" TI PPA on 13.x?
<Vanfanel> once I have that set up, I should be ready to go on with 13.x
<Vanfanel> If I asked an stupid question, please tell me also :D
<ogra> no, but you are using a totally unsupported and untested setup
<ogra> and the PPA will most likely break your install if you have working GLES now
<ogra> (the panda is dead beef since quite some time, the TI team that cares for it is gone ... the panda images in ubuntu are largely unmaintained)
<Vanfanel> ogra: thanks, I know I am on an unsupported setup
<Vanfanel> but I have GLES working on 12.04
<ogra> well, its rather unpredictable what will happen ...
<Vanfanel> (12.04 Ubuntu core)
<ogra> so i guess it means trial and error for you and keep the pieces if it breaks
<Vanfanel> yes, so I am trying but there seems to be no good way to do "add-apt-repository ppa:tiomap-dev/release" on 13.04
<Vanfanel> it only works on 12.04 systems
<Vanfanel> does that make any sense?
<ogra> yes
<Vanfanel> but... if 3D comes included on 13.04...
<Vanfanel> how comes the PPA cant be added?
<Vanfanel> is 13.04 an "ubuntu arm" thing without any TI's support?
<ogra> the PPA only has gstreamer codecs ... no GLES drivers ... the archive has GLES drivers that only work with the kernel in the archive (nobody wanted to port the 1700 patches to mainline for PVR support)
<ogra> if you use the PPA you get a kernel update ... that breaks the drivers in the archive
<ogra> (somewhere between these two bits appeared, TI shot down the mobile division including panda development)
<Vanfanel> sorry if I look a bit dumb, english is not my main language: does that mean that, with 13.04, there's no need for an external PPA and 3D support comes included with the default kernel??
<ogra> the 3D support didnt change between 12.04 and today
<ogra> it should still work the same as long as you only use the archive
<Vanfanel> ogra, what archive?
<ogra> ubuntu
<Vanfanel> ehm...
<Vanfanel> the default install image?
<ogra> yes
<Vanfanel> ogra: is there an special omap4 package containig /usr/lib/GL/gl.h or should I install the mesa dev package?
<ogra> no, you want the pvr driver
<ogra> use the desktop image ...
<ogra> i doubt anyone will remember off the top of his head what you need to do to set it up
<Vanfanel> the desktop image is unusably slow
<Vanfanel> and I don't need a desktop enviroment at all
<Vanfanel> ogra: It seems I don't need GL/gl.h after all :)
<ogra> just for building stuff
<ogra> and there indeed the mesa package should have all you need
<Vanfanel> I'm trying to compile a program that uses KMS+EGL, no need for desktop GL if well configured before compiling
#ubuntu-arm 2013-09-20
<fahadash> hello
<fahadash> Can I download Ubuntu for ARM Tablet ?
<fahadash> !arm
<fahadash> !commands
<day> how long does the downloading 'boot.img' during the installation usually take?
<day> apparently its supposed to take less than a second :P
<day> ah lol now it works...wtf
<day> fuck. i managed to reflash the original android T_T
<day> after the boot.img installation. the routine starts CWM-based Recovery :/
<day> that doesnt look promising
<day> anyone an idea?
<day> does anyone know a good virtualkey board that has arrowkeys?
#ubuntu-arm 2013-09-21
<Nothing_Much> How do you install Ubuntu on an Arm device?
#ubuntu-arm 2013-09-22
<Nothing_Much> Erm..
<Nothing_Much> Well I guess I'm gonna need to figure that on my own.
<AmEv> Any Tegra 2 porter assistans available?
<AmEv> *assistants
<Nothing_Much> AmEv, I don't think you'll find anybody here that talks :(
<Nothing_Much> I'm still wondering how Ubuntu gets installed on an Arm device
<AmEv> Tablet?
<AmEv> I'm still trying to get it on my Toshiba Thrive.
<AmEv> Found lots of guides, but every time I try applying it to the Thrive, all I get is..... About that much.
<Nothing_Much> AmEv, It's not a tablet I'm looking to put Ubuntu on, it's a tiny PC like the Raspberry Pi.
<Nothing_Much> But powerful
<AmEv> Oh.....
<AmEv> What model is it?
<Nothing_Much> Odroid is what it's called
<AmEv> OK.
<AmEv> Is that a "zero" or an "O"?
<Nothing_Much> an O as in oreo
<AmEv> Never mind; found ti.
<AmEv> *i
<AmEv> *it
<AmEv> http://www.hardkernel.com/renewal_2011/main.php right?
<Nothing_Much_> What'd I miss?
<AmEv> Still here. Think I found something.
<AmEv> Which model do you specifically have, Nothing_Much_?
<Nothing_Much> AmEv, I'm looking to get the U2 one
<Nothing_Much> It's half the size of a credit card :O
<AmEv> Heh. No kidding.
<Nothing_Much> I really really need something like that, but I'd also like to know if there's a repository for Ubuntu's Arm build
<Nothing_Much> I'd like to do some video editing, if possible.
<Nothing_Much> With Kdenlive preferably.
<AmEv> Did you take a look at http://forum.odroid.com/viewtopic.php?f=8&t=12 ?
<Nothing_Much> AmEv, That looks outdated
<AmEv> Well, I'm no ARM expert (obviously), but it looks like you might be able to update.
<Nothing_Much> I've never heard of Linaro before
<Nothing_Much> Lemme check it out
<AmEv> Also, Kdenlive does have an ARM build. Can't attest to how good it is (let alone on ARM), though.
<Nothing_Much> I'm really confused about it
<Nothing_Much> It SHOULD be as easy as just installing on an x86 cpu!
<AmEv> Welcome to the world of ARM.
<AmEv> I also wish it was that easy, too.
<AmEv> Though.
<Nothing_Much> I'm open to trying something new
<Nothing_Much> But c'mon, where's the instructions on the Ubuntu website?? D:
<AmEv> Looks like the Ubuntu website doesn't have links; guess it's jsut the odroid link I posted.
<infinity> If you want it to be as easy as x86, get the hundreds of ARM SoC/board vendors to get their kernels functional upstream.
<infinity> Our userspace works fine on all of them, but we can't give you nice hassle-free installers without sane and functional kernels.
<Nothing_Much> infinity, I'm not sure what you mean by that.
<Nothing_Much> The hardware kernels or firmware?
<AmEv> The kernel sources merged upstream, right?
<Nothing_Much> I'm confused, what kernels?
<infinity> Yes, that.  They need to get their patches merged upstream, and they need to make them function with the new generic/multiplatform world order.
<infinity> Sadly, most vendors don't put much effort into that, and then just blame distros for being "lazy" and not maintaining 75 out-of-tree kernels.
<AmEv> Well, prepare for literally hundreds of gnu_linux_<board>_defconfig.... haha
<infinity> It's improving, though.  Slowly.
<Nothing_Much> I'd give anything that I can afford to get rid of this heater right next to me :/
<AmEv> Yeah... Still frustrated at the fact that Tegra foo support is spotty.
<Nothing_Much> foo?
<infinity> AmEv: Tegra's actually better than most now.  srwarren and friends have been putting a lot of effort in.
<AmEv> Oh...
<infinity> (which reminds me, I need to review a patch from him to debian-installer...)
<AmEv> It's just that my Tegra 2 device has never booted anything other than Android.
<Nothing_Much> Ugh, Android
<Nothing_Much> I'd take iOS over that mess of an OS
<AmEv> Heck, I couln't even get Ubuntu Touch to properly boot, either.
<AmEv> (Toshiba Thrive, if you missed it at all).
<Nothing_Much> I can't wait for Ubuntu Touch to come out though, on a phone I can buy.
<AmEv> Got a kernel. Got a rootfs. Got a boot.img. Then got.... Stuck at "Toshiba" screen.
<AmEv> Then got frustrated and walked away for several months.
<Nothing_Much> Can I get a translation as to why there's so many different out of tree kernels for 1 CPU?
<Nothing_Much> Or arch, I should say?
<AmEv> Still, infinity, anything specific you know of that you can point me to, to help me out?
<AmEv> Well, "arch" is short for "architecture". It's literally how the CPU is designed.
<Nothing_Much> Exactly
<Nothing_Much> So I would assume there shouldn't be more than 1 kernel for Arm... right? What am I missing?
<AmEv> x86 uses what is known as "self-describing hardware".
<AmEv> ARM, however, each and every piece of hardware *needs* to be explained in the kernel.
<Nothing_Much> So.. why aren't the firmware devs giving out anything to the main kernel or the arm version of the Linux kernel?
<AmEv> Most companies are just doing the bare minimum because they don't see the point in doing more with a product with "minimal market share".
<AmEv> Plain english? "We're just plain lazy".
<Nothing_Much> Wait, so Android has an installer easily?
<infinity> Nothing_Much: ARM doesn't have a standard for device discovery (like openfirmware on PPC/Sparc, or ACPI on x86/ia64), so booting a "generic" kernel that could discover devices on the fly and function well wasn't an option.
<infinity> Nothing_Much: That led to fragmentation as everyone just did their own thing in their own little playground to have kernels that could only boot on one very specific and narrow devic definition.
<AmEv> Also, each and every device has very different GPIO pinouts. Even MOAR fragmentation.
<infinity> Nothing_Much: We're fixing that with device tree and a slow consolodation of code back into the generic/multiplatform kernel, but it's slow going to fix an old unfriendly tree to play well with others.
<AmEv> So, hopefully, in the future, we can get ARM kernels in the repos, right?
<Nothing_Much> Oh please god make it so.
<infinity> AmEv: The future is now? :P
<infinity> AmEv: We *have* a generic kernel in the archive that boots several platforms.  What we don't have is dozens of platform-specific kernels.
<AmEv> I thought it went "the past is history, the future is history, but right now is a gift; that's why it's called the 'present'"?
<AmEv> *future is a mystery
<AmEv> Still, that's one reason why manufacturers are required to push kernel sources, right?
<infinity> They're required by the GPL to publish their sources if they give you a device with a Linux kernel binary on it, yes.  Not that that helps much when their source is some hacked up fork of a fork of a fork of a tree from three years ago, unless you want to spend countless man-months fixing up their stuff to work the Right Way.
<AmEv> I'm still curious if there's a way to inject the ADB server into Android-to-native-Ubuntu devices.....
<AmEv> If so, that would make debugging a crapton easier.
<AmEv> Still, if any Tegra guru wants to give me pointers, I'm on XDA, same handle.
<AmEv> (Not that you haven't given me any help at all right now, guys! Humor always is a GREAT help!)
<Vanfanel> Hi, how can I add TIOMAP PPA to the apt repositories list in Ubuntu 13.04??
#ubuntu-arm 2014-09-15
<Kevin`> the installer is giving me "No installable kernel was found in the defined APT sources" on pandaboard
<Kevin`> can I make it use the installer kernel somehow for first boot?
<Kevin`> what's causing the error anyway
#ubuntu-arm 2014-09-18
<thresh> hi guys. does anyone run arm64/trusty on x-gene by any chance?
<thresh> wonder if the kernel from https://launchpad.net/~santacruz-team/+archive/ubuntu/xgene is better/worse/musthave than the stock from http://ports.ubuntu.com/ubuntu-ports/
<thresh> I'm on hp m400 machine, if that matters
<infinity> thresh: That kernel is (very) outdated, you want to use the archive one.
<thresh> ok
#ubuntu-arm 2015-09-14
<Gaming4JC> Hello, I am curious what is the point of grub-uboot and grub-efi-arm? Is it possible to use grub-efi-arm entirely without uboot on a device?
<Gaming4JC> https://launchpad.net/ubuntu/trusty/+package/grub-efi-arm
<Gaming4JC> I can't find any documentation on it
<algyz> Hi guys, so I have tv stick mk809iv plus, based onamlogic s805 chip. Rooted it, with win32 image writer wrote lubuntu 14.04 odroid c1 image on microsd, inserted, tried to boot, no luck. Wrong image, anything else to do?
<Doinky> Hi, can someone point me to an ISO for t bb black thats extreamly small
<Doinky> thanks for your outstanding support as eva
#ubuntu-arm 2015-09-15
<algyz> Nobody knows :(
#ubuntu-arm 2015-09-17
<rpiuser> hi everyone i am using ubuntu mate on raspberry pi. i need help running flash on the browser for arm.
#ubuntu-arm 2015-09-20
<zirpu> anyone have ubuntu installed on an hp chromebook 14, tegra armv7?
#ubuntu-arm 2016-09-19
<zzarr> hello! I'm having problems with gpg keys for repositories in xenial (arm)
<zzarr> I get this message "The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5  NO_PUBKEY 3B4FE6ACC0B21F32"
<zzarr> I ran "apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5 3B4FE6ACC0B21F32", but it didn't help
<zzarr> my sources.list file http://pastebin.com/d13mcDpu
<Guest74403> Hi, does anyone know how to get the source for packages on arm64 Ubuntu 16.04.1?
<mrutland> apt-get source ${PACKAGE} ?
<genii> If different arch, then apt-get source packagename:archname
<rbasak> Sources are independent of arch.
<Guest74403> this is what i get "E: You must put some 'source' URIs in your sources.list"
<rbasak> Duplicate your deb lines in sources.list into deb-src lines.
<rbasak> Or grab sources from Launchpad instead, or use pull-lp-source.
<Guest74403> thanks that worked great!
<marcel_> hello everybody how i can install wine on raspberry pi 3 ?? hope you can help
#ubuntu-arm 2016-09-22
<frederikkunze> Hello, i tried to flash Snappy on a Raspberry 3 but it ended in being stuck in the gpu-check screen of the raspi. I did read that the problem exists since a few month is there any solution for it? I could not find any.
<bitanarchy> I had a failed apt-get upgrade, complaining about missing module 4.4.0-31.generic
<bitanarchy> Now I have a kept back package linux-image-c2
#ubuntu-arm 2016-09-24
<YUTrainee> I am teaching a class to underprivileged inner-city youth and would like to demonstrate the merits of Linux. There are students who have heard of RPi's and vaguely know Linux exists, however, the vast majority are unaware of what the OS can do. I'd like to expose them to intermediate and advanced skills/projects/demonstrations in order to inspire them to learn about it. Since I have a limited amount of time with them, I'd like t
<YUTrainee> community page for them to watch.
<YUTrainee> Would anyone here have suggestions of such videos that I could share with my group?
#ubuntu-arm 2017-09-18
<alex1s> Hi all
<alex1s> I have bad performance when running a SVG zoom inside firefox with Ubuntu on a Rpi3, in raspbian it is smooth, do you have any idea what I can do to have the same performance on the 2 distribution ?
#ubuntu-arm 2017-09-19
<zarzar> i need help finding and installing gcc/g++/as arm-linux-gnueabihf version 4.8.1 on ubuntu
#ubuntu-arm 2017-09-20
<zarzar> how do i install 4.8.1 arm-linux-gnueabihf ?
<stephaun> Hi everyone, quick question: do I *NEED* a full-on desktop manager like lightdm or xdm in order to boot directly into my custom application AND retain the ability to switch TTY's by ctrl+alt+F1,2,3... ?
<stephaun> or can i somehow initialize those alternate TTY's before running my application with startx <my_app>
#ubuntu-arm 2017-09-22
<MalcomX710> AN IRCD DESIGNED FOR REAL NIGGAS (NOT COON ASS NIGGAS)
<MalcomX710> YOU MAY ASK IS THIS IRCD FOR YOU? ANSWER THE QUESTIONS BELOW
<alex1s> hi all, I use a Rpi and ubuntu MATE, Classic and Core. I upgrade Firefox package to version 55.0.2 but it crash at boot for all the distrib ? Is it normal ?
