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

[sbav1]

To interface 5v logic, I keep it simple (some would say "quick and dirty") : As 5v-TTL levels are compatible with 3.3v levels, the only need is a voltage protection.
The easiest way to do it is through a resistor with a 1N4148 rectifier tied to 3.3v (in many cases, the rectifier is already embedded in the chip for ESD protection, but it's worth the cost to add it anyway).

I really like it's simplicity . If I understand correctly: no matter what level is on the 5V side, this will ensure 3.3V-side GPIO level will be always kept below 3.3-0.6 == 2.7 volts (which should be still recognizable as "high" by 3.3V logic). Nice!

AFAIK Samsung SoC GPIOs are generally "push-pull" type (+ the 3rd state, when both transistors are switched off - when GPIO pin is configured as input). To directly interface 3.3V Soc Samsung GPIO pin with Raspberry Pi 3.3V GPIO pin I think I'll still need a resistor between them, for added protection - it may come in handy in case both pins are misconfigured as outputs.. Assuming both sides can withstand (at least) 2mA current draw, I guess such resistor should be in 3.3/0.002 == 1650 ohm range (1K5, 1K8 ?). But 1K8 will be probably to big in case Samsung SoC has internal pull-up/pull-down resistor configured on it's GPIO port input . Aw, what the heck, I'll try to use 330 or 470 ohm and see what happens .

But first I'll need to order some decent soldering iron/soldering station; my trusty (transformer-type) Lutola 6C is really not that much usable for nowadays electronics.

[sbav1]

3) Tap into serial/rs232 connection between main SoC and Micom

@juuso, I think Micom UART2 TX and RX pins should be (just a guess) somewhere on the east side, inside 13-24 pin range of the Weltrend chip (RX: pin 16, TX: pin 17 ???).
With an oscilloscope etc., you may try to confirm those locations - on UART2 TX there will be some traffic visible after any remote keypress, probably even on bricked TV.

Micom UART1 is clearly on pins 31 & 32 - but I doubt this UART port will be in any way usable for unbricking procedure.

[sbav1]

2) Forcing partition select by SoC GPIO <-> Weltrend GPIO pins/trace shorting:

Not surprisingly, it's virtually impossible to locate the proper Micom pin (the one which is used for partition selection) on supplied image.. Unless there is some track on the mainboard visible between Micom and Genoa SoC (not belonging to UART2 port connection - ?), the only sure method for finding the proper pin will be:
- measuring the assorted (circa 30) Micom pins: some pins with known functions can be excluded, but >>50% pins will still require such testing,
- toggle the partitions (by applying firmware update, etc),
- measuring ~30 micom pins again,
- and compare the results.

But this can't be done on bricked TV. And I don't expect we will be able to find a volunteer for this task (with similar TV model, proper equipment, steady hands, and a lots of patience).

[hondavtec]

-

[juusso]

Bad thing is that i don`t have oscilloscope neither required skills, and yes, no way to check on bricked mainboard

[oga83]

If I understand correctly: no matter what level is on the 5V side, this will ensure 3.3V-side GPIO level will be always kept below 3.3-0.6 == 2.7 volts (which should be still recognizable as "high" by 3.3V logic)

That's it !

Not surprisingly, it's virtually impossible to locate the proper Micom pin (the one which is used for partition selection) on supplied image.. Unless there is some track on the mainboard visible between Micom and Genoa SoC (not belonging to UART2 port connection - ?), the only sure method for finding the proper pin will be:
- measuring the assorted (circa 30) Micom pins: some pins with known functions can be excluded, but >>50% pins will still require such testing,
- toggle the partitions (by applying firmware update, etc),
- measuring ~30 micom pins again,
- and compare the results.

Can we really assume that the partition info is given by an I/O ?
The only reason for this would be to directly drive an address bit on the memory chip (let's say A24=0 for partition 0, A24=1 for partition 1) : the partition would be selected by hardware.
In this case, the micom I/O would probably not go to the SoC, rather to the memory chip.
If it's not driving an address line, it's not worth wasting an I/O as there is a serial link between micom and Soc.

[juusso]

I`m not sure this info may be helpfull, but /sbin/toggle sends some data (which is actually boot flag) to submicom, but we don`t know what address it is.
Look at console output after toggle is called. what does it mean ack and migh 0x35 can be some addresss or value...

-

thanks, will keep in mind when we`re sure what is needed to do...

