gslx680 driver ported to sunxi

[joe.a.bu...@gmail.com]

Hi,

For a while I've been working on getting my A13 tablet touch screen working with GNU/Linux.

It's now working well enough for my purposes and I figured it was time to push it out.
The code can be found at:
https://gitorious.org/gslx680-for-sunxi

It would be easy to move it in tree. What is a bit different from the other touch screen drivers is that it doesn't include the firmware in the driver.
I've split the firmware into a separate file that you name in the fex/script.bin file.
The reason for this is that the firmware defines things about the hardware such as resolution and can't be easily modified. So to support multiple devices you'd need multiple firmware included. Or your have to build for each driver+firmware combination. Better to have it a seperate file and which firmware be a configuration thing. That fits better to me with fex/script.bin or Device Tree. I've also added legacy single touch as well as multi touch.

Not sure where we go from here, but no point me sitting on it. ;-)

Joe

 

[Sergio Costas]

Hi joe:

Just yesterday I ended an user-space device driver for gslx680. It has
the advantage of being able to do scrolling and zoom in X by emulating
the mouse wheel, and also allows to do a "right click". Just in case
someone wants to play with it...

https://github.com/rastersoft/gsl1680

El 27/08/13 21:14, joe.a.bu...@gmail.com escribi�:

--
Nos leemos
RASTER (Linux user #228804)
ras...@rastersoft.com http://www.rastersoft.com

[joe.a.bu...@gmail.com]

Hi Sergio,

It must be time for the gslx680!
Mine is basically a port of the one this document points to. Plus the single touch and breaking out the firmware that I mentioned.

I'll update the wiki page with a reference to my port and anything extra I know about the registers.

Not sure about integrating mouse wheel and "right click". I'll think about it, but it would be useful for using with the existing desktops.

Interestingly, from the example bit of firmware at least, though our tablets seam very very similar, the firmware is different. How different I'm not sure yet. I need to compare the complete things.

Joe

On Tuesday, August 27, 2013 8:39:38 PM UTC+1, Sergio costas wrote:

Hi joe:

Just yesterday I ended an user-space device driver for gslx680. It has
the advantage of being able to do scrolling and zoom in X by emulating
the mouse wheel, and also allows to do a "right click". Just in case
someone wants to play with it...

https://github.com/rastersoft/gsl1680

El 27/08/13 21:14, joe.a.bu...@gmail.com escribi�:

[joe.a.bu...@gmail.com]

Hi Sergio,

Looks like we found different firmware worlds. For me the firmware was included in the driver and I had to cut it out.

I wrote a tool to do this for the future as it's a pain to manually find it in hex and dd it out.

https://gitorious.org/gslx680-for-sunxi/gslx680-for-sunxi/source/firmware/fw_extractor

I've added a link to this on the wiki http://linux-sunxi.org/GSL1680

Just out of interest, can you send me your firmware?

Thanks

Joe

On Tuesday, August 27, 2013 8:39:38 PM UTC+1, Sergio costas wrote:

Hi joe:

Just yesterday I ended an user-space device driver for gslx680. It has
the advantage of being able to do scrolling and zoom in X by emulating
the mouse wheel, and also allows to do a "right click". Just in case
someone wants to play with it...

https://github.com/rastersoft/gsl1680

El 27/08/13 21:14, joe.a.bu...@gmail.com escribi�:

[selim...@gmail.com]

27 Ağustos 2013 Salı 22:14:14 UTC+3 tarihinde joe.a.bu...@gmail.com yazdı:

Hi,

I have a A13 tablet (just like this one --> http://moveontechnology.com/hugoenchina/?p=324)
and while trying to make touchscreen working I came acrross with this gslx680 driver(https://gitorious.org/gslx680-for-sunxi)

I'm using sunxi-3.4 kernel and compiled the driver successfully for this kernel. My screen resolution is 800x480 so I'm using the firmware supplied by the source code.

I can successfully insmod the driver, got the successfull dmesg messages as expected, but when I try testing the driver with "evtest" tool, i got totally no output from gslx680 mmodule (/dev/event/event1).

I am completely stuck at this point, any suggestion will be really helpfull.
Thanks in advance.

selim

[Joe Burmeister]

Hi Selim,

I've done an update recently that makes the new code work properly with
X, it was broken at one point.
At this point, as far as I know, I need to start the process of getting
it into sunxi properly. Maybe add DT and get it fully upstreamed. Yet to
start that process.

Anyway, no output from evtest tells me the problem is probably the firmware.

You need to extract the firmware from your android driver. There is a
python script in the firmware directory called fw_extractor (and
fw_info) that should be able to do this, if the driver is related to the
Android one with my device. If the firmware isn't in the Android driver,
then we need to find where it lives on your device and put it into the
same binary format.

If you feel you aren't getting anywhere, send me the Android driver and
I'll have a look to see if the firmware is in there and adapt the script
to find it there too.

We need to start building a database of the firmware for the gslx680
chips. If we can work out how to tell which chip needs which firmware,
we can select the right one automatically. The aim of course is
everything just works. :-)


Joe

[selim...@gmail.com]

13 Mart 2014 Perşembe 12:20:15 UTC+2 tarihinde Joe Burmeister yazdı:

Joe Hi,

Thanks for the quick reply,

Indeed I have read in some forum posts that people trying wrong
gslx680 firmwares got shifted touch outputs, I haven't seen a post
with no output from the driver.

I hope its about the wrong firmware.

Ok, now I will pull the successfully running driver (gslX680.ko)
from running android device and extract the firmware as you suggested.

Thanks again.

selim

[Joe Burmeister]

Hi Selim,

No prob, delighted when someone has a play with it. :-)

The result of the wrong firmware is hard to guess.
The firmware for this device is just a buck load of settings from what I
can see.
Only thing that probably holds is it depends how far out your device is
from the settings in the firmware on how well it works.

Please please let me know how you get on.

Joe

[selim...@gmail.com]

13 Mart 2014 Perşembe 14:22:52 UTC+2 tarihinde Joe Burmeister yazdı:

Hi Joe,


Today I have rooted my tablet, successfully find the touchscreen module named as "A13_gslX680" and pulled the ko file with adb pull.

Good news :)
After extracting the firmware from the original module and trying gslx680_ts driver with the original firmware everything worked like a charm, now I can get outputs from evtest tool.

More information about my tablet and firmware is;

my tablet exactly looks like this one --> https://drive.google.com/file/d/0B7kdmqnGET4eeHVlY1k2REVlemc/edit?usp=sharing

Screen size: 9" , 800x480

Mainboard ID : TW_A0910_16B_V1.1_0830

Touch screen IC : GSL3680

Original Module : https://docs.google.com/file/d/0B7kdmqnGET4eeHVlY1k2REVlemc/edit?pli=1

Original Firmaware (extracted): https://docs.google.com/file/d/0B7kdmqnGET4eNzItc0tYYW5PY3M/edit?pli=1


I hope it is useful for others.

Thanks for your help.

selim

[selim...@gmail.com]

14 Mart 2014 Cuma 17:33:56 UTC+2 tarihinde selim...@gmail.com yazdı:

sorry wrong link for the tablet !

my tablet exactly looks like this one -->

http://www.aliexpress.com/item/MV90-9-inchs-Allwinner-A13-Tablet-9-single-core-4GB-512MB-360-deg-gravity-sensor-cheap/1528614982.html

[Joe Burmeister]

Hi Selim,

Cool, really happy it went smoothly for you. When I'm back home, I'll
add your firmware to the repo, and see if I can get more details about
my gslx680 firmware to label it better.

You tried it with X yet? I take it you are using the latest code from
https://gitorious.org/gslx680-for-sunxi
Let me know if how it goes.
Anything that could have been more useful on the wiki?


Joe

[Joe Burmeister]

Thanks, I've added your firmware to the repo. I also took apart my
tablet to see exactly which gsl?680 mine is. Answer, gsl1680. So we have
gsl1680 and gsl3680. When I get a spare moment, I'll process this stuff
update the wiki page.

Joe

[selim...@gmail.com]

17 Mart 2014 Pazartesi 00:52:27 UTC+2 tarihinde Joe Burmeister yazdı:

Joe,

I'm using the latest sources, but while I dont have an X
(or any kind of window manager) on my target device,
I cant help you with X compatibility.

I'm using Qt/QWS with tslib (direct access to fb) on my target,
now I'm trying to work it out.
I will inform you when I succeed.

Regards.

selim

[Joe Burmeister]

Cheers,

Should work, I'm sticking the to protocol as far as I know.
You should be able to use single or multitouch events.

Joe

[hunter hu]

Hi Joe,

I have a gsl1680 chip and it is a 4.3" 480x272 display.  I used the  "firmware/fw_extractor" tool extracted the firmware from the Android binary gslx680.ko for my tablet, but experiencing the same issue Selim had before. 

dmesg shows the driver successfully loaded, chip probed and firmware also loaded correctly, but evtest shows no output whatsoever.

Any help or ideas will be appreciated, thanks in advance.

thanks,

-Hunter

[Joe Burmeister]

Hi Hunter,

Sorry didn't get back sooner, only had my phone with me and writing anything of any length on it is painful.

Can you send me your dmesg output and your gslx680.ko?

Maybe there is something in the dmesg output that will tells us more. If not, perhaps some extra verbose info can be added to the driver to give us a clue.

The other thing I want to check the firmware extracted by the extractor, perhaps it's not all of it.

Joe

--
You received this message because you are subscribed to a topic in the Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to linux-sunxi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hunter hu]

Hi Joe,

Thank you so much for replying and following up the issue, I really appreciate your help.

Here I attached the dmesg on the driver integration output, my android gslx680.ko and the firmware extracted from it using your script.

Regards,

-Hunter

[hunter hu]

I believe it is not allowed to attach dmesg on the forum, I copy the driver's output:

396 [    8.005277] ===========================gslx680_ts_init=====================

397 [    8.036669] _fetch_sysconfig_para.

398 [    8.039569] gslx680 firmware 420tpc.fw.

399 [    8.048699] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe

400 [    8.131368] _fetch_sysconfig_para: ctp_twi_id is 1.

401 [    8.162988] _fetch_sysconfig_para: screen_max_x = 480.

402 [    8.185533] _fetch_sysconfig_para: screen_max_y = 272.

403 [    8.208446] _fetch_sysconfig_para: revert_x_flag = 0.

404 [    8.232748] _fetch_sysconfig_para: revert_y_flag = 0.

405 [    8.262853] _fetch_sysconfig_para: exchange_x_y_flag = 0.

406 [    8.291023] i2c-core: driver [gslx680] using legacy suspend method

407 [    8.322871] i2c-core: driver [gslx680] using legacy resume method

408 [    8.353931] ctp_detect: Detected chip gslx680 at adapter 1, address 0x40

409 [    8.391662] ====gslx680_ts_probe begin=====.

410 [    8.393688] ==kzalloc success=

411 [    8.396476] [GSLX680] Enter gsl_ts_init_ts

412 [    8.422147] ctp_set_irq_mode: config gpio to int mode.

413 [    8.451901] ctp_set_irq_mode, 862: gpio_int_info, port = 7, port_num = 11.

414 [    8.453855]  INTERRUPT CONFIG

415 [    8.490769] input: gslx680 as /devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input1

416 [    8.618349] =============gsl_load_fw start==============

417 [   23.431110] =============gsl_load_fw end==============

418 [   23.738046] ==gslx680_ts_probe over =

[Joe Burmeister]

Hi Hunter,

Had a quick look. The firmware seams to be extracted correctly. It all looks like what I'd expect.

There is something else starting at 000a5f00 offset in the android driver, it looks like it could be some other firmware. But it's not very big, and doesn't fit what I think I know about gslx680 firmware.

It's no strong indicator, because there isn't a clear 1 to 1 relationship, but the resolution stated by fw_info is 800x480, which is quite a bit bigger then 480x272.

Can you send me the fex file that came with the device?

Joe

[hunter hu]

Thanks Joe, the fex is attached.

[bon...@gmail.com]

I have compiled the gslx680 driver, but there is a problem finding the firmware file (Error -2). Is there an standard location where the module will search for it? 

I'm using a 3.4 kernel, and the F20 image. Many thanks! 

Module loading dmesg excerpt following:

[  342.700742] ===========================gslx680_ts_init=====================

[  342.704643] _fetch_sysconfig_para. 

[  342.708780] gslx680 firmware /lib/firmware/tablet.fw. 

[  342.718037] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe 

[  342.722046] _fetch_sysconfig_para: ctp_twi_id is 2. 

[  342.726244] _fetch_sysconfig_para: screen_max_x = 800. 

[  342.730476] _fetch_sysconfig_para: screen_max_y = 480. 

[  342.734587] _fetch_sysconfig_para: revert_x_flag = 1. 

[  342.738699] _fetch_sysconfig_para: revert_y_flag = 1. 

[  342.743223] _fetch_sysconfig_para: exchange_x_y_flag = 1. 

[  342.748665] _init_platform_resource: tp_io request gpio fail!

[  342.760743] i2c-core: driver [gslx680] using legacy suspend method

[  342.772884] i2c-core: driver [gslx680] using legacy resume method

[  342.781601] incomplete xfer (0x20)

[  342.786900] incomplete xfer (0x20)

[  342.793411] ctp_detect: Detected chip gslx680 at adapter 2, address 0x40

[  342.797667] ====gslx680_ts_probe begin=====.  

[  342.801305] ==kzalloc success=

[  342.804136] [GSLX680] Enter gsl_ts_init_ts

[  342.808394] ctp_set_irq_mode: config gpio to int mode. 

[  342.815161] ctp_set_irq_mode, 854: gpio_int_info, port = 8, port_num = 21. 

[  342.817574]  INTERRUPT CONFIG

[  342.825989] input: gslx680 as /devices/platform/sunxi-i2c.2/i2c-2/2-0040/input/input1

[  342.920231] =============gsl_load_fw start==============

[  404.034587] gslx680 2-0040: Unable to open firmware /lib/firmware/tablet.fw

[  404.045146] init_chip: gsl_load_fw fail: -2

[  404.048717] gslx680 2-0040: init_chip failed

[  404.057737] gslx680: probe of 2-0040 failed with error -2

[Joe Burmeister]

Hi,

The driver gets the file location from the fex file, from "ctp_firmware".
There is no point having a standard location because the firmware device can not be generic. There needs to be a different one for every hardware configuration.

Joe

[bon...@gmail.com]

Thanks Joe,

I've set that ctp_firmware parameter with relative and complete path, but the kernel doesn't seem to be able to find it. I was told to use /lib/firmware, and it fails with the same error, and the kernel I'm using (3.4.79+), hasn't a very detailed debugging of where it is searching. Is there a more bullet proof good way to load the firmware?, or, how can I debug where the kernel is trying to load the firmware from? 

Many thanks in advance!

[Joe Burmeister]

Hi again,

