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
On 03/06/14 19:38, [email protected] wrote:
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.
On Tuesday, 3 June 2014 14:08:38 UTC-4, [email protected] wrote:
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.
On Tuesday, 3 June 2014 07:42:23 UTC-4, Joe Burmeister wrote:
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
On 02/06/14 18:33, [email protected] wrote:
============= 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?
On Monday, 2 June 2014 11:13:35 UTC-4, Joe Burmeister wrote:
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
On 02/06/14 14:12, [email protected] wrote:
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.
--
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 email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
