[01:24] <davecheney> are perf events support on armhf/omap4 ? http://lwn.net/Articles/368607/
[01:25] <davecheney> /support/supported/
[10:51] <ndec> ogra_: hi. i just realised that we never really discussed about 12.10 OMAP4 kernel... what do you guys expect?
[11:16] <ogra_> ndec, hmm, not sure, ppisati ^^^ any idea ?
[12:02] <ppisati> ndec: you mean the kernel version? or what else?
[12:10] <ndec> ppisati: how to you plan to manage the OMAP4 kernel? so it's both the kernel version, and the branch strategy.
[12:10] <ndec> and also are you planning to make panda images?
[12:12] <ogra_> oh, a "panda tablet" in germany !
[12:12] <ogra_> http://aldi-nord.de/aldi_ab_mittwoch_0606_48_5_967_15052.html
[12:13]  * ogra_ wonders why anyone would go with 4:3 nowadays ... weird decision
[12:13] <ogra_> bah, and it uses only a 4430
[12:14] <ppisati> ndec: omap4/panda is still our refernce platform wrt arm
[12:14] <ppisati> ndec: so yes, we'll do panda images
[12:14] <ndec> ogra_: i didn't know about this tablet ;-)
[12:14] <ppisati> ndec: if omap4 delta against upstream is small, we could collapse omap3/4 in master and leave a topic branch for omap5
[12:15] <ndec> which kernel version are you shooting for?
[12:15] <ppisati> ndec: 3.5 for sure, but if 3.6 is out in time, we could pick it
[12:15] <ndec> ok. there will be very minimal enablement effort by us on 3.5.
[12:16] <ndec> we are going to spend some more time on 3.4 for customer/products constraints.
[12:16] <ppisati> ndec: ah, and we are going to support any omap5* reference/broadly available that comes out before 12.10
[12:16] <ndec> that includes the tilt tree.
[12:16] <ppisati> ok
[12:16] <ndec> ppisati: i don't think OMAP5 has been discussed.
[12:16] <ndec> i mean between canonical and IT
[12:16] <ndec> TI
[12:17] <ppisati> nope
[12:17] <ppisati> AFAIK
[12:17] <ppisati> but i pick andy's tilt code, so omap5 support is included
[12:17] <ndec> yes.
[12:17] <ppisati> cool
[12:17] <ndec> but there won't be a 3.5 kernel with omap4+omap5
[12:18] <ndec> from us nor andy
[12:18] <ppisati> ah
[12:18] <ppisati> so you are going to stay on 3.4
[12:18] <ndec> yes.
[12:18] <ppisati> ok
[12:18] <ppisati> about 3.6?
[12:18] <ndec> too far away!
[12:18] <ndec> ;-)
[12:18] <ppisati> ok
[12:18] <ppisati> so 3.4 is going to be well supported, i see
[12:19] <ppisati> do you know which kernel will jelly bean use?
[12:19] <ogra_> ndec, i think its based on some lenovo device (medion is owned by lenovo)
[12:19] <ndec> if you use mainline'ish kernel for OMAP4, you are missing 4460 support (e.g. it will run at 600Mz, instead of 1.2). you are missing PM (DVFS, thermal, ...), and you are missing audio analog.
[12:19] <ndec> but you should get everything else.
[12:19] <ndec> including some decent HDMI (display+audio)
[12:20] <ndec> ppisati: jelly bean, there is no official information on it. there are 3.4 branches in google trees. so i guess that's what they will use.
[12:20] <ppisati> hopefully some of this stuff will enter 3.[5|6]
[12:20] <ppisati> i see
[12:21] <ndec> but our decision to stay on 3.4 is not correlated with android. we need to fix some PM issues in 3.4 for a product.
[12:21] <ppisati> ogra_: and indeed fakeroot debian/rules clean binary in a fresh quantal-amd64 chroot chokes on tools too
[12:21] <ndec> i think we should be able to get a 3.6 kernel. but not 100% sure.
[12:21] <ppisati> ndec: ack
[12:21] <ogra_> ppisati, aha, i guess tim should be able to help though
[12:21] <ppisati> ndec: btw there was a nasty bug about freq scaling
[12:22] <ppisati> ogra_: yep
[12:22] <ndec> in 3.3, right?
[12:22] <ndec> ppisati: well, what bug?
[12:23] <ppisati> ndec: kernel hangs after a period of forcefull freq scaling (using a dummy script to stress the cpu and then leave it idle)
[12:24] <ppisati> ndec: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/971091
[12:24] <ubot2`> Launchpad bug 971091 in linux-ti-omap4 "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Confirmed]
[12:24] <ppisati> ndec: when you have time, can you try it (and leave a panda es overnight) with one of your kernel?
[12:24]  * ppisati -> really out to get some food, brb
[12:50] <janimo> ogra_, what is the status with armel, will we have the same images built with it as with armhf for 12.10?
[12:52] <ogra_> we dont build armel images since precise
[12:53] <ogra_> and by the looks of it armel will completely vanish soon
[13:11] <ogra_> janimo, what do you do with armel that you ask ?
[13:12] <janimo> ogra_, nothing, just wondering if we should drop the ac100 armel kernels once armhf + graphics work
[13:12] <ogra_> we should drop them with the next upload imho
[13:12] <janimo> oh right, I forgot there are no images anymore
[13:12] <janimo> great
[13:12] <janimo> I am rebasing on 3.1 now
[13:13] <ogra_> yay
[13:13] <janimo> and I hope to have a working package soon
[13:13] <janimo> sometimes I hate git too :)
[13:13] <ogra_> great, i'll upload my driver package then after the freeze
[13:13] <janimo> especially when rebasing between wildly differing repositories
[13:13] <ogra_> heh
[15:12] <ogra_> hmpf, jasper seems unhappy on the current images
[16:09] <marvin24_DT> janimo: did you acutally tried booting a 3.1 kernel with your config?
[16:09] <janimo> marvin24, yes and it failed :)
[16:10] <marvin24_DT> I guessed so
[16:10] <ogra_> mine works fine over here
[16:10] <janimo> it was a shot in the dark really
[16:10] <janimo> I hate merging config files and reviewing dozens of config entry docs :/
[16:11] <ogra_> you should have kept my packaging ;)
[16:11] <marvin24_DT> yeah, so big thanks for doing it anyway
[16:12] <marvin24_DT> janimo: at least all the CONFIG_*TEGRA* stuff should be enabled
[16:12] <marvin24_DT> I'll give a detailed reply on the list
[16:12] <janimo> ok, I was not sure how much of it is tegra3
[16:12] <janimo> I'll do an updateconfig now but will take all hints from your mail too :)
[16:18] <ogra_> hmof, isntalling PVR on the panda image kills the package manager with held broken packages, fun
[16:22] <ogra_> eeek, infinity we need to patch flash-kernels default bootscr's for all arches i fear...
[16:22] <ogra_> cat /proc/cmdline
[16:22] <ogra_> ro
[16:22] <ogra_> ...
[16:22] <ogra_> indeed debian does neither use quiet nor splash
[16:23] <ogra_> though beyond that it works surprisingly well
[16:23] <marvin24_DT> janimo: you cannot activate something specific for tegra3 if the cpu is not selected
[16:33] <infinity> ogra_: If it works at all, that's something. :P
[16:33] <ogra_> yeah, it seems to work fine apart from my kernel issues
[16:33] <ogra_> (display isnt detected)
[16:33] <infinity> Displays are overrated.
[16:34] <ogra_> especially on preinstalled desktop images without sertial output :P
[16:35] <infinity> ;)
[16:43] <janrinze2> lilstevie: do you accept bugfixes for your git tree?
[16:47] <marvin24_DT> janimo: remember that the 3.1 doesn't need a mem=448M@0 option anymore
[16:47] <marvin24_DT> it may fail to boot if you add one
[16:48] <janimo> marvin24, oh so not only kernel changes but flash-kernel possibly.
[16:48] <janimo> ogra_, do you know what the deal is there ^ ?
[16:48] <ogra_> f-k doesnt have any special options at all in the booltloader setup
[16:50] <marvin24_DT> abootimg provides a standard bootimg.cfg ?
[16:51] <ogra_> nope
[16:51] <ogra_> f-k in quantal isnt tested on the ac100 yet
[16:51] <ogra_> that will likely need some tweaks
[16:52] <ogra_> i wasnt thinking janimo actually uses quantal on his test ac100 though
[16:53] <janimo> I am not doing an SRU with 3.1 but I am on the precise userland when testing
[16:54] <janimo> marvin24, I'll do some tests with the abootimg, I need to flash it anyway as the current kernel does not boot now
[16:55] <ogra_> you dont have sosboot installed ?
[16:57] <janimo> ogra_, I have 2.2 android I think so lost sosboot quite a while ago
[16:57] <janimo> I even forgot about it :)
[16:58] <ogra_> ah, sad
[16:58] <ogra_> makes working on the device so much harder
[16:58] <janimo> I am not sure if I could not go back to 2.1 ar all or it was just too annoying
[16:59] <janimo> well only bad kernel can mess it up, and I knew I'd have to resort to nvflash if I break it, oh well :)
[17:32] <ogra_> janimo, http://paste.ubuntu.com/1025386/ in case that helps you ... thats my config based on the 3.0 one, works fine since about six weeks for me
[17:32] <marvin24_DT> ogra_: what's you mem line if any?
[17:32] <ogra_> tegrapart=recovery:300:a00:800,boot:d00:1000:800,mbr:1d00:200:800 root=UUID=f8d60f31-32db-4655-8276-332dd4c7e703 mem=512M@0M quiet splash
[17:33] <ogra_> thats my cmdline
[17:35] <marvin24_DT> ok
[17:35] <ogra_> works fine with the binary driver
[17:39] <marvin24_DT> yes
[17:39] <marvin24_DT> I haven't tested mem=448M@0 yet
[17:40] <ogra_> well, mem=512M@0M somewhat sounds like we are stealing away all video ram
[17:40] <ogra_> but it doesnt seem to have any bad effect
[17:40] <marvin24_DT> it is reserved by the kernel now
[17:40] <marvin24_DT> I wonder if we need it at all
[17:40] <marvin24_DT> (I'm on for-next and too lazy to compile a 3.1 kernel
[17:41] <ogra_> i can try that if i'm through with the alpha1 tests tomorrow
[17:42] <marvin24_DT> no need, I can try it myself later on
[17:42] <ogra_> well, its not like we are in a hurry for quantal yet :)
[17:44] <marvin24_DT> who made the stupid decission to release a distro every 6 month ...
[17:44] <marvin24_DT> that's a lot of stress for everyone
[17:45] <ogra_> the initial ubuntu dev team did :)
[17:45] <marvin24_DT> if we had more time, I would give u-boot a try
[17:45] <marvin24_DT> get rid of fastboot
[17:45] <marvin24_DT> and android partitions
[17:45]  * ogra_ doesnt care ... 
[17:46] <ogra_> if we could have an installer that wouldnt require flashing as the first step, that would intrest me
[17:46] <ogra_> but the few MB you gain by dropping the partitions i dont really care about
[17:48] <marvin24_DT> remember that we still need this tegra/nvidia partitions patch
[17:49] <marvin24_DT> and the ugly command line to support it
[17:49] <janimo> hmm, no boot woth al those config options added
[17:50] <marvin24_DT> janimo: maybe you should try to lay you config beside and try paz00_defconfig first
[17:50] <marvin24_DT> janimo: can you post your config somewhere?
[17:50] <marvin24_DT> I'll try it here
[17:51]  * marvin24_DT just finished porting nvec to device tree and is in danger to get bored
[17:51] <janimo> yes, I may just try a simple defconfig build
[17:51] <janimo> I'll pastebin my config
[17:53] <janimo> marvin24, http://paste.ubuntu.com/1025415/
[18:06] <infinity> janimo: Are there enough cookies in the world to bribe you to figure out what's up with mono on armel?
[18:06] <janimo> infinity, vegan cookies?
[18:06] <infinity> Of course.
[18:07] <janimo> I am not suicidal enough from fighting git rebases and the slight twists in  kernel packaging on various trees that make me dig for hours so why not?
[18:08] <janimo> notice I talk like Ncommander when it comes to mono
[18:09] <janimo> only armel but armhf fine. Ah this is the new armel for v5 ?
[18:10] <janimo> infinity, is our armel like Debian's now?
[18:10] <infinity> janimo: Ish.
[18:10]  * NCommander bails out of the nearest window head first upon hearing NCommander and mono
[18:10] <infinity> janimo: Debian is v4t, we're v5t, but close enough.
[18:11] <janimo> but just enough not to freeload I guess :)
[18:11] <NCommander> janimo: infinity is it a FTBFS or something worse?
[18:11] <infinity> janimo: Freeloading should, in theory, work.  We may have toolchain issues confusing things.  Dunno.
[18:11] <janimo> NCommander, is there worse? :) glibc dobule free causing FTBFS
[18:11] <NCommander> The ARMv7 extensions were at one point #ifdef guarded, but upstream redid that patch a lot which may have broken it
[18:12] <NCommander> janimo: I recommend holy water and a sacrifice to $DIETY
[18:12]  * janimo wonders which deities are monkeys
[18:13] <infinity> Some Hindu ones, probably.
[18:13] <janimo> infinity, wikipedia confirms, and chinese and japanese too
[18:13] <janimo> a latino monkey deity would have been preferable though. oh well
[18:13] <infinity> Heh.
[18:17] <marvin24_DT> janimo: your config booted here
[18:54] <scientes> how do i debug unaligned memory fault in kernel code?
[19:01] <janimo> marvin24, oh nice. It may be a command line option then
[19:02] <janimo> So I may get the boot part, modify the cmdline in some meaningful way and retry
[19:07] <janimo> marvin24_DT, ^
[19:07] <janimo> marvin24_DT, is the nvec DT work required for mainlining?
[19:52] <marvin24_DT> janimo: nvec is already mainlined
[19:52] <marvin24_DT> it is required for the future ;-)
[19:53] <marvin24_DT> tegra arch will remove board files soon
[20:39]  * janimo is using a digital camera to film the ac100 screen while booting. Easier than going through all the trouble of figuring out how to get earlier kernel messages from a hung kernel
[20:40] <janimo> marvin24, here is hangs after Freeing init memory: 336K
[20:41] <janimo> unless I pass --no-log to the kernel it keeps saying it does not find init and ptys, but I see there are similar bugs in LP
[20:50] <janrinze> marvin24_DT: will the ASUS TF101 (transformer) be supported with this new endeavor?
[22:30] <ipersite> hi everybody
[22:31] <ipersite> nobody here?
[22:32] <TypoNAM> we're around, what's up?
[22:32] <ipersite> i need some help with the beaglebone. i think it's a stupid problem.
[22:34] <TypoNAM> I'm not familiar with that board, but I'm sure somebody here will help you figure it if you state what the problem is once they become available ;)
[22:34] <ipersite> thank you in advance :)
[22:35] <ipersite> anyway i just copied the preinstalled image on the sd card (zcat | dd)... put it in the board... and nothing happens!
[22:36] <TypoNAM> as in nothing on the monitor (if you have one connected) or nothing in the serial console (serial port connection)?
[22:37] <ipersite> I see two serial ports once I connect the usb cable (ttyUSB0/1)
[22:37] <ipersite> nothing appears on minicom
[22:37] <ipersite> it's 115200 8N1
[22:38] <TypoNAM> and software and hardware flow control is set to No/None right?
[22:38] <ipersite> exactly
[22:38] <TypoNAM> thats correct then, strange that you get two USB TTY devices from a single USB to serial adapter
[22:39] <TypoNAM> what USB adapter are you using?
[22:39] <ipersite> mmm.. the one integrated on the board
[22:39] <ipersite> Ltd FT2232C Dual USB-UART/FIFO IC
[22:40] <TypoNAM> ahh, an embedded FDTI chip
[22:40] <ipersite> right
[22:40] <ipersite> should i check other serial ports? using ttl to rs232/usb?
[22:41] <TypoNAM> I'm looking up the documentation on the beaglebone, see if I see something you might have missed ;)
[22:42] <ipersite> thanks... i checked all resources on the web, for ex. elinux.org gives instructions for manual installation but those don't apply to my case
[22:44] <TypoNAM> interesting trick/suggestion in the readme to use this instead of minicom: screen `ls /dev/{tty.usb*B,beaglebone-serial}` 115200
[22:46] <ipersite> ls: impossibile accedere a /dev/tty.usb*B: File o directory non esistente
[22:46] <ipersite> ls: impossibile accedere a /dev/beaglebone-serial: File o directory non esistente
[22:46] <ipersite> it means no such file or directory
[22:46] <TypoNAM> which revision of the beaglebone do you have?
[22:48] <ipersite> i think it's a3
[22:49] <ipersite> i'm not sure... wait i'm double checking
[22:49] <ipersite> ok is A5
[22:49] <TypoNAM> hmmmm
[22:50] <TypoNAM> ok, try the second ttyUSB in /dev/ if you haven't already
[22:51] <ipersite> already done... nothing
[22:51] <TypoNAM> what image file did you use to copy from on to the sd card/
[22:51] <TypoNAM> ?
[22:52] <ipersite> the one for omap3 server... (ubuntu-12.04-preinstalled-server-armhf+omap.img.gz)
[22:52] <TypoNAM> that looks right to me
[22:53] <TypoNAM> do you have another sd card you could try it on instead?
[22:53] <ipersite> yes of course. what do i need to try?
[22:54] <TypoNAM> try that same image, but on your other sd card and then place that into the beaglebone just to see if maybe its a problem with the first SD card
[22:55] <ipersite> i tried to flash the same sd with Angstrom dist. and it worked like a charm.
[22:56] <TypoNAM> hmmm, so its just a problem with the ubuntu 12.04 server image huh? :/
[22:56] <ipersite> mmm... i'll try with the desktop...
[22:57] <TypoNAM> the desktop image most likely does not have serial console enabled, of which is the case for pandaboard for example, so you'll need a monitor, keyboard, and mouse hooked up in order to make use of that image
[22:57] <ipersite> i don't have the dvi cape :(
[23:01] <ipersite> ok now i flash the sd with the desktop image...
[23:16] <ipersite> it's slower copying the desktop image that the server one
[23:16] <ipersite> despite the desktop image is 200MB less (compressed)
[23:24] <ipersite> ok finally... i'm testing
[23:25] <ipersite> nothing.. uff
[23:26] <GrueMaster> From what I have been told, beaglebone requires a different kernel.  If so, desktop & server will both fail you.
[23:26] <GrueMaster> (same kernel on both images).
[23:26] <ipersite> oh... and where i can get the working kernel?
[23:28] <GrueMaster> That I don't know.  Try asking on #beagle.
[23:28] <ipersite> thank you a lot.
[23:28] <GrueMaster> The Ubuntu omap image is (iirc) moving to community supported, so...
[23:29] <ipersite> ah...i didn't know that
[23:30] <infinity> We'd be happy if that community told us what we needed to do to make it work on the bone. :P
[23:30] <GrueMaster> Well, don't take my word for it, I no longer work on this project (I just pass on knowledge).
[23:30] <infinity> But I'm not going to buy the hardware and do it myself.  -ENOTIME.
[23:30] <GrueMaster> infinity == slacker.  :P
[23:31] <ipersite> eheheh
[23:31] <infinity> >:(
[23:31] <GrueMaster> You should be able to do it in your sleep.
[23:32] <infinity> I feel like there's a "that's what she said" joke there.
[23:34] <ipersite> ok, thank you guys, i'm going to sleep. bye and thanks again.