Ok I think I know what is going on, and my bad for not seeing earlier, been in userland only for months. Sorry about that.
You are giving the Linux firmware finder " /lib/firmware/tablet.fw", which it is thinking of as a filename, and thus not finding it.
You should leave it where it is, but set ctp_firmware to just "tablet.fw" and let the firmware finding system look in "/lib/firmware/".

Joe

[eynst...@gmail.com]

Greetings,

I've just been reading this message board regarding the 420TPC.
The board is INET A13_66V but cannot find sources for that board so have been
using a sun5i configuration.
What I have working so far is the latest sunxi 3.4.90 kernel, 8188eu wifi driver and both a linaro and debian prebuilt image from the olimex site.
The only driver that seems to be of most difficulty is the gslx680 touchscreen.
Upon inspecting this in android, it depends upon an inet_ctp module which I have attempted to force modprobe but with kernel taints and crashes so this is no longer an option.
The firmware is loaded properly because Android can also load it and the touchscreen remains working so the FW dump form the gslx680.ko works.

It is simply the inet_ctp.ko driver I have no idea about.
It seems like an ioctl interface because a whole bunch of random touchscreen modules are loaded into it and one will eventually be the proper driver.
I cannot find sources for this driver, it seems proprietary.

Not sure what to do at this point. On a previous tablet, the same issue with an ioctl driver that needed to be loaded before wifi, touchscreen, keypad and would only work force modprobing if lucky.

Any ideas on where or how to figure what is inside this inet_ctp.ko driver?
Here is a modinfo of it:

filename: /home/eynstyne/Desktop/modules/inet_ctp.ko
license: Dual BSD/GPL
description: INET CTP CONTROL
author: <mbg...@163.com>
srcversion: 4BF8B04CF61036647FA46D2
depends:
vermagic: 3.0.8+ preempt mod_unload modversions ARMv7

and here is a modprobe --dump-modversions:

0xa87cd4f1 module_layout
0x2e5810c6 __aeabi_unwind_cpp_pr1
0xeae3dfd6 __const_udelay
0x27e1a049 printk
0xefd6cf06 __aeabi_unwind_cpp_pr0

Any ideas on how to get this touchscreen working?

[Joe Burmeister]

Hi,

I've never tried the Android build. I left it in pretty much as from the
original yuandao-n90-window-dual-core-2 I ported from.
But I don't see how this dependency came in if you are building the
source I worked on.

Unless I'm miss understanding, it looks like you are taking kernel
modules from one kernel and inserting them into another kernel. That is
not good. The Linux kernel doesn't have a stable ABI, so you can't
safely swap modules between kernels.

You will need to build the gslx680 driver from
https://gitorious.org/gslx680-for-sunxi, pointing it at the build of the
your sunxi kernel.
It's currently out of tree you see. So you will need to build the sunxi
kernel, then build the gslx680 kernel module. You will also need to
extract the firmware from your Android gslx680.ko to feed your build of
the gslx680.ko as a separate file. All the gslx680 stuff is explained in
the repo's readme, and the how to build sunxi is explained at:
http://linux-sunxi.org/Linux_Kernel

On my list of assorted things to do in life, "get gslx680 merged" is
listed. ;-)

As I've never tried the Android build, it might not "just work", in
which case, as we know the normal Linux build one works, just comment
out the Android stuff. It will use more power, but it will work at least.

Joe

[eynst...@gmail.com]

Ok, the driver is compiled now.
loads without force modprobe.
It creates an input device, but after:
i2c state isn't idle (0xf8)
STOP failed!
incomplete xfer (0xff)
reset_chip: gsl_ts_write 1 fail!
init_chip: reset_chip fail: -70
gslx680 1-0040: init_chip failed

The incomplete xfer is not 0x20 so the twi_id is 1 and adapter address correct.
Not sure what the 0xf8 / 0xff codes are but
I'm guessing something is being read sequentially from START. I think it wants early suspend in the kernel source so the touchscreen is idle in low powered state.

Still trying.

[Joe Burmeister]

Can you give me the dmesg?

Joe

[eynst...@gmail.com]

Can't attach files here for some reason:
Dmesg log of the TS and the LCD panel
[ 71.988222] ===========================gslx680_ts_init=====================
[ 71.990707] _fetch_sysconfig_para.
[ 71.994277] gslx680 firmware 420TPC.fw.
[ 72.003405] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe
[ 72.007980] _fetch_sysconfig_para: ctp_twi_id is 1.
[ 72.012163] _fetch_sysconfig_para: screen_max_x = 480.
[ 72.016639] _fetch_sysconfig_para: screen_max_y = 272.
[ 72.020732] _fetch_sysconfig_para: revert_x_flag = 0.
[ 72.025096] _fetch_sysconfig_para: revert_y_flag = 0.
[ 72.029553] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 72.038401] i2c-core: driver [gslx680] using legacy suspend method
[ 72.043973] i2c-core: driver [gslx680] using legacy resume method
[ 72.049655] ctp_detect: Detected chip gslx680 at adapter 1, address 0x40
[ 72.055382] ====gslx680_ts_probe begin=====.
[ 72.057404] ==kzalloc success=
[ 72.060192] [GSLX680] Enter gsl_ts_init_ts
[ 72.072400] gslx680: disagrees about version of symbol module_layout
[ 72.077220] ctp_set_irq_mode: config gpio to int mode.
[ 72.083418] ctp_set_irq_mode, 854: gpio_int_info, port = 7, port_num = 11.
[ 72.086606] INTERRUPT CONFIG
[ 72.088189] ==CTP_IRQ_NO=
[ 72.096139] input: gslx680 as /devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input5
[ 72.120945] incomplete xfer (0xff)
[ 72.123925] reset_chip: gsl_ts_write 1 fail!
[ 72.127072] init_chip: reset_chip fail: -70
[ 72.130301] gslx680 1-0040: init_chip failed
[ 72.135248] gslx680: probe of 1-0040 failed with error -70

*****************************************************************
[ 3.131863] [DISP] ***
[ 3.135430] [DISP] *** LCD Panel Parameter Check
[ 3.136756] [DISP] ***
[ 3.140323] [DISP] *** by dulianping
[ 3.141642] [DISP] ***
[ 3.148328] [DISP] *****************************************************************
[ 3.149653] [DISP] ***
[ 3.151747] [DISP] *** Interface:
[ 3.154621] [DISP] *** Parallel HV Panel
[ 3.157507] [DISP] *** Lcd Frm to RGB666
[ 3.158822] [DISP] ***
[ 3.160828] [DISP] *** Timing:
[ 3.163529] [DISP] *** lcd_x: 480
[ 3.166229] [DISP] *** lcd_y: 272
[ 3.168944] [DISP] *** lcd_ht: 525
[ 3.171472] [DISP] *** lcd_hbp: 2
[ 3.174173] [DISP] *** lcd_vt: 572
[ 3.176708] [DISP] *** lcd_vbp: 2
[ 3.179236] [DISP] *** lcd_hspw: 0
[ 3.181768] [DISP] *** lcd_vspw: 0
[ 3.184902] [DISP] *** lcd_frame_frq: 79Hz
[ 3.186224] [DISP] ***
[ 3.190659] [DISP] *** WRN03: Recommend "lcd_dclk_frq = 9"
[ 3.191979] [DISP] ***
[ 3.195892] [DISP] *** LCD Panel Parameter Check End
[ 3.202590] [DISP] *****************************************************************

I still have no idea why it disagrees about module_layout and perhaps a manual hex edit is needed. I have compiled the driver against my kernel so that should not be there.

[Joe Burmeister]

"disagrees about version of symbol module_layout" is saying the gslx680
module is not for the same kernel build as the kernel.

Try using:

