S905X box startup corrupts EDID due to vendor firmware

[dreamlayers]

I have an OTT TV Box, model ABOX-A1 ( 1G + 8G, S905X ). Inside it looks very similar to NEXBOX A95X. When it starts up while connected to a Protron PLTV-26 TV, the TV EDID gets changed. This happens both with the original Android and when booting Armbian. I don't think it's due to Armbian. I wonder if it is due to startup code on eMMC or SOC ROM.

 

The changes happen at every startup and are always the same. It writes a 1 at EEPROM offset 2, and a 0 at offset 0x20. Normally, the EDID EEPROM chip is at I2C address 0x50, and many devices write protect it. On this TV it responds to addresses from 0x50 to 0x57 according to i2cdetect, and it is not write protected. The Amlogic SOC can read from I2C address 0x52 to force a particular boot mode: https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle . I guess this means it also writes to the EEPROM at I2C address 0x52.

 

Fortunately, I had an EDID backup from before, and the change was easy to undo via i2cset from my Raspberry Pi. Armbian also provides access to the HDMI I2C bus on this TV box, so it should be possible to fix this using it, as long as HDMI gets unplugged before the next startup.

 

A TV with a writeable EDID that can be accessed at address 0x52 could be used to force a boot mode. Though the Protron PLTV-26 only has a 128 byte EEPROM, and the string for forcing boot mode needs to be at EEPROM offset 0xF8 through 0xFF, requiring at least a 256 byte EEPROM.

 

It would be nice if I could alter something on eMMC to prevent this. If it is in ROM, I need to not use it with that TV, open up the TV to write protect the EEPROM, or break a HDMI cable or adapter to prevent communication with the EEPROM.

[SteeMan]

What armbian build are you using?

[dreamlayers]

I am using Armbian_23.11.1_Aml-s9xx-box_bookworm_current_6.1.63_minimal.img.xz

[SteeMan]

Ok.  So the Armbian build you are using uses the android uboot bootloader on emmc to boot.  Given what you report this looks like a bug in the android bootloader as it happens on Android as well as Armbian.

[dreamlayers]

I connected the ABOX to an 24LC21 I2C EEPROM programmed with the Protron PLTV-26 EDID, also connecting the hot plug detect line to the +5V line. Then I monitored I2C communication using a logic analyser. Here is the I2C activity I observed:

 

Quickly after startup, there is a sequential read of 8 bytes from memory address 0xF8 on I2C address 0x52. That is what https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle is talking about. It is safe. This won't corrupt EDID. (Note that some EEPROMS like the 24LC21 do not care about the lowest order 3 bits of the address and the pins that select the address, and respond to I2C addresses 0x50 through 0x57. Also note that the contents of the EEPROM wrap around, so even a 128 byte EEPROM can be used. A read to memory address 0xF8 on the 24LC21 ends up reading address (0xF8 & 0x7F) == 0x78. So you can put the boot string at address 0x78 through 0x7F on a 128 bit EEPROM.)

 

Then, just under a second later, accesses to I2C address 0x54 start:

Two reads from EEPROM address 1.

Write 1 to EEPROM address 2.

Write 0 to EEPROM address 0x20.

Those writes do the corruption.

 

Then 1.5 seconds later the EDID is finally read, using a sequence of individual byte reads from I2C address 0x50. It has already been corrupted by this point, by the two earlier writes. I think this is the firmware reading it, for the initial video mode.

 

About 12 seconds later there are more EDID reads. I think that's the Linux kernel doing it.

 

HDMI 2.0 puts the Status and Control Data Channel (SCDC) at I2C address 0x54. There, at address 2 you have "source version" and at address 0x20 you have "TMDS config". So, the firmware is attempting to write to those things. It is only allowed to access the SCDC if the EDID contains the HF-VSDB structure and the "SCDC present" bit there is set. But it is accessing SCDC without first checking the EDID. Another device, the EZCOO EZ-SW21HA21 HDMI audio extractor switch. also inappropriately accesses this SCDC.

 

Edit: I don't know where is the source for the exact U-Boot found in this box, but https://github.com/endlessm/u-boot-s905x/blob/9149dd46279da8c347f36b7ca3164f660cfd6581/arch/arm/cpu/armv8/gxb/hdmitx20/hdmitx_set.c#L300 shows code which causes this EDID corruption. There, scdc_wr_sink() writes to I2C address 0x54, and in scdc_prepare() it is used to do the two writes that corrupt my EDID.

 

Edited March 6 by dreamlayers
Found source code that corrupts EDID