Display glitch at Pinn boot menu

[JeffyBeepBoop]

I recently switched monitors and am now getting a display glitch on boot with the PINN boot menu.

On boot it shows the Raspberry Pi logo and boot text, then the rainbow, and then glitches as it loads the PINN boot menu, after the wait period, it will load my default OS and once again display properly.

I'm guessing I changed some default that isn't compatible with this monitor.

How can I get the Pinn boot menu to work again?

What I've tried: Press 1 & 2 on my keyboard at the glitch screen to try to switch display modes (does this need to be after pressing shift?) Add display=1 to recovery.cmdline Add display=2 to recovery.cmdline Removed dsi from recovery.cmdline

https://user-images.githubusercontent.com/79879140/144734798-1194f34e-8339-4e9b-866a-9436f587e0ed.mov

[procount]

What was your previous monitor? Does that still work normally? What is this new monitor? Is it connected over dsi? Is it the rpf touchscreen? What model of RPi are you using? Can you post copies of recovery.cmdline and config.txt from your PINN partition?

[JeffyBeepBoop]

The previous monitor was a portable monitor like this. I don't have access to it anymore, so I can't test it.

New monitor is this 7" touchscreen, not the rpf touchscreen. In the current setup, I'm not using the touchscreen over usb, and only have hdmi and micro usb power plugged in to the screen.

RPi 4B 4GB

recovery.cmdline

repo_list=http://raw.githubusercontent.com/procount/pinn-os/master/os/repo_list.json alt_image_source=http://pinn.mjh.nz/os_list.json?lineage17-rpi4=12000&raspberrypioslite32-bit=31650&raspberrypios32-bit=12547&twister=65102&lineage17-rpi4-atv=12000&projectspace-3=16128&datapartition=60162 quiet ramdisk_size=32768 root=/dev/ram0 init=/init vt.cur_default=1 elevator=deadline   loglevel=2 sdhci.debug_quirks2=4 display=2

config.txt

gpu_mem=16
start_file=recovery.elf
fixup_file=fixup_rc.dat

[pi4]
start_file=recover4.elf
fixup_file=fixup4rc.dat
max_framebuffers=2

disable_overscan=1

[procount]

I can't really see anything wrong with your settings, although I would probably remove display=2 if it is not making any difference. Are you able to connect to this Pi from another computer over the network via SSH and/or VNC? That way you can investigate further even though you have no display. Add forcetrigger ssh vncshare to recovery.cmdline to enable these features.

[JeffyBeepBoop]

After the wait period RPi OS (Buster) loads with display and I can ssh and vnc into it at that point.

Not sure what to look for. The way the screen glitches makes me think it's some sync/config issue. Not sure why the display works on boot and afterwards once the OS loads, but not PINN.

Is there a recovery mode to make it load the recovery file? Or does it do that automatically? I believe the keyboard is still working on the PINN boot menu even though I can't see it. I can probably pause boot as well and ssh into it while it's at the PINN boot menu if that's helpful.

Will remove display=2 since it doesn't seem to be doing anything.

[JeffyBeepBoop]

Update: I switched hdmi ports on the pi during the glitch, and briefly saw the PINN boot menu before it auto picked the default OS.

When I restarted the glitch returned, but I tapped up at the glitch to give me more time, and when I unplugged it and plugged it back in the same port, I could see the boot menu displayed properly!

This is on the Argon One V2 case.

🤔🤔🤔

[procount]

What I was suggesting was to SSH/VNC into PINN rather than Buster, but at least you are familiar with these tools. Please add forcetrigger ssh vncshare to the recovery.cmdline of the PINN partition to enable these features. (As you don't have a display in PINN I suggest you remove your SD card and edit it on a separate PC. Recovery.cmdline should consist of 1 single text line. Forcetrigger simulates the Shift key being pressed on each boot, so PINN will stop at the boot menu, which will allow you time to ssh/vnc into PINN and investigate further. As you cannot see the display whilst using PINN, you won't see the IP address displayed, so as a first guess, use the same IP address that you use to ssh/vnc into buster. If that doesn't work, using FING, IPScanner or other tools to identify the RPi's IP address, or examine your router DHCP tables.

PINN uses the legacy display, whereas Buster uses the new KMS drivers on the PI4. Not sure if that is significant because PINN does not actually try to change the display - it leaves is all to the firmware and Qt. I use an Argon One case too, so I doubt that is significant, unless there is a fault with it. Do you have a pinn_init.sh file left over from your previous monitor? If you do, please rename or delete it.

Once PINN has booted, please try to SSH into it. Use the login/password of root/raspberry.

Please report the output of:

tvservice -snl
fbset

(The last letter of snl is the letter ell)

After that try unplugging the HDMI cable from the Pi and reinserting it in the SAME socket. Then try the other socket. If you VNC into the pi, then you should get a mimic of your monitor's display (whether it is displaying or not).