https://github.com/jabjoe/linux-sunxi/tree/sunxi_3.4_gslx680

(Just add it as a remote, do a fetch, then checkout the
sunxi_3.4_gslx680 branch, that should avoid pulling all of git repo
down, just my bits)

and adding CONFIG_TOUCHSCREEN_GSLX680_TS to your build config.

It's a very rough branch as it doesn't take any of the history.

Joe

[eynst...@gmail.com]

Ok the driver built without the symbol error.
Still the same problem with the I2C bus not being idle (0xf8). STOP failed!

Cracked open the tablet just to make sure it is using a GSL chip. It is: 1680E

Added this to script.fex
[gpio_para]
gpio_used = 1
gpio_num = 1
gpio_pin_1 = port:PB03<1><default><default><1>

gpio-sunxi loads successfully in /sys/devices/

Thought the rtc was tying up the bus, disabled it in kernel, but still no go.
Loaded this driver in linaro, i2cdetect showed that address 0x40 was in use 'UU' and that's good so far.

I did notice something about the original android gslx680.ko driver from the 420TPC. It loads multiple firmwares so the fw_extractor tool basically took all of them including the 420TPC which will be invalid firmware data.

Contains 14 chip firmwares for the motherboards:
1. GSL1680E_FW_86VS_INET
2. GSL1680E_FW_86VSH_INET
3. GSL1680E_FW_66V_M4302_INET_V2 <--- this is the one for 420TPC
4. GSL3680_FW_shenghexiang0072
5. GSL1680D_FW_86VSH_INET
6. GSL1680D_FW_86VS_INET
7. GSLx680_FW_85V_M501V
8. GSL1680_FW_newdingshengwei_1
9. GSLx680_FW_86FV_M728_TOPSUN_C0801
10. GSLx680_FW_NEWDINGSHENGWEI_OGS_4
11. GSL1680_FW_newdingshengwei_5
12. GSL1680_FW_TOPSUN_OGS_G7009
13. GSLX680_FW_86V_TOPSUN_OGS
14. GSL1680_FW_haina

[Joe Burmeister]

Well now we know it's nothing to do with mix of kernel build.
Not that easy.

Can you send me that Android gslx680 driver? I sort out the extractor.

Assuming the firmware is cut correctly, next would be check the state of the device. Did you comment out the Android specific code? Maybe that suspend code is broken and the gslx680 is asleep. I've never play with Android part but didn't scope out that old code.

Joe

[eynst...@gmail.com]

From 420TPC running Android 4.1
https://www.dropbox.com/s/ahzqp78us9vre9x/gslx680.ko

Interesting you mention about the build. I changed the kernel from 3.4 to 3.0.76 (and there are many of them)
and the android drivers inet_ctp and gslx680 force modprobed without kpanic.
The only thing is now it's no longer reporting STOP or i2c state not idle, but
instead incomplete xfer (0x20) and incomplete xfer (0x48) right after a blurb
ctp_init_platform_resource: tp_reset request gpio failed!
It however did read the script.bin parameters correctly like ctp_exchange_x_y_flag etc.

The error 0x48 is about wakeup. Device probably didn't wake so nothing got sent.
If this passes, then the touchscreen should be active and the following incomplete xfer (0x20) <-- tons of these messages might actually send legit data over the bus. I think those xfers were to download the firmware.

So gonna enable some debugging on the i2c and pinpoint this.
Then if this works, try out the linux driver compilation and see how it differs in output.

[Joe Burmeister]

The firmware from extractor does look too big.
You said before you found it was multiple ones, and knew what they where.
How did you do that? All I've got to go on is if the data continues to
follows the rules for the GSLx680 register+value pairs. Writing to a
page written to before is all I can think to go on, and that I wouldn't
trust.

At 0x000a5f00 there is what looks like firmware. BUT very quickly the
register numbers are beyond 8 bit, which doesn't fit with what I thought
we knew about the GXLx680. It also doesn't start with GSLx680's page
control register. The GSLx680 uses a paged register scheme, with f0
being the page control register. So normally the first thing the
firmware does is set the page the first page of data is for. So I'm
wondering if what looks like a small secondary firmware isn't for the
GSLx680. Or if the GSLx680 does unpaged registering when the register
numbers are beyond 8bit, which is new to me. If it is firmware, we need
to find out about it. Is it a new to us way of doing GSLx680 firmware,
after or alongside the main firmware? Is it for a different chip
altogether? If so, what and how do we load this firmware on it, etc etc
etc. All of which could be pretty painful to work through.

A data sheet for the GSLx680 could make all this so much easier!

Let me know how your wakeup investigations go, patches are always most
welcome. :-)

Joe

[eynst...@gmail.com]

============= Extraction of the 2 files ==============
TPC 5 point touch firmware 800x480:
https://www.dropbox.com/meta_dl/eyJzdWJfcGF0aCI6ICIiLCAidGVzdF9saW5rIjogZmFsc2UsICJzZXJ2ZXIiOiAiZGwuZHJvcGJveHVzZXJjb250ZW50LmNvbSIsICJpdGVtX2lkIjogbnVsbCwgImlzX2RpciI6IGZhbHNlLCAidGtleSI6ICIzOWRrajFjamw0MTJ1d24ifQ/AAKIoE8LVcuSgujNz0kc8Ao27eniAftE09TUtg2cpQ1WGQ?dl=1

TPC 10 point touch firmware 1280x800:
https://www.dropbox.com/meta_dl/eyJzdWJfcGF0aCI6ICIiLCAidGVzdF9saW5rIjogZmFsc2UsICJzZXJ2ZXIiOiAiZGwuZHJvcGJveHVzZXJjb250ZW50LmNvbSIsICJpdGVtX2lkIjogbnVsbCwgImlzX2RpciI6IGZhbHNlLCAidGtleSI6ICIzNGs1ajN1MDhvZzJmc2QifQ/AAKoqqQ6bWxc0Sa-m6CO0Z4J3REyDthtO-HmK2lZusscWA?dl=1

I do not believe there are 7 firmwares, because from my understanding a firmware footer visually ends with many 0xFFFFFFF so if I counted correctly, there are only 2 and the rest of the data is configuration. After extracting just those two, I get 2 different screen resolutions and more parameters like 10 point touch, 1280x800 for the bigger screen of course.
The end footer in this case is 7C 00 00 00 16 FF FF FF {0x7c,0xFFFFFF16}

In a hex editor, I scanned instances of 0xC0FFA5A5 (Common object file format) as this seems to be a marker. It does start with 0xF0 and 0x03 but it's read in reverse so "F0 00 00 00 03 00 00 00 00 00 00 00 C0 FF A5 A5". In the android driver when I dmesg in android not linux, the driver looks for those bytes during the firmware download process and outputs them to screen.

So it appears that it uses an 800x480 touch screen resolution on an LDPI 480x272 screen resolution which is actually 1024x768 in script.bin's screen_output_mode parameter.

By the way 3.4 removed early_suspend and 3.0.76 has it.
Could early_suspend have anything to do with this?

[Joe Burmeister]

Input, nom nom nom!

I cut by {0x7c,0xFFFFFF16} termination I get 14 blocks.

Which is interesting because doing "strings" on your android driver I see:

