[08:53] <punxos> Hi
[10:25] <ppisati> ogra_: do i remember misremember, or does the preinstalled image resize during the first boot?
[10:25] <ogra_> it does
[10:26] <ogra_> it resizes, does some config bits and then does an auto-reboot
[10:28] <ppisati> ogra_: but there's no output on console
[10:28] <ogra_> on which image ?
[10:28] <ppisati> ogra_: previously i remeber something was written out
[10:28] <ppisati> preinstalled oma3
[10:28] <ppisati> omap3
[10:28] <ogra_> desktop images write to the splash only
[10:28] <ogra_> its just the server image that writes to console
[10:29] <ppisati> ok
[10:30] <ogra_> what are you installing, desktop ?
[10:30] <ogra_> you will need a monitor for that, else you cant use oem-config on the second boot
[10:35] <ppisati> ogra_: saw it
[10:35] <ogra_> :)
[10:36] <ppisati> ogra_: actually, the image from friday still had a 3.0.x kernel (and thus broken usb) but the video was ok
[10:36] <ppisati> ogra_: 28nov image has kernel 3.2.x
[10:36] <ppisati> ogra_: so good usb but my monitor says "out of range freq"
[10:37] <ppisati> ogra_: now i wonder if it's a "new feature" of the new kernel or any other new component
[10:37] <ogra_> we didnt change anything in arm land yet
[10:37] <ogra_> the build should be identical to oneiric, modulo the general package updates we inherit
[10:37] <ppisati> all the pkgs are still O? at least the kernel is not
[10:37] <ogra_> (which indeed could be at fault)
[10:38] <ppisati> btw, this on a xm rev c
[10:38] <ogra_> no, thats what i mean ... there were package updates ... but no specific arm changes yet
[10:38] <ppisati> ok
[10:38] <ogra_> does linaro have rev C's ? they probably know what could cause it
[10:40] <ppisati> the problem with the rev c was usb only
[10:40] <ppisati> but has been fixed upstream
[10:40] <ppisati> what i discovered this morning
[10:40] <ppisati> is that we lost video output now
[10:41] <ogra_> right, which could be either xorg or the kernel DSS driver
[10:41] <ppisati> right
[10:43] <ogra_> and to my knowledge nothing in xfbdev (which is our default Xserver on all arm images) has changed
[10:48] <ogra_> to me it smells like an EDID issue
[10:48] <ppisati> we dropped one patch in 3.2
[10:48] <ppisati> but according to the maintainer, it was not needed anymore
[10:49] <ogra_> well, i know rsalveti tried to get some EDID stuff upstream for omap3 since a while, that might have landed and be broken or something similar
[10:50] <ppisati> is there a deafult user before oem-config completes?
[10:51] <ogra_> no
[10:51] <ogra_> do you get the out of sync message only when x starts or already before
[10:51] <ppisati> sorry
[10:51] <ppisati> during the boot, i get a yellow/orange screen
[10:52] <ppisati> then during boot it says "no signal detected"
[10:52] <ppisati> and it turns off
[10:52] <ppisati> and gitweb on kernel.ubuntu.com is slow...
[10:52] <ogra_> orange screen ?
[10:52] <ogra_> nothing in ubuntu creates orange screens
[10:53] <ogra_> are you sure there is no nand on that XM ?
[10:53] <ppisati> it's a brand new xm
[10:53] <ogra_> (which carries something like an angstrom u-boot ... (which in turn uses orange screens on u-boot))
[10:54] <ppisati> btw, we dropped this oneiric/master @ 1704827e32f20204b6af9b8143aff226211ac270
[10:54] <ogra_> i know theoretically there shouldnt be nand, but i know that a handfull XMs were producsed with it
[10:54] <ppisati> "UBUNTU: ARM: Adding regulator supply for vdds_sdi."
[10:54] <ogra_> hmm
[10:55] <ppisati> http://paste.ubuntu.com/752363/
[10:55] <ppisati> here's my boot
[10:55] <ppisati> i added ttyO2 to /etc/init
[10:55] <ppisati> now let me add a root user
[10:56] <ogra_> OMAP3 Beagle board + LPDDR/NAND
[10:56] <ogra_> there you have your issue
[10:56] <ppisati> wait
[10:56] <ppisati> with a 3.0.x kernel the video output was working
[10:56] <ogra_> it doesnt even seem to load the boot.scr
[10:56] <ogra_> looks like you boot from NAND
[10:56] <ppisati> no no
[10:57] <ppisati> it loads boot.scr
[10:57] <ogra_> or no, it actually reads boot.scr a bit later
[10:57] <ppisati> "Loaded script from boot.scr"
[10:57] <ogra_> *after* it complained it couldnt find it
[10:57] <ogra_> *** Warning - readenv() failed, using default environment
[10:57] <ogra_> it definitely uses the wrong x-loader
[10:58] <ogra_> our x-loader comes from the u-boot package since oneiric, it would have the same build data
[10:58] <ogra_> which it apparently doesnt
[10:58] <ogra_> there must be a key combo to enforce loading from SD ...
[10:59] <ppisati> "Texas Instruments X-Loader 1.5.1 (Jul 15 2011 - 21:29:14)"
[10:59] <ppisati> is it wrong?
[10:59] <ogra_> try holiding down the user button wuring boot and see
[10:59] <ogra_> *during
[10:59] <ppisati> let's try
[11:00] <ogra_> you should never see an organe screen on an ubuntu boot
[11:00] <ogra_> *orange
[11:00] <ppisati> but that's when i press the reset button/during the bootloaders
[11:00] <ppisati> perhaps is an artifact of the reboot
[11:01] <ogra_> i doubt that
[11:01] <ppisati> (some regs have some values etcetc)
[11:01] <ppisati> btw
[11:01] <ogra_> i would think its x-loader
[11:01] <ppisati> can you confirm me the X-loader version?
[11:02] <ogra_> should be from the same build as u-boot
[11:02] <ogra_> they come from the same source package
[11:02] <ogra_> and your u-boot clearly states it finds NAND
[11:03] <ppisati> no
[11:03] <ogra_> hmm, though it matches the actual last x-loader upload
[11:03] <ppisati> it says
[11:03] <ppisati> "NAND:  0 MiB"
[11:03] <ogra_> i wonder why ...
[11:03] <ppisati> IMO the bootloader part is correct
[11:03] <ppisati> let's see if i have an O installation on anotther sd
[11:03] <ogra_> but you see orange if the board powers up ...
[11:03] <ppisati> i can try that kernel
[11:03] <ppisati> on the other installation
[11:04] <ppisati> true
[11:04] <ogra_> and the only thing loaded first is x-loader
[11:04] <ppisati> ok
[11:04] <ppisati> now i resetted the board
[11:04] <ppisati> and pressed the button
[11:04] <ppisati> i'm at the
[11:04] <ppisati> u-boot prompt
[11:04] <ppisati> and i've the yellow/orange screen
[11:04] <ppisati> so
[11:05] <ogra_> hmpf
[11:05] <ppisati> it loaded x-loader and u-boot only
[11:05] <ppisati> let me try with a cold boot
[11:06] <ppisati> ah!
[11:06] <ppisati> with a cold boot
[11:06] <ppisati> no orange screen
[11:06] <ogra_> aha
[11:06] <ppisati> the screen stays off
[11:07] <ppisati> no matter how many times i reset it
[11:07] <ppisati> if i stop the board at the u-boot promp
[11:07] <ppisati> t
[11:07] <ppisati> the screen is off
[11:08] <ppisati> first boot completed
[11:08] <ppisati> screen is still off
[11:08] <ppisati> reset
[11:08] <ogra_> hmm
[11:08] <ogra_> auto-reset ?
[11:08] <ppisati> and there we go
[11:08] <ppisati> orange screen
[11:08] <ppisati> no, reset button
[11:09] <ppisati> let me try thus kernel on O
[11:09] <ogra_> k
[11:25] <fisuk> is there a bug in video hw decode on oneiric or am i doing something wrong (custom rootstock + omap4-extras installed + totem as a video player) as totem crashes from time to time (segfault) and there's strange artefacts displayed on the screen?
[11:25] <fisuk> video scaling seems to be a bit off too..
[11:25] <fisuk> (on pandaboard that is)
[11:29] <ogra_> rootstock shouldnt be used anymore
[11:30] <ogra_> use a properly built image
[11:38] <fisuk> so like, ubuntu core?
[11:40] <ogra_> ubuntu-aerver if you want without desktop, ubuntu-desktop if you want with desktop
[11:40] <ogra_> ubuntu-core if you know how to build images
[11:41] <ogra_> -core is just a base for building your own stuff if you exactly know what you are doing, its completely unconfigured and doesnt even have things likd dhcp support by default
[11:44] <fisuk> hmm, alright
[11:48] <fisuk> well, i'll give the server a spin and if it feels too bloaty, i'll go for the core... thanks for the pointers.
[13:11] <rsalveti> ogra_: edid should be in for 3.3, at least robclark said it's now at staging-next
[13:12] <rsalveti> we could backport it easily I believe, as it'll only affect staging
[13:12] <rsalveti> ppisati: but I don't believe we tested beagle with 3.2 upstream yet
[13:13] <ppisati> ok
[13:13] <ppisati> when you test it, tell me if get video out
[13:16] <rsalveti> ppisati: is this issue happening with the current precise tree?
[13:17] <rsalveti> ppisati: will give it a try here
[13:17] <ppisati> yes
[13:17] <ppisati> P/master
[13:17] <ppisati> i was trying the preinstalled image from 28Nov
[13:18] <ppisati> when i noticed that my screen was blank
[14:36] <ppisati> ogra_: seems it's the 3.2 kernel
[14:36] <ogra_> aha
[14:36] <ppisati> ogra_: installing it on a brand new O/omap3
[14:36] <ogra_> intresting that it gets orange
[14:36] <ppisati> ogra_: kills the video
[14:36] <ppisati> wait
[14:36] <ppisati> it's orange even in O
[14:36] <ppisati> what is strange is that
[14:36] <ppisati> X starts
[14:37] <ppisati> but my mionitor stays off
[14:37] <ogra_> hmm, sounds like EDID again
[14:38] <ppisati> but rsalveti said it didnb't enter mainline
[14:38] <ppisati> now i'm uptading it
[14:38] <ogra_> but it could also be that it is caused by the resolution we set on the cmdline
[14:39] <ogra_> you could tzry to mangle boot.scr
[14:39] <ppisati> well
[14:39] <ppisati> uhm
[14:39] <ppisati> actually IMO
[14:39] <ppisati> X thinks is connected to something else
[14:39] <ppisati> else it wouldn't start
[14:39] <ogra_> it uses /dev/fb0
[14:40] <ogra_> however that was set up by the kernel
[14:40] <ogra_> it doesnt mangle anything and just adopts the existing data the kernel has set
[14:40] <ogra_> (resolution, frequency etc)
[14:41] <ppisati> i'll try to see if there's any difference in dmesg
[14:41] <ogra_> yeah
[14:41] <ppisati> and X log
[14:41] <ogra_> yup
[14:42] <ogra_> if its just the splash, it could well be a plymouth bug
[14:43] <ppisati> [    3.394592] omapfb omapfb: no driver for display: dvi
[14:43] <ppisati> [    3.394622] omapfb omapfb: cannot parse default modes
[14:43] <ppisati> uhm
[14:44] <ogra_> aha
[14:58] <rsalveti> ppisati: iirc there's a new dvi driver, or something like that
[14:58] <rsalveti> maybe it's just not enabled at the config
[14:58] <rsalveti> not sure
[15:00] <ogra_> i'm still stunned that it turns your screen orange :)
[15:03] <rsalveti> ogra_: that's u-boot
[15:04] <ogra_> evil, can we disable that =
[15:04] <ogra_> ?
[15:04] <rsalveti> ogra_: probably, any reason to disable it?
[15:04] <ogra_> its orange !
[15:05] <rsalveti> ogra_: haha, guess we can change to any other color
[15:05] <rsalveti> ideally it'd be nice to have a picture of something there
[15:05] <ogra_> the ubuntu splash
[15:05] <ogra_> ;)
[15:06] <infinity> Or just the same purple that the Ubuntu plymouth theme uses.
[15:06] <infinity> Since grub does that too.
[15:07] <ynezz> but I've heard, that orange color shows you better the crappy color reproduction of your LCD :p
[15:08] <Wellark> ogra_: thanks for the invitation :)
[15:09] <rsalveti> infinity: yeah, should be easy to change it to purple
[15:17] <rsalveti> ppisati: ogra_: cool, just noticed my edid changes at the dvi driver was applied at the kernel
[15:17] <rsalveti> that's why, we have a new panel now
[15:17] <rsalveti> panel-dvi.c
[15:17] <rsalveti> that's based on my implementation
[15:17] <rsalveti> that in theory probes and parses the edid
[15:28] <rsalveti> ppisati: I believe it's just a config change here, I'm building the kernel now and will check in a few
[15:34] <ppisati> ah
[15:35] <ppisati> i was just reverting some changes in omapfb
[15:35] <ppisati> "OMAPFB: find best mode from edid"?
[15:35] <ppisati> this one?
[15:35] <ppisati> rsalveti: ^^
[15:35] <rsalveti> ppisati: I don't believe we need to revert anything
[15:36] <rsalveti> ppisati: panel_dvi is =m
[15:36] <rsalveti> should probably be =y
[15:36] <rsalveti> and generic_panel should be disabled
[15:36] <rsalveti> that's my guess
[15:37] <ppisati> saw it
[15:40] <ogra_> rsalveti, and i suspect we should drop the hardcoded resolution from boot.scr
[15:40] <ogra_> :)
[15:40] <rsalveti> ogra_: probably :-)
[16:10] <ppisati> rsalveti: yes it works
[16:10] <ppisati> with panel_dvi=y
[16:11] <rsalveti> ppisati: awesome, and should also be working with edid
[16:11] <rsalveti> ppisati: try removing the cmd line that forces a resolution
[16:14] <ogra_> awesome that this didnt break it :)
[16:33] <ppisati> ok, pushed
[16:34] <ppisati> so, you want me to drop:
[16:34] <ppisati> "omapfb.mode=dvi:1280x720MR-16@60"
[16:34] <ppisati> right?
[16:34] <rsalveti> ogra_: https://blueprints.launchpad.net/u-boot-linaro/+spec/spl-enablement-for-omap3
[16:35] <rsalveti> ppisati: yes
[16:36] <ogra_> rsalveti, awesome !
[16:38] <ppisati> yes, it works
[16:40] <rsalveti> ogra_: https://blueprints.launchpad.net/u-boot-linaro/+spec/investigate-common-spl-for-omap3-and-omap4
[16:40] <rsalveti> ppisati: great!
[16:42] <rsalveti> ogra_: seems you can now remove the omapfb cmd line from the kernel then
[16:42] <ogra_> rsalveti, well, once that kernel is in
[16:43] <ogra_> or that config change rather
[16:43] <rsalveti> ogra_: well, the current kernel doesn't work anyway
[16:43] <ogra_> yeah
[16:43] <ogra_> not a good start of the milestone freeze :/
[16:44] <rsalveti> at least we found the fix at monday
[16:44] <ogra_> ppisati, do you see any chance there will be a kernel upload today or tomorrow with that fix ?
[16:50] <ppisati> ogra_: hope so
[16:50] <ogra_> k
[16:50] <ogra_> we need to tell GrueMaster to hold off on omap3 testing
[16:51]  * GrueMaster holding off.  (will read backscroll to get rest of what he is holding off from).
[16:51] <ogra_> broken display driver
[16:52] <ogra_> you might be able to test server omap3 if you feel like ... but that will also need re-testing for the new kernel
[20:23] <micahg> suihkulokki: did you try to just disable webrtc w/out reenabling system vpx for chromium?