On Fri, Jan 13, 2017 at 11:48 AM, Brian Masney <masn...@onstation.org> wrote: > 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.
Not sure if this has anything of use: https://github.com/anholt/vc4-gpu-tools _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot