Video image shifts right randomly

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

Shifted.jpg

Normal.png

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

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.

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 :wink:

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,

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.

Regards,

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 :wink:

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.

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