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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot