[U-Boot] [RESEND] video: bcm2835: add support for reading from the video-mode environment variable

[Brian Masney]

On Thu, Jan 12, 2017 at 11:47:48AM -0700, Stephen Warren wrote:
> On 01/12/2017 11:32 AM, Brian Masney wrote:
> > On Thu, Jan 12, 2017 at 11:02:14AM -0700, Stephen Warren wrote:
> > > On 01/12/2017 01:57 AM, Brian Masney wrote:
> > > > The bcm2835 driver polls the monitor and selects the highest resolution
> > > > that is available. This patch allows optionally setting the video-mode
> > > > environment variable so that a different video resolution can be used.
> > > > If the environment variable is not specified, then it will fall back to
> > > > using the old behavior of using the maximum allowable resolution.
> > > > 
> > > > This patch is needed to fix an issue booting an upstream Linux kernel
> > > > on a Raspberry Pi 2 with a Pi Top screen. Previously, the bcm2835 would
> > > > select the 1366x768 resolution (which is a supported resolution),
> > > > however the screen would be unreadable. (See
> > > > https://www.flickr.com/photos/masneyb/30942037416/ for picture). Using
> > > > this patch, the resolution 1024x768 can be selected and is readable on
> > > > the screen.
> > > 
> > > Doesn't this mean that the RPi firmware is reporting the wrong resolution?
> > > If so, isn't the correct fix to get an updated firmware that reports the
> > > correct resolution, rather than patching each piece of SW to ignore the
> > > FW-reported resolution? Or, if this is caused by incorrect EDID in the Pi
> > > Top, then fix the EDID EEPROM on that.
> > > 
> > > Perhaps there are other use-cases for using a non-default resolution, but to
> > > support that, you'd need to make a call into the FW to request and configure
> > > that non-default resolution, not just ignore what resolution the FW
> > > programmed.
> > 
> > Hi Stephen,
> >    The Pi Top screen works correctly with the 1366x768 resolution when
> > booting the 4.4 kernel provided by the Raspberry Pi foundation in
> > stock Raspbian (no u-boot). (There are no outside provided drivers from
> > Pi Top.) When booting with u-boot, I can't use the 1366x768 resolution,
> > even when setting the resolution manually using my patch. When auto
> > detection is in place, u-boot correctly detects the 1366x768 resolution
> > according to debugging messages that I see on the serial console.
> > 1024x768 is the highest resolution that I can get a working display with
> > the Pi Top and u-boot. I also tried changing the display depth.
> > 
> >    I tried booting u-boot using the latest Raspberry Pi firmware and the
> > older firmware provided with the Raspbian 4.4 kernel. In both cases, the
> > screen correctly displays the rainbow square at the top left when the
> > GPU is booting, but then the screen becomes garbled when it gets to
> > u-boot and the bcm2835 code sets the resolution.
> > 
> >    I tried going through the Pi Top vendor for help but didn't get very
> > far with them. I'm open to other suggestions to try.
> 
> Is the bad image that you get static/fixed, or does it move about randomly?
> 
> If it's static/fixed, I wonder if the issue is with the memory pitch
> calculation. What value does bcm2835_pitch have without your patch? (and
> with your patch, I think it's uninitialized?).
> 
> I wonder if you round the value of bcm2835_pitch up to a multiple of 256 (or
> something like that), then perhaps the issue may be solved? If you change
> the pitch value, and you notice the angle of the diagonal edges in the image
> change, the issue is almost certainly related to this pitch value.
> 
> I can't recall how the mainline kernel driver works now. If it also uses the
> property mailbox to configure the display, and you're just using the dumb
> simplefb driver, perhaps you can compare the memory layout parameters the
> kernel uses when it's working to what U-Boot uses when it's not working.

The image is fixed. I can see when the Linux Kernel boots and the
console messages scroll across the screen.

Without my patch, u-boot detects the screen resolution as 1366x768 with
a pitch of 5504. With my patch, 1024x768 uses a pitch of 2048.

I reverted my u-boot patch and tried hard coding the pitch to the values
5376, 5632, 2048, 4096, and 6144 with no success. Once I read what the
pitch value does, I also tried 5464 (1366 x 4 (for 32bpp)) and 2732.

I don't see a utility to dump the pitch value from the property mailbox.
I see this
https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes and
will have to look at it tonight (I'm in GMT-05). In the mean time, I
dumped the EDID information with the Pi Top booted using Raspbian's
4.4.21 kernel:

# tvservice -d edid-raw
# edidparser edid-raw

HDMI:EDID version 1.3, 0 extensions, screen size 29x17 cm
HDMI:EDID features - videodef 0x80 !standby !suspend !active off; colour
encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred
format is native; does not support GTF
HDMI:EDID ignored unknown descriptor tag 0x0
HDMI:EDID found monitor ascii descriptor tag 0xfe
HDMI:EDID found monitor ascii descriptor tag 0xfe
HDMI:EDID does not yet know monitor vertical range, setting to default
24 to 120Hz
HDMI:EDID failed to find a matching detail format for 1366x768p hfp:40
hs:32 hbp:94 vfp:3 vs:12 vbp:20 pixel clock:73 MHz
HDMI:EDID calculated refresh rate is 60 Hz
HDMI:EDID guessing the format to be 1366x768p @60 Hz
HDMI:EDID found preferred DMT detail timing format: 1366x768p @ 60 Hz
(81)
HDMI:EDID established timing I/II bytes are 00 00 00
HDMI:EDID standard timings block x 8: 0x0101 0101 0101 0101 0101 0101
0101 0101 
HDMI:EDID adding mandatory support for DMT (4) 640x480p @ 60Hz
HDMI:EDID filtering formats with pixel clock > 162 MHz or h. blanking >
1023
HDMI:EDID best score mode initialised to DMT (4) 640x480p @ 60 Hz with
pixel clock 25 MHz (score 0)
HDMI:EDID best score mode is now DMT (4) 640x480p @ 60 Hz with pixel
clock 25 MHz (score 36864)
HDMI:EDID best score mode is now DMT (81) 1366x768p @ 60 Hz with pixel
clock 85 MHz (score 5188835)
HDMI:EDID preferred mode remained as DMT (81) 1366x768p @ 60 Hz with
pixel clock 85 MHz
HDMI:EDID has only DVI support and no audio support
edid_parser exited with code 0

Brian