[SOLVED] Forced "toggle" to repair bricked TV?

[sbav1]

if I'm not wrong, there is no uart between Soc And Micom, rather I2C or SPI,

AFAIK, in BD-D8XXX/E8XXX BD-player models, Samsung is using SPI bus (+ one extra line for rising SoC external IRQ) as main mode for SoC <-> Micom communications..
I think Firenze/Echo-B SoC is SPI master, and Renesas/NEC micom is acting as SPI slave. In case Renesas Micom needs to send something to Sasmung SoC (e.g., to report remote keypress, CEC event, etc.), it generates an IRQ to the main SoC. And in their IRQ handler routine, Samsung SoC probably queries the Renesas Micom via SPI bu (eg., in case it was a remote keypress event: to obtain specific remote code from Micom).

There is an UART connection between Firenze/Echo-B SoC and Renesas Mincom, but - like you said, it is apparently only used for micom firmware programming

[oga83]

it generates an IRQ to the main SoC

I didn't find any IO for which the scope was triggered when a key was pressed (except on the demodulated IR signal pin)
IRQ could be on P121; as there are many spikes, it would also be triggered very often for some other reasons.
At worse, they may have used polling (SPI is continuously active on P20/P21, so latency would be low when a key is pressed).

Being given the timings, I'm pretty sure that P24/P25 is CLK/DATA for I2C front panel, and P20/P21 is CLK/DATA for SPI link with SoC.

Any idea about the 1.35kHz square wave (P22) ?

[sbav1]

it generates an IRQ to the main SoC

I didn't find any IO for which the scope was triggered when a key was pressed (except on the demodulated IR signal pin)
IRQ could be on P121; as there are many spikes, it would also be triggered very often for some other reasons.
At worse, they may have used polling (SPI is continuously active on P20/P21, so latency would be low when a key is pressed).

I just assumed they use IRQ , because after each CEC event (I don't have a remote control for my BD-D6900 - so I'm controlling it with TV remote via CEC), SoC IRQ31 count goes up:

Code: Select all

cat /proc/interrupts

           CPU0
  0:     356839  sdp interrupt controller  irqtsd
  1:       3199  sdp interrupt controller  irqaio
  2:      82476  sdp interrupt controller  BDGA
  3:     411584  sdp interrupt controller  SDP Timer tick
  4:          0  sdp interrupt controller  irqpsd
  5:        251  sdp interrupt controller  irqse
  6:         38  sdp interrupt controller  irqae
  7:       1282  sdp interrupt controller  irqhdmitx
  8:      16047  sdp interrupt controller  ahci-sata0
  9:          0  sdp interrupt controller  ahci-sata1
 12:     408754  sdp interrupt controller  irqDp
 13:       2174  sdp interrupt controller  ehci_hcd:usb1
 14:          0  sdp interrupt controller  ehci_hcd:usb2
 15:      41064  sdp interrupt controller  irqmfc
 16:       1886  sdp interrupt controller  eth0
 17:      42054  sdp interrupt controller  sdp-mmc
 22:          1  sdp interrupt controller  ohci_hcd:usb3
 23:          1  sdp interrupt controller  ohci_hcd:usb4
 26:       4085  sdp interrupt controller  sdp-serial
 27:          0  sdp interrupt controller  SspHandler
 28:      81854  sdp interrupt controller  sdp_i2c_irq, sdp_i2c_irq
 31:        102  sdp interrupt controller  front
Err:          0

Looks like SoC IRQ31 ("front") is handled by fpi.ko kernel module, I yet have to take a proper look what's inside..

Being given the timings, I'm pretty sure that P24/P25 is CLK/DATA for I2C front panel, and P20/P21 is CLK/DATA for SPI link with SoC.

When exeDSP is running, we can probably expect an non-stop chatter on SoC-Micom SPI link (watchdog "I'm alive" messages, etc.). Also when the player is in TV mode/media player mode, I think exeDSP constantly commands Renesas Micom to update VFD X:XX:XX display (several times per second), that should also explain subsequent "non-stop" traffic on I2C bus (between Micom and VFD display controller - ???).

