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

[Peter Robinson]

On Fri, Jan 13, 2017 at 11:48 AM, Brian Masney <masneyb at 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