============= 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.
