Half-resolution framebuffer (?)

[sbav1]

Hi,

Apparently there are some regions in tv memory used as half-res (960x540) "framebuffers" by TV OSD
menu, flash engine and (maybe) sdl library (?).

I found some possibly interesting addresses in [ TD Debug Menu ] -> 0x03 : SDAL Debug -> 95 : SPCScreen Gfx Debug -> 0x02 : Gfx GetResolution:

Code: Select all

############################### plane 0 ###############################
[spIGfx_GetRes]Width : 960
[spIGfx_GetRes]Height: 540
[spIGfx_GetRes]PixelDepth : 4
---------------------------------------------------------------------------
[osgInfo]planeId    : 0
[osgInfo]pixelDepth : 4
[osgInfo]horStart   : 0
[osgInfo]verStart   : 0
[osgInfo]uiWinHSize : 1920
[osgInfo]uiWinVSize : 1080
[osgInfo]baseAddr   : 0x79900000
[osgInfo]uiDstHByteSize : 3840
[osgInfo]blendType  : 3
[osgInfo]blendFactor: 255
[osgInfo]osgFormat  : 3
[osgInfo]trColorEn  : 0
[osgInfo]doublingMode : 0
[osgInfo]compressorOffset : 0
[osgInfo]uiSrcHByteSize   : 3840
[osgInfo]uiGaSrcHSize     : 960
[osgInfo]uiGaSrcVSize     : 540
[osgInfo]uiGaDstHSize     : 960
[osgInfo]uiGaDstVSize     : 540
[osgInfo]uiVdHorSize : 1920
[osgInfo]uiVdVerSize : 1080
---------------------------------------------------------------------------
[osgInfo]HScaleRatio_t.ScaleRatio : 1.000000
[osgInfo]HScaleRatio_t.uiDstRatio : 1
[osgInfo]HScaleRatio_t.uiSrcRatio : 1
[osgInfo]VScaleRatio_t.ScaleRatio : 1.000000
[osgInfo]VScaleRatio_t.uiDstRatio : 1
[osgInfo]VScaleRatio_t.uiSrcRatio : 1
---------------------------------------------------------------------------
[osgInfo]VdFrameRate : GP_NTSC_60Hz

############################### plane 1 ###############################
[spIGfx_GetRes]Width : 960
[spIGfx_GetRes]Height: 540
[spIGfx_GetRes]PixelDepth : 4
---------------------------------------------------------------------------
[osgInfo]planeId    : 0
[osgInfo]pixelDepth : 4
[osgInfo]horStart   : 0
[osgInfo]verStart   : 0
[osgInfo]uiWinHSize : 1920
[osgInfo]uiWinVSize : 1080
[osgInfo]baseAddr   : 0x79d00000
[osgInfo]uiDstHByteSize : 3840
[osgInfo]blendType  : 3
[osgInfo]blendFactor: 255
[osgInfo]osgFormat  : 3
[osgInfo]trColorEn  : 0
[osgInfo]doublingMode : 0
[osgInfo]compressorOffset : 0
[osgInfo]uiSrcHByteSize   : 3840
[osgInfo]uiGaSrcHSize     : 960
[osgInfo]uiGaSrcVSize     : 540
[osgInfo]uiGaDstHSize     : 960
[osgInfo]uiGaDstVSize     : 540
[osgInfo]uiVdHorSize : 1920
[osgInfo]uiVdVerSize : 1080
---------------------------------------------------------------------------
[osgInfo]HScaleRatio_t.ScaleRatio : 1.000000
[osgInfo]HScaleRatio_t.uiDstRatio : 1
[osgInfo]HScaleRatio_t.uiSrcRatio : 1
[osgInfo]VScaleRatio_t.ScaleRatio : 1.000000
[osgInfo]VScaleRatio_t.uiDstRatio : 1
[osgInfo]VScaleRatio_t.uiSrcRatio : 1
---------------------------------------------------------------------------
[osgInfo]VdFrameRate : GP_NTSC_60Hz

I don't understand how exactly those "planes" work, but some early experiments look somehow promissing..

Attached simple program (more like a proof of concept) "gfx-test1" seems to work OK on my Tv. It's supposed to display some random colorfull bars on the screen, for about 30 seconds.
Included also are some utilites I used while investigating Tv memory regions.

Is such half resolution "framebuffer" actually usefull for something ? More importantly, is it safe to use ?
I don't know..

Use at your own risk!
Memory regions are most likely model-dependent.
Tested only on european LE B650 T2W T-CHL7DEUC-2005.0.

BTW, there are some mysterious things going in other memory regions too, as listed in

Code: Select all

