Help Touchscreen bricked? (don't compile with behold driver)

[screaminbug]

Hi,

Those of you who were yesterday (Wednesday) on IRC probably remember that fellow with the nick betzi. Was unable to find him here.

Anyway, long story short: he tried to put melfas driver from Behold2 sources and changed the CONFIG_SAMSUNG_BIGFOOT define to capela (probably CONFIG_SAMSUNG_CAPELA).

With this, his phone wouldn't boot at all, so he restored his IK5 nandroid backup only to find that his ts isn't working anymore. There were even no messages regarding touchscreen or melfas in the kernel log. He also tried to flash IK5 with Odin, but it didn't help.

If anyone has some idea how could we help him fix it please reply or come to IRC (I told him to drop by too). It could be a firmware problem. If it is that, and we manage to fix it by downloading some firmware from behold sources, then we'll, apart from helping him, prove that firmware can indeed be safely downloaded that way and maybe even get some new info on multitouch in the process.

 

[Rastaman-FB]

are there any touch screen drivers in the galaxy source code from samsungs website?

 

[Pieter]

That should be fixable, if the firmware flashing of the touchscreen still works. What you could try is:

Patch the firmware update code from the behold 2 source code into the galaxy kernel. Compile it, alter it to flash one update only (instead of automatically trying to find the most recent compatible one) and try flashing some of the touchscreen firmwares from the behold 2 source, starting with the galaxy firmware with number 33.

If that doesn't work, write code to dump the firmware from the touchscreen of a galaxy. Write that back into his touchscreen.

What might have happened is that the behold firmware got flashed to the galaxy screen, which is probably different hardware. The behold kernel automatically tries to update the touchscreen firmware at boot. That would explain the problem.

 

[Andronix]

That should be fixable, if the firmware flashing of the touchscreen still works. What you could try is:

Patch the firmware update code from the behold 2 source code into the galaxy kernel. Compile it, alter it to flash one update only (instead of automatically trying to find the most recent compatible one) and try flashing some of the touchscreen firmwares from the behold 2 source, starting with the galaxy firmware with number 33.

If that doesn't work, write code to dump the firmware from the touchscreen of a galaxy. Write that back into his touchscreen.

What might have happened is that the behold firmware got flashed to the galaxy screen, which is probably different hardware. The behold kernel automatically tries to update the touchscreen firmware at boot. That would explain the problem.

easy as 1,2,3

 

[Deleted User]

Hi all,

The guy from IRC is me actually. Thanks for discussing my problem here, BTW.

What is odd, is that now when I boot stock Galaxy kernel, the melfas driver doesn't appear at all in the dmesg output. Not even something like "melfas: probing" etc.

I didn't have too much time to look into what the behold driver tried to do as the galaxy with the behold driver didn't boot up at all (BTW: are there any other files that belong to the melfas driver apart the two in drivers/input/touchscreen/melfas*?)

Any help appreciated... I'll try to figure out if the fw of the touchscreen can still be flashed, but as I said, the driver doesnt seem to print anything at the moment at all.

Chris/Betzi

BTW: I havent flashed with odin again, but i flashed the boot.img with fastboot (which should be same thing. Anyway i am back on stock kernel (built from someone called "andy").

 

[screaminbug]

What might have happened is that the behold firmware got flashed to the galaxy screen, which is probably different hardware. The behold kernel automatically tries to update the touchscreen firmware at boot. That would explain the problem.

I thought about that, but one thing that doesn't fit in that scenario is system not booting (it hangs at logo). That's also a problem because it's impossible to see the kernel log.

The thing to do is to carefully analyze the code and see what exactly is going on there.

 

[Deleted User]

Is there no way of attaching a serial<>USB cable to the phone and somehow log what happens in those early kernel booting phases? Or USB network with netconsole or something?

Chris

 

[screaminbug]

Hi all,

The guy from IRC is me actually. Thanks for discussing my problem here, BTW.

What is odd, is that now when I boot stock Galaxy kernel, the melfas driver doesn't appear at all in the dmesg output. Not even something like "melfas: probing" etc.

Hello Chris,

I may have some idea why it doesn't show in dmesg. It probably fails on initialization in int __devinit melfas_ts_init(void)
As you can see, there is no logging there. So to make sure try to see what does i2c_add_driver(&melfas_ts_driver) returns.

 

[Deleted User]

Hi,

I have added more traces and turned the FB console on, to see what's happening. In fact the behold sources first "successfully" erases the fw of the ts and then tries to reflash the new one. The process stops after a while of flashing (I can see the printed #s of the flash routine on the fb console) but then the kernel reboots without a message.

I just tried to flash one block of data and I can immediatly after that, read back the written data. If I write only randomly half of the FW size, writing succeeds but the device doesn't seem to like it (no wonder) as further verification routines fail.

So either:
- we write to wrong location
- the FW is not one of the FWs in the melfas_fw_binary folder of the behold
- the behold flash routine is buggy

The question is: why does the kernel/device reboots while flashing. I suspect that the flashing routine is bogus.

Chris

 

[skandalfo]

I just tried to flash one block of data and I can immediatly after that, read back the written data.

So theoretically if you know what the erased+upgraded addresses are, you could just read the touchscreen firmware from a working galaxy by using a modified kernel, and then reflash that to the bricked one, can't you?

 

[Deleted User]

So theoretically if you know what the erased+upgraded addresses are, you could just read the touchscreen firmware from a working galaxy by using a modified kernel, and then reflash that to the bricked one, can't you?

Yes. I think that's possible. But it's not without risk, as the reading part writes READ commands to the i2c bus. But...

Chris

 

[Deleted User]

Update: Pieter was able to extract the FW from his working touchscreen. Wow! Flashing it back with the behold sources doesn't work though for me. It seems to reboot / crash during the flashing. It actually seems to randomly flash, as when I add more waits it seems to crash earlier (printing the block numers that it is flashing). Maybe its a timing issue, maybe the behold sources are not adapted or buggy....

Chris

 

[Pieter]

Chris, the Behold sources actually look quite good in this respect - although they are rather messy. Does it print:
[MELFAS] MCSDL_RET_PROGRAM_FLASH_FAILED
?

did you:
- disable module/fw version check
- set the length of the firmware dump correctly (very important!)
- did you try skipping the erase check?
- did you try to skip the disable/enable baseband irq thing?

Probably the easiest way to debug is just copy this one step at a time into the galaxy source i last sent you, with everything disabled but the firmware dump. May seem like more work, but then you can monitor where things go wrong, fix them and continue with the next step.

 

[screaminbug]

Well, good work Pieter. What was the length then? Does it match any fw in behold sources?

Chris, what routines are you using? Are they from melfas_downloadmcs5000.c or from melfas_i2c_tsi.c? The latter ones don't look finished (?), and apparently there isn't a check for odd fw length.

 

[Deleted User]

Yeheeee!!!!!!!

Got it working again. I flashed "melfas_fw_binary/5S_MTH_SI7500P_RKA1_VA33_bin.c" this one onto it.
And i see this in dmesg:
<6>[ 1.607866] melfas_ts_probe: Firmware Version 6
<6>[ 1.608528] melfas_ts_probe: Module Revision 10
<4>[ 1.610960] melfas_ts_probe: max_x 320, max_y 480
<6>[ 1.611943] input: melfas-tsi-touchscreen as /devices/virtual/input/input2
<6>[ 1.642020] melfas_ts_probe: Start touchscreen melfas-tsi-touchscreen in interrupt mode

I think the problem with flashing is, that it takes somewhat too long and the kernel reboots (or it is just a problem with my kernel and FB console which reboots anyway at some point).

I dont know though why flashing Pieters didnt work. Maybe just some FFs too less/much.

Anyway thanks to all of you who helped me especially Pieter who spend some time to help me.... And remember... If anybody wants the code, PM me.
Chris

 

[Xenon]

It's good that you didn't brick your touchscreen after all

Did we learn anything new about multitouch from this?

 

[informale]

It's good that you didn't brick your touchscreen after all

Did we learn anything new about multitouch from this?

Yes! It's dodgy

And yes, congrats on restoring the touchscreen!