[01:49] <Tinti> hello, I am following the rootsock documentation in https://wiki.ubuntu.com/ARM/RootfsFromScratch is there  a new documentation? It is not working for precise 12.04 but I finally have succeed in building an image
[01:49] <Tinti> if I could help anyone
[02:44] <lilstevie> robclark: that is pretty awesome
[02:46] <infinity> robclark: Only $259?  That makes it more cost-effective than a Panda with a monitor.  Not bad.
[02:50] <TheMuso> Sounds cool./
[03:12] <robclark> lilstevie, infinity, from what I understand it is running a sort of customized ubuntu 10.10 already.. but hopefully when they post the kernel the board support isn't too hard to forward port and get newer kernel and 12.04 running on it
[03:21] <infinity> robclark: Hang a USB drive off the thing, and it would be a perfect devel kit to recommend to people.
[03:21] <rsalveti> robclark: that's cool
[03:21] <robclark> yup
[03:25] <ojn> robclark, do you know if it's a 4430 or 4460? hard to argue with that price for something that has a monitor, etc.
[03:25] <robclark> I think it is 4430
[03:27] <heathkid> support for realtek USB wifi?
[03:28] <robclark> http://h18000.www1.hp.com/products/quickspecs/14358_na/14358_na.HTML#Technical Specifications
[03:29] <ojn> robclark, excellent, thanks!
[03:36] <lilstevie> I kinda want one
[03:42] <lilstevie> I also noticed that it has flash
[06:54] <cvanvliet> Tinti, I am trying to do a 12.04 image for gumstix (armel), and got errors - Failed to create pty - disabling logging for job
[06:55] <infinity> cvanvliet: Does your kernel have support for devpts?
[06:57] <cvanvliet> I only compiled my first kernel  a few days ago, and am not great with kernel foo yet, wil check it
[06:59] <cvanvliet> (what I did do was enable initramfs, and move init to / and it helped, but ended up in init being /bin/sh?)
[07:00] <cvanvliet> bbs, thanks infinity
[07:07] <cvanvliet> quick check -> yes, unix98 and bsd are both enabled
[07:13] <infinity> Okay, but it sounds like you're doing some odd things with your initramfs...
[07:13] <infinity> Are you creating it with update-initramfs?
[07:13] <infinity> I mean, talk of moving init around and whatnot sounds a bit unconventional. :P
[07:13] <cvanvliet> yes
[07:14] <cvanvliet> infinity, I am mainly trying to learn, don’t take anything I say as being correct
[07:14] <infinity> Anyhow, I probably shouldn't get into this tonight, I need to sleep and be up early.
[07:14] <cvanvliet> thanks
[07:15] <infinity> But, yeah.  If you think you need to move init around, you're almost certainly doing something wrong elsewhere. ;)
[07:15] <cvanvliet> I may have just seen something :/, let me try
[07:15] <cvanvliet> thanks!
[13:32] <ppisati> ogra_: we are going to stay with this kernel for omap4, sorry
[13:32] <ppisati> ogra_: tilt-tracking is heavily based on linaro kernels
[13:33] <ppisati> ogra_: and a rebase gave me all kinds of clashes
[13:33] <ppisati> ogra_: after alpha2 is out, i'll start building a 3.5 kernel for omap4 (as the email on the ubuntu kernel ml stated)
[13:36] <ogra_> damned
[13:36] <ogra_> but ok
[13:36] <ogra_> i guess then we cant really make A2
[13:37] <ogra_> (with the display issues and the switch to full live images we wont have a way to install)
[13:37] <ppisati> ogra_: it works for some monitors actually
[13:37] <ogra_> i have tried three so far
[13:37] <ogra_> none of them works
[13:38] <ppisati> i dont' know what to tell
[13:38] <ppisati> i've two here and they work
[13:38] <ogra_> n othing to tell, ndec already said they completely reworked the graphics driver
[13:38] <ogra_> we just need that code dump ....
[13:39] <ndec> but we don't have it for 3.5
[13:39]  * ndec checks ubuntu kernel list...
[13:39] <ogra_> oh, i thought you said it was 3.5
[13:39] <ppisati> nope
[13:39] <ppisati> still 3.4 for them
[13:39] <ogra_> my prob is that omap doesnt boot either
[13:40] <ppisati> and it's actually 3.4 + a lot of stuff from linaro + ...
[13:40] <ogra_> and ac100 doesnt build yet
[13:40] <ppisati> a disaster! :)
[13:40] <ndec> we have 'frozen' tilt-3.4 just today. so tilt-tracking will start tracking 3.5 any day now.
[13:40] <ogra_> so we wont have any arm images for A2
[13:40] <ppisati> wait wait
[13:40] <ppisati> what's wrong with omap?
[13:40] <ndec> however we (TI) will not spent a lot of energy on 3.5...
[13:40] <ndec> so i am not sure which features will work in 3.5
[13:41] <ogra_> ppisati, given that the QA team only has 5 weeks left to get their automated testing working, it is a desaster, there are no images yet for them to write scripts for
[13:41] <ndec> yet
[13:41] <ppisati> ndec: i know i know, we are going to use 3.5 upstream after alpha2 + cherry picks useful stuff from tilt
[13:41] <ndec> it's likely that the TILT 3.5 won't get many more than what's in mainline already
[13:42] <ndec> so ppisati what's the problem exactly?
[13:42] <ppisati> ogra_: what's wrong with omap?
[13:42] <ogra_> oopses all over the place
[13:42] <ogra_> we didnt release it for A1 if you remember
[13:42] <ppisati> ogra_: i've been testing it till an hour ago
[13:42] <ndec> 3.4?
[13:42] <ppisati> ndec: 3.5
[13:42] <ndec> ah...
[13:42] <ogra_> ndec, oopses -> omap3 ...
[13:42] <ogra_> not omap4
[13:43] <ndec> tilt-3.4 should be in quite a good shape on OMAP4 and 5.
[13:43] <ndec> hum. omap3?
[13:43] <ogra_> omap4 3.5 simply freaks out with the wlan device (demsg gets massively spammed) and doesnt detect any monitor here for me
[13:43] <ogra_> err 3.4 that is ...
[13:44] <ppisati> ogra_: me and ming were tracking down an mmc/fs issue in omap for 3.5
[13:44] <ppisati> ogra_: but apart from that, kernel works here
[13:44] <ogra_> ah
[13:44] <ndec> we use wlan with 3.4-tilt with *precise* these days. and it seems to be working.
[13:44] <ppisati> it seems it's an sd card problem with a late commit
[13:44] <ogra_> ppisati, well, it didnt for A1 thats why it was decided to be dropped
[13:45] <ppisati> ogra_: video wasn't working iirc
[13:45] <ppisati> ogra_: anyway, let me check
[13:45] <ogra_> and with the switch to full live images the XM install (with only 512M) wont be any fun anymore ... apart from fully relying on video
[13:46] <ogra_> infinity, around ?
[14:12] <ppisati> ogra_: i still believe we should enable serial console output by default
[14:16] <ogra_> that wont help anymore
[14:17] <ppisati> why?
[14:17] <ogra_> we are just in the process to switch to full live images, serial wont gain you anything there
[14:18] <ppisati> and how do we debug problems during installation?
[14:18] <ogra_> (upstart doesnt enable serial by default so you wont have a login, quiet and splash are set as default so you wont get much kernel output)
[14:18] <ogra_> oh, for debugging you just dump an uEnv.txt in place
[14:18] <ogra_> with the cmdline you want
[14:19] <ppisati> ogra_: so, i;m trying the daily image installation
[14:19] <ppisati> ogra_: omap3 on a beagle xm
[14:19] <ogra_> but that wont get you anywhere with a live image
[14:19] <ogra_> since the installer doesnt run on serial
[14:20] <ppisati> ogra_: i modifided boot.scr to have srial output
[14:20] <ppisati> and it's X failing
[14:20] <ogra_> right, you can just use uEnv.txt nowadays
[14:20] <ogra_> no need for fiddling with mkimage etc
[14:20] <ogra_> lucky you, for me it didnt boot (with A1 at least)
[14:21] <ppisati> daily from today
[14:21] <ppisati> so maybe we can fix it
[14:21] <ogra_> yeah, but there werent any omap related changes, were there ?
[14:21] <ppisati> eutehr something screwed in the kernel (omapfb&c)
[14:21] <ppisati> well, we passed from 3.4 to 3.5
[14:21] <ppisati> so, everything could have happened
[14:22] <ogra_> ah, well, i'll try an omap image on monday, currently i'm focused to get omap4 live working
[14:22] <ppisati> ok, let's do that
[14:22] <ppisati> btw, can you get a new sd card and try an old P release on that panda?
[14:22] <ogra_> why a new SD card ?
[14:22] <ppisati> i wonder if video output is ok
[14:22] <ppisati> or rewrite it, whatever
[14:22] <ppisati> i mean, don't dump your installation
[14:22] <ogra_> i teasted all püanda images during precise development
[14:22] <ogra_> well, all milestones
[14:23] <ogra_> including the final reelase
[14:23] <ogra_> there were no issues at all
[14:23] <ogra_> (and you asked me to test the precise kernel when my A1 image didnt work if you remember)
[14:24] <ogra_> downgrading to the precise kernel fixes everything here
[14:25] <ppisati> ah, when was last time you had a working video kon that?
[14:25] <ppisati> because
[14:25] <ppisati> http://www.kernelhub.org/?msg=30802&p=2
[14:25] <ppisati> there was a window of time
[14:26] <ppisati> where you could destroy your video output
[14:37] <ppisati> reboot
[14:51] <cvanvliet> what are the differences between ubuntu and linaro ( particularly omap3 , SGX)
[14:53] <ogra_> linaro takes snapshots of the ubuntu archive and rolls monthly images from them
[14:53] <ogra_> on top of that they include their imporvements that will soon land in the ubuntu archive ...
[14:53] <ogra_> they dont support their images though ... no security fixes updates etc
[14:55] <ogra_> so you get an image with outdated (or the same) SW from the last ubuntu release but with added linaro sweetness on top (toolchain fixes, other kernels, bootloaders etc)
[14:57] <cvanvliet> ok, that clears a lot up
[14:57] <Tinti> hello ogra_ did you wrote rootstock tool?
[14:57] <ogra_> Tinti, yes, but its dead since over a year now
[14:58] <cvanvliet> was Tinti the gumstix guy earlier?
[14:58] <Tinti> I saw, I want to start developing in linaro do you have any advices or tools that I should use?
[14:59] <ogra_> ask in #linaro ? :)
[14:59] <Tinti> cvanvliet, no I am Tinti for a long time :)
[14:59] <cvanvliet> I think I jumped to conclusion
[14:59] <cvanvliet> sorry long night :/
[15:00] <Tinti> in fact I am there but I am not getting much things ... in fact I would like to get recommendations from you. probably you have switched from rootstock to something else right?
[15:01] <ogra_> nope
[15:01] <ogra_> rootstock was never actually used anywhere in ubuntu, it was just a script combining a lot of hacks
[15:01] <ogra_> to roll a rootfs you can use live-build ... and i think there are a ton of linaro tools to create images
[15:02] <ogra_> so best ask in linaro (we dont use these tools either in ubuntu, #linaro is a better place to ask about this)
[15:02] <Tinti> yes there are, I was thinking in use it
[15:02] <cvanvliet> are they any tutorials to get 12.04 armel up an running?
[15:03] <ogra_> well, there are installation howtos for the official images
[15:03] <Tinti> yeah thanks. I need to compile an environment for iMX51
[15:04] <Tinti> I would like to do it from scratch in fact
[15:04] <infinity> ogra_: Around now...
[15:04] <cvanvliet> ogra, I have tried most of these (they all seem beagle based)?
[15:04] <ogra_> infinity, so i will switch the crontab to roll live images for omap, omap4 and mx5 today
[15:05] <ogra_> infinity, what do we do about preinstalled server ?
[15:05] <Tinti> cvanvliet, I really would like to have this
[15:05] <infinity> ogra_: We leave it as-is for now.
[15:05] <ogra_> i dont want to introduce alternate again
[15:05] <ogra_> ah, cool
[15:05] <infinity> ogra_: If x86 server switches to live, we'll follow suit.
[15:05] <ogra_> cvanvliet, right, they are either beagle, panda or freescale mx5 based
[15:05] <cvanvliet> netboot, server image (armhf), build up form ubuntu core, qemu-debootstrap
[15:05] <infinity> ogra_: Most sane server users install from d-i netboot anyway, regardless of the platform.
[15:06] <cvanvliet> ogra I have a gumstix
[15:06] <ogra_> infinity, they dont switch to live, they just use a squashfs in d-i
[15:06] <Tinti> the tutorials seems to be old in fact no?
[15:06] <Tinti> at least on wiki
[15:06] <ogra_> right, server on omap or omap4 is mostly intresting as minimal dev image
[15:06] <infinity> ogra_: That's a "live-style" install.
[15:06] <ogra_> well, its still d-i
[15:06] <infinity> ogra_: As in, no more installing packages.
[15:06] <ogra_> :)
[15:06] <ogra_> right
[15:06] <infinity> ogra_: ubiquity is d-i.
[15:07] <ogra_> pfft, yeah
[15:07] <infinity> I see this as "text ubiquity". :P
[15:07] <ogra_> k ... so i wont touch server ... thats good
[15:07] <ogra_> wrt install speed live is pretty horrid btw
[15:07] <ogra_> especially the partitioner takes like 5min after you clicked anything
[15:08] <ogra_> my test install took about 90min until it failed in the bootloader install
[15:08] <infinity> That seems odd.
[15:08] <infinity> The 5m partitioner thing, I mean.
[15:08] <infinity> I expect the copy to be slow, not much else.
[15:08] <ogra_> thoguh i'm trying out the slowest HW combo i can atm
[15:08] <infinity> Oh, installing to a USB stick?
[15:08] <cvanvliet> ogra, the live installs ar armhf? I assume
[15:09] <ogra_> i.e. installing to an SD in a cardreader as target
[15:09] <ogra_> cvanvliet, everything is armhf
[15:09] <ogra_> we dropped armel last release
[15:09] <cvanvliet> yep
[15:09] <cvanvliet> armel is dropped after precise ?
[15:09] <ogra_> while the archive is still there it is currently largely unmaintained and we dont roll any images for that arch
[15:09] <infinity> cvanvliet: We didn't ship armel images for precise either.
[15:10] <infinity> cvanvliet: Just netboot images (which we still ship).
[15:10] <cvanvliet> there is a core though
[15:10] <ogra_> and its likely it will be completely dropped before final release
[15:10] <cvanvliet> infinity, it wont find my ethernet
[15:11] <ogra_> file a bug and ask for the NIC driver module to be included in the installer
[15:11] <ogra_> (file it against linux and debian-installer)
[15:12] <infinity> We might not have the driver at all, if this is an SoC we don't support.
[15:13] <ogra_> gumstix ?
[15:13] <ogra_> should all be in mainline
[15:13] <infinity> Or a device.
[15:13] <cvanvliet> ok
[15:13] <cvanvliet> the base is a Tobi board
[15:14] <ogra_> never heard of that
[15:16] <cvanvliet> I have to reconsider somethings now (re support of armel)
[15:16] <cvanvliet> wish they would just release the drivers for armhf
[15:17] <ogra_> they will at some point, all distros are switching
[15:20] <cvanvliet> I feel that way to, but, I am trying to find the best tools for use (this is for my business)
[15:21] <ogra_> ppisati, hmm, https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001440.html only talks about a 3.4 tilt kernel
[15:22] <infinity> cvanvliet: Just keep pestering people in #beagle until an sgx drop appears, and let me know? ;)
[15:22] <cvanvliet> infinity, you will know within seconds
[15:22] <cvanvliet> I may also try Imagination (the powervr guys)
[15:22] <infinity> We have PVR on armhf.
[15:23] <infinity> Err, for omap4, that is.
[15:23] <ogra_> just not for the chip in the beagle
[15:23] <infinity> YOu could just switch SoCs. :)
[15:23] <cvanvliet> they are in the UK, and may have a symapthetic ear for a UK startup :p
[15:23] <cvanvliet> sorta
[15:23] <cvanvliet> that was my thinking above in my reconsider
[15:23] <infinity> I suspect they won't do much for you.  Their licensees are the ones who are responsible for code drops.
[15:24] <infinity> (In this case, TI)
[15:24] <cvanvliet> ok
[15:24] <ppisati> ogra_: it's a 3.4 + all linaro stuff
[15:24] <ogra_> ah, k
[15:25] <ppisati> ndec: AFAYK, FB_OMAP + DSS is enough to get decent video support for omap3, right?
[15:25] <ppisati> ndec: and what about DRM_OMAP?
[15:25] <ndec> well, i think robclark tested DRM_OMAP on beagle...
[15:25] <ppisati> ndec: DRM_OMAP and FB_OMAP can't live together
[15:25] <ndec> if that works, that's what we should be using i think...
[15:26] <ogra_> ppisati, and very very likely three tons of commandline options you need to set to even see a single pixel :)
[15:26] <cvanvliet> I may be wrong but omap4 is not industrial grade
[15:26] <ogra_> if not five tons
[15:26] <ogra_> (metric tons)
[15:26] <infinity> cvanvliet: Define "industrial grade".
[15:26] <ppisati> the problem is that, FB_OMAP i get /dev/fb, right?
[15:26] <ppisati> while with DRM_OMAP do i need an external video driver? like pvr or what?
[15:26] <ogra_> well, fb0
[15:27] <ogra_> but yeh, that should be the difference
[15:27] <cvanvliet> infinity, that was the answer I got form our supplier, only yesterday, I have to follow that up
[15:27] <ogra_> (for details ask koen in #beagle ;) )
[15:27] <robclark> w/ omapdrm you will get a /dev/fb0 as well.. and xf86-video-omap will work without pvr (but without accel)
[15:28] <infinity> cvanvliet: I mean, what do you mean by "industrial grade".  Are you building life-and-death-critical systems, telco backbones...?
[15:28] <ppisati> robclark: so, which one is better/the right one? DRM or FB_OMAP?
[15:28] <ogra_> robclark, on omap3 ?
[15:28] <infinity> cvanvliet: Or is it just about wanting "reliable parts"?  In which case, omap4 seems to be good enough for Amazon and HP (and many others).
[15:28] <infinity> ogra_: He claims all the way back to omap2, though not tested. ;)
[15:28] <ogra_> heh
[15:29] <robclark> ogra_, it should work on omap3..  admittedly it gets tested more on omap4, but I'll fix bugs if there are any on omap3
[15:30] <robclark> infinity, some of the o3 based parts (and other various parts) are avail in industrial package for harsh environments
[15:30] <infinity> robclark: Ahh, kay.
[15:31] <infinity> robclark: Again, I'm curious if that's actually what cvanvliet needs.
[15:31] <cvanvliet> infinity, yeah our supplier is generally in that area, and we may be at a later point, but not right now.
[15:31] <cvanvliet> but, they already haev a product, very similar to what we need
[15:32] <cvanvliet> so we don’t have the engineering costs
[15:32] <cvanvliet> and we can tweak it a little
[15:32] <cvanvliet> to suite our stuff, it is based on omap3 (igep boards)
[15:33] <cvanvliet> infinity, it is more which is the easiest (and cheapest ) way for a self backed start up :)
[15:34] <infinity> cvanvliet: Absolutely.  Build-your-own hardware isn't a sane way to startup, unless your business model is, in fact, designing hardware.
[15:34] <cvanvliet> but our stuff is not life or death, that is for sure
[15:35] <cvanvliet> so that is why I want 12.04, armel, SGX in omap3
[15:36] <cvanvliet> we do a lot of 3d display
[15:37] <infinity> cvanvliet: Check.  Well, we'd all prefer if we could make that be armhf (but until we see an sgx driver, meh), but there's certainly no one stopping you from using 12.04 armel.  It's not "officially supported", but it's not going away for 5y either.
[15:38] <cvanvliet> i just need to get it going ;)
[15:38] <cvanvliet> infinity, we make things like hawk-eye for sports
[15:39] <infinity> cvanvliet: Sounds fun.
[15:39] <cvanvliet> accelerometers, forceplates,  camera etc
[15:39] <cvanvliet> starting in golf industry
[15:40] <infinity> Sounds like an industry where price-point isn't dead critical, and omap4 might be viable.
[15:40] <cvanvliet> yes
[15:40] <infinity> (And I can't think insane durability is important either)
[15:41] <infinity> Not that I'm recommending you start from scratch. :P
[15:41] <GrueMaster> Depends on if you are hitting the device with a driver.
[15:41] <cvanvliet> we have enough to do as it is
[15:41] <infinity> Starting from scratch every 6 months leads to Duke Nukem Forever disease.
[15:41] <GrueMaster> Most electronics don't take well to being clubbed.
[15:41]  * ogra_ prefers hiting devices with wrenches
[15:42] <cvanvliet> GrueMaster, Xbee plus arduino can fly 30 metres ;)
[15:42] <cvanvliet> when gaffa tape breaks on a golf club :p
[15:42] <GrueMaster> Heh
[15:42] <ogra_> drivers look so new-rich ... wrenches are more "male" :)
[15:43] <ppisati> uhm
[15:43] <ppisati> is it normal for my board to use fbdev?
[15:43] <ogra_> yes
[15:43] <ppisati> well
[15:43] <ogra_> on all arm boards
[15:43] <ppisati> X says i'm having a 1280x720 display
[15:43] <ppisati> but to me it looks like 640x480
[15:43] <ogra_> (until we are installing SGX or whatever)
[15:43] <ogra_> thats omap3 ?
[15:43] <ppisati> yes
[15:44] <ogra_> well, as i said, three tons of cdmline options
[15:44] <ppisati> i'm using FB_OMAP here
[15:44] <ppisati> with
[15:44] <ppisati> vram=12M omapfb.mode=dvi:1280x720MR-16@60
[15:44] <ppisati> isn'it enough?
[15:44] <ppisati> and what do we use for our installer?
[15:45] <ogra_> nothing
[15:45] <ppisati> so how does it work?
[15:45] <ogra_> we always asked the kernel team to set a proper default :P
[15:45] <ppisati> uh?
[15:46] <ogra_> and with the merge of omap in mainline that default should have been carried over
[15:46] <ogra_> it likely wasnt though and we need to set a cmdline option again to get a proper mode
[15:46] <ogra_> i remember in the first images we had omapfb.mode=dvi:1280x720MR-16@60
[15:46] <ogra_> but i'm not even sure the option is still called like that
[15:47] <rcn-ee> it is, just not for omapdrm/kms..
[15:47] <GrueMaster> Note that the above setting is for wide screen.  Looked like crap on my 19" standard LCD monitors.
[15:47] <ogra_> well, he built with FB_OMAP
[15:48] <rcn-ee> yeap, so it should work. ;)
[15:48] <ogra_> not DSS
[15:48] <GrueMaster> I used 1280x1024.
[15:48] <ppisati> so, in P we were using FB_OMAP
[15:48] <ppisati> so, either we passed something in the cmdline
[15:48] <ppisati> or i don't know
[15:49]  * ppisati trying with a kernel with FB_OMAP
[15:49] <rcn-ee> once it's up, can you access /proc/cmdline...
[15:49] <ppisati> rcn-ee: talking about the installer
[15:50] <rcn-ee> the older d-i? or the live-cd thing..
[15:50] <ogra_> ogra@nusakan:~/branches/debian-cd$ grep omapfb tools/boot/quantal/post-boot-armhf+omap
[15:50] <ogra_>     v_opts="vram=12M omapfb.mode=dvi:1280x720MR-16@60"
[15:50] <ppisati> the one that we use with the preinstalled-omap image
[15:51] <ogra_> ppisati, you are right, we do set it on omap3
[15:51] <ppisati> ok, cool
[15:51] <ogra_> probably needs some adjustments
[15:51] <GrueMaster> Too bad it can't do autodetect.
[15:52] <ogra_> i was promised autodetection for ages
[15:52] <rcn-ee> it was set to that, since the default u-boot value was so small.. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap3_beagle.h;hb=HEAD#l229
[15:52] <ogra_> a bitz longe than i was promised unity 3d on arm (which only twook 2 years)
[15:52] <rcn-ee> actually autodetection works pretty good with v3.3/3.4 (omapdrm/kms) on the beagle. ;)
[15:53] <ogra_> "pretty good" ?
[15:53] <ogra_> like every tenth time ? on every second board ?
[15:53] <ogra_> or is it already reliable
[15:53] <ppisati> rcn-ee: so, what's the difference between drm and fb_omap?
[15:53] <rcn-ee> works on my 4-5 monitors.. (but until recently it wasn't stable enough to push to all users)
[15:54] <rcn-ee> both use omapdss internally. ;)
[15:55] <rcn-ee> ppisati, you better ask robclark, he wrote alot of the omapdrm/kms stuff.. i just enable/tweak it...
[15:56] <ppisati> robclark: ^
[15:56] <robclark> omapfb is using old fbdev driver infrastructure/interface..  omapdrm is using drm/kms..
[15:56] <robclark> short version, w/ omapdrm you can get xrandr
[15:57] <robclark> (and dri2, hotplug detection, etc)
[15:57] <ogra_> well, if its stable i'm all for switching
[15:57] <ppisati> robclark: any drawback?
[15:58] <ppisati> btw, just compiled in fb_omap, X is up, but i don't have any output
[15:59] <robclark> well.. omapdrm is newer... sometimes exposes some issues in omapdss, relies on monitors to have sane EDID (although more recently there is some drm bootargs added to allow reading EDID from firmware file to deal with broken monitors)
[16:03] <ppisati> omapfb omapfb: no driver for display: dvi
[16:03] <ppisati> uhm
[16:03] <rcn-ee> ppisati, this is 3.4 or 3.5?
[16:04] <ppisati> 3.5
[16:04] <rcn-ee> ah, haven't figured that one out yet, it was broken in rc3 last tried, sorry..
[16:05] <ppisati> rcn-ee: are you saying fb_omap is broken somehow?
[16:06] <rcn-ee> with 3.5-rc3, it oppes'ed on my beagle_xm, and the display didn't come up, didn't dig into to much as i'm mostly on 3.4.x at the moment.. but the stuff for rc4 probally fixed that..
[16:43] <ppisati> this time fb seems to be ok
[16:43] <ppisati> fbcvt: 1280x720@60: CVT Name - .921M9-R
[16:43] <ppisati> but i still get an ugly 640x480
[16:43] <ppisati> any idea how to debug this?
[16:55] <GrueMaster> ppisati: What does xdpyinfo thing the resolution is?  And does your monitor display the incoming signal info?
[17:18] <rsalveti> ogra_: edid autodetection should work on omap3 just fine
[17:18] <rsalveti> it was supported by upstream since 3.2 I believe
[17:20] <rsalveti> if you're using omapfb with panel-dvi you should also get edid detection
[17:21] <ppisati> rsalveti: panel-dvi?
[17:21] <rsalveti> CONFIG_PANEL_DVI
[17:21] <rsalveti> drivers/video/omap2/displays/panel-dvi.c
[17:21] <rsalveti> this is based on an implementation I had for quite a while ago
[17:22] <ppisati> rsalveti: it seems they killed it in 3.5
[17:22] <ppisati> ls -la drivers/video/omap2/displays/*dvi* | wc -l
[17:22] <ppisati> 0
[17:22] <rsalveti> could be, let me check
[17:23] <rsalveti> omapdrm should probably be replacing most of the stuff
[17:23] <ppisati> trying that right now
[17:25] <ppisati> PANEL_TFP410?
[17:26] <ppisati> ok, it was renamed
[17:33] <rsalveti> ppisati: yup
[17:34] <ppisati> rsalveti: so i assume i need to change cmdline too
[17:35] <ppisati> rsalveti: from omapfb.mode=dvi:1280x720MR-16@60 to omapfb.mode=tfp410:...
[17:36] <ppisati> btw, enabling DRM_OMAP didn't give me any /dev/fb*, what's wrong?
[17:36] <ppisati> robclark: ^
[17:38] <robclark> ppisati, if using omapdrm, then omapfb.mode won't do anything.. but you also shouldn't need it..
[17:38] <robclark> but possibly the kernel is not registering the platform device?
[17:39] <rsalveti> ppisati: you don't need any cmdline for this panel as well
[17:39] <ppisati> wait
[17:39]  * robclark wonders what kernel we are talking about?
[17:39] <ppisati> robclark: didn't you say that with DRM_OMAP we would get a /dev/fb, right?
[17:40] <ppisati> robclark: foerget about the omapfb stuff, i'm testing DRM and FB_OMAP in parallel
[17:40] <ppisati> 3.5rc3
[17:40] <robclark> yes, you will..  but only if the driver is loaded (which it won't be if the device is not registered)
[17:40] <robclark> if pure upstream kernel, there is one patch you need
[17:40] <ppisati> robclark: it's pure upstream
[17:41] <robclark> k, hang on
[17:41] <ppisati> rsalveti: on the other hand, with FB_OMAP we always passed omapfb.etcetc
[17:42] <rsalveti> ppisati: but it's not needed with this panel, afaik
[17:42] <ppisati> rsalveti: uhm ok
[17:42] <robclark> ppisati, http://permalink.gmane.org/gmane.linux.ports.arm.omap/77544
[17:43] <ppisati> robclark: ack, i'll try
[18:55] <ppisati> robclark: added your patch on top of 3.5rc3, got /dev/fb0 but still no output
[18:55] <ppisati> anywa, i'm off for the day
[18:56] <robclark> ppisati, I guess next step, turning on omapdss.debug=1 and possibly drm.debug=7 in bootargs and then start havign look at the log
[19:24] <Pokinawa> hello people....
[19:25] <Pokinawa> anyone here work at ARM? :P