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.
