[00:22] <GrueMaster> rsalveti: Where is this script for omap4 audio?
[00:22] <GrueMaster> It isn't in bug 628217.
[00:22] <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
[00:23] <robclark> GrueMaster: amixer.sh?
[00:24] <GrueMaster> I guess.  I keep hearing about a script to make audio work on the panda analog ports.
[00:24] <robclark> if rsalveti doesn't beat me to it, I'll fwd in a couple min
[00:30] <robclark> GrueMaster: http://paste.ubuntu.com/498061/
[00:30] <robclark> run amixer.sh -a
[00:32] <GrueMaster> thanks.
[00:33] <robclark> np
[00:33] <rlameiro> evening everyone
[00:38] <GrueMaster> robclark: Still no audio.  Ran sudo sh amixer.sh -a.  Rebooted.  Now nothing shows up in gnome volume control.
[00:39] <GrueMaster> am I missing a driver?
[00:39] <robclark> GrueMaster: oh, ok.. maybe still the updated default.pa is needed?
[00:39] <robclark> hang on..
[00:39] <GrueMaster> This is a base image
[00:40] <robclark> GrueMaster: http://paste.ubuntu.com/498064/ is /etc/pulse/default.pa.. and one more coming
[00:41] <robclark> GrueMaster: http://paste.ubuntu.com/498068/ is daemon.conf
[00:42] <GrueMaster> Ok.  Will test then add these to the bug report.
[00:42] <robclark> there is some TI package, I think, that configures everything..
[00:42] <robclark> and still I think open point about how to do it without overwriting system files.. but that is a known issue I suppose
[00:43] <GrueMaster> Well, having these attached to the bug report will give the respective developers something to work with.
[00:43] <robclark> yup
[00:47] <rlameiro> audio problems too?
[00:47] <rlameiro> lol
[00:47] <rlameiro> they are comming
[00:47] <rlameiro> Evening GrueMaster  :D
[00:47] <GrueMaster> hello, and welcome back.
[00:48] <robclark> there is lot of ongoing work for ASoC..  which is making audio a bit painful right now
[00:48] <robclark> but should make things better for the future
[00:49] <GrueMaster> yea, I've seen a flood of traffic on alsa-devel mailing list.
[00:50] <rlameiro> well, i see that i have some serious bugs on the audio setup on igepv2
[00:50] <rlameiro> but seems to be the same problem with the beagle
[00:53] <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.
[00:53] <rlameiro> i did that on my igep
[00:54] <GrueMaster> Does "speaker-test -c 2 -t wav" produce audio with those settings?
[00:54] <rlameiro> but even like that, the driver seems very buggy, as it cant handle big "WORKLOAD"
[00:55] <rlameiro> GrueMaster: never tried it out with those settings but it should
[00:55] <rlameiro> my problem is runnig puredata on it
[01:07] <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)
[01:07] <robclark> ahh, ok
[01:26] <persia> Hrm.  Actually, might be able to do something with udev.
[01:26]  * persia reads more docs
[01:50] <GrueMaster> Gah.  death by alsa.  After copying the default.pa and running the amixer.sh script, I am now getting kernel segfaults in alsa.
[01:55] <persia> \o/
[01:55]  * GrueMaster bangs head in silence.
[01:55] <persia> So it's obviously a kernel bug.  The kernel isn't supposed to segfault, regardless of what we do with userspace :)
[01:56] <GrueMaster> I know.
[01:56] <GrueMaster> Bug 644828
[01:56] <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
[01:57] <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.
[01:57] <GrueMaster> Until now, no SOC was multicore, and some of the SOC specific code got a little free with the atomic stuff.
[01:59] <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.
[02:31] <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.
[02:32] <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.
[02:33] <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)
[02:34] <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)
[02:35] <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.
[02:35] <persia> (and. absolutely worst cast, that hack package could run amixer.sh in postinst or something)
[02:36] <GrueMaster> What I have found is that I have had to run amixer.sh after each reboot.
[02:36] <GrueMaster> Even running it sudo doesn't save state properly.
[02:37] <persia> Ugh.  That's too painful for words.
[02:37] <persia> Right.  Kernel patch!
[02:37] <robclark> GrueMaster: I noticed same issue.. it used to work (saving settings on shutdown) with older internal fs that I had
[02:37] <robclark> but now I have to re-run script too :-(
[02:39] <GrueMaster> well, it is after 6:30pm here.  I could be doing this while drinking a beer. brb
[02:58] <persia> Bother.  Making pulse's module-udev-detect work requires properly poplating sysfs.
[02:59] <persia> Could someone with a panda check /sys/class/sound/card.../pcmC...../pcm_class and tell me what it contains?
[03:00] <GrueMaster> generic for all.
[03:00] <persia> berco, /lib/udev/rules.d/78-sound-card.rules might be interesting to you (let's hope it isn't)
[03:00] <persia> That's not helpful :(
[03:01] <persia> Yeah, I think we just don't have enough information in userspace to detect that we want to do special stuff right now :(
[03:03] <GrueMaster> Anything else I can do for you tonight?  If not I'm calling it a day.  12 hours is enough.
[03:03] <robclark> persia: http://paste.ubuntu.com/498132/
[03:03] <persia> GrueMaster, Have a good night.
[03:04] <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/
[03:05] <persia> specifically the "load-module module-alsa-{sink,source} device=..." lines
[03:15] <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
[03:17] <persia> You probably have to perform some sort of reset on uboot.  Check the docs for your specific board for low-level recovery instructions.
[03:18] <persia> For example, some boards allow you to hold down some special button to boot from an alternate bootloader
[03:19] <ajay> persia, thanks but this board doesnot have any type of button as input
[03:19] <ajay> there is no recovery mode inside flash
[03:20] <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.
[03:21] <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)
[03:21] <ajay> persia,ok
[03:24] <davidm> ajay, it may require the use of a hardware debugger
[03:24] <davidm> jtag
[03:25] <ajay> davidm, i have onle serial port console that is minuicm
[03:25] <ajay> minicom
[03:26] <davidm> ajay, if your board is: http://www.igep-platform.com/index.php?option=com_content&view=article&id=46&Itemid=55
[03:26] <davidm> Then it has holes for a JTAG connector and that with special instructions will allow you to reflash the boot system
[03:28] <robclark> will IGEP boot off of MMC before NAND?
[03:28] <robclark> (or are there some DIP switch or jumpers to make that so)
[03:28] <ajay> robbiew, yes it tryies to boot from mmc first
[03:28] <ajay> then flash
[03:29] <robclark> then you should be able to put a good bootloader on an MMC card and recover that way
[03:30] <ajay> i did that as well for this i am getting white screen in LCD and no message over minicom
[03:31] <robclark> hmm, is that different behavior than booting without MMC card?
[03:31] <robclark> if so, then you know MMC comes first..
[03:32] <robclark> then it is "just" a matter of getting a correctly formatted MMC card with good MLO and u-boot.bin..
[03:32] <robclark> (there are scripts floating around to correctly format the MMC card under linux..)
[07:58] <furibondox> have you had a similar problem? http://paste.ubuntu.com/498254/
[08:07] <persia> I haven't seen that reported previously.
[08:07] <persia> Please file a bug against qemu-kvm-extras-static (assuming you generated that on an Ubuntu system)
[08:15] <furibondox> yes I've generated that using rootstock
[08:22] <persia> Was that error produced as part of a rootstock build?
[08:31] <hrw> morning
[09:22] <ogra> dmart_, fyi http://forums.computers.toshiba-europe.com/forums/thread.jspa?threadID=56355&start=30&tstart=0
[09:22] <ogra> dmart_, so general bootloader access is there it seems, but nobody figured out the details
[09:22] <furibondox> hi ogra
[09:25] <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/).
[09:26] <persia> I don't think upstart is your issue there.
[09:26] <furibondox> with this asyncronous method seems that some daemons wait something else but I don't understand when and what
[09:27] <furibondox> persia... I think so, because some times all the boot process goes ok, sometimes no
[09:28] <furibondox> and the problem is always similar to the one I reported in the pastebin
[09:32] <furibondox> when the problem occurrs, all devices in /dev have a wrong datetime (01-01-1970) and ownership (root:root)
[09:32] <ogra> thats with ubuntu kernel ?
[09:33] <ogra> and does your system have an rtc battery and/or a network connection ?
[09:34] <furibondox> the rtc is taken from another processor (a secure processor)
[09:34] <furibondox> so it's good
[09:35] <furibondox> the problem seems related to the devices generated by udev during the the initrd and the devices in the real filesystem
[09:35] <furibondox> but I'm using the same initrd of the ubuntu
[09:40] <furibondox> http://paste.ubuntu.com/498300/
[09:40] <furibondox> it seems that udev fails to be killed in the initrd??
[09:43] <ogra> udev is supposed to be carried over from initrd, how did you generate the initrd assuming you use a different kernel
[09:43] <ogra> also do your kernel config options match with the ubuntu ones
[09:44] <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)
[09:45] <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
[09:45] <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
[09:46] <ogra> you should recreate the initrd if you use a different kernel
[09:46] <furibondox> but I don't use any modules...
[09:46] <furibondox> so the initrd should be the same except that
[09:46]  * ogra wonders why people always assume initrd is only for using modules
[09:47] <ogra> i heard that three times this week
[09:47] <furibondox> I have read all scripts inside the initrd
[09:47] <ogra> it wont break but will gain you unexpected results
[09:47] <persia> ogra, leftovers from embedded development models
[09:47] <furibondox> and they should work with my configuration
[09:47] <ogra> like for example udev misbehaving with broken RTC :)
[09:48] <ogra> what HW is that exactly ?
[09:48] <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.
[09:48] <ogra> a standard beagle ?
[09:49] <furibondox> no
[09:49] <furibondox> it's not a standard beagleboard
[09:49] <furibondox> it's a custom board
[09:49] <furibondox> with omap 3530
[09:49] <ogra> but you are trying to use a kernel that was compilde from a beagleboard defconfig ?
[09:49] <furibondox> no
[09:49] <furibondox> we use our kernel
[09:49] <ogra> well, the above one surely is
[09:49] <ogra> rcn-ee kernels are all beagle kernels afaik
[09:50] <furibondox> I've only used the kernel I said you above in order to generate the initrd with the rootstock
[09:50] <ogra> ah
[09:50] <furibondox> only for that
[09:50] <ogra> how much ram do you have on your board ?
[09:50] <furibondox> 256MB
[09:50] <ogra> the plymouth error is likely the ureadahead OOM
[09:50] <ogra> yeah, that would fit
[09:51] <ogra> currently uredahead needs more than 256M else it will OOM and tear down plymouth with it
[09:51] <ogra> (you should actually see OOM messages for both in dmesg)
[09:52] <furibondox> yesterday i tried also to disable ureadahead and plymounth but the problems remained
[09:52] <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 ??
[09:52] <ogra> you cant disable plamouth
[09:52] <furibondox> ogra: yes I saw ;-)
[09:52] <ogra> avinashhm, that you are using an SD card which it cant sacn
[09:53] <ogra> avinashhm, or any other flash device
[09:53] <ogra> avinashhm, that message is fine, its only info, not an error
[09:54] <avinashhm> ogra, its not related to network ... ?? it hangs after this .. i do nt get the prompt  ....
[09:54] <ogra> furibondox, try removing ureadahead
[09:54] <furibondox> ok
[09:54] <avinashhm> I have removed all nw options from make menuconfig ...
[09:54] <ogra> furibondox, which prompt on which console ?
[09:55] <furibondox> just disable in the /etc/init/ureadahead or aptitude purge ureadahead ?
[09:55] <ogra> i.e. if you expect something on serial, did you make sure serial was enabled during rootstock with the --serial option ?
[09:55] <ogra> apt-get purgs
[09:55] <ogra> *purge
[09:55] <furibondox> ok
[09:55] <ogra> (why do people always use aptiture is beyond me)
[09:55] <furibondox> yes I use --serial ttyS2
[09:56] <ogra> k
[09:56] <ogra> and thats also the console you are looking at ?
[09:57] <furibondox> yes
[09:57] <alf_> ogra: Hi! For a BB xM with possible memory corruptions issues, is "mem=256M" a reliable workaround?
[09:57] <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
[09:57] <ogra> alf_, yes, according to some testers
[09:58]  * ogra never had these RAM probs on his XM so i cant tell for sure
[09:58] <alf_> ogra: Great, thanks. Hopefully this will make my BB xM experience more deterministic :)
[09:58] <ogra> heh
[09:59] <ogra> i think ricardo uses that option on his XM too
[09:59] <furibondox> ok now (w/o ureadahead) I've only this error in the boot.log
[09:59] <furibondox> init: procps main process (3090) terminated with status 139
[10:00] <ogra> thats an issue with your kernel config
[10:01] <furibondox> yes, I'm investigate on this...
[10:02]  * ogra recommends pulling the ubuntu kernel deb and looking at the config file inside
[10:03] <ogra> enabling devtmpfs is also helpful
[10:03] <ogra> and there are a good bunch of other options i guess
[10:04] <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 ??
[10:04] <ogra>  "Last login: " ??
[10:05] <ogra> that looks like you have some kind of autologin going on
[10:05] <avinashhm> its tells ... Last login time ... and other things right ??
[10:05] <ogra> that line comes from motd iirc
[10:05] <avinashhm> yeah ... ubuntu @ ubuntu is logged by default ...
[10:06] <ogra> n/w = network ?
[10:06] <avinashhm> yeah ... network ... :-) .. sorry for confusion.
[10:07] <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
[10:07] <ogra> but apparently you dont get an fsck so it all seems fine to me
[10:09] <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 ...
[10:09] <ogra> which error ?
[10:09]  * ogra doesnt see an error in any of your questions above
[10:09] <avinashhm> not error .. the hang .... it hangs after the print "init: ureadahead main process (487) terminated with status 5" ...
[10:10] <ogra> i thought it gives you an autologin
[10:10] <avinashhm> yeah ... it give autologon normally ...but when i disable network in menuconfig, it hangs
[10:11] <ogra> do you disable the NIC or all network support ?
[10:11] <ogra> indeed, as any linux system ubuntu needs a loopback device
[10:11] <ogra> so you should have basic networking enabled
[10:12] <avinashhm> Networking support  ---> Networking options  ---> TCP/IP networking .... whats NIC ?? and loopback ???
[10:12] <ogra> ugh, why do you play with these options if you dont know what you do ?
[10:13] <ogra> NIC = network interface card
[10:13] <ogra> (your network card driver)
[10:13] <ogra> and loopback is the lo interface lostening for localhost connections on the virtual 127.0.0.1 address
[10:13] <ogra> *listening
[10:14] <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 ...
[10:14] <ogra> some apps expect loopback networking to be available to properly run
[10:15] <avinashhm> ogra, so no way to boot ubuntu, with network disabled ???
[10:15] <ogra> well, i dont know
[10:15] <ogra> but i know that some apps look for loopback
[10:15] <ogra> X wont start without it iirc
[10:16] <ogra> not sure about the low level, we never disable TCP/IP in ubuntu kernels
[10:16] <ogra> so i cant really tell what would happen then :)
[10:17] <avinashhm> thanks for hlep ogra ... :) ...let me give some more time on this ... and see what happens ..:-)
[10:17] <ogra> heh, ok
[12:30] <ogra> persia, did you work with dyfet on the hdf issues ? where is that at ?
[12:32] <dmart> dyfet: ping?
[12:33]  * dmart guesses it may still be too early
[12:34] <ogra> or to late (in care of persia)
[12:34] <ogra> *case
[12:34] <ogra> dmart, btw, did you see my ping this morning ?
[12:35] <dmart> ogra: hmm, guess not.
[12:35] <ogra> dmart, http://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=218590&#218590 someone found access to the bootloader on the toshiba
[12:35] <dmart> ogra: (very faintly) pong
[12:35] <ogra> heh
[12:35] <dmart> ooo
[12:35] <ogra> so it seems to be just a matter of time now :)
[12:36]  * 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
[12:36] <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.
[12:37] <ogra> dmart, ^^^
[12:37] <persia> dmart, If you want to investigate, remove -marm, rebuild, and then look at the detection macros in h5detect.
[12:37] <ogra> persia, there was discussion about bug #635199 in #linaro (why are you not in there ? :) )
[12:37] <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
[12:37] <persia> The code does some things that end up being very ugly for any architecture that can handle more than one instruction set :)
[12:38]  * persia doesn't currently have attention to contribute to linaro
[12:38] <ogra> we have a team wide agreement
[12:38] <ogra> that everyone will be in both channels
[12:38] <dmart> persia: well, it's ubuntu too :)
[12:39] <persia> Yao Qi's comment is correct, and matches what dyfet was telling me.
[12:40] <persia> I should have some spare attention soon, and will be there more :)
[12:45] <dmart> Hmmm, the .diff.gz is almost twice as big as .orig.tar.gz for hdf5 :O
[12:45] <dmart> that's a bit scary
[12:46] <dmart> persia: yes, it doesn't look like a toolchain issue
[12:47] <dmart> I'm also wondering whether the kernel does something wrong with respect to alignment fixups.
[12:47] <dmart> (in addition to reporting them as SIGILL...)
[12:47] <persia> That's a deeper question than I can answer: best wait for dyfet.
[12:48] <dmart> sure
[12:48] <dmart> no problem
[12:48] <persia> h5detect is a good way to exercise alignment issues though :)
[12:48] <dmart> :)
[12:49] <ogra> wow software-center is really a myth
[12:50] <ogra> i wonder if the design team is aware that they overengineerd a bit here :)
[12:50] <dmart> how do you mean
[12:50] <dmart> more than less /var/lib/apt/lists/*Packages ?
[12:50] <ogra> well, i'm just testing a few things in it
[12:51] <ogra> and i dont find it very intuitive
[12:51] <ogra> i.e. trying to install all of OO.o i indeed click on the metapackage
[12:51] <ogra> which only gets me an "update now" button (that in the backend seems to run apt-get update)
[12:52] <ogra> you actually have to click on something like "openoffice writer" and then select the metapackage under "addon packages"
[12:52] <dmart> hmmm, that sounds weird... surely installing the metapackage that ought to suck in everything?
[12:52] <ogra> yes, it does, but only if you pick one of the sublevel packages and check a box
[12:53] <dmart> hmmm
[12:54] <dmart> I would have thought "install it all" would be a sensible default for inexperienced users
[12:54] <ogra> heh, yeah
[12:54] <ogra> i'm probably to experienced to understand it though
[12:54] <ogra> who knows :)
[12:54]  * dmart shrugs
[12:55] <ogra> ah, seems to actually be a bug :)
[12:55] <ogra> phew
[13:20] <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?
[13:23] <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
[13:35] <sebjan> ok, thanks
[13:36] <sebjan> sakoman: we have this issue with the linaro u-boot used on omap4: bug 645167
[13:36] <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
[13:39] <ogra> eek
[13:40] <ogra> you filed it in the upstream project :)
[13:41]  * ogra triages properly
[13:44] <lool> that's ok
[13:44] <lool> as long as it indeed affects the git repo  :-)
[13:46] <ogra> lool, well, both, git and the package :)
[13:46] <ogra> i do care more about the package in maverick though :)
[13:52] <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.
[13:53] <ndec> lool: ^^^^
[13:53] <ogra> ndec, what does maverick have atm ?
[13:53] <ogra> we can surely try
[13:53] <ndec> ogra: 1.2
[13:53]  * ogra hopes 1.3 is in debian
[13:54] <ogra> it gets tricky if it isnt, should be easy if it is
[13:54] <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
[13:54] <lool> ndec: Given that systemtap is not seeded, it would seem possible
[13:55] <lool> ndec: We could take it from Debian experimental
[13:55] <lool> ndec: Did you try the 1.3 as packaged?
[13:55] <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
[13:55] <ogra> lool, oh, it is in experimental ? awesome
[13:56] <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.
[13:56] <ogra> that makes it easy
[13:56] <lool> ndec: Would be nice if you could track this in a bug and report results of your testing of 1.3 as packaged
[13:57] <ogra> ++
[13:57] <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.
[14:02] <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
[14:27] <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)
[14:28] <ogra> mpoirier, yo
[14:28] <mpoirier> ogra: wazup !
[14:28] <ogra> mpoirier, seems there is another bug with the IEGP2 that affects networking
[14:28] <ndec> mpoirier: hi... did you get your new wild animal?
[14:29] <rsalveti> and it seems to be fixed already for linaro's kernel
[14:29] <mpoirier> ndec: yes, thaming it right now.
[14:29] <rsalveti> just saw the bug
[14:29] <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
[14:29] <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
[14:29] <mpoirier> ogra: hold on.
[14:29] <ogra> (i guess the main question here is why doesnt it work as a module though)
[14:35] <rsalveti> ogra: yep, doesn't sound like a correct fix for me
[14:35] <ogra> ++
[14:35] <ogra> but seems to be a workaround if it doesnt affect other oamp3 subarches
[14:35] <rsalveti> yup
[14:35] <ogra> and i'm not sure about the latter
[14:36] <rsalveti> ogra: do we have one igepv2 around in our team?
[14:36] <ogra> nope, only linaro has them
[14:36] <rsalveti> seems lool has one
[14:36] <rsalveti> got it
[14:36] <ogra> right and some other folks in the linaro team
[14:38] <rsalveti> jo-erlend: maybe you could also help us testing this issue
[14:38] <rsalveti> jo-erlend: you said at the other bug that you don't have your eth0 working
[14:39] <jo-erlend> rsalveti, right. I have both wlan and wired on my board, but none of them is working.
[14:39] <rsalveti> for wireless the cause is probably missing firmware
[14:40] <rsalveti> for wired it seems that a workaround is to move the config to built-in
[14:40] <rsalveti> still need to understand why this fixed the issue
[14:40] <jo-erlend> what does that mean?
[14:41] <mpoirier> ogra: sorry for the delay - took me a while to find a wrothy tree.
[14:41] <mpoirier> ogra: It may help with some arch but affect others.
[14:41] <ogra> yeah, thats what i feared
[14:42] <mpoirier> ogra: I'd like to have an explanation for what the real effect of turning off CONFIG_FIXED_PHY has.
[14:42] <mpoirier> ogra: i.e, why it's fixing the problem on some arch and not others.
[14:42] <ogra> ask on the bug, i just stumbled over the fix in linaro (well, lool pointed me to it)
[14:43] <mpoirier> ogra: looks like a work around to me.
[14:43] <ogra> after i had seen the request in the other bug you filed a merge request for
[14:43] <jo-erlend> rsalveti, "move the config to built-in"?
[14:43] <ogra> yes, its surely just a workaround
[14:44] <rsalveti> jo-erlend: currently the kernel is generating a module for your ethernet adapter
[14:44] <rsalveti> the workaround is to move to built-in
[14:44] <hrw> I have good news - armel cross compiler 4.5 landed in ubuntu (gcc-4.4 is on a way)
[14:44] <ogra> hey you didnt post that to #ubuntu-motu (but in every other dev channel)
[14:45] <jo-erlend> rsalveti, ok.. I have no idea how to do that though. :)
[14:45] <hrw> ogra: I am not on ubuntu-motu
[14:45] <hrw> 'd
[14:45] <ogra> but all universe developers are
[14:45] <ogra> ;)
[14:46] <rsalveti> jo-erlend: it's easy, we're just discussing if we're able to have this change to our kernel
[14:46] <rsalveti> but first we need to understand why it's needed
[14:47] <jo-erlend> oh, ok. Can you tell me how to do it? :)
[14:48] <rsalveti> jo-erlend: you'll need to recompile the kernel, not that hard to do it, but takes a while
[14:48] <ogra> especially on omap3
[14:48] <rsalveti> if you want, I can easily generate a new uImage for you
[14:49] <jo-erlend> rsalveti, that'd be nice. Thanks.
[14:49] <rsalveti> based on the kernel package I sent you
[14:49] <jo-erlend> perfect.
[14:49] <ogra> ndec, lol, you commented on the wrong bug :)
[14:49]  * ogra was wondering which steve you are talking to in the systemtap bug
[15:00] <sakoman> ogra, sebjan: I will prepare a u-boot patch for the panda pinmux corrections
[15:00] <ogra> sakoman, yeah, i saw the bug comment, thanks a loit
[15:00] <ogra> *lot
[15:00] <sebjan> sakoman: thanks!
[15:00] <sakoman> I was told that omap4 wasn't a priority, so I've kept all omap4 stuff on the back burner
[15:01] <ogra> huh ?
[15:01] <rlameiro> morning/afternoon/evening all
[15:01] <ogra> its our highes prio in ubuntu
[15:01] <rlameiro> really?
[15:01] <ogra> *highest
[15:01] <sakoman> ogra: from a linaro perpective
[15:01] <rlameiro> omap4 is the fuzz :D
[15:01] <ogra> we're not linaro here :)
[15:01] <ogra> <- ubuntu.arm
[15:01] <sakoman> understood, but my direction comes from linaro ;-)
[15:01] <ogra> bah, we should also pay you then :P
[15:02] <rsalveti> haha :-)
[15:02] <sakoman> works for me
[15:02] <sakoman> ogra: patch is basically ready, but there is one pad I need to research a bit more
[15:02] <ogra> ok
[15:03] <sakoman> the panda x-load sets a few pins more than once
[15:03] <sakoman> and not the same each time :-)
[15:03] <ogra> we'll need to get it into the package too which will add some delay
[15:03] <sakoman> so I need to look at the schematic and see if that is just a screwup or might be intentional
[15:03] <rsalveti> sakoman: cool, thanks for working on it :-)
[15:03] <ogra> ++
[15:04] <ogra> yeah
[15:04] <sakoman> you might notice that I have a few other omap patches in my omap4-dev branch
[15:04] <sakoman> they are still being tested and may be tweaked a bit
[15:04] <ogra> useful for us ?
[15:04] <sakoman> some of them
[15:05] <ogra> (if we need an upload anyway i would indeed like them in the package)
[15:05] <ogra> oh, and note that we use linaros u-boot in ubuntu :)
[15:05] <rsalveti> yep, to have all these new patches we would need it first to go to linaro's tree
[15:06] <rsalveti> then a new release and then a package update
[15:06] <sakoman> I was just giving a "heads up" that new omap4 stuff was pending
[15:06] <ndec> ogra: can I remove a comment from launchpad...
[15:06] <rsalveti> sakoman: cool, will take a look at the tree :-)
[15:06] <ogra> ndec, nope
[15:07] <sakoman> mistype above -- omap4-exp brnach is the right one
[15:07] <sakoman> branch :-)
[15:07] <ogra> ok, i dont know where jcrigby pulls from currently though
[15:07] <ogra> for omap4
[15:08] <sakoman> I don't wither :-)
[15:09] <sakoman> either! jees I can't type this morning!
[15:09]  * ogra hands sakoman some good brazilian coffee
[15:09] <sakoman> 7am is too early
[15:09] <jcrigby> u-boot stable is just -rc1 plus a few patches for vexpress and mx51
[15:09] <rlameiro> sakoman: coffe man
[15:09] <jcrigby> omap is just upstream
[15:10] <sakoman> I'm drinking a brazilian/guatamalan blend (home roast)
[15:10] <ogra> jcrigby, omap4 :)
[15:11] <ogra> jcrigby, we'll need a fix for bug 645167 in your package
[15:11] <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
[15:11] <jcrigby> I see that
[15:14] <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...
[15:14] <ogra> ndec, can you note that on the bug (especially the successfull test)
[15:15] <ogra> i'll care for the rest
[15:15] <ndec> ogra: it's done already!
[15:15] <ogra> oh, cool, my mail is slow today :)
[15:15] <ndec> ogra: only tested on OMAP4, but given the problem we have it's very likely that x86 has the same problem
[15:16] <ndec> ogra: cool ;-) can you please let me know when you pull it in maverick?
[15:16] <rsalveti> sakoman: cool, some interesting patches
[15:16] <rsalveti> sakoman: new mmc driver, hm
[15:16] <rsalveti> saveenv for SDP4430
[15:18] <sakoman> could work for panda on sd card too
[15:18] <sakoman> but would require raw partition
[15:18] <rsalveti> got it
[15:18] <ogra> right, i guess its mainly for the blaze eMMC
[15:19] <rsalveti> yup
[15:19] <ogra> we plan to support that
[15:19] <ogra> so we shoudl get these patches too
[15:23] <fredim> Hi, I'm following https: / / wiki.ubuntu.com / ARM / BeagleServerInstall
[15:23] <fredim> I do the dd command, but nothing is copied to my sdcard
[15:24] <fredim> mmcblk0 what is?
[15:28]  * ogra curses ....
[15:29] <ogra> damned, the panda installs to fast
[15:29] <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
[15:29] <ogra> (the preparation takes longer than the install actually)
[15:30] <ogra> ndec, please build slower boards !
[15:30] <ndec> ogra: well... this should be easier than the opposite ;-)
[15:31] <ogra> fredim, you need to adjust the command to match your device name indeed
[15:34] <ogra> fredim, some MMC controllers name them sdb or sdc or so, some (the real MMC controllers) name them mmcblk
[15:35] <ogra> easiest is to watch dmesg when you plug in the card
[15:35] <ogra> that should show the name
[15:35] <sakoman> argh! git meltdown :-( lost some of my patches in omap4-dev :-(
[15:37] <sakoman> ogra, rsalveti: while I recover, you can review the pinmux patch here:
[15:37] <sakoman> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=56b18c5248a1478b6d6263e428ada02af174df77
[15:37] <rsalveti> ouch
[15:37] <rsalveti> sure
[15:38] <lool> sakoman: You might be able to recover them if you can dig into the git repo
[15:39] <sakoman> lool: yeah, doing that now
[15:39] <lool> searching for files modified recently in the objects dir for instance
[15:39] <sakoman> otherwise will need to recreate them
[15:39] <fredim> 1 - Plug SDcard in my notebook and use "sudo dd if = / part / to / img / file of = / dev/mmcblk0"
[15:39] <fredim> 2 - take sdcard, place in BeagleBoard
[15:40] <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
[15:40] <fredim> plug in the keyboard and monitor BeagleBoard, then connect the power supply
[15:40] <fredim> correct?
[15:42] <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
[15:44] <fredim>  / Dev/mmcblk0 symbolics
[15:45] <fredim>  / Media / disk files sdcard
[15:45] <rsalveti> sakoman: cool, at least it's setting the same values as x-loader
[15:45] <fredim> 3 directories are mounted
[15:45] <rsalveti> sebjan: could you also check at http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=56b18c5248a1478b6d6263e428ada02af174df77 ?
[15:45] <rsalveti> ndec: ^
[15:45] <rsalveti> should fix the pin mux at u-boot
[15:45] <sakoman> rsalveti: that was the intent, right? :-)
[15:46] <fredim> you recommend me some good howto?
[15:46] <ogra> fredim, so you are sure your device is /dev/mmcblk0 ?
[15:46] <rsalveti> yup :-)
[15:46] <fredim> yes
[15:47] <ogra> and what is the path to the img file you downloaded ?
[15:47] <ogra> starting from /
[15:48] <ndec> sakoman: your patch should apply on top of uboot-linaro-stable which is used by ogra for panda, right?
[15:48] <ogra> thats the plan, yeah
[15:48] <sakoman> ndec: I would expect so
[15:49] <fredim> /home/ubuntu-10.04-server-armel+omap.img
[15:49] <ndec> sakoman: ok. we will give this a try. sebjan will confirm if it works.
[15:49] <fredim> sudo dd if=/home/ubuntu-10.04-server-armel+omap.img of=/dev/mmcblk0
[15:49] <sakoman> ndec: thanks!  I couldn't test becasue my panda is broken at the moment
[15:49] <fredim> but nothing is copied to SDcard
[15:50] <rsalveti> sakoman: ouch, your es2?
[15:50] <sakoman> rsalveti: yes -- the serial port connector broke :-(
[15:50] <sakoman> I need to do some surgery later today
[15:50] <ndec> sakoman: what do you mean at the moment ;-)
[15:50] <rsalveti> ouch, not good for a u-boot/x-loader developer
[15:51] <sakoman> rsalveti: indeed
[15:51] <ndec> sakoman: the problem with the wrong pin mux was only affecting bluetooth, not sure if you have the firmware for this. do you?
[15:51] <sakoman> no, I don't
[15:51] <sakoman> so all the more reason for you to test :-)
[15:51] <rsalveti> jo-erlend: could you test http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v3 ?
[15:52] <ndec> sakoman: rsalveti: so we should cherry pick this patch on top of current uboot-linaro-stable, right? this is a better test, no/
[15:52] <rsalveti> jo-erlend: i just removed CONFIG_FIXED_PHY from our config
[15:52] <rsalveti> ndec: yep
[15:52] <ndec> rsalveti: do you build it native or cross in general?
[15:53] <rsalveti> currently I'm building most of my things in a native environment
[15:53] <rsalveti> my panda es2 6 layer is doing a good work, with an usb disk :-)
[15:54] <ndec> rsalveti: cool. root FS on SD and you build on USB? or root FS on USB?
[15:54] <ogra> fredim, are you sure ? the command is definitely ok
[15:54] <ndec> rsalveti: USB flash stick or USB external disk?
[15:54] <rsalveti> ndec: rootfs on usb
[15:54] <rsalveti> external disk :-)
[15:55] <ogra> fredim, oh, you need to make sure the card is not mounted before running dd
[15:55] <rsalveti> 100gb, 7200 rpm
[15:55] <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 ;-)
[15:55] <fredim> So, after successfully copying. what is the next path?
[15:55] <ndec> rsalveti: how long for kernel build? full .deb?
[15:56] <ogra> ndec, 2.5h
[15:56] <rsalveti> ndec: usually 2 hours for omap4 and 3 for omap3
[15:56] <rsalveti> less modules I guess
[15:56] <ogra> ndec, mount SD, mount USB disk, cp -a ?
[15:56] <ndec> rsalveti: 2 hours for omap4 means that USB is faster than SD, since we are in the 2.5+ hours range
[15:57] <ogra> ndec, then add the UUID of the USB disk to boot.scr
[15:57] <rsalveti> ndec: currently I'm not using the daily img, just a very simple rootfs built with rootstock
[15:57] <ogra> and modify /boot/boot.script after booting and run flash-kernel
[15:57] <rsalveti> without X11 and stuff
[15:57] <ndec> ogra: remember I said instructions would be simple ;-)
[15:57] <rsalveti> to be just a build machine
[15:57] <ogra> ndec, that were all instructions :)
[15:57] <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?
[15:58] <ogra> neno
[15:58] <ogra> ndec, no
[15:58] <ogra> you need to do the install on SD
[15:58] <ogra> then do the above
[15:58] <ndec> ogra: why?
[15:58] <ogra> because its designed like that currently
[15:58] <fredim> ogra.. So, after successfully copying. what is the next path?
[15:58] <ogra> fredim, boot your beagle
[15:59] <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?
[15:59] <fredim> sdcard shot the notebook, I put in BeagleBoard, correct?
[15:59] <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
[15:59] <fredim> orbarron, sdcard shot the notebook, I put in BeagleBoard, correct?
[16:00] <fredim> sry... orbarron
[16:00] <ogra> fredim, right
[16:00] <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?
[16:00] <fredim> I connect usb BeagleBoard -> notebook?
[16:00] <ndec> ogra: well... good point...
[16:01] <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)
[16:01] <ogra> ndec, we can discuss live images with installer for panda at UDS
[16:01] <ogra> one way or the other i would like to see USB rootfs support too
[16:01] <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?
[16:01] <fredim> ogra, I turn BeagleBoard on the notebook via USB cable?
[16:01] <ogra> its just not clear yet which way
[16:02] <ogra> ndec, right
[16:02] <fredim> ogra, or just turn on my monitor and keyboard in BeagleBoard?
[16:02] <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
[16:02] <rsalveti> sebjan: it's different because u-boot is setting it for LED
[16:02] <ogra> lucid relied on the preinstalled bootloader on the beagle
[16:03] <ogra> ndec, though boot.scr is updated from a different script than the resizing
[16:03] <ogra> ndec, we have one srcipt only for configuration, the other one has the dangerous pieces (i.e. resizing)
[16:03] <fredim> ogra, theoretically BeagleBoard sdcard should ride with, but in my dmesg shows nothing.
[16:04] <ndec> ogra: ok.. sometimes I boot manually and overide the bootargs and use mmblk0p2... and I could see the resizer was run again!
[16:04] <ogra> fredim, well, if it boots you should see something on the screen thats attached to the board
[16:04] <ogra> ndec, then you didnt run the oem-config bit
[16:04] <jo-erlend> rsalveti, I just have to replace uImage, nothing else?
[16:04] <ogra> ndec, that removes the resizer (jasper-initramfs) at the end
[16:04] <fredim> ok
[16:05] <fredim> thanks
[16:05] <sebjan> rsalveti: ok, for both pins?
[16:05] <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...
[16:06] <ogra> ndec, well, it is definitely gone if you rean the configuration tool (the graphical bit)
[16:06] <rsalveti> sebjan: yep, FREF_CLK4_REQ is the first led and FREF_CLK4_OUT is the second one
[16:06] <ogra> there is no way it could start
[16:06] <ogra> since its not there anymore :)
[16:07] <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.
[16:07] <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
[16:08] <rsalveti> jo-erlend: please let me know if the newer uImage works for you, because then we can forward the change to our kernel
[16:08] <ogra> the last bit of the graphical installer removes jasper-initramfs and re-rolls your initrd
[16:09] <ogra> if you see it resizing something *after* that (while using the newly created initrd), then we have a bug
[16:14] <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.
[16:15] <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?
[16:15] <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
[16:16] <rsalveti> jo-erlend: yep, you just needed to overwrite your uImage with this one
[16:16] <rsalveti> and you still need to use the uInitrd
[16:16] <jo-erlend> well, there was nothing to overwrite. All contents of the first partition is deleted every time I reboot the board.
[16:16] <rsalveti> jo-erlend: ouch
[16:17] <rsalveti> that's definitely a bug, not sure where
[16:18] <GrueMaster> jo-erlend: Are you rebooting or are you letting the resize process reboot the system?
[16:18] <jo-erlend_nb> GrueMaster, I'm rebooting.
[16:19] <rsalveti> if you still have jasper installed at your system it could be that it's affecting you somehow
[16:19] <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.
[16:19] <ogra> ndec, without uInitrd ?
[16:20] <ogra> ndec, the resizing happens *from* uInitrd
[16:20] <ogra> its not possible that you saw any resizing at all without using it
[16:21] <ndec> ogra: ok.. let me do this again. and I will let you know. i am not 100% sure of what I did
[16:21] <ogra> ndec, in any case the resizer lives inside the uInitrd :)
[16:22] <ogra> since we keep a backup of the old initrd around it could possibly happen if you use the uInitrd.bak file for booting
[16:22] <ogra> but surely not without
[16:24] <jo-erlend_nb> GrueMaster, that might be the case. After the first boot, I had to manually resize rootfs.
[16:25] <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.
[16:26] <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.
[16:26] <ogra> and CPU :)
[16:26] <ogra> pnada install just fly by nowadays
[16:26] <GrueMaster> ogra: Same as beagle.
[16:26] <rsalveti> jo-erlend: please paste me your lsmod output
[16:27] <ogra> (apart from tehg SWAP creation)
[16:27] <jo-erlend_nb> rsalveti, I cannot paste from it since I have no network. Is there anything in particular you're looking for?
[16:27] <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.
[16:28] <ogra> GrueMaster, yes, but it will require some heavy changes to the build scripts ... i'm scared ...
[16:28] <rsalveti> jo-erlend_nb: try loading module smc911x
[16:28] <GrueMaster> I've seen the build scripts.  Fear is justified.
[16:28] <rsalveti> see if it makes any difference
[16:28] <jo-erlend_nb> rsalveti, just "modprobe smc911x"?
[16:29] <rsalveti> jo-erlend_nb: yep
[16:29] <ogra> GrueMaster, i'm trying to leverage if its better to just live with 2-3min for SWAP creation or risk the build system
[16:29] <ogra> its very late for such a change
[16:29] <jo-erlend_nb> rsalveti, no change.
[16:30] <rsalveti> jo-erlend_nb: ifconfig -a?
[16:30] <rsalveti> that's weird
[16:30] <ogra> cat /proc/net/dev
[16:30] <ogra> (lower level than ifconfig)
[16:32] <jo-erlend_nb> ogra, that only gives me lo
[16:32] <ogra> then your kernel definitly doesnt know about other interfaces
[16:38] <rsalveti> jo-erlend_nb: check dmesg | grep -i smsc9 , see if your kernel says something about it
[16:39] <jo-erlend_nb> rsalveti, smsc9 or smc9?
[16:39] <jo-erlend_nb> well. Neither returned any results.
[16:43] <sakoman> rsalveti, ogra, jcrigby:  I think I've recovered from my git meltdown, omap4-exp branch should be OK now:
[16:43] <sakoman> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-exp
[16:44] <sakoman> feedback/test results most welcome
[16:44] <rsalveti> jo-erlend_nb: http://people.canonical.com/~rsalveti/kernel/uImage.igep2-v4 new kernel, with the same changes from linaro
[16:45] <jcrigby> sakoman, thanks
[16:45] <sakoman> jcrigby: I'm sure there will be tweaks this week as I spend some time testing and tracking down a few issues
[16:46] <rsalveti> sakoman: cool, expansion stuff is now in
[16:46] <jcrigby> rsalveti, is there sru info for the panda pinmux problem?
[16:46] <sakoman> rsalveti: it is in, but performance needs improvement and there is an i2c error message that shows up on beagle but not overo
[16:47] <sakoman> rsalveti: I'll be investigating this week, but let me know if you find fixes :-)
[16:47] <ogra> everybody who is intrested (and jcrigby indeed) i just switched the oma3 images to linaros u-boot as well
[16:47] <ogra> *omap3
[16:47] <jcrigby> sakoman, latest git looks much better, I was wondering why no new mmc for beagle
[16:48] <ogra> so we sue it on all images now
[16:48] <ogra> *use
[16:48] <jcrigby> ogra, so now when I break u-boot everything breaks:)
[16:48] <ogra> jcrigby, we'll be the first to complain, yeah :)
[16:48] <rsalveti> jcrigby: bt and wlan doesn't work with current u-boot for omap4, so that should fill the sru
[16:48] <sakoman> jcrigby: something went wonky while I was pushing the pinmux patch
[16:49] <rsalveti> ogra: cool
[16:49] <ogra> test image should be ready soon
[16:49] <ogra> (its building since a while already)
[16:50] <GrueMaster> ogra: will this be 20100922.1?
[16:50] <GrueMaster> or a private test image?
[16:50] <rsalveti> jo-erlend_nb: smc911x is the wrong module, smsc911x should be the correct one =\
[16:51] <rsalveti> but the latest uImage should have the correct one as built-in
[16:51] <rsalveti> if it works for you than we need to understand why the module wasn't loaded by default
[16:52] <ogra> GrueMaster, 20100922.1 (i only rebuilt omap3, omap4 will just be copied from 20100922)
[16:54] <GrueMaster> Ok.  I had just finished pulling 0922.  Shouldn't take too much to pull with zsync.
[16:59] <sakoman> rsalveti, jcrigby, ogra: let me know whe you are happy with the testing of the pinmux patch and I will submit upstream
[17:00] <sakoman> it would be good to get the fix in this release
[17:00] <sakoman> (v2010-09)
[17:02] <rsalveti> sure
[17:02] <rsalveti> but I guess we're depending on ndec and sebjan, as we don't have the bt and wlan firmware
[17:02] <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
[17:03] <ogra> *resize
[17:03] <ogra> you must have done something really weird or the install didnt finish properly before you made that change
[17:04] <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.
[17:04] <ndec> ogra: just installed unity on my laptop... and i am lost...
[17:04] <ogra> well, as i said above there is no techinically possible way resize runs again after a successful install run
[17:04] <GrueMaster> rsalveti: We should test it anyways to make sure it doesn't break something else.
[17:05] <ogra> ndec, i havent tried it since UDS :)
[17:05] <ogra> ndec, i think you are supposed to use the search bar a lot with it
[17:05] <rsalveti> GrueMaster: sure, I just mean that we're unable to test if it actually fixed what we wanted :-)
[17:05] <GrueMaster> agreed.
[17:07] <rsalveti> ogra: http://paste.ubuntu.com/498575/
[17:07] <rsalveti> I believe this should be enough to get the correct headers for the dkms module
[17:07] <ogra> yeah
[17:07] <rsalveti> and I added linaro headers as an alternative
[17:07] <ogra> right, thats how it should be
[17:07] <rsalveti> will push & test
[17:07] <rsalveti> let you know about the result
[17:08] <rsalveti> then I believe we should be fine
[17:08] <ogra> ok
[17:09] <ogra> i'll put uploading them to the archive and filing the bugs on my TODO for tomorrow
[17:09] <rsalveti> cool
[17:09] <ogra> with luck we'Re ready by weekend :)
[17:09] <rsalveti> nice!
[17:10] <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 :)
[17:10] <ogra> we'll need something on the desktop
[17:10] <rsalveti> hm, ok
[17:10] <ogra> oh, and one of the postinsts needs some hack to remove icon and .desktop file
[17:10] <ogra> (in your packages)
[17:10] <ogra> ndec, see PM
[17:11] <rsalveti> sure, that's fine
[17:11] <sebjan> rsalveti, sakoman, jcrigby: I just tested the patch, on top of the ubuntu u-boot package, and it fixes the BT issue!
[17:11] <jcrigby> sebjan, thanks
[17:11] <ogra> perfect !
[17:12] <rsalveti> sebjan: awesome, thanks!
[17:12] <jcrigby> rsalveti, bug #607250
[17:12] <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
[17:12] <jcrigby> I need to grab that from ubuntu once it gets there right?
[17:13] <jcrigby> rsalveti, grab you latest patch I mean
[17:13] <rsalveti> jcrigby: yep
[17:13] <ogra> jcrigby, it should be in some tree already
[17:13] <ogra> there was a pull request on the kernel ML
[17:13] <rsalveti> you can find it at my tree, the one from the pull request
[17:13] <jcrigby> ogra, rsalveti, I have link to your tree
[17:13] <rsalveti> http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/fix-igepv2-display
[17:15] <rsalveti> jcrigby: do you have an igepv2 around?
[17:15] <rsalveti> if so then you could also help testing them
[17:15] <jcrigby> rsalveti, no but some other linaro guys do
[17:15] <rsalveti> otherwise I'd wait for an answer from our kernel team
[17:16] <jcrigby> ok, once I see it in a released ubuntu kernel I'll cherry pick it from there
[17:16] <rsalveti> jcrigby: hm, ok, would be nice to test them on top of linaro's kernel
[17:17] <jcrigby> rsalveti, I'll see if torez can test it, she has an igep
[17:18] <rsalveti> nice
[17:18] <sakoman> sebjan: thanks for confirming your test results!  I will submit the patch to upstream u-boot list today
[17:19] <sebjan> sakoman: great, thanks!
[17:20]  * rsalveti out for lunch
[17:21] <ogra> GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100922.1/ is there
[17:22] <GrueMaster> Ok, pulling.
[17:27] <ogra> mpoirier, looking at bug 644828, shouldnt we keep the sound work on bug 637947 ?
[17:27] <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
[17:27] <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
[17:27] <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!
[17:28] <ogra> it really seems we fragment a lot here
[17:28] <mpoirier> ogra: I'm not *actively* working on 644828.
[17:29] <ogra> mpoirier, but you research the sound problems on panda
[17:29] <mpoirier> ogra: i'm concentrating on 637947.  Fixing that one will most likely help fixing the other one.
[17:29] <mpoirier> yes, that's what I'm doing 12hrs a day.
[17:31] <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 :)
[17:31] <ogra> it fells a bit scattered to me
[17:31] <sebjan> sakoman: sure, can you CC me please?
[17:32] <mpoirier> ogra: We need several bugs as it is extremely complex to address bugs within other bugs.
[17:32] <ogra> ok
[17:32] <mpoirier> ogra: as long as we all know sound on panda is taking care of.
[17:33] <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.
[17:33] <mpoirier> ogra: /s/and/an/g
[17:34] <ogra> you could add a tag but that wont help much
[17:35] <ogra> what i usually do is just add a comment with a link to the other bugs
[17:37] <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?
[17:38] <sebjan> rsalveti: it's the same issue. We were suspecting an issue in x-loader
[17:38] <sebjan> rsalveti: ... since this is where I expected the pinmux to be done...
[17:38] <orbarron> hey all is there anyway to get the dailybuild for 20100914?
[17:38] <rsalveti> hm, ok
[17:39] <sakoman> sebjan: done
[17:40] <ogra> orbarron, nope, thats gone
[17:40] <ogra> orbarron, why would you want such an old build ?
[17:42] <orbarron> looking for an environment that will be tested thoroughly... will all omap4 stuff :D
[17:42] <GrueMaster> orbarron: I have a copy for omap4 only.
[17:42]  * orbarron has a copy but thought the dailybuilds would be archive somewhere :D
[17:42] <GrueMaster> But I wouldn't go as far as saying "thoroughly tested".
[17:42]  * orbarron did not want to load up a build on another server
[17:42] <ogra> orbarron, daylies dont recive much testing and such an old daily will have a lot more bugs than a recent one
[17:43] <ogra> orbarron, use zsync to keep them up to date :)
[17:44] <ogra> orbarron, the 14 build is way worse than anything recent
[17:45] <GrueMaster> iirc, oem-config was borked on it pretty badly.
[17:45] <ogra> no, that was the one after 14
[17:45] <ogra> or two of them
[17:45] <ogra> after that it improved daily
[17:45] <rlameiro> mpoirier: are you into making a ubuntu-arm-sound group?
[17:45] <ogra> actually todays is pretty close to being good
[17:45] <ogra> (not perfect, but good)
[17:46]  * 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
[17:46] <mpoirier> rlameiro: what a good idea !
[17:46] <ogra> orbarron, dailies are movimg targets
[17:46] <rlameiro> mpoirier: i would glady help on what i can
[17:46] <ogra> orbarron, and we dont test them much, wait for RC
[17:46] <mpoirier> rlameiro: but I was wondering if it couldn't be something like linux-omap-sound...
[17:46] <rlameiro> I have an idea for a project that will greatly benefit from it
[17:47] <mpoirier> opinion anyone ?
[17:47] <rlameiro> well, i just have one card to test...
[17:47] <ogra> orbarron, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100922.1/ this one is really good, but it still has bugs
[17:47] <ogra> orbarron, and it will be wiped in two days
[17:47] <rlameiro> if someone is into send me more caqrds i will hapily receive them :D
[17:48] <ogra> mpoirier, i wouldnt make it arch specific
[17:48] <ogra> once you have the bugs fixed it will be dead
[17:48] <ogra> while the team moves on to new HW and has new sound bugs
[17:49] <mpoirier> ogra is correct - we will work with other processor, ubuntu-sound it is.
[17:49] <ogra> i think ubuntu-sound exists
[17:49] <rlameiro> isnt there already a grup like that?>
[17:49] <ogra> i thought you wanted something arm specific
[17:50] <rlameiro> crimsums group or something?
[17:50] <ogra> persia usually knows details about such groups
[17:50] <mpoirier> ubuntu-sound now exists - go for it.
[17:50] <ogra> hmm
[17:50] <ogra> you might clash with an existing group
[17:50] <ogra> which is probably differently named
[17:50] <rlameiro> well, the thing its that arm sound is far away from the other archs..
[17:50] <ogra> right
[17:50] <mpoirier> ok, i'll fix.
[17:51] <ogra> thats why it shoudl have arm in its name
[17:51] <rlameiro> arm is ok, mmaybe not omap just...
[17:51] <ogra> and we should find out what that general sound group is :)
[17:51] <rlameiro> but on the description explain that for now is omap oriented
[17:51] <ogra> to work together, since they mainly maintain the packages (alsa, pulse, jack etc)
[17:52] <rlameiro> mpoirier: when ogra said to dont lock to archs I think he meant ARM sub archs, like tegra omap, imx5 etc
[17:52] <mpoirier> how do I delete my own group ?
[17:52] <ogra> rlameiro, yeah
[17:53] <ogra> mpoirier, #launchpad might know
[17:54] <devilhorns> if I install lucid, can I still run a "rootstock" for maverick ?
[17:54] <GrueMaster> devilhorns: You will need to pull rootstock manually.  The lucid version has issues iirc.
[17:54] <rlameiro> devilhorns: i did it
[17:55] <devilhorns> GrueMaster, ok, but it can be done right ?
[17:55] <GrueMaster> yes.
[17:55] <rlameiro> just need to put -dist maverick
[17:55] <rlameiro> *--dist maverick
[17:55] <devilhorns> ok, looks like I may need todo a reinstall then :/
[17:56] <devilhorns> GrueMaster, thanks
[17:59] <mpoirier>  #ubuntu-arm-sound has been created
[18:06] <rlameiro> persia: ping
[18:07] <GrueMaster> rlameiro: It is 2am where he's at.
[18:07] <rlameiro> ahhh, ok
[18:07] <rlameiro> australia?
[18:08] <rlameiro> well, someone in here knows how to put an ubuntu bot on a ubuntu related channel?
[18:08] <GrueMaster> Tokyo.
[18:08] <ogra> mpoirier, err, an irc channel ?
[18:09] <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)
[18:10] <davidm> devilhorns, the board powers from USB :-)
[18:10] <devilhorns> davidm, gotcha :) just figuring that out now w/ ogra :)
[18:11] <devilhorns> so I pretty much have everything then ... except the powered usb hub, which I can proally pick one up @ a local store here
[18:11] <davidm> devilhorns, yea, I think most folks with a beagle use a powered hub
[18:12] <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
[18:12] <devilhorns> not a big deal
[18:16] <GrueMaster> devilhorns: Eventually you might want to get a cable like this:  https://specialcomp.com/beagleboard/DSCN0401_s.JPG
[18:16]  * ogra calls it a day
[18:16] <devilhorns> g'night ogra :) thanks again
[18:16] <GrueMaster> It costs $8.  Or you can make one.  Real simple.
[18:17] <devilhorns> GrueMaster, not really into making my own cables ... they always shoot sparks :P
[18:17] <GrueMaster> heh.
[18:19] <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.
[18:20] <devilhorns> ahhh good to know, thanks :)
[18:20] <GrueMaster> And if you can find a powered hub with ethernet, it makes life even simpler.
[18:22] <devilhorns> yea, that certainly would make life easier :)
[18:22] <GrueMaster> For the serial port, I am using a serial cable that came with a motherboard with an internal port header.
[18:23] <GrueMaster> At any rate, here is a link for a supplier that has good accessories.  https://specialcomp.com/beagleboard/order.htm
[18:23] <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
[18:24] <GrueMaster> Mine came from an old 486 before it found the e-Recycling bin.
[18:24] <devilhorns> hahaha
[18:35] <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?
[18:35] <Neko> I can just drop you the entire archive, or a portion?
[18:42] <GrueMaster> rsalveti: Have you tried the mini-usb port on the ES2 yet?
[18:48] <GrueMaster> Nevermind.  It isn't even enabled in the kernel.
[18:48]  * GrueMaster files a bug.
[18:50] <Neko> oh neat maverick is frozen frozen??
[18:50] <rsalveti> devilhorns: cool, got your board?
[18:51] <devilhorns> rsalveti, yea :) missing some items to actually make it work, but I'll go out tonight and grab em from a local place
[18:52] <GrueMaster> rsalveti: Can you mark bug 645420 as confirmed?  thanks.
[18:52] <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
[18:52] <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??
[18:57] <rsalveti> argh, my notification system is still broken :-)
[18:57] <rsalveti> devilhorns: cool, now you can test it on arm :-)
[18:57] <rsalveti> GrueMaster: let me check
[18:58] <rsalveti> Neko: last time I tested I used the console oem-config
[18:59] <rsalveti> Neko: what is the issue you're facing?
[18:59] <devilhorns> rsalveti, yea, when I get the rest of the stuff I need to be able to run the board :)
[19:00] <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?
[19:00] <GrueMaster> devilhorns: Make sure you use a >=4G SD card.  Image is 2.2G atm.
[19:01] <devilhorns> GrueMaster, indeed :)
[19:01]  * rlameiro spelling sucks
[19:01] <GrueMaster> Anything I can tell you before you head to the store?  Want to make sure you have a proper shopping list.
[19:02] <devilhorns> don't think so ... only thing I am really missing is the usb powered hub
[19:02] <GrueMaster> rlameiro: I have my DHCP server set to assign the same IP based on mac.
[19:02] <rlameiro> buy a cheap usb sound device:D
[19:02] <rlameiro> that small thingies that cost 3 usd
[19:02] <rlameiro> or something
[19:02] <rlameiro> GrueMaster: my router isnt so advanced :D
[19:03] <GrueMaster> rlameiro: Why?  Sound works on beagle.
[19:03] <rlameiro> GrueMaster: testing :D
[19:03] <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
[19:03] <GrueMaster> rlameiro: You mean it isn't running linux?
[19:04] <rlameiro> GrueMaster: i almost sureit runs linux, but i dont want to fiddle with it, it haves a telnet connection...
[19:04] <ogra_ac2> devilhorns, well, you could play quake, we have it in the archive and rsalveti just packaged the GL drivers *g*
[19:05] <rsalveti> for sure you could use it for games ;-)
[19:05] <GrueMaster> Or just run with the aalib drivers.  :P
[19:05] <devilhorns> ogra_ac2, lmao ... who has time for games ? :)
[19:06] <ogra_ac2> heh
[19:06] <armin76> ogra_ac2: bought another ac100? :D
[19:06] <ogra_ac2> armin76, no, the wlan disconnects often
[19:07] <GrueMaster> More likely broke another.  :P
[19:07] <armin76> heh
[19:07]  * GrueMaster hides.
[19:07] <ogra_ac2> and that android client just attaches numbers it seems
[19:07] <ogra_ac2> GrueMaster, nah, i'm waiting for someone to hack teh bootloader
[19:07] <ogra_ac2> i wont risk that again
[19:07] <ogra_ac2> though it seems they are close
[19:08] <ogra_ac2> (someone managed to pull the partitions down via nvflash)
[19:09] <armin76> replace with omap4? :D
[19:09] <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)
[19:09] <ogra_ac2> jayabharath, no we dont have a project
[19:10] <ogra_ac2> well, we do, its ubuntu :)
[19:10] <jayabharath> Mmm.. I see. But, bugs can be logged at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap ??
[19:10] <ogra_ac2> depends what the bug is
[19:10] <ogra_ac2> the bugs should be targetd for teh specific package it is in
[19:10]  * jayabharath is new to launchpad and its confusing...
[19:11] <ogra_ac2> just use ubuntu-bug to file them
[19:11] <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
[19:11] <ogra_ac2> they wont
[19:11] <ogra_ac2> the average joe will get an automatic popup if there is an oops
[19:12] <ogra_ac2> which walks you through
[19:12] <jayabharath> That presumes board has not reset or network is functional.. :)
[19:12] <ogra_ac2> a developer will use: ubuntu-bug linux
[19:12] <ogra_ac2> for omap3
[19:12] <ogra_ac2> and ubuntu-bug linux-ti-omap4 for panda
[19:13] <ogra_ac2> even without network it will collect crash info in /var/crash
[19:13] <ogra_ac2> and tell syou wnt to do with it
[19:13] <jayabharath> great...
[19:13]  * jayabharath looks for a wiki page that tells this
[19:14] <ogra_ac2> i think there is one
[19:14] <ogra_ac2> persia ususally has the urls up his sleeve
[19:14]  * ogra_ac2 searches
[19:14] <jayabharath> no worries.. I will search for it.. I am sure there is something on ubuntu.co
[19:14] <jayabharath> m
[19:15] <ogra_ac2> help.ubuntu.com/community/ReportingBugs
[19:16]  * jayabharath bows to ogra_ac2 and thanks him
[19:17] <ogra_ac2> heh, just thank google :)
[19:45] <rsalveti> bug 628029
[19:45] <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
[19:46] <rsalveti> lag: ogra: ndec: this bug was created for ES1, but does any of you know if CONFIG_PM works for ES2?
[19:48] <GrueMaster> rsalveti: I would just try it.  Worst case is that it fails (I hope).
[19:48] <rsalveti> yep, building a new kernel
[19:48] <GrueMaster> I think there was mention of work needed to be done for suspend to work properly and it was waiting on ES2.1.
[19:49] <rsalveti> hm
[20:11] <pirearadu> hy all
[20:11] <pirearadu> i can install ubuntu arm on my samsung omnia i900?
[20:13] <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.
[20:15] <pirearadu> but
[20:15] <pirearadu> ubuntu for cell phones exists?
[20:15] <GrueMaster> not that I know of.
[20:27] <hrw> pirearadu: i900? jaunty (9.04) may work if you have kernel
[20:27] <pirearadu> yea
[20:28] <pirearadu> i900
[20:28] <pirearadu> what kernel hrw?
[20:28] <armin76> :D
[20:28] <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.
[20:28] <hrw> pirearadu: if this is still black magic for you then forget about ubuntu on i900
[20:29] <pirearadu> i know that
[20:29] <pirearadu> but
[20:29] <pirearadu> what kernel i need?
[20:29] <hrw> the one which works on i900 - thats simple
[20:30] <hrw> how to get it and from where is other thing
[20:31] <ogra_ac> we should probably also stop suggesting jaunty, given its only supoprted for another 4 weeks
[20:32] <hrw> ogra_ac: or generally: if you do not have (list of all 4 supported boards) then you out of luck?
[20:32] <ogra_ac> nah, then rootstock wouldnt make sense
[20:32] <ogra_ac> but jaunty will be EOL very soon
[22:43] <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.)
[23:01] <rlameiro> well, out of the channel :D
[23:01] <rlameiro> persia: the idea was to make a group really
[23:01] <rlameiro> not a channel
[23:03] <persia> Why does it need a group?  What does it do that isn't achieved by ubuntu-audio and ubuntu-arm?
[23:03] <persia> How does this group increase collaboration and cooperation?
[23:03] <rlameiro> well, that was the disvution
[23:03] <rlameiro> discusion
[23:05] <rlameiro> i think that the problem is that, for now, there are some bugs arm related
[23:05] <rlameiro> and i dont think there are to much people interested in fix them
[23:06] <persia> I'll agree with that, which is why I'm against a new team or channel.
[23:07] <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.
[23:07] <rlameiro> so, better inter communication beetween ubuntu-sound and ubuntu-arm?
[23:08] <rlameiro> i shal tag the bugs to ubuntu-sound also then
[23:08] <persia> I'd rather "more overlap between ubuntu-audio and ubuntu-arm", but better communication may help if that fails.
[23:08] <persia> Please don't.
[23:09] <persia> See https://wiki.ubuntu.com/DebuggingSoundProblems for how to triage the sound bugs.
[23:10] <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.
[23:10] <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.
[23:17] <rlameiro> persia: but i am not using an ubuntu kernel, i am using rcn-ee one
[23:18] <persia> Ubuntu can only support Ubuntu kernels.  To the best of my knowledge, rcn-ee regularly pushes patches into Ubuntu.
[23:19] <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.
[23:20] <rlameiro> persia: is there an easy way to install an ubuntu kernel inside my board?
[23:20] <persia> Make sure flash-kernel does the right thing for you.
[23:20] <rlameiro> for instance if i install it where is the uImage and uInitrd
[23:20] <persia> Then apt-get install linux-omap (or whatever)
[23:21] <rlameiro> flash-kernel?
[23:21] <persia> Yep.
[23:21] <rlameiro> never heard of it..
[23:21] <rsalveti> rlameiro: you can easily install it by giving apt-get or downloading the deb and giving dpkg -i
[23:21] <rsalveti> flash-kernel will replace your uImage and uInitrd with the new one
[23:21] <persia> rsalveti, Do you know this works for IGEPv2?
[23:21] <rsalveti> at the first partition
[23:22]  * persia is fairly certain flash-kernel is device-specific
[23:22] <rlameiro> i have them on my fat partition
[23:22] <rsalveti> should work, I believe, but nobody tested I guess
[23:22] <rlameiro> ok
[23:22] <rlameiro> here i go
[23:22] <rlameiro> testing freenzy
[23:22] <rsalveti> if doesn't work, fill a bug :-)
[23:22] <persia> rlameiro, If you want to check the script first: install the flash-kernel package, and look at /usr/sbin/flash-kernel
[23:22] <rlameiro> I should make a backup :D
[23:22] <rsalveti> otherwise install your package, generate the uImage and uInitrd with mkimage and copy them to the first partition
[23:22] <persia> (shouldn't that really be in /sbin, rather than /usr/sbin ?)
[23:26] <rlameiro> weird
[23:26] <rlameiro> flash-kernel isnt neither in sbin or /usr/bin ...
[23:27] <persia> apt-get install flash-kernel
[23:28] <persia> rsalveti, Maybe rootstock should encourage people to include flash-kernel?
[23:28] <rlameiro> persia: i did that already :D
[23:28] <persia> And you don't have /usr/sbin/flash-kernel?
[23:28]  * persia is very confused
[23:28] <rlameiro> no
[23:28] <rsalveti> depends, as our current support at flash-kernel is not that good
[23:28] <rlameiro> oops
[23:28] <persia> rsalveti, Shouldn't we fix that :)
[23:28] <rlameiro> sorry
[23:28] <rsalveti> and generally rootstock should be recommended for hardwares that we don't officialy support
[23:28] <rlameiro> i didnt look at usr/sbin
[23:28] <rlameiro> just /usr/bin
[23:29] <rlameiro> its a binary
[23:29] <persia> rsalveti, Especially as ARM kernels converge, we'll find that the set of supported hardware grows wider than is well-understood.
[23:30] <persia> Specifically, the set of supported hardware is the set of hardware supported by kernels in Ubuntu plus any bugs anyone wants to fix :)
[23:31] <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.
[23:34] <rsalveti> we have bugs on both
[23:34] <persia> Not surprising :)
[23:34] <rsalveti> the only difference is that at linaro's the ethernet is working
[23:35] <rsalveti> I sent the patches to fix the display, but not applied yet
[23:35] <persia> Really?  Maybe I should try that: might make the internet on my board work.
[23:35] <rsalveti> persia: do you have an igepv2?
[23:35]  * persia decides to stop IRCing until there is enough awakeness to not mistype "ethernet" as "internet"
[23:36] <persia> rsalveti, Nope: beagleboard
[23:36] <persia> C4
[23:36] <rsalveti> but the ethernet fix at linaro's is related with igepv2
[23:36] <rlameiro> rsalveti: there is comming more work from igepv2 side
[23:37] <rlameiro> they are to launch their expansion board
[23:37] <rsalveti> I'd like to get one for testing, but needs to find a way to buy it
[23:37] <rlameiro> LCD/VGA/compositevideo etc etc
[23:37] <rlameiro> well, ask them to send 2 or 3 to canonical
[23:37] <rsalveti> could be :-)
[23:37] <rlameiro> well, true is that it is on their interest
[23:38] <rsalveti> sure, will send an email later :-)
[23:38]  * rsalveti out for while, football game :-)
[23:43] <rlameiro> persia: flash kernel outputs "unsuported platform....
[23:44] <persia> rlameiro, It's a shell script: tell it how to store the kernel for your board, and file a bug :)
[23:45] <persia> (this is how platforms gret supported)
[23:45] <rlameiro> well, i wish i had the kwoledge
[23:46] <persia> Which part of the shell script don't you understand?
[23:46] <rlameiro> just started reading it
[23:46] <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.
[23:50] <rlameiro> persia: http://pastebin.ubuntu.com/498796/
[23:50] <rlameiro> maybe its in here on this case
[23:50] <rlameiro> i need to add IGEPv2 to it
[23:50] <rcn-ee> actually the igepv2 will be under omap.. in that script there should be a "beagle" case
[23:51] <rlameiro> http://pastebin.ubuntu.com/498798/
[23:52] <rlameiro> it check for proc cpu info
[23:52] <rcn-ee> there should be "OMAP3 Beagle Board" check (from cat /proc/cpuinfo)
[23:52] <rlameiro> this is mine
[23:52] <rlameiro> and in hardware it is not the omap but igep :D
[23:52] <rlameiro> that is my cpuinfo cat http://pastebin.ubuntu.com/498798/
[23:53] <rcn-ee> yeap mine is that too... i forget where in flash-iamge it happens..
[23:53] <rlameiro> but from what i see it copy it to the NAND, is that right?
[23:53] <rlameiro> because i dont want to mess with the nand
[23:53] <rlameiro> ...
[23:53] <rlameiro> i prefer to copy it by hand to the partition
[23:53] <rcn-ee> in the beagle case (lucid defaulted to nand) and with maverick mmc is first i think...
[23:54] <rcn-ee> i'd really use mmc, less likely for bricks by new users...
[23:54] <rlameiro> well I dont know shell script, so i will not mess with it..
[23:54] <rlameiro> i think i will copy it by hand
[23:54] <GrueMaster> If you have a fat partition, you can create /etc/kernel-img.conf file and add UBOOT_PART=<fat partition> entry.
[23:55] <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
[23:56] <GrueMaster> Sorry, /etc/flash-kernel.conf is the file.
[23:56] <GrueMaster> It contains two lines, one for UBOOT_PART= and one for root=.
[23:57] <rlameiro> beagle routine
[23:57] <rlameiro> http://pastebin.ubuntu.com/498802/
[23:59] <persia> If you set UBOOT_PART, that routine should just work.  The trick would be in ensuring that IGEPv2 boards trigger that routine.
[23:59] <rcn-ee> rlameiro, this http://pastebin.com/2RWdavzp on top of https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/flash-kernel/maverick
[23:59] <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.