Downlaod GSL1680E_FW_86VS_INET
Downlaod GSL1680E_FW_86VSH_INET
Downlaod GSL1680E_FW_66V_M4302_INET_V2
Downlaod GSL3680_FW_shenghexiang0072
Downlaod GSL1680D_FW_86VSH_INET
Downlaod GSL1680D_FW_86VS_INET
Downlaod GSLx680_FW_85V_M501V
Downlaod GSL1680_FW_newdingshengwei_1
Downlaod GSLx680_FW_86FV_M728_TOPSUN_C0801
Downlaod GSLx680_FW_NEWDINGSHENGWEI_OGS_4
Downlaod GSL1680_FW_newdingshengwei_5
Downlaod GSL1680_FW_TOPSUN_OGS_G7009
Downlaod GSLX680_FW_86V_TOPSUN_OGS
Downlaod GSL1680_FW_haina

Which is what you listed at one point.

But only two of the blocks have information that I have any information
about (and that information could of course be wrong).

However, if I run this new extractor against my own firmware. It cuts it
up into multiple ones, only one of which has information we know.
And all but one of them work on their own. So I've taken the working one
that still has the known information in it.

My android driver doesn't have the handy little list of the different
contained firmwares though.

Anyway, updated the extractor. Thank you very much. :-)



In your android driver 000a5f00-000b27b0 really does look like there is
firmware for something. It just doesn't look like a GSLX680.

I can well believe the suspend stuff shouldn't still be in there, again
a left over from the port that I wasn't using.
Early suspend could well be a problem. Just remove it.

Joe

[eynst...@gmail.com]

Full dmesg of TPC now:
https://www.dropbox.com/s/m9bv990gcjzn6rt/dmesg.txt

So after you cut the fw, 14 blocks? Hmmm, this is almost a go.
I'll try out fw_extractor and fw_info again and see which file makes it work. Other source code I've seen needs firmware + config.

The 3.4 kernel continued to bug out and state i2c not idle so scrapped it and went 3.0.76. Interesting is that enabling/disabling early_suspend in this kernel doesn't make much difference other than the fact that early_suspend had in the past corrupted many of my SDCARDs! This kernel seems to behave well and load android/linux compiled drivers no problem. 8188eu wifi is messed, but that's another story and different prob.

Compiled the driver and it registered an input device!
After that, it went on to the firmware download process, lagged a bit because of the large file being passed (wrong firmware) and I am betting
if the right file is passed this will work and should see output with "cat /dev/input/event3"

The original script.bin contained other touch firmware ctp names.
In android, the init basically loads all those drivers until the right one just works. The inet_ctp module does nothing more than check for the right ctp_name because the gslx680 was ctp12_name in the script.bin and it's usually just ctp_name. inet_ctp isn't needed, it doesn't contain any firmware.

[eynst...@gmail.com]

Great news!

It works! Backwards... Basically the board was the 3rd in that list (INET_66V), but that's an easy fix in the script.bin with the x y order.

Here's the firmware for 420TPC:
https://www.dropbox.com/s/7fz9i74l8rp70pk/420TPC.fw

Thank you for this amazing tool and driver port!
Stay tuned as I'll be dd'ing an SDCARD image very soon once other drivers sorted out and distro deemed ready.

[Joe Burmeister]

yer!!! \o/

I'll add your firmware to the others.

I take it this is still with the 3.0 kernel?
Can you humour me and try 3.4 with the suspend and Android stuff removed?
It is works with Android without the untested Android and suspend stuff,
I'll just drop them, and I don't have the guilt of carry code I've not
tested.

You are welcome and thank you for working it through with me. Not only
have a got another firmware out of it but the tools are improved. :-)

Joe

[trungk...@gmail.com]

Hi,
Thank you for your update. Now I can load the correct firmware for my IC.

I also have a suggestion: With A20, I think you should remove "IRQF_TRIGGER_FALLING |".

WITH ORIGINAL SOURCE CODE, dmesg shows the error with irq:

[ 23.424864] ===========================gslx680_ts_init=====================
[ 23.432022] _fetch_sysconfig_para.
[ 23.442333] gslx680 firmware gslX680.fw.
[ 23.456662] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe
[ 23.467703] _fetch_sysconfig_para: ctp_twi_id is 2.
[ 23.472789] _fetch_sysconfig_para: screen_max_x = 1024.
[ 23.477010] _fetch_sysconfig_para: screen_max_y = 600.
[ 23.483917] _fetch_sysconfig_para: revert_x_flag = 0.
[ 23.489023] _fetch_sysconfig_para: revert_y_flag = 0.
[ 23.496604] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 23.505517] _init_platform_resource: tp_io request gpio fail!
[ 23.513521] i2c-core: driver [gslx680] using legacy suspend method
[ 23.522049] i2c-core: driver [gslx680] using legacy resume method
[ 23.525090] incomplete xfer (0x20)
[ 23.528837] incomplete xfer (0x20)
[ 23.534765] ctp_detect: Detected chip gslx680 at adapter 2, address 0x40
[ 23.540658] ====gslx680_ts_probe begin=====.
[ 23.555247] ==kzalloc success=
[ 23.558058] [GSLX680] Enter gsl_ts_init_ts
[ 23.562263] ctp_set_irq_mode: config gpio to int mode.
[ 23.568908] ctp_set_irq_mode, 854: gpio_int_info, port = 8, port_num = 21.
[ 23.572230] INTERRUPT CONFIG
[ 23.579844] input: gslx680 as /devices/platform/sunxi-i2c.2/i2c-2/2-0040/input/input1
[ 23.667193] =============gsl_load_fw start==============
[ 25.466695] =============gsl_load_fw end==============
[ 25.779206] setting trigger mode 2 for irq 60 failed (gic_set_type+0x0/0xd8)
[ 25.791386] gslx680 2-0040: gslx680_ts probe: request irq failed
[ 25.801959] gslx680: probe of 2-0040 failed with error -22

SOURCE CODE REMOVED "IRQF_TRIGGER_FALLING |", dmesg shows:

[ 23.312732] ===========================gslx680_ts_init=====================
[ 23.317943] _fetch_sysconfig_para.
[ 23.320942] gslx680 firmware gslX680.fw.
[ 23.330076] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe
[ 23.337726] _fetch_sysconfig_para: ctp_twi_id is 2.
[ 23.343156] _fetch_sysconfig_para: screen_max_x = 1024.
[ 23.373210] _fetch_sysconfig_para: screen_max_y = 600.
[ 23.383419] _fetch_sysconfig_para: revert_x_flag = 0.
[ 23.387623] _fetch_sysconfig_para: revert_y_flag = 0.
[ 23.392110] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 23.396943] _init_platform_resource: tp_io request gpio fail!
[ 23.420559] i2c-core: driver [gslx680] using legacy suspend method
[ 23.425636] i2c-core: driver [gslx680] using legacy resume method
[ 23.430995] incomplete xfer (0x20)
[ 23.433508] incomplete xfer (0x20)
[ 23.445736] ctp_detect: Detected chip gslx680 at adapter 2, address 0x40
[ 23.459730] ====gslx680_ts_probe begin=====.
[ 23.461769] ==kzalloc success=
[ 23.464620] [GSLX680] Enter gsl_ts_init_ts
[ 23.494149] ctp_set_irq_mode: config gpio to int mode.
[ 23.518132] ctp_set_irq_mode, 854: gpio_int_info, port = 8, port_num = 21.
[ 23.522062] INTERRUPT CONFIG
[ 23.537085] input: gslx680 as /devices/platform/sunxi-i2c.2/i2c-2/2-0040/input/input1
[ 23.627277] =============gsl_load_fw start==============
[ 25.653621] =============gsl_load_fw end==============
[ 25.965873] ==gslx680_ts_probe over =

It seems to be initialized successfully. But my touchscreen does not work anyway. I'm still debugging it. If you have any idea about this, please let me know. Thank you so much!

[Priit Laes]

