Well Kodi is the very last app that is started during boot. Usually the Pi should be booting completely before kodi is going to launch.
I have done some more testing and as a result I no longer think that this is a firmware bug as it happens when Kodi is set to autostart. If default terminal is set to start then HDMI output does not fail.
I used this command G_CONFIG_INJECT ‘dtoverlay=vc4-kms-v3d’ ‘dtoverlay=vc4-kms-v3d,noaudio’ /boot/config.txt and used dietpi-config to change autostart option to terminal (0) default. I rebooted the Pi3 and it displayed the login prompt on the TV fine.
I then used dietpi-config to change autostart option to Kodi (1) and rebooted. The Pi3 flashed some text on screen and appeared to be booting as usual. The Kodi screen never appears and HDMI output drops and does not return before the Kodi screen is ever shown.
I then SSH back into the server and issued another reboot command to see if just by simply rebooting HDMI would fire back up on the next attempt. However, it goes through the same process of looking like it is going to reboot and HDMI drops again. This is kind of expected as I did not change anything and only simply issued a reboot command. This time though I am unable to SSH back into the server and I get message SSH connection refused. So, I waited and tried to SSH in again and this time SSH did not respond the cursor just flashed as though it was trying to connect but was very slow. After waiting for a little while the Pi3 rebooted of its own accord so I am guessing that whatever it was doing or trying to do eventually caused it to crash completely. After it rebooted of its own accord HDMI dropped again but I was able to get back into it using SSH to remove the noaudio option from /boot/config.txt. Having removed noadudio the Pi3 will boot straight into Kodi.
The problem appears to be if Kodi is set to autostart and the noaudio option is set in /boot/config.txt.
I hope this information is of some use and it makes sense.
I also tested now and verified that noaudio breaks full KMS video output completely, at least on RPi. The X server still works well, so I’m wondering whether this is Kodi specific, but looks like a bug as it breaks the parameters intention. Not yet 100% sure how to deal with it on sound card selection. It breaks the “auto” option to use HDMI audio when available and fallback to 3.5mm otherwise automatically. Also we need to check whether USB DACs (and other external sound cards) are ordered before or after the vc4hdmi devices 
.
Did further testing: Actually noaudio is not the issue, but that this triggers the firmware HDMI audio device to appear again is: While KMS is used, any attempt to play audio via the firmware HDMI audio device (which is present either when KMS is disabled or when noaudio is added) leads to a blank screen until reboot/power cycle. Not only Kodi triggers this, but also running speaker-test from console.
If a USB DAC is attached, it is possible to start Kodi, configure it to use the USB DAC, then add noaudio, reboot and Kodi starts fine without blanking the screen. But as fast as in Kodi the bcm2835 HDMI audio device is selected, the screen blanks. When selecting anything different than rpi-bcm2835-auto or rpi-bcm2835-hdmi as sound card via dietpi-config, onboard firmware HDMI is disabled anyway, so then noaudio can be as well added without causing any issues. Makes somehow sense to firmware HDMI audio and KMS/VC4 HDMI audio are always toggled together.
I’ll change the KMS and sound card selections in dietpi-config so that vc4hdmi is disabled/enabled whenever regular onboard HDMI is disabled/enabled to have some consistency regardless whether KMS is enabled or not.