I wonder what kind of interface they are using between front panel touch key controller and Renesas Micom in BD-players (in TVs, there are usually two KEY1 & KEY2 lines on IR/function connector for that, and Weltrend Micom measures the voltage levels on those lines using it's built-in analog-digital converters).

When exeDSP is not running (fpi.ko needs to be loaded, though), SoC-Micom SPI communication becomes much more easier to understand . 'cat /dev/spi0 | ...' yelds some data after each remote keypress - like in TVs, each remote keypress seems to generate at least 2 events (1 key press event + 0 or more key repetition events + 1 key release event). This is for CEC remote, but for real IR remote I expect the same behaviour.

Any idea about the 1.35kHz square wave (P22) ?

Interesting - some kind of PWM signal perhaps, but for what exactly? Is it present while micom is in standby mode, too?
Maybe it's for front panel LED indicators.. Apart from VFD display, there are several (individually driven) LEDs on the front panel (+ the white LED array above the loader - at least in BD-D6900). Also, there seems to be some kind of circuit to control VFD brightness on the front panel display board.

[sbav1]

I guess that when a key is pressed, it's code is also read by I2C (why would they implement 2 dialog lines ?).

By SPI, more likely (just IMO); unless I'm very much mistaken, there is no I2C bus between Firenze/Echo-B SoC and Renesas Micom. But perhaps there is an I2C bus between Renesas Micom and front panel VFD display controller??

Why the two (SPI+UART) SoC<->Micom dialog lines in recent top-tier Samsung BD-player models?? Dunno.. I agree, from engineering standpoint (not to mention bean-counters standpoint), this is an abomination .
While I'm unable to find any service manuals for Samsung recent BD-players, there are some service manuals for older C-series (Broadcom SoC based) Samsung BD-player models available, and (judging from the block diagrams), they were using SPI + IRQ mode of communication in older models as well! So, maybe it's a backward-compatibility-related thing, because Samsung developers were simply more familiar with previously used SPI+IRQ method (?).

[sbav1]

We still have 12 candidates for the partition toggle pin

After the recent onboot source code release for 2011 Firenze BD-players ("onboot_Firenze_2011.tgz", available since yesterday on Samsung opensource site in TV -> DTV -> ETC section), I'm now 99% sure Samsung is not using SoC gpio pin for partition selection in their Firenze (2011,2012) & Echo-B BD-player models .
Instead, in BD-D6900/BD-D8XXX/BD-E8XXX/BD-E6100 devices, current partition setting is stored in eMMC or OneNAND flash:

Code: Select all

int get_part_flag(void)
{
	char* tempReadPage;
	int part_flag = 0;

	mmc->block_dev.block_read(mmc, PARTITION_FLAG, PARTITION_FLAG_SIZE, (void*)PARTITION_FLAG_ADDR);

	tempReadPage = PARTITION_FLAG_ADDR;

	if( tempReadPage[0] == 'S' 
			&& tempReadPage[1] == 'T'
			&& tempReadPage[2] == 'A'
			&& tempReadPage[3] == 'R'
			&& tempReadPage[4] == 'T'
			&& tempReadPage[9] == 'E'
			&& tempReadPage[10] == 'N'
			&& tempReadPage[11] == 'D')
	{
		if( tempReadPage[5] == '2' 
				&& tempReadPage[6] == '2'
				&& tempReadPage[7] == '2'
				&& tempReadPage[8] == '2')
		{
			part_flag = 1;
		}
		else if( tempReadPage[5] == '1' 
				&& tempReadPage[6] == '1'
				&& tempReadPage[7] == '1'
				&& tempReadPage[8] == '1')
		{
			part_flag = 0;
		}
		else
		{
			part_flag = 0;
		}
	}
	else
	{
		part_flag = 0;
	}

	return part_flag;
} 

But I still believe they use GPIO pin for partition toggling in Valencia/Genoa/Echo-P TV models with Weltrend Micom..

[E3V3A]

^^ In which file is that? (And, what is the partition flag address?) Then, even though the current boot partition is set in eMMC, there still have (?) to be another way to toggle it from UART/I2C etc... If not, there would not be much use for having a second boot partition in the first place, would it?

Also, if anyone has a "buspirate", you can use it to communicate with the I2C bus in case you're not sure what's on those pins. I'm sure there's some I2C code for the Strawberry Pi out there as well...

@juuso: How did you obtain the micom commands you posted here?

[juusso]

@juuso: How did you obtain the micom commands you posted here?

You should ask not me, but Denny, where he got it from. Afaik - from sources (bootloader`s/toggle`s), maybe micom`s firmware and also blind testing on its ovn TV.

We don`t know partition flag address. This is one of goals we`re trying to reach...

[sbav1]

I'll try to summarise what we know so far (sorry for repeating myself - but in order to help avoiding some possible further confusion, as we now discuss all kinds of Samsung devices in this thread, not only D-series TV models).

Apparently Samsung is using (at least) two completely different mechanisms for partition toggling purposes in their recent devices:

1) In C-Series, D-Series and E-series TVs (models based on Samsung-developed Valencia, Genoa-*, and Echo-P SoCs - with T-VAL*, T-GA*, and T-EC* firmwares): partition switching is controlled by SoC <-> Weltrend Micom GPIO pins (partition setting being stored - most likely - in Weltrend Micom EEPROM, and toggled by sending UART command to Micom - via /dev/ttyS*, using /sbin/toggle or /sbin/rollback),
2) In D-Series and E-series BD-players (models based on Samsung-developed Firenze and Echo-B SoCs - with B-FIR* and B-ECB* firmwares): partition setting is stored directly in flash chip (OneNAND or eMMC flash, depending on what flash is being used in particular model), and Renesas/NEC Micom is not involved in partition switching.
3) We don't know yet what partition switching mechanism (if any) Samsung is using in their other devices, not based on Samsung-developed SoCs (like Mstar-based TV models with T-MST* firmwares, or Broadcom-based BD-player models with B-BRC* firmwares).

[sbav1]

^^ In which file is that?

MMC_BM_NBL2_Common.c, from Samsung onboot sources for their 2011 Firenze-based BD-player models (in "onboot_Firenze_2011.tgz" open source package recently released by Samsung).

(And, what is the partition flag address?)

Partition flag location/address in eMMC or OneNAND flash is most likely model-dependent. E.g, in my D-series HT-D7100 and BD-D6900 BD-players, partition selection setting string ("START2222END" or "START1111END") seems to be stored on first 12 bytes of /dev/mmcblk0p11 partition, but I expect it to be in different places in other variants/models/firmware branches.

Then, even though the current boot partition is set in eMMC, there still have (?) to be another way to toggle it from UART/I2C etc...

Not likely . At least, not likely for BD-D6XXX/7XXX/8XXX Samsung BD-players with eMMC flash.. Well, in theory, perhaps it may be somehow possible to modify eMMC flash contents using it's embedded CPU/controller, via some hidden UART or I2C eMMC chip interfaces (if any). While there are usually various extra eMMC chip pins labeled as "do not use - manufacturer use only" in flash chip datasheets, those are typically not documented at all - from user PoV, eMMC internal CPU/controller is a black box. And those hidden eMMC controller interfaces (if any) are probably not even connected to any external buses on Samsung "production" motherboards.

If not, there would not be much use for having a second boot partition in the first place, would it?

Why? It's handy to have two separate partition sets (so it's possible to flash partitions which are currently not mounted/not active - firmware upgrades are much safer that way). And for Samsung purposes, it's probably quite sufficient to be able to switch active partition sets from OS level only (by sending UART command to Weltrend Micom - in TV models, or by rewriting 12 bytes in some flash location - in BD-players).

[sbav1]

@juuso: How did you obtain the micom commands you posted here?

You should ask not me, but Denny, where he got it from. Afaik - from sources (bootloader`s/toggle`s), maybe micom`s firmware and also blind testing on its ovn TV.

Surest method will be probably /sbin/toggle or /sbin/rollback disassembly - it's relatively small binary. Even if exact command[s] will be find for Denny E-Series TV, it's not 100% guaranteed they are exactly the same as in D-series TV models.

We don`t know partition flag address. This is one of goals we`re trying to reach...

But you are (???) talking about partition flag address in Weltrend Micom EEPROM (in D6500 TV models etc.), while E3V3A is probably referencing different kind of partition setting address (the START1111END, START2222END strings stored in eMMC/OneNand flash memory - in BD-players).