Odroid-C2 solid green screen on "echo c > /proc/sysrq-trigger" on Arch 4.16/4.17rc6

[narmstrong@baylibre.com (Neil Armstrong)]

On 05/06/2018 18:07, Jerome Brunet wrote:
> On Tue, 2018-06-05 at 13:48 +0000, Swabey, Matthew A wrote:
>> I'm not happy with the Raspberry Pi 3B, never really have been happy with any of their products due to their weird bootloader (just google netbooting Rpis - their implementation is badly broken), their overall hardware architecture etc. I much prefer the Odroid-c2, except for the 3.14 kernel. So when it went mainline I was very happy.
>>
>> However the reboot-greenscreen is problematic for my usecase, and I believe indicative of a possible race somewhere in the software stack, probably bootloader.
> 
> I don't think so.
> My guess would be that your screen somehow read raw '0x00' on link while the
> board resets. If your display is configured in YUV mode, you would see a green
> screen. 0,0,0 is green in YUV
> 
> If you were using RGB instead YUV, I suspect you would have a black screen,
> which is sad compared to 'funky green' but it is matter of taste I suppose.
> 

As I explained in a previous answer, the Watchog reset stops the whole SoC at a single point and reboots.
There is no way to handle this in software since it's designed to reset the SoC when the software is stuck.

As Jerome explained, the HDMI PHY is probably still sending some TMDS data but half of the SoC must in reset state,
thus sending data from YUV '0's. The HDMI on GXBB is configured to always send RGB, but the video converter must
still work when the reset occurs, thus seeing the last zero frame on the screen.

In watchdog reset, the fix is quite limited. As I replied earlier, it may be necessary to reset the HDMI
PHY in early code, but this code is in the control of Amlogic, and maybe HardKernel.
Anyway this SoC is no longer supported by Amlogic, so anything related to Firmware won't be fixed.
It should be interesting to see if the issue remains on the S905X/S905D SoCs.

Finally, if you see the same green screen after a normal shutdown/reboot command, this is another issue
and it means the HDMI disabling misses some code to avoid sending bad TMDS to the monitor.
This could be fixed for sure.

Neil