Ühel kenal päeval, T, 03.06.2014 kell 20:10, kirjutas Joe Burmeister:
> yer!!! \o/
>
> I'll add your firmware to the others.
>
> I take it this is still with the 3.0 kernel?
> Can you humour me and try 3.4 with the suspend and Android stuff removed?
> It is works with Android without the untested Android and suspend stuff,
> I'll just drop them, and I don't have the guilt of carry code I've not
> tested.
>
> You are welcome and thank you for working it through with me. Not only
> have a got another firmware out of it but the tools are improved. :-)

Could you please add a page to Linux-sunxi wiki about this driver? Just
a stub would suffice that would mention the repository, tools and where
to download the firmware blobs.

Thanks :)

[Joe Burmeister]

There is something about it, and another GSLX680 driver (userspace one) at:
http://linux-sunxi.org/index.php?title=GSL1680

Really I should start the process of getting it merged so it's not out
of tree. Then it will be a case of instructions to get it working, which
should be get/extract firmware and set up fex. But while it isn't not
that for people, I don't feel I should do so.

Joe

[Joe Burmeister]

Hi

I'll have a look tonight hopefully about the irq flags.

I'm guessing eynst...@gmail.com and trungk...@gmail.com are not the
same person as both gmail addresses.
I take it your not working with him/her?

Have you ever got the firmware to work?
Now I've reworked the extractor, it would be worth re-extracting from
the Android driver and trying the multiple results, if you have multiple
results.
If you do have multiple results, do "strings" on the Android driver and
see if you see a list of names. The list of names should match the
amount of firmwares extracted, and should have a one to one index. So
you should be able to see which firmware is which. (Notice all those
"shoulds" ;-) )

Joe

[eynst...@gmail.com]

No the 3.4 kernel doesn't go and I want it to work so that wifi is automatically sorted out. The i2c code in 3.4 differs greatly particularly i2c-gpio.c.
My suspicion is the bus being busy flag is an error in the xfer function, there is a hardcoded I2C_XFER_RUNNING flag not used in prior kernel.
Perhaps this doesn't clear, idk.Too many unknown variables with this. Either way, many of my drivers don't load in 3.4 like mxc622x and fails with same error. This looks like an i2c bug or something idk. For now, sticking with 3.0.76.

[peb...@gmail.com]

Hi Joe, i just received A20 tablet with manufactured code K711_OGS and this tab using gsl1688 for the touchscreen.. for a week i tried to make your driver works but always ended up with incomplete xfer 0xf8.

Just yesterday i found out that 3.4.90 kernel has bugs with i2c devices since they changes i2c transfer speed from 200khz to standard 100khz. Changed back to 200 khz and the complaining about incomplete xfer dissapeared. The driver load successfully but i still can't get output. Maybe just firmware problem since fw extractor give me strange output.. it's split fw by 20 or more files.

[peb...@gmail.com]

Hi, sorry late reply. Lack of free time here. This week i tried play again with the driver. After get 24 files from fw_extractor and tried load every firmware, not a single fw file are correct, seems every firmware give a random coord output touch.

tried check every fw with fw_info and the result every fw files not given information by fw_info. Any suggestion?

[Joe Burmeister]

Hi, no worries, this is a hobby thing for me anyway, and not one I've
really touch much for quite a while.

The fw_info only knows very little because there isn't much I knew at
the time. I'm not sure there is any more publicly known now about the
register map of the GSL chips.


It could be the separate firmwares thing isn't working right. What might
be worth a try is using a previous revision, the one before the
splitting of firmwares, and seeing if the single blob works any better.

Are you sure the coords coming out are random and this isn't a FEX
settings thing?

Joe

[Michal Suchanek]

Hello,

I have tried to extract the firmware from a tablet and I get 2
firmwares with the partial firmware method and 1 different with the
full firmware method.

The touchscreen on the tablet is broken so I am not sure if I can tell
which is correct if any but the tablet is definitely 800x480 and one
of the partial dumps shows 1280 resolution.

Thanks

Michal

[Joe Burmeister]

Hi Michal,

The screen resolution may not match the touch resolution, but I wouldn't
expect it to be that different.
So I'd think it would be the one that isn't 1280.
What happens when it tries to load the other firmware? Can you send the
dmesg log, there might be some tell tell in there.

Joe

[BBUK]

Dear all

I managed to get this driver and Sergio's userspace one working on an A20 tablet (a A70x).  I thought to post back with my findings.

First of all although fw_extractor does a great job, there is not a lot of consistency in how firmwares in the Android kernel driver start and finish and so it is natural that it is going to be misguided for some firmwares (I found firmwares that started f0 00 00 00 97 00 00 00, f0 00 00 00 03 00 00 00 and f0 00 00 00 00 00 00 00 and I found firmwares that ended both 7c 00 00 00 00 00 00 00 as well as 7c 00 00 00 16 ff ff ff).  The most reliable way I found of identifying the start and end of each firmware was to use "readelf -s" to extract the lengths of the objects directly (I used "readelf -s | grep -i fw" but bear in mind that I was running on an arm system and readelf may not necessarily produce correct results with arm binaries on an x86 system unless you tell it that you are dealing with an arm binary.  Actually, that might be an idea to update fw_extractor to use readelf ... hmm.

When working out which firmware to use, the gslx680 does not seem to like being uploaded with different firmwares and will stop responding (neither driver will, however, report any errors).  It took me about 20 hours to work this out!  If you try a firmware the device must be fully switched off (a reboot is not sufficient) before trying another one.

For me, non-working firmwares just produced no output.

Fourthly, as identified earlier, the i2c incomplete xfer stuff is caused by a recent(ish) patch to the 3.4 sunxi kernel changing the default transfer speed to 100khz.  The file to change is arch/arm/plat-sunxi/include/plat/i2c.h (towards the end).  I think the patch should be reverted.  This certainly affected Joe's driver (kernel).  I did not investigate whether the change to the default speed was needed for Sergio's (user space) driver.

Fifthly, for Joe's driver, the previous comment about 'With A20, I think you should remove "IRQF_TRIGGER_FALLING |"' is important.

Finally, thanks to both Joe and Sergio.  Great work, saved me a bunch of time.  In passing, I identified some possibly useful changes to both drivers, are you accepting pull requests?

Have fun

BBUK

[Joe Burmeister]

Hi BBUK,

Some serious work there.

I'd love patches thank you. I've not got much spare time to throw at this any more, so patches are most welcome in any form.
Readelf is a really good idea, I'll have a look at that in the next few days or so if I can find a free few hours in the evening.
Getting the right firmware for the device is nearly always the sticking point, so anything that makes this better is a big win.

Thank you for your work, already been most helpful and that's before any possible patches. :-)

Joe

[Kristijan Vrban]

Hello,

attached is a gslX680.ko module from a Q88 A23 based tablet (the cheap USD 32 devices) I just started to extract the firmware to use gsl1680 IC with the touch panels that are used in this Q88 devices.

I think "GSL1680_K70_FW" should be the one. from this module.

Attached is also a small PCB design made in eagle to make test connection between that touch panels and I2C interface. Maybe it is useful for someone.

Kristijan

[Joe Burmeister]

Hi Kristijan,

Not sure quite what your after, but here is a new, not tested yet (would have to dig up the tablet), firmware extractor.

It uses just readelf, objcopy and dd. Quick and dirty "python for shell" implementation.

Hopefully this should help.

Joe

[Kristijan Vrban]

Hi Joe,

it was not necessary to extract the firmware. I just used this fw source:
http://dl.linux-sunxi.org/SDK/A23-v1.0/unpacked/A23/lichee/linux-3.4/drivers/input/touchscreen/gslx680/gsl1680_k70.h

Which is working with the Q88 touch panel. We just had issues to solder the gsl1680 manually without electrical shorts :)

