DPI mode with May 15th eeprom #1397
Comments
|
There are no plans to support anything except HDMI for a diagnostics screen the bootloader. There's no way to automatically probe for other displays and there isn't enough code space in the L2 cache for the drivers. |
|
You are misunderstanding me. The problem isn't showing the bootloader screen. The problem is when I switched to the beta bootloader using a working SD card, NORMAL DPI LCD was black ALWAYS. No screen ever came up. The only change was the bootloader version. Why the bootloader would affect this is WHY I posed this since I dont see why a bootloader should have effected this at all. Switch back to the current stable bootloader, no other change, same SD card, and Pi4 boots and displays the console correctly. Note, I can log in via SSH after the board boots using the beta bootloader just fine so I know the PI is booting into the SD card well past the bootloader. Just no DPI LCD display at all. There is hsync, vsync dotclock and data enable signals but no data on any RGB pins. |
|
I cannot yet see how that can happen if the only change is the bootloader. Are you sure tha is the only change, or could there also be firmware/kernel changes? |
|
Use the Raspberry Pi Imager to put the default production EEPROM on there. If the black screen persists then as @JamesH65 says it will be an issue with either the firmware or the 5.4 kernel from rpi-update. To revert |
|
As I said in my previous posts, the STABLE EEPROM bootloader does NOT
exhibit this problem. Only the BETA EEPROM bootloader does.
I THOUGHT you would want to check out this potential problem with the BETA
EEPROM bootloader since I thought the point of the beta was to FIND and FIX
problems before making it the stable release.
As I said in my first post I am using 4.19 kernel. I also tested the
problem on the 5.4 kernel and found it to also be a problem there but I am
SPECIFICALLY using an existing SD image that works with the stable
bootloader without a problem. Only when I load the beta bootloader to the
eeprom does this problem crop up. No other changes were made to the RPI4
and NO changes were made the my SD card image AT ALL while testing to
figure out this but.
Nathan Scherdin
…On Tue, May 26, 2020 at 10:21 AM Tim Gover ***@***.***> wrote:
Use the Raspberry Pi Imager to put the default production EEPROM on there.
If the black screen persists then as @JamesH65
<https://github.com/JamesH65> says it will be an issue with either the
firmware or the 5.4 kernel from rpi-update.
To revert
sudo BRANCH=stable rpi-update
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKNKMWDCMSLT33J3YATRTP3BLANCNFSM4NJZILEQ>
.
|
|
James Hughes,
After I found this problem I went back and eliminated all other variables
to narrow down the problem. I made sure I had a working clean image(my
control image SD) of Raspbian running 4.19 kernel. I used an unmodified
RPi4 to test and it worked correctly(DPI LCD comes up fine). I then
updated that RPI4 to the stable eeprom release using another SD image(not
my control image). After updating the eeprom I booted my control SD and
DPI LCD came up fine. Then I updated the RPI4 to the beta eeprom release
using the other SD image. I then booted the RPI4 with my control SD again.
This time no DPI display. Just blank. Has valid HSYNC, VSYNC, DOTCLOCK and
DATAENABLE but not RGB DATA coming out any pins.
Nathan Scherdin
…On Tue, May 26, 2020 at 10:14 AM James Hughes ***@***.***> wrote:
I cannot yet see how that can happen if the only change is the bootloader.
Are you sure tha is the only change, or could there also be firmware/kernel
changes?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKLAZ7NR5XRDBSKULG3RTP2GBANCNFSM4NJZILEQ>
.
|
|
I've passed this on, not sure if anyone has a DPI display to hand |
|
For testing, if you have a scope, you don't need a display. Just check some
of the DPI RGB pins for signals. Should see something on nearly any RGB
pin even if it is only "displaying" the usual "message of the day" and
command prompt. When using the beta bootloader my RGB pins all remain low
without changes, only hsync, vsync, dotclk and dataenable are active. Let
me know if you want want me to test something. I'll be happy to help
however I can.
Nathan Scherdin
…On Tue, May 26, 2020 at 11:18 AM Tim Gover ***@***.***> wrote:
I've passed this on, not sure if anyone has a DPI display to hand
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKKVCSNLWJ533BLWCPLRTQBWPANCNFSM4NJZILEQ>
.
|
|
Don't have one of those either, I'll upload a binary with a mini patch which resets a few more HVS registers before starting. Failing that, I might be able to take a look towards the end of next week if I visit the lab. |
|
Best guess without a debugger or DPI display |
|
Thank you. I will try to test this today.
Nathan Scherdin
…On Tue, May 26, 2020 at 11:53 AM Tim Gover ***@***.***> wrote:
Best guess without a debugger or DPI display
pieeprom-1c942e-hvs-reset.zip
<https://github.com/raspberrypi/firmware/files/4684392/pieeprom-1c942e-hvs-reset.zip>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKNQ4OWI7PKOLZC2OWTRTQFYZANCNFSM4NJZILEQ>
.
|
|
DISABLE_HDMI=1 in the bootloader config is also worth trying because that prevents any HVS initialisation |
|
Having a similar issue since May 15th. "dpi24" overylay results in a blank screen on my VGA LCD attached; the pi still boots though, and can run headless over SSH. However, using a Gert666 interface results in no boot at all. Tried DISABLE_HDMI=1 no luck. I'll give the patched pieeprom a shot today or tomorrow. |
|
This appears to have worked. Thank you.
For those who dont know how here is the command to update using this
file: sudo rpi-eeprom-update -d -f pieeprom-1c942e-hvs-reset.bin
Note I used the -d option to restore config to defaults just in case
something may have been corrupt in my config.
Nathan Scherdin
…On Tue, May 26, 2020 at 1:51 PM Tim Gover ***@***.***> wrote:
DISABLE_HDMI=1 in the bootloader config is also worth trying because that
prevents any HVS initialisation
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKONEAVN3VU7ZZK46FLRTQTWNANCNFSM4NJZILEQ>
.
|
|
Didn't work for my setup, but I am on linux 5.4. Could be an additional issue. |
|
Reverted to linux 4.19.118-v7l+ and still no luck with pieeprom-1c942e-hvs-reset.zip as bootloader. No apparent change in boot behavior. |
|
Did you reset the bootloader config(eg -d option)? Also have you gone back
to the April stable bootloader and confirmed your setup is still working
otherwise?
Nathan Scherdin
…On Tue, May 26, 2020 at 6:35 PM vol-2 ***@***.***> wrote:
Reverted to linux 4.19.118-v7l+ and still no luck with
pieeprom-1c942e-hvs-reset.zip as bootloader. No apparent change in boot
behavior.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKN6DJLE2XGBMZOW73TRTRU6BANCNFSM4NJZILEQ>
.
|
Yes.
No. The last bootloader I had working was from earlier in the year. I hadn't turned on that particular Pi since February. |
|
Using @timg236 patched bootloader as shown here raspberrypi/rpi-eeprom#133 Here is an image of what the text looks like: It's also extremely noisy and shaky, which doesn't come across in the photo. The text is really messed up though, it's like parts of the letters are missing and there are extra parts elsewhere. |
|
That's probably a different firmware or maybe FKMS issue. Please you verify that DPI is ok with the vanilla Buster February image? |
|
I am using the vanilla Buster February image right now, but with your firmware patch. The issue persists with dtoverlay=vc4-fkms-v3d commented out, so I don't know if that impacts your question about FKMS. I found that at least one of the DMT modes is somehow incorrect. When choosing 2,28 (which should be 1280x800) It sends 600x800 to my monitor. I'm fairly sure it's the Pi which is sending incorrectly because the aspect controls on the monitor distort when I stretch it horizontally. Mode 2,4 displays 640x480 as it should, but with considerable distortion to the image. Unless you think there's something else I should try first, I'm going to try and revert the bootloader back to and older one and see if I can get anything. |
|
If you are seeing any data at all on your DPI LCD, then your problem is
something other than the one I had. I had zero data coming out the RGB
pins, all the pins were always held low as tested with an oscilloscope.
The fact you have some data as shown by your image definitely points to a
different problem probably unrelated to the eeprom bootloader version. But
the only way to find out is to back track to the old bootloader and confirm
the problem persists.
Nathan Scherdin
…On Wed, May 27, 2020 at 7:18 AM vol-2 ***@***.***> wrote:
I am using the vanilla Buster February image right now, but with your
firmware patch.
The issue persists with dtoverlay=vc4-fkms-v3d commented out, so I don't
know if that impacts your question about FKMS.
I found that at least one of the DMT modes is somehow incorrect. When
choosing 2,28 (which should be 1280x800) It sends 600x800 to my monitor.
I'm fairly sure it's the Pi which is sending incorrectly because the aspect
controls on the monitor distort when I stretch it horizontally. Mode 2,4
displays 640x480 as it should, but with considerable distortion to the
image.
Unless you think there's something else I should try first, I'm going to
try and revert the bootloader back to and older one and see if I can get
anything.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1397 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE3QXKNPCXQ6PAGGUNOFUGLRTUOLXANCNFSM4NJZILEQ>
.
|
Yes, it certainly seems like a different issue than yours. You got nothing and I'm getting garbage. I don't wonder it's got something to do with the display controller. If we are theoretically getting the same thing out of the GPIO, then it stands to reason the difference is occurring downstream. |
On an RPi 4, DPI LCD will not display anything after updating to May 15th bootloader. The Display is active, hsync, vsync, dotclock and data enable are all active, but the display is blank.
bootloader_version info:
May 15 2020 11:05:52
version 23a9f59b85f5a81bb2eec455e064ef9905216322 (release)
timestamp 1589537152
Using the same SD image with the stable bootloader from April DPI LCD starts up correctly.
Using the same SD image on a second RPi4 with the May 15 bootloader I get just a blank screen.
After reverting that RPi4 back to the April bootloader the problem goes away.
Note this image is running kernel: Linux retropie 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux.
I also tried with an image using kernel 5.4. Same problem.
Note I was testing the beta bootloader so I could setup a USB SSD when I found this problem, then I back tracked to my previous image which still had the problem, and then I tried my previous image with another RPi4 with the stable eeprom bootloader.
Hoping this is something stupid on my part.
The text was updated successfully, but these errors were encountered: