[01:25] <TheMuso> /c/c
[05:49] <heathkid> trying firefox
[05:49] <heathkid> just a sec
[05:49] <heathkid> win explorer completely crashed
[05:49] <heathkid> had to end process
[06:42] <cvanvliet> infinity, I heard in #beagle, that there is talk at TI re SGX, omap3 armhf
[06:42] <cvanvliet> they have it a copy internally
[07:57] <infinity> cvanvliet: Snazzy.
[07:57] <cvanvliet> who do we poke ;)
[07:58]  * cvanvliet wants an LTS version of ubuntu, just as much as any speed increase
[08:00] <infinity> cvanvliet: The poking would go to ndec and robclark, I assume, to get it released in the wild.  From there, we can probably hand-wavingly SRU it to precise.
[08:02] <cvanvliet> s/poke/beg
[08:07] <cvanvliet> if they are in the UK, I would certainly by them a beer ;)
[08:14] <ndec> infinity: neither robclark nor me are doing any work on OMAP3.
[08:15] <infinity> ndec: Fair enough.  Figured maybe that if there were shiny internal omap3 sgx builds, you guys might still be more in the know than, say, me.
[08:15] <ndec> nope.
[08:16] <infinity> Kay. :)
[08:16] <ndec> i think #beagle is the better place to ask.
[08:20] <cvanvliet> ndec, well for me it is about getting omap3 sgx into an ubuntu LTS, not just SGX
[08:20] <cvanvliet> but thanks, I will pursue there
[08:21] <ndec> the problem is armhf right? TI is doing SGX releases publicly for OMAP3, iirc.
[08:21] <cvanvliet> yes
[08:22] <cvanvliet> there is no roadblock here for me, it is just not how I want things :)
[08:22] <cvanvliet> everyone is moving towards armhf, and we will be stuck on armel
[09:07] <infinity> cvanvliet: If you can give me pointers to public omap3 sgx builds that will work on precise/armhf, I can drive getting them included in an SRU.
[09:09] <cvanvliet> thanks
[10:04] <ogra_> ndec, http://paste.ubuntu.com/1052388/ do you have any nice cpuinfo lines for me for omap4460 based blazes etc ?
[10:15] <ndec> ogra_: I don't have it, but the source code says this: http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=blob;f=arch/arm/mach-omap2/board-4430sdp.c;h=b61d0ed718a013557c4c5affd555be7b01729447;hb=2c963fa702cb8bcc4eb3a580e05e3304df4911b2#l997
[11:16] <lilstevie> ogra_: hardware line cardhu for tf201, and ofc cardhu development platform
[11:16] <lilstevie> ogra_: nvidia-tegra ofc
[11:17] <lilstevie> if you would like to add that one
[11:17] <ogra_> lilstevie, i need the exact copy/paste please
[11:18] <lilstevie> k sec
[11:18] <ogra_> ndec, hmm, so there is no 4460 blaze ?
[11:19] <lilstevie> http://paste.ubuntu.com/1052478
[11:20] <ogra_> uuh, ok
[11:20] <lilstevie> is there something you are looking for there that is missing?
[11:20]  * ogra_ has never seen such a short HW string on arm yet
[11:20] <lilstevie> heh
[11:21] <lilstevie> tf101 is the same
[11:21] <lilstevie> tf101 is ventana
[11:21] <lilstevie> nothing extra
[11:22] <ogra_> added both
[11:22] <lilstevie> thanks :)
[11:32] <ndec> ogra_: there are 4460 blaze, but they will use the same 'machine', so same output.
[11:32] <ndec> like panda btw.
[11:32] <ogra_> ok
[11:33] <ogra_> yeah, well, if someone is insane enough to use a lucid kernel on his install or so, the old values would still match
[11:33] <ogra_> (not that the driver would work though :P)
[11:33] <ndec> ogra_: that said... if you want to be doing something with some forward thinking... you need to handle device tree as well.
[11:33] <ndec> for DT, you will have 1 generic name for each CPU family. iirc
[11:34] <ogra_> well, 80% of our HW detection tools on arm use cpuinfo
[11:34] <ogra_> i wont have to care how it is populated
[11:35] <ndec> ogra_: but the cpuinfo/machine info will be different on a panda which is booted with DT
[11:35] <ogra_> oh, yeah, indeed
[11:35] <hrw> ogra_: so now we have one rfc822 database in flash-kernel?
[11:36] <ogra_> hrw, not sure if its rfc conform, but yeah, we have a DB
[11:36] <ogra_> i think infinity planned to actually split out a -data package that has only the DB
[11:36] <ndec> ogra_: if you look at that: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/board-generic.c;h=20293465786701f8650e1377ea070c6eee536673;hb=bc259adc9b76f625fff0423df3ffb80a03802927
[11:36] <ndec> you see that all OMAP4 will show up as "Generic OMAP4 (Flattened Device Tree)"
[11:37] <ndec> and all OMAP5 will be "Generic OMAP5 (Flattened Device Tree)"
[11:37] <ndec> etc...
[11:37] <ogra_> right, but "OMAP4" would match all oamp4 devices still
[11:37] <ogra_> even if i would have typed it right :P
[11:37] <ndec> note that it will be a problem ... since not all OMAP4 will use the same pvr-omap4 ;-)
[11:37] <ndec> 4430 and 4460 have the same GPU, 4470 have a different GPU.
[11:38] <ogra_> for these we need a more specific matching then
[11:38] <ndec> with conflicting libs in the user space
[11:38] <hrw> 4470 got MP2 powervr?
[11:38] <ndec> 4470 544, single core
[11:38] <ogra_> for now the concept of having a line per supported SoC should be fine
[11:38] <lilstevie> is that exported somewhere though
[11:38] <ndec> OMAP5 is 544 MP2
[11:39] <lilstevie> or visible from sysfs
[11:39] <ndec> lilstevie: i don't know for now. we manage it 'by hand' for now, and don't have a clean solution yet.
[11:40] <lilstevie> sure
[11:43]  * XorA|gone wonders when PVR will catch up with the 1990s and have runtime detection
[11:52] <lilstevie> heh
[11:52] <lilstevie> the tegra driver does it
[11:53] <ndec> lilstevie: how is it done on the tegra? 1 set of user space binary blobs that work on multiple h/w? or is it doing some symlinks tricks?
[11:56] <lilstevie> 1 binary
[11:57] <lilstevie> they have released platform tarballs for each development device, but the binaries work across devices just fine
[12:04] <ndec> lilstevie: ok... we aren't there yet with PVR.
[12:04] <lilstevie> fair enough
[12:04] <lilstevie> it is all good having one binary, but five binaries that work would be better :p
[12:05] <ndec> well, we have the binaries that work ;-)
[12:07] <lilstevie> heh
[12:07] <lilstevie> tegra ones are horrible
[12:07] <lilstevie> the latest release is probably the best yet though
[12:07] <lilstevie> :p
[13:19] <janimo> ogra_, so did you test with current 3.1 kernel and graphics work with the latest nvidia drivers?
[13:19] <janimo> if so the ac100-meta can also be bumped to make the 3.1 version the default
[13:20] <ogra_> janimo, i think infinity did right after your upload anyway :)
[13:20] <ogra_> and yes, a smoketest worked
[13:20] <janimo> ogra_,  I thought so too, but I tried the installer yesterday and got 3.0,27
[13:20] <ogra_> i havet used it for long though
[13:20] <janimo> the installer crashed though
[13:20] <ogra_> i dont think we have recent ac100 images for quantal yet
[13:21] <janimo> ogra_, ah I missed they were dated May 30
[13:21] <ogra_> http://cdimage.ubuntu.com/daily-preinstalled/current/ has images from may 30
[13:21] <janimo> just saw they're under jun 18 or such
[13:21] <ogra_> i fixed flash-kernel though, the next successfull build should have them
[13:21] <janimo> ogra_, is this because the kernel will likely not boot?
[13:21] <janimo> ogra_, good to know then
[13:22] <ogra_> the kernel will likely need a console statement or so
[13:22] <ogra_> in the bootargs
[13:22] <ogra_> but i first want working images before i look into details
[14:52]  * satellit_ testing TrimSlice -h 250 
[22:18] <robclark> rsalveti, ogra_, we need precise on http://www.engadget.com/2012/06/21/hp-passport-1912nm-internet-monitor/  :-)
[22:19] <robclark> actually you might even just be able to take an o4/panda image and boot it.. not sure, maybe there is a new board file, etc..