Kristijan

[Joe Burmeister]

Hi Kristijan,

OMG, there is the full source already ported to Sunxi!
To get it working for GNU/Linux I had to find and port some random SoC GSLx driver over!

About the only concrete thing I'd say mine has over this is that mine loads firmware from a separate file.

I'll have to do a more complete comparison. Maybe a rebase. Firmware must be a separate file to scale to a generic driver.

At some point I really should look into the mainlining effort and making it support Device Tree, I'm just got next to no time at all spare for this. :-(


Joe

[Michal Suchanek]

Hello,

I tried extracting firmware from my pmp3670b tablet and I got 4
firmware files with fw_extractor2.py. Unfortunately, fw_info does not
recognize any of them as firmware:

$ python /scratch/Downloads/fw_extractor2.py modules/A13_gslX680.ko
Found GSLX680_FW offset 180 count 39072
39072+0 records in
39072+0 records out
39072 bytes (39 kB) copied, 0.0768463 s, 508 kB/s
Found GSLX680_FW_2 offset 39252 count 39336
39336+0 records in
39336+0 records out
39336 bytes (39 kB) copied, 0.073385 s, 536 kB/s
Found GSLX680_FW_3 offset 78588 count 39336
39336+0 records in
39336+0 records out
39336 bytes (39 kB) copied, 0.0800411 s, 491 kB/s
Found GSL_TEST_FW offset 117988 count 8184
8184+0 records in
8184+0 records out
8184 bytes (8.2 kB) copied, 0.0161824 s, 506 kB/s

$ for i in /scratch/pmp3670b/GSL*.fw ; do ./fw_info $i ; done
/scratch/pmp3670b/GSL_TEST_FW.fw doesn't contain any known firmware information.
/scratch/pmp3670b/GSLX680_FW_2.fw doesn't contain any known firmware
information.
/scratch/pmp3670b/GSLX680_FW_3.fw doesn't contain any known firmware
information.
/scratch/pmp3670b/GSLX680_FW.fw doesn't contain any known firmware information.

I have old firmware extracted from my broken inet 86vs tablet and from
that the old fw_extractor extracted 35 firmware files out of which 2
are recognized as firmware:

$ ls Manta_MID705_gslx680.fw*
Manta_MID705_gslx680.fw Manta_MID705_gslx680.fw.11
Manta_MID705_gslx680.fw.20 Manta_MID705_gslx680.fw.30
Manta_MID705_gslx680.fw.02 Manta_MID705_gslx680.fw.12
Manta_MID705_gslx680.fw.21 Manta_MID705_gslx680.fw.31
Manta_MID705_gslx680.fw.03 Manta_MID705_gslx680.fw.13
Manta_MID705_gslx680.fw.22 Manta_MID705_gslx680.fw.32
Manta_MID705_gslx680.fw.04 Manta_MID705_gslx680.fw.14
Manta_MID705_gslx680.fw.23 Manta_MID705_gslx680.fw.32.txt
Manta_MID705_gslx680.fw.05 Manta_MID705_gslx680.fw.14.txt
Manta_MID705_gslx680.fw.24 Manta_MID705_gslx680.fw.33
Manta_MID705_gslx680.fw.06 Manta_MID705_gslx680.fw.15
Manta_MID705_gslx680.fw.25 Manta_MID705_gslx680.fw.34
Manta_MID705_gslx680.fw.07 Manta_MID705_gslx680.fw.16
Manta_MID705_gslx680.fw.26 Manta_MID705_gslx680.fw.35
Manta_MID705_gslx680.fw.08 Manta_MID705_gslx680.fw.17
Manta_MID705_gslx680.fw.27
Manta_MID705_gslx680.fw.09 Manta_MID705_gslx680.fw.18
Manta_MID705_gslx680.fw.28
Manta_MID705_gslx680.fw.10 Manta_MID705_gslx680.fw.19
Manta_MID705_gslx680.fw.29

However, the old extractor does not seem to like the pmp3670b module.
I never get any firmware out of it.

Any suggestions?

Thanks

Michal

> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Joe Burmeister]

Hi,

Ignore fw_info. It knows about such a small fraction of the registers it
can be ignored.
In fact, I've just removed it, it only confuses.

The old extractor was floored in the way if found firmware, that's why
it's dumped.
In the git repos now, there is only fw_extractor.py which is the new one
replacing the old.

As to which firmware to use, the only way is suck and see for each. :-\

Hope this helps.

Joe

[Michal Suchanek]

Hello,

I tried loading the firmware into the driver but none works:

[ 10.960812] gslx680 firmware GSL_TEST_FW.fw.
[ 10.973297] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40,

dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe

[ 10.983950] _fetch_sysconfig_para: ctp_twi_id is 1.
[ 10.991410] _fetch_sysconfig_para: screen_max_x = 800.
[ 10.998847] _fetch_sysconfig_para: screen_max_y = 480.
[ 11.007377] _fetch_sysconfig_para: revert_x_flag = 0.
[ 11.014716] _fetch_sysconfig_para: revert_y_flag = 0.
[ 11.022134] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 11.035043] i2c-core: driver [gslx680] using legacy suspend method
[ 11.043136] i2c-core: driver [gslx680] using legacy resume method
[ 11.051768] ctp_detect: Detected chip gslx680 at adapter 1, address 0x40
[ 11.066141] ====gslx680_ts_probe begin=====.
[ 11.071434] ==kzalloc success=
[ 11.076877] [GSLX680] Enter gsl_ts_init_ts
[ 11.083758] ctp_set_irq_mode: config gpio to int mode.
[ 11.092630] ctp_set_irq_mode, 854: gpio_int_info, port = 7, port_num = 11.
[ 11.097284] INTERRUPT CONFIG
[ 11.111467] input: gslx680 as
/devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input2
[ 11.145929] incomplete xfer (0xff)
[ 11.154534] reset_chip: gsl_ts_write 1 fail!
[ 11.160662] init_chip: reset_chip fail: -70
[ 11.170239] gslx680 1-0040: init_chip failed
[ 11.177661] gslx680: probe of 1-0040 failed with error -70

[ 10.576719] gslx680 firmware GSLX680_FW_3.fw.
[ 10.588253] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40,

dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0x
fffe

[ 10.596985] _fetch_sysconfig_para: ctp_twi_id is 1.
[ 10.603522] _fetch_sysconfig_para: screen_max_x = 800.
[ 10.610014] _fetch_sysconfig_para: screen_max_y = 480.
[ 10.616396] _fetch_sysconfig_para: revert_x_flag = 0.
[ 10.622717] _fetch_sysconfig_para: revert_y_flag = 0.
[ 10.629272] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 10.640746] i2c-core: driver [gslx680] using legacy suspend method
[ 10.648077] i2c-core: driver [gslx680] using legacy resume method
[ 10.655851] ctp_detect: Detected chip gslx680 at adapter 1, address 0x40
[ 10.668371] ====gslx680_ts_probe begin=====.
[ 10.672655] ==kzalloc success=
[ 10.677327] [GSLX680] Enter gsl_ts_init_ts
[ 10.683471] ctp_set_irq_mode: config gpio to int mode.
[ 10.691275] ctp_set_irq_mode, 854: gpio_int_info, port = 7, port_num = 11.
[ 10.695124] INTERRUPT CONFIG
[ 10.707793] input: gslx680 as
/devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input2
[ 10.741366] i2c state isn't idle(0xf8)
[ 10.744748] STOP failed!
[ 10.748912] incomplete xfer (0xff)
[ 10.753940] reset_chip: gsl_ts_write 1 fail!
[ 10.759040] init_chip: reset_chip fail: -70
[ 10.764190] gslx680 1-0040: init_chip failed
[ 10.770551] gslx680: probe of 1-0040 failed with error -70

[ 10.603294] gslx680 firmware GSLX680_FW.fw.
[ 10.614822] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40,

dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0x
fffe

[ 10.623589] _fetch_sysconfig_para: ctp_twi_id is 1.
[ 10.630117] _fetch_sysconfig_para: screen_max_x = 800.
[ 10.636642] _fetch_sysconfig_para: screen_max_y = 480.
[ 10.643057] _fetch_sysconfig_para: revert_x_flag = 0.
[ 10.649358] _fetch_sysconfig_para: revert_y_flag = 0.
[ 10.655950] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 10.667123] i2c-core: driver [gslx680] using legacy suspend method
[ 10.674460] i2c-core: driver [gslx680] using legacy resume method
[ 10.682170] ctp_detect: Detected chip gslx680 at adapter 1, address 0x40
[ 10.694755] ====gslx680_ts_probe begin=====.
[ 10.698902] ==kzalloc success=
[ 10.703970] [GSLX680] Enter gsl_ts_init_ts
[ 10.710082] ctp_set_irq_mode: config gpio to int mode.
[ 10.717925] ctp_set_irq_mode, 854: gpio_int_info, port = 7, port_num = 11.
[ 10.721752] INTERRUPT CONFIG
[ 10.734032] input: gslx680 as
/devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input2
[ 10.761094] incomplete xfer (0xff)
[ 10.767462] reset_chip: gsl_ts_write 1 fail!
[ 10.772840] init_chip: reset_chip fail: -70
[ 10.778132] gslx680 1-0040: init_chip failed
[ 10.784611] gslx680: probe of 1-0040 failed with error -70

[ 10.350849] gslx680 firmware GSLX680_FW_2.fw.
[ 10.367761] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40,

dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0x
fffe

[ 10.393507] _fetch_sysconfig_para: ctp_twi_id is 1.
[ 10.400330] _fetch_sysconfig_para: screen_max_x = 800.
[ 10.407542] _fetch_sysconfig_para: screen_max_y = 480.
[ 10.417560] _fetch_sysconfig_para: revert_x_flag = 0.
[ 10.425735] _fetch_sysconfig_para: revert_y_flag = 0.
[ 10.432515] _fetch_sysconfig_para: exchange_x_y_flag = 0.
[ 10.457018] i2c-core: driver [gslx680] using legacy suspend method
[ 10.469440] i2c-core: driver [gslx680] using legacy resume method
[ 10.483385] ctp_detect: Detected chip gslx680 at adapter 1, address 0x40
[ 10.505369] ====gslx680_ts_probe begin=====.
[ 10.509616] ==kzalloc success=
[ 10.524958] [GSLX680] Enter gsl_ts_init_ts
[ 10.531257] ctp_set_irq_mode: config gpio to int mode.
[ 10.553030] ctp_set_irq_mode, 854: gpio_int_info, port = 7, port_num = 11.
[ 10.562305] INTERRUPT CONFIG
[ 10.579935] input: gslx680 as
/devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input2
[ 10.640939] incomplete xfer (0xff)
[ 10.646128] reset_chip: gsl_ts_write 1 fail!
[ 10.653646] init_chip: reset_chip fail: -70
[ 10.661966] gslx680 1-0040: init_chip failed
[ 10.669947] gslx680: probe of 1-0040 failed with error -70

[ctp_para]
ctp_used = 1
ctp_name = "gslx680"
ctp_twi_id = 1
ctp_twi_addr = 0x40
ctp_screen_max_x = 800
ctp_screen_max_y = 480
ctp_revert_x_flag = 0
ctp_revert_y_flag = 0
ctp_exchange_x_y_flag = 0
ctp_int_port = port:PG11<6><default><default><default>
ctp_wakeup = port:PB03<1><default><default><1>
ctp_io_port = port:PG11<0><default><default><default>
ctp_firmware = "GSL_TEST_FW.fw"

There is stop error in one case but otherwise the result seems the
same. The 0x40 address was not in the fex file but presumably if the
address was different the driver would not detect anything on it. Also
when the address is not specified 0x40 can be probably used as
default. It seems the Android driver just assumes this address.

Thanks

Michal

[Michal Suchanek]

Hello,

I tried the other tablet with broken screen and there the fw_extractor
extracts many files:

/lib/firmware/GSL1680D_FW_66V_M4302_TOP.fw
/lib/firmware/GSL1680D_FW_86VS_CTD_NIUS.fw
/lib/firmware/GSL1680D_FW_86VS_FUHUAFEN.fw
/lib/firmware/GSL1680D_FW_86VS_FW_CTD_A.fw
/lib/firmware/GSL1680D_FW_86VSH_INET.fw
/lib/firmware/GSL1680D_FW_86VSH_INET_V2.fw
/lib/firmware/GSL1680D_FW_86VS_INET.fw
/lib/firmware/GSL1680D_FW_86VS_JINXING.fw
/lib/firmware/GSL1680D_FW_86VS_PG_JIUZH.fw
/lib/firmware/GSL1680D_FW_86VS_SHXWUYIN.fw
/lib/firmware/GSL1680D_FW_86VS_TUOBU_ZH.fw
/lib/firmware/GSL1680D_FW_86VS_V1.fw
/lib/firmware/GSL1680E_FW_66V_M4302_INE.fw
/lib/firmware/GSL1680E_FW_86VS_CTD_SEND.fw
/lib/firmware/GSL1680E_FW_86VS_FW_CTD_A.fw
/lib/firmware/GSL1680E_FW_86VS_GS0060_S.fw
/lib/firmware/GSL1680E_FW_86VSH_INET.fw
/lib/firmware/GSL1680E_FW_86V_SHXHLD072.fw
/lib/firmware/GSL1680E_FW_86VS_INET.fw
/lib/firmware/GSL1680E_FW_86VS_PG_JIUZH.fw
/lib/firmware/GSL1680E_FW_86VS_SHXWUYIN.fw
/lib/firmware/GSL1680E_FW_86VS_TUOBU_ZH.fw
/lib/firmware/GSL1680_FW_haina.fw
/lib/firmware/GSL1680_FW_newdingshengwe.fw
/lib/firmware/GSL1680_FW_TOPSUN_OGS_G70.fw
/lib/firmware/GSL2682A_FW_86FV_TOPSUN_G.fw
/lib/firmware/GSL3680_FW_shenghexiang00.fw
/lib/firmware/gsl_load_fw.fw
/lib/firmware/GSLx680_FW_85V_M501V.fw
/lib/firmware/GSLX680_FW_86V_TOPSUN_OGS.fw
/lib/firmware/GSLx680_FW_NEWDINGSHENGWE.fw

I read the writing on the chip and it appears to be a GSL1680 (without
a letter appended) so I tried all firmware that don't have a letter at
the end.

However, none works. I also tried some other random firmware from the list.

Problem is loading new firmware requires editing script.bin and reboot.

This is lengthy and error-prone.

On the tablets where some firmware works can the controller be
uploaded with wrong firmware, reset, uploaded with right firmware and
still work?

If so you could just specify a list of firmware files and try all.

If not then all this testing is dubious. What guarantees that the
controller is reset on reboot on device that has battery?

Also the stop error is probably normal and happens at random.

On both tablets there is a device other than the touch controller on
the i2c bus (on address 15 on one and 18 on other). Presumably the
other device may use the bus sometimes.