Video image shifts right randomly

[Brett]

Hey guys, our product based on the beaglebone black is experiencing an issue with the video image shifting to the right randomly. This usually happens no sooner than 15mins after our application starts(sometimes it takes hours) then will stay this way for a while before shifting back. I attached 2 pictures, one with it shifted, the other "normal". One thing the picture does not really show is the very top left row of pixels in the (shifted)black area are lit with random colors. The application uses OpenGL ES 2 to generate the graphics and we have HDMI connected to the micro HDMI port. I am pretty confident that our application is not doing anything to move the image, it is pretty simple as you will see from the pictures. We have tried updating the kernel and various combinations of different monitors/cables but the problem still persists. We are nearing 150 BBBs in the field and it appears they all do this but it seems like some do it sooner than others. Anyone else seen this type of thing before? Does anyone have any idea why this could be happening? Any ideas on how I can narrow the issue?

The kernels we tried are 3.13.6-bone8 and 4.4.45-bone-rt-r16

[Brett]

When in the shifted state I have tried:

• Restarting our application
• remains shifted, more reason to think it may not be something our app is doing
• Killing our application then issuing "/etc/init.d/rc.pvr stop" followed by "/etc/init.d/rc.pvr start"
• this had no effect
• Unplugging the monitor, then plugging it back in again
• this actually worked! Unfortunately this isn't an acceptable solution for our product

Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all the random colors, even in the left blank area when the image is shifted. Then I started our app and the top left 10 or so pixels remained the random colors. If I then using dd fill /dev/fb0 with zero from /dev/null, everything becomes black, including the top left row. I am not sure what all this means yet...

This is the result of parse-edid for one of the BBBs setup right now (we are in the process of setting 4 or 5 of them up with different monitors/cables to test in parallel)

Checksum Correct

Section "Monitor"

        Identifier "LCD195VX+"

        ModelName "LCD195VX+"

        VendorName "NEC"

        # Monitor Manufactured week 25 of 2008

        # EDID version 1.3

        # Digital Display

        DisplaySize 380 300

        Gamma 2.20

        Option "DPMS" "true"

        Horizsync 31-81

        VertRefresh 56-75

        # Maximum pixel clock is 140MHz

        #Not giving standard mode: 1152x864, 75Hz

        #Not giving standard mode: 1280x960, 75Hz

        Modeline        "Mode 0" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync

EndSection

[Brett]

I forgot to mention that I am setting the resolution via kernel command line "video=HDMI-A-1:1024x768@60". The monitor settings do report the same resolution.

[William Hermans]

Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all the random colors, even in the left blank area when the image is shifted. Then I started our app and the top left 10 or so pixels remained the random colors. If I then using dd fill /dev/fb0 with zero from /dev/null, everything becomes black, including the top left row. I am not sure what all this means yet...

/dev/fb0 is most likely a direct access frame buffer for the video device. In the case, the SGX video chip. I honestly do not know about the Linux frame buffer in great detail. But if it works similar to how old VGA frame buffers work. Essentially it's a two dimensional array. Similar to how you plot a coordinate in geometry.  So think 1024( up / down ) rows, of 768( left to right ) columns.

Absolute top left is considered coordinate 0,0, where absolute opposite would be 1023, 767. How a frame buffer works, is that once you go over the maximum value in width(767), you wrap back to 0(most left ), and drop down a row. If that row is your maximum height, then there are a couple this can be implemented. Wrap back to 0 height, or continue on to the next "page" Which is how sometimes frame buffering is done. Again, I do not know the Linux frame buffer specification at all, so this part I'm not sure how this is dealt with.

Anyway, this makes it really simple, and fast to "blast" or blit changed to screen. As the whole screen is seen at one large file, with x amount of bytes. Each byte representing a pixel on screen. While each byte value represents the actual color of that pixel. So when you dd random values into this file. you're actually dding those value to your screen. By the same logic, if you blast nothing but NULL to this file. Well, your screen will be black ;)

[Robert Nelson]

What version of U-Boot are you using?

This kinda smells like:

http://git.denx.de/?p=u-boot.git;a=commit;h=8c17cbdf8a8023abdd0009af4dc9dbc0541b4a0f

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Brett]

I am using 2014.01. Do we know what version this bug was introduced with?

[Robert Nelson]

On Mon, Feb 6, 2017 at 3:09 PM, Brett <mixmast...@gmail.com> wrote:
> I am using 2014.01. Do we know what version this bug was introduced with?

Well that bug has always been there, it was just fixed in v2017.01,
something worth to try.

[William Hermans]

And, of course I think I answered the wrong question,. e.g. one you did not ask. So if I now understand your statement correctly there. It would seem like someone's math is wrong. Perhaps in the frame buffer driver for this hardware.

 

[Brett]

We've been running with the new bootloader for a few days and it seems like updating the bootloader did the trick! Thank you!