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

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

2017-02-02 Thread Eric Anholt

Stephen Warren  writes:

> On 01/13/2017 04:48 AM, Brian Masney 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.
>
> Is this related?
>
>> https://www.riscosopen.org/forum/forums/4/topics/6400?posts_per_page=25_per_page_change=Change
> (See "I think I've just fixed that")
>
>> https://www.riscosopen.org/viewer/revisions/logs?ident=1471703957-443671.html
> (See the diff in the BCMVideo file)
>
> Another thing to try might be to remove the SET_* operations from 
> U-Boot's property mailbox calls (I think the FW always initializes video 
> out anyway, so U-Boot doesn't need to set anything up), and simply 
> invoke the relevant GET_* operations to query where the buffer is and

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

2017-01-23 Thread Stephen Warren

On 01/18/2017 07:15 PM, Brian Masney wrote:

On Fri, Jan 13, 2017 at 10:21:15AM -0700, Stephen Warren wrote:

On 01/13/2017 04:48 AM, Brian Masney 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.

Is this related?

https://www.riscosopen.org/forum/forums/4/topics/6400?posts_per_page=25_per_page_change=Change

(See "I think I've just fixed that")

https://www.riscosopen.org/viewer/revisions/logs?ident=1471703957-443671.html

(See the diff in the BCMVideo file)

Another thing to try might be to remove the SET_* operations from U-Boot's
property mailbox calls (I think the FW always initializes video out anyway,
so U-Boot doesn't need to set anything up), and simply invoke the relevant
GET_* operations to query where the buffer is and its size. IIRC I didn't do
that because you can only query certain information as a side-effect of
asking the FW to allocate a frame-buffer though (i.e. the info comes back in
a SET_xxx/ALLOCATE_xxx response message, but there's no GET_xxx to query the
data without modifying the configuration or re-allocating anything).

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

2017-01-18 Thread Brian Masney

On Fri, Jan 13, 2017 at 10:21:15AM -0700, Stephen Warren wrote:
> On 01/13/2017 04:48 AM, Brian Masney 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.
> 
> Is this related?
> 
> > https://www.riscosopen.org/forum/forums/4/topics/6400?posts_per_page=25_per_page_change=Change
> (See "I

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

2017-01-13 Thread Stephen Warren

On 01/13/2017 04:48 AM, Brian Masney 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:

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?).

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.

Is this related?

https://www.riscosopen.org/forum/forums/4/topics/6400?posts_per_page=25_per_page_change=Change

(See "I think I've just fixed that")

https://www.riscosopen.org/viewer/revisions/logs?ident=1471703957-443671.html

(See the diff in the BCMVideo file)

Another thing to try might be to remove the SET_* operations from
U-Boot's property mailbox calls (I think the FW always initializes video
out anyway, so U-Boot doesn't need to set anything up), and simply
invoke the relevant GET_* operations to query where the buffer is and
its size. IIRC I didn't do that because you can only query certain
information as a side-effect of asking the FW to allocate a frame-buffer
though (i.e. the info comes back in a SET_xxx/ALLOCATE_xxx response
message, but there's no GET_xxx to query the data without modifying the
configuration or re-allocating anything).

___
U-Boot mailing list
U-Boot@lists.denx.de

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

2017-01-13 Thread Peter Robinson

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

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

2017-01-13 Thread 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

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

2017-01-12 Thread Brian Masney

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.

Thanks,

Brian

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2017-01-12 Thread Brian Masney

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.

Signed-off-by: Brian Masney 
---
Here is a link to my initial submission of this patch that did not
receive any feedback:

http://lists.denx.de/pipermail/u-boot/2016-November/272760.html

I updated the patch to ensure that it applies cleanly to the latest
master.

 doc/README.video| 12 
 drivers/video/Makefile  |  2 +-
 drivers/video/bcm2835.c | 42 +-
 3 files changed, 42 insertions(+), 14 deletions(-)

diff --git a/doc/README.video b/doc/README.video
index e7ae98a..31ceeab 100644
--- a/doc/README.video
+++ b/doc/README.video
@@ -76,3 +76,15 @@ The sunxi U-Boot driver supports the following video-mode 
options:
 For example to always use the hdmi connector, even if no cable is inserted,
 using edid info when available and otherwise initalizing it at 1024x768@60Hz,
 use: "setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=1".
+
+
+U-Boot bcm2835 video controller driver
+==
+
+The bcm2835 driver supports polling the monitor for the maximum supported
+resolution. This can be changed by using the video-mode environment
+variable:
+
+Example: video-mode=bcm2835:1024x768-16@60
+
+Note: The frequency is currently not used by the driver.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index db34904..7c13faf 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -36,7 +36,7 @@ obj-$(CONFIG_S6E8AX0) += s6e8ax0.o
 obj-$(CONFIG_S6E63D6) += s6e63d6.o
 obj-$(CONFIG_LD9040) += ld9040.o
 obj-$(CONFIG_SED156X) += sed156x.o
-obj-$(CONFIG_VIDEO_BCM2835) += bcm2835.o
+obj-$(CONFIG_VIDEO_BCM2835) += bcm2835.o videomodes.o
 obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o
 obj-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
 obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index cc6454f..90fed68 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include "videomodes.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -45,21 +46,36 @@ void lcd_ctrl_init(void *lcdbase)
int ret;
u32 w, h;
u32 fb_start, fb_end;
+   const char *options;
+   unsigned int depth = 0, freq = 0;
 
-   debug("bcm2835: Query resolution...\n");
-
-   BCM2835_MBOX_INIT_HDR(msg_query);
-   BCM2835_MBOX_INIT_TAG_NO_REQ(_query->physical_w_h,
-   GET_PHYSICAL_W_H);
-   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, _query->hdr);
-   if (ret) {
-   printf("bcm2835: Could not query display resolution\n");
-   /* FIXME: How to disable the LCD to prevent errors? hang()? */
-   return;
+   if (video_get_video_mode(, , , , ) != 1) {
+   debug("bcm2835: video_get_video_mode() unsuccessful; polling 
monitor for defaults\n");
+   w = 0;
+   h = 0;
}
 
-   w = msg_query->physical_w_h.body.resp.width;
-   h = msg_query->physical_w_h.body.resp.height;
+   if (w == 0 || h == 0) {
+   debug("bcm2835: Query resolution...\n");
+
+   BCM2835_MBOX_INIT_HDR(msg_query);
+   BCM2835_MBOX_INIT_TAG_NO_REQ(_query->physical_w_h,
+GET_PHYSICAL_W_H);
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
+_query->hdr);
+   if (ret) {
+   printf("bcm2835: Could not query display resolution\n");
+   /*
+* FIXME: How to disable the LCD to prevent errors?
+* hang()? */
+   return;
+   }
+
+   w = msg_query->physical_w_h.body.resp.width;
+   h = msg_query->physical_w_h.body.resp.height;
+
+   depth = 32;
+   }
 
debug("bcm2835: Setting up display for %d x %d\n", w, h);
 
@@ -71,7 +87,7 @@ void lcd_ctrl_init(void *lcdbase)
msg_setup->virtual_w_h.body.req.width = w;
msg_setup->virtual_w_h.body.req.height = h;
BCM2835_MBOX_INIT_TAG(_setup->depth, SET_DEPTH);
-

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

2017-01-12 Thread Stephen Warren


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.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2017-01-12 Thread Stephen Warren


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.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

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

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

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

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

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

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

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

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

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

10 matches

Site Navigation

Mail list logo

Footer information