[sbav1]

Can we really assume that the partition info is given by an I/O ?

I'm not 100% sure it is given by an Weltrend I/O, but it's most certainly obtained by SoC using it's I/O. I.e., boot loader is testing certain SoC GPIO pin, like that

Code: Select all

static int getPartFlag(void)
{
   /* UPDATE_FLAG P0.7 : SET CONTROL MODE */
   *(volatile unsigned int*)0x30090d00 |= (0x2 << 28);     /* SET P0.7 TO INPUT MODE*/
    
   /* UPDATE_FLAG P0.7 : READ */
   return (*(volatile unsigned int*)0x30090d08)>>7 & 0x1;
} 

(this is from Echo-P onboot sources; in Valencia/Genoa based TVs GPIO pin number / pad control register used may be different, but I believe the mechanism is more or less the same).

And AFAIRC in C-series partition toggle command was sent to micom via UART (I was actually hunting for micom backlight on/off command, but I remember there was a command for partition switching in C-series firmware as well - between other commands, for: setting timers, front panel LED blinking, watchdog petting etc.).
I'm assuming SoC GPIO used for partition select is connected to Weltrend Micom GPIO pin - and this is indeed just a guess . We can't exclude some other, more remote possibilities (like, e.g.: yet another sub-micom possibly integrated into Genoa SoC, controlled by yet another internal ARM UART port).

The only reason for this would be to directly drive an address bit on the memory chip (let's say A24=0 for partition 0, A24=1 for partition 1) : the partition would be selected by hardware. In this case, the micom I/O would probably not go to the SoC, rather to the memory chip.
If it's not driving an address line, it's not worth wasting an I/O as there is a serial link between micom and Soc.

I think it is (in a manner of speaking) driving a certain bit in internal SoC register (inside SoC "pad control" area), which (from ARM CPU point-of-view) is just another location in ARM address space.
About wasting I/O: true, but there are a lot of gpio pins/ports in those Samsung SoCs (and usually only about 50% actually used). While it would be quite possible for main SoC to obtain partition select flag via UART port, for some unknown reasons Samsung instead decided to use SoC gpio pin - I don't know why, perhaps because it was a little bit faster, or maybe it was more convenient for them in FPGA/development phase.

[oga83]

static int getPartFlag(void)
{
/* UPDATE_FLAG P0.7 : SET CONTROL MODE */
*(volatile unsigned int*)0x30090d00 |= (0x2 << 28); /* SET P0.7 TO INPUT MODE*/

/* UPDATE_FLAG P0.7 : READ */
return (*(volatile unsigned int*)0x30090d08)>>7 & 0x1;
}

With this code, I do agree with your assumption

there are a lot of gpio pins/ports in those Samsung SoCs (and usually only about 50% actually used)

That's a good reason, indeed !

[sbav1]

I`m not sure this info may be helpfull, but /sbin/toggle sends some data (which is actually boot flag) to submicom, but we don`t know what address it is.
Look at console output after toggle is called. what does it mean ack and migh 0x35 can be some addresss or value...

Looks like (more or less - in comparision with B,C-series models) typical SoC <-> Micom chatter over UART, 0x35 being acknowledge code expected by SoC after Micom command execution. Can you upload somewhere /bin/toggle binary from your particular TV model - we will eventually need to disassemble (or strace) it to check what exact commands it is sending to Micom. If any .