Testing 2.6.28 with Sony Bravia KDL-32W4000
recalcati
compatibility of omap3x with LCD TV's.
The same 720p works with Samsung SyncMaster 245T.
In my opinion is really important the compatibility with TV's.
Can I be sure that DVI output will be compatible with any TV?
Using 2.6.27 I was able to see from DVI to Sony Bravia KDL-32W4000.
fbset
mode "1280x720-58"
# D: 72.005 MHz, H: 43.639 kHz, V: 58.186 Hz
geometry 1280 720 1280 720 16
timings 13888 110 220 20 5 40 5
accel false
rgba 5/11,6/5,5/0,0/0
endmode
Now with 2.6.28 I can't:
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720MR-24@60
omapfb.debug=y'
not supported by Sony KDL-32W4000
fbset
mode
"1280x720-60"
# D: 64.000 MHz, H: 44.444 kHz, V: 59.979
Hz
geometry 1280 720 1280 720
32
timings 15625 80 48 3 13 32
5
rgba
8/16,8/8,8/0,0/0
endmode
I can I set the same pixel clock that worked on 2.6.27?
Below some tests
-------------------------------
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720MR-24@60
omapfb.debug=y'
not supported by Sony KDL-32W4000
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720M-24@60
omapfb.debug=y'
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720R-24@60
omapfb.debug=y'
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1024x768MR-8@60m
omapfb.debug=y'
not supported by Sony KDL-32W4000
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720-24@60 '
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=640x480@60 '
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=640x480@72'
not supported by Sony KDL-32W4000
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1366x768@60'
omap-dss DISPC error: Excessive DISPC errors
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x800@60'
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x800-MR@60'
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720-24@58
omapfb.debug=y'
Oops
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720MR-24@60
omapfb.debug=y'
not supported by Sony KDL-32W4000
mpoullet
your TV set needs probably a proper 720p@50Hz or 720p@60Hz timing.
These timings can be found in the SMPTE-296M standard and are also
found in the CEA-861 standard, as mode 19 (50Hz) and mode 4 (60Hz).
Both timings need a pixelclock of 74.25MHz.
When you use the 2.6.27 kernel, you use the first Display Sub-System
(DSS) implementation that was available.
It is fine but can not produce a pixelclock of more than about 72MHz
because it doesn't make use of the DSI PLL available in the DSS.
If your TV works with this 72MHz pixelclock, it simply means that it
has a low sync, but that's not 100% correct.
When you use the 2.6.28 kernel, you use the second DSS implementation.
It makes use of the DSI PLL and can output the required pixelclock of
74.25MHz.
I've solved this by adding the right timings in drivers/video/modedb.c
and can confirm that it perfectly works with my Sony KDL-40Z4500 and
the 720p@60Hz mode.
For the 720p@50Hz mode, there's still another issue: the beagleboards
previous to Rev.C have a bug in silicon (see sprz278c.pdf from TI) and
some fields in registers DISPC_TIMING_H and DISPC_TIMING_V are limited
to 8 bits instead of 11 bits (see the function _dispc_set_lcd_timings
in arch/arm/plat-omap/dss/dispc.c). This will be fixed in Rev.C which
a new ES of the OMAP on it.
I've removed the limitations in _dispc_set_lcd_timings and can confirm
that it doesn't work with my B5 board but that it works with my B7
board.
Unfortunately I'm not sure if I can post the timings (I've bought them
and there are some copyright restrictions on it that I don't fully
understand) so that you can test on our own.
Hope it helps and that it's accurate,
Best regards,
Matthieu.
Robert Kuhn
> When you use the 2.6.28 kernel, you use the second DSS implementation.
> It makes use of the DSI PLL and can output the required pixelclock of
> 74.25MHz.
IMHO DSS2 is also not in the 2.6.28 kernel. You have to use the right
patches or to use Angstrom which has all the patches.
Robert
Koen Kooi
Op 3 feb 2009, om 15:47 heeft mpoullet het volgende geschreven:
> For the 720p@50Hz mode, there's still another issue: the beagleboards
> previous to Rev.C have a bug in silicon (see sprz278c.pdf from TI) and
> some fields in registers DISPC_TIMING_H and DISPC_TIMING_V are limited
> to 8 bits instead of 11 bits (see the function _dispc_set_lcd_timings
> in arch/arm/plat-omap/dss/dispc.c). This will be fixed in Rev.C which
> a new ES of the OMAP on it.
>
> I've removed the limitations in _dispc_set_lcd_timings and can confirm
> that it doesn't work with my B5 board but that it works with my B7
> board.
The kernel has a macro to detect ES revisions, could you use that and
send patch for it?
regards,
Koen
mpoullet
to play around and then put my little changes in my Angstrom kernel
back.
On 3 Feb., 15:52, Robert Kuhn <rowka...@googlemail.com> wrote:
> 2009/2/3 mpoullet <matthieu.poul...@gmail.com>:
Matthieu Poullet
As I've never done this before, maybe it's not correctly formatted...
Regards,
Matthieu.
Koen Kooi
Op 3 feb 2009, om 17:11 heeft Matthieu Poullet het volgende geschreven:
> I've attached a patch, it's against latest l-o branch omap-2.6.28 +
> DSS patches series from Tomi.
> + if (omap_rev() < OMAP3430_REV_ES3_1)
Isn't B7 and C1 ES3.0 instead of ES3.1?
regards,
Koen
Kridner, Jason
They are. Rev C2 will be ES3.0 as well.
Matthieu Poullet
The issue is that according to [1] ES3.0 is still having the issue. However I confirm that with the two B7 that I've tested so far, the correct full values were written in the registers and the output signal was clean (correct h-sync, v-sync, pxclk...).
So I can modify the patch, but it's mostly a hack that TI cannot guarantee to work with ES3.0...
Regards,
Matthieu.
[1] http://focus.ti.com/lit/er/sprz278c/sprz278c.pdf
mpoullet
need a negative h-sync/v-sync/pxclk.
The quickest way to change this is to modify the generic panel [1],
see e.g. [2], and to add:
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC
to the .config field.
But it's an awful hack, the proper way to do that may be to read the
EDID information in the HDTV set, to map them to the CEA 861 modes and
then to setup the DSS...
Regards,
Matthieu.
[1] http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/packages/linux/linux-omap-2.6.28/0003-DSS-Add-generic-DVI-panel.patch
[2]
http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/packages/linux/linux-omap-2.6.28/0005-DSS-Sharp-LS037V7DW01-LCD-Panel-driver.patch
On 3 Feb., 19:00, Matthieu Poullet <matthieu.poul...@gmail.com> wrote:
> Sorry I thought the Rev.C2 uses ES3.1 already...
>
> The issue is that according to [1] ES3.0 is still having the issue. However
> I confirm that with the two B7 that I've tested so far, the correct full
> values were written in the registers and the output signal was clean
> (correct h-sync, v-sync, pxclk...).
>
> So I can modify the patch, but it's mostly a hack that TI cannot guarantee
> to work with ES3.0...
>
> Regards,
> Matthieu.
>
> [1]http://focus.ti.com/lit/er/sprz278c/sprz278c.pdf
>
Søren Steen Christensen
> previous to Rev.C have a bug in silicon (see sprz278c.pdf from TI) and
> some fields in registers DISPC_TIMING_H and DISPC_TIMING_V are limited
> to 8 bits instead of 11 bits (see the function _dispc_set_lcd_timings
> in arch/arm/plat-omap/dss/dispc.c). This will be fixed in Rev.C which
> a new ES of the OMAP on it.
>
> I've removed the limitations in _dispc_set_lcd_timings and can confirm
> that it doesn't work with my B5 board but that it works with my B7
> board.
> Unfortunately I'm not sure if I can post the timings (I've bought them
> and there are some copyright restrictions on it that I don't fully
> understand) so that you can test on our own.
Hi Matthieu,
From where in sprz278.pdf did you get the information, that these registers
would be extended in either ES3.0 or ES3.1?
As I read chapter 2 of this document it just states some limitations of the
OMAP3530 compared to what an ordinary user might expect. I'm *happy* that
you can confirm, that the registers in ES3.0 apparently has been extended,
but I don't like that I can't find this information officially in any
documents - On the contrary I think to find the exact opposite info in
sprz268.pdf - What have I missed? :-)
Best regards and thanks
Søren
recalcati
I have to understand better OE in order to know wich git version is
the kernel I'm using.
Anyway, EDID is "the right solution", but can be enough
640x480p
720x576p
1280x720p or 1920x1080i
Now I'm too tired.
I'll test the patch ... tomorrow.
I have rev.B6
To have fixed the bug for 720p@50Hz I have to wait rev.C, so when can
I buy it?
My idea is to prepare a demo version of beagleboard and to go to a
market in order to test beagleboard DVI out with a lot of TV's.
thx to everybody
On 3 Feb, 19:50, Søren Steen Christensen
Gerald Coley
mpoullet
I've asked my TI FAE because I need the 720p@50Hz mode and so need a
front porch of 440.
He answers that this is fixed in ES3.1, not before, so the Rev.C. will
still have this issue, what Gerald has already confirmed.
In ES3.1 DISPC_TIMING_H and DISPC_TIMING_V will be 12/12/8 bits
instead of 8/8/6 at the moment.
However my experiments show that with the two B7 I own, it works well.
With my B4 and B5 it doesn't work.
With the Tomi's DSS2 you can safely use the 720p@60Hz mode which only
needs a front porch of 110.
Regards,
Matthieu.
On 3 Feb., 19:50, Søren Steen Christensen
Tomi Valkeinen
I can confirm that the timing registers have been extended on my OMAP
SDP board which has ES3.0. Also the latest TRM has been changed to
reflect the HW change. But I haven't found information about which ES
versions have this change. I guess experiments have proven it to be
ES3.0+ =).
Tomi
Søren Steen Christensen
To summarize: Great - Meaning Rev B7/C2 support full timing (12/12/8)
although not officially according to TI.
The extended registers are officially first announced/promised in ES3.1, but
seems to be active already in ES3.0 - Right?
@Tomi: Which version of the TRM do you have? The version I have is
inconsistent on this topic as highlighted in my previous post "Re: HDMI
output from Beagle board" around one week ago...
Thanks
Søren
mpoullet
On 4 Feb., 13:39, Søren Steen Christensen
> @Tomi: Which version of the TRM do you have? The version I have is
> inconsistent on this topic as highlighted in my previous post "Re: HDMI
> output from Beagle board" around one week ago...
> Thanks
> Søren
Regards,
Matthieu.
Tomi Valkeinen
> @Tomi: Which version of the TRM do you have? The version I have is
> inconsistent on this topic as highlighted in my previous post "Re: HDMI
> output from Beagle board" around one week ago...
I have:
OMAP34xx Multimedia Device
Silicon Revision 3.1
Texas Instruments OMAP™ Family of Products
Version O
Technical Reference Manual
I only now noticed the "silicon revision 3.1" note there. But it _does_
work on my ES3.0 SDP... Probably more testing is needed until we can
really say it works on ES3.0s.
Tomi
Søren Steen Christensen
Søren
> -----Original Message-----
> From: beagl...@googlegroups.com
> [mailto:beagl...@googlegroups.com] On Behalf Of Tomi Valkeinen
> Sent: Wednesday, February 04, 2009 3:10 PM
> To: beagl...@googlegroups.com
> Subject: [beagleboard] Re: Testing 2.6.28 with Sony Bravia KDL-32W4000
>
>
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.17/1934 - Release Date:
> 02/04/09 08:24:00
Puneet Gupta
As part of my project on OMAP3/Beagle board, I have been exploring the possibility of using the Angstrom as the choice for Linux OS distribution. I have seen a lot of activity on the same on this forum as well.
Could anyone please tell me what the associated licensing model for Angstrom is. Is it GPL or LGPL? I haven’t been able to find out too much about it from the Angstrom website or the previous posts on this group.
Regards
Puneet
Koen Kooi
Firstly: Don't start a new thread by using the 'reply' button, your
message will get burried in the other thread (the sony bravia on in
this case)
Secondly: Angstrom as a whole has no license, every single package
*does* have a license. The license is inside the control file of
each .ipk file:
koen@dominion:/OE/angstrom-dev/deploy/glibc$ dpkg-deb -I ipk/armv7a/
libcairo2_1.8.0-r0.1_armv7a.ipk
new debian package, version 2.0.
size 207506 bytes: control archive= 592 bytes.
582 bytes, 12 lines control
118 bytes, 6 lines * postinst #!/bin/sh
Package: libcairo2
Version: 1.8.0-r0.1
Description: Cairo graphics library
Section: libs
Priority: optional
Maintainer: Angstrom Developers <angstrom-d...@linuxtogo.org>
License: MPL LGPL
Architecture: armv7a
OE: cairo
Homepage: unknown
Depends: libpixman-1-0 (>= 0.12.0), libfontconfig1 (>= 2.6.0),
libfreetype6 (>= 2.3.6), libexpat1 (>= 2.0.0), libpng12-0 (>= 1.2.31),
libxrender1 (>= 0.9.4), libx11-6 (>= 1.1.5), libxau6 (>= 1.0.4),
libxdmcp6 (>= 1.0.2), libc6 (>= 2.6.1), libz1 (>= 1.2.3), libgcc1 (>=
4.3.1)
Source: http://cairographics.org/releases/cairo-1.8.0.tar.gz
Or you can use the online package browser: http://www.angstrom-distribution.org/repo/
regards,
Koen
UTHAM
We will be starting development on BB.
We are interested in Angstrom Linux. Please help me with the link to
its source tree.
I might want to build the image myself. It will be highly appreciated
if you could lead me to the build procedure of the same.
Thanks a lot!
Utham
> Architecture: armv7a
> OE: cairo
> Homepage: unknown
> Depends: libpixman-1-0 (>= 0.12.0), libfontconfig1 (>= 2.6.0),
> libfreetype6 (>= 2.3.6), libexpat1 (>= 2.0.0), libpng12-0 (>= 1.2.31),
> libxrender1 (>= 0.9.4), libx11-6 (>= 1.1.5), libxau6 (>= 1.0.4),
> libxdmcp6 (>= 1.0.2), libc6 (>= 2.6.1), libz1 (>= 1.2.3), libgcc1 (>=
> 4.3.1)
> Source:http://cairographics.org/releases/cairo-1.8.0.tar.gz
>
> Or you can use the online package browser:http://www.angstrom-distribution.org/repo/
>
> regards,
>
> Koen
>
> < 1KViewDownload
Koen Kooi
Op 10 feb 2009, om 11:04 heeft UTHAM het volgende geschreven:
>
> Hi All,
>
> We will be starting development on BB.
> We are interested in Angstrom Linux. Please help me with the link to
> its source tree.
> I might want to build the image myself. It will be highly appreciated
> if you could lead me to the build procedure of the same.
A good starting point would be http://elinux.org/BeagleBoardAndOpenEmbeddedGit
regards,
Koen
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Beagle Board" group.
> To post to this group, send email to discu...@beagleboard.org.
> To unsubscribe from this group, send email to beagleboard...@beagleboard.org
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en
> -~----------~----~----~----~------~----~------~--~---
>