<Memory Base Table>
        DDRA_BASE : 0x60000000
        DDRA_SIZE : 0x10000000
        DDRB_BASE : 0x70000000
        DDRB_SIZE : 0x10000000
        SYSTEM_MEM_SIZE_A : 0xc400000
        SYSTEM_MEM_SIZE_B : 0x6500000
        Kernel0_BASE : 0x60000000
        Kernel0_SIZE : 0xc400000
        DP0_Base : 0x6c400000
        DP0_SIZE : 0x3be0000
        DP1_Base : 0x6ffe0000
        DP1_SIZE : 0x0
        Kernel1_BASE : 0x70000000
        Kernel1_SIZE : 0x6500000
        AE0_BASE : 0x76500000
        AE0_SIZE : 0x400000
        AE1_BASE : 0x76900000
        AE1_SIZE : 0x0
        MFD_BASE : 0x76900000
        MFD_SIZE : 0x2e00000
        GFX0_BASE : 0x79700000
        GFX0_SIZE : 0x400000
        GFX1_BASE : 0x79b00000
        GFX1_SIZE : 0x400000
        GFX2_BASE : 0x79f00000
        GFX2_SIZE : 0x0
        CURSOR_BASE : 0x79f00000
        CURSOR_SIZE : 0x80000
        TSD_SECTION_BASE : 0x79f80000
        TSD_SECTION_SIZE : 0x80000
        PVR_BASE : 0x7a000000
        PVR_SIZE : 0x400000
        GP3D_BASE : 0x7a400000
        GP3D_SIZE : 0x400000
        AVD_BASE : 0x7a800000
        AVD_SIZE : 0x600000
        SE_EXTERNAL_BUF_BASE : 0x7ae00000
        SE_EXTERNAL_BUF_SIZE : 0x400000
        MSPI_BASE : 0x7b200000
        MSPI_SIZE : 0x40000
        MSPI_RD_BASE : 0x7b240000
        MSPI_RD_SIZE : 0x20000
        MSPI_WR_BASE : 0x7b260000
        MSPI_WR_SIZE : 0x20000
        GEN_GAOPERATION_BASE : 0x7b280000
        GEN_GAOPERATION_SIZE : 0x2800000
        DP2_BASE : 0x7da80000
        DP2_SIZE : 0x1700000
        TTX_VBI_BASE : 0x7f180000
        TTX_VBI_SIZE : 0x20000
        DP3_BASE : 0x7f1a0000
        DP3_SIZE : 0x800000
        MPEG0_BASE : 0x76a00000
        MPEG0_SIZE : 0x2300000
        JPEG_DEC_BASE : 0x76a00000
        JPEG_DEC_SIZE : 0x2000000

For example, I noticed that first 2833920 bytes (2624 bytes x 1080 lines ?) in DP0_BASE (and others) are somehow related to screen contents while Tv is switched to HDMI source. Obviously those are not RGB/ARGB full-hd frames; I was hoping it may be some weird YUV packed/hybrid/whatever coding scheme, but so far I had no luck decoding them.

[antapetr]

Hi,

This info definitely should help when people will start porting (graphical) frameworks like Qt\Embeded, Cairo and others.
I was playing with SDL sources and found than Samsung ported SDL to use some memory which address is accessible using GetFrameBufferAddress() function.
Using pmap I found that this address is for some mapped physical memory that could be from physical device other that main TV memory (for example graphics controller memory or registers).
On my LE46B652 GetFrameBufferAddress() returns 0x48491000 and pmap command of exeDSP shows this info:

Code: Select all

Address     Kbytes Mode  Offset           Device    Mapping
...
0x48291000    2048 rw-s- 0000000079700000 08b:00006 mem
0x48491000    4096 rw-s- 0000000079b00000 08b:00006 mem
0x48891000    2048 rw-s- 0000000079900000 08b:00006 mem
0x48a91000    2048 rw-s- 0000000079d00000 08b:00006 mem
...

So physical memory offsets are same as sbav1 found.
After some research I found:
1. that when using SDL library functions i paint something it goes to memory at 0x48491000 (first two megs:960x540x4)
2. when i ask to update screen with these things all bits from 0x48491000 goes to 0x48691000 and 0x48a91000
3. when i write to memory at 0x48691000 or 0x48a91000 it instantly appears on screen (i can write only at one offset and same data appears at other offset automatically)
4. memory at 0x48291000 and 0x48891000 looks like overlay buffer. When i write to these offsets overlay picture appears instantly on screen independently of main TV source. Same addresses are used by Samsung to display all (or most of) overlay pictures and media play menu and info screens.
If we could identify graphics controller chip and find it's registers we could use them for accelerated graphics operations.

happy hacking

[erdem_ua]

Good informations. Thanks. I wish that you put this informations to wiki.

[sbav1]

cat /proc/iomem

Nah, there are no (video processing related) memory regions io-mapped directly in B650 kernel.

Here's an example: http://goo.gl/0tKil

It looks like MPEG decoder output (or processing areas) to me.
MPEG is usually YCbCR 4:2:0 (chroma subsampling). Color data may be not so easily recognizable/decodable.

I did some research on B-Series for JPEG and HDMI only.
Findings for JPEG "framebuffer" are posted here http://forum.samygo.tv/viewtopic.php?f=6&t=1644.
For HDMI input (1920x1080, YCbCr 4:4:4):
- there are multiple frames (about a dozen) in DP0 memory region, different "planes" for each component (?).
- luma plane (1st frame): 0x6c400000, 2833920 bytes (2624 bytes per line, active pixels: 2560 bytes); non-standard format, 8 bytes (two U32 words) == 6 pixels, 10bits per pixel.
- chroma plane #1 (1st frame, I don't know which component it is, exactly): 0x6d7be000; pixel format probably similar to Y plane.
As it turned out, there are functions in B-series for screen capture (mixed hardware-firmware implementation, [A]RGB format, they work regardless of the input), so my research stopped there.

From my limited experience, the easiest (but perhaps a little dangerous) way for finding exact planes/buffers addresses is: overwrite various image-related memory regions (mmap + memset) and see what happens on the screen .
Memory table (assignments for different hardware subsystems): TDM -> TD Debug -> spI Debug -> Print System Config/Memory Table .

Of course it may be very much different in D-Series. I kinda doubt it is (judging from irqs-sdp1002.c file from D7000 kernel sources, most subsystems known from SDP83 leonid platform are still there in SDP1002 dalma). Samsung rarely redesigns anything completely from scratch.

Anyhow, the 46D7000 has an ARM Mali-400 MP gpu and that's great!

Nice; yet another processing unit in Samsug TV SoC. As if their big-mess-on-chip wasn't big enough mess already .

[sbav1]

For HDMI input (1920x1080, YCbCr 4:4:4):
- there are multiple frames (about a dozen) in DP0 memory region, different "planes" for each component (?).
- luma plane (1st frame): 0x6c400000, 2833920 bytes (2624 bytes per line, active pixels: 2560 bytes); non-standard format, 8 bytes (two U32 words) == 6 pixels, 10bits per pixel.
- chroma plane #1 (1st frame, I don't know which component it is, exactly): 0x6d7be000; pixel format probably similar to Y plane.

Turns out, for HDMI sources in Chelsea, Samsung is using 4:2:2 YCbCr format in internal processing . That's really disappointing. Bad engineering monkeys, NO bananas!
Well, at least it explains why thin, color vertical lines are so funny-looking on my LExxB650..
In case anyone is interested in details, here is small command-line program https://rapidshare.com/files/1368563858 ... 010170.tgz for: capturing relevant memory areas/decoding pixel data/converting 4:2:2 YCrCb -> RGB888.

Output file format is raw RGB; I used ImageMagic for .rgb -> .bmp convertion:

Code: Select all

convert -size 1920x1080 -depth 8 GoT-d3.rgb GoT-d3.bmp

Overall, this is not very good capture utility; final images are often partially distorted (it's a mater of luck and timing, ~better results for 24p input, worse for 50p/60p).
But it doesn't require picture freeze, like the older well-known screen capture method; I guess pixel decoding procedures may be perhaps useful for DYI ambilight development or something.

[arris69]

For HDMI input (1920x1080, YCbCr 4:4:4):
- there are multiple frames (about a dozen) in DP0 memory region, different "planes" for each component (?).
- luma plane (1st frame): 0x6c400000, 2833920 bytes (2624 bytes per line, active pixels: 2560 bytes); non-standard format, 8 bytes (two U32 words) == 6 pixels, 10bits per pixel.
- chroma plane #1 (1st frame, I don't know which component it is, exactly): 0x6d7be000; pixel format probably similar to Y plane.

Turns out, for HDMI sources in Chelsea, Samsung is using 4:2:2 YCbCr format in internal processing . That's really disappointing. Bad engineering monkeys, NO bananas!
Well, at least it explains why thin, color vertical lines are so funny-looking on my LExxB650..
In case anyone is interested in details, here is small command-line program https://rapidshare.com/files/1368563858 ... 010170.tgz

whats about space in svn for sample code for devs?

for: capturing relevant memory areas/decoding pixel data/converting 4:2:2 YCrCb -> RGB888.

Output file format is raw RGB; I used ImageMagic for .rgb -> .bmp convertion:

Code: Select all

convert -size 1920x1080 -depth 8 GoT-d3.rgb GoT-d3.bmp

Overall, this is not very good capture utility; final images are often partially distorted (it's a mater of luck and timing, ~better results for 24p input, worse for 50p/60p).
But it doesn't require picture freeze, like the older well-known screen capture method; I guess pixel decoding procedures may be perhaps useful for DYI ambilight development or something.

nice as always
http://samygo.svn.sourceforge.net/viewv ... iew=markup
some routines for convert to png or jpeg (with some little changes you can do it for rgb data original code use sdl_surface)

hth
arris

[sbav1]

here is small command-line program https://rapidshare.com/files/1368563858 ... 010170.tgz

whats about space in svn for sample code for devs?

Thanks; in the meanwhile I putted it into download area: http://sourceforge.net/projects/samygo/ ... z/download
Wasn't aware I have rights to do this.. I probably shouldn't - in afterthought, the chosen category doesn't look quite right

[erdem_ua]

If you really don't have needed rights, just tell me.