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, eynstyn...@gmail.com 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, eynstyn...@gmail.com 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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
