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, eynst...@gmail.com 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, 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.
