When someone can post a disassembly I'll make tables of the caller:callee relationships among the functions and map the global variable addresses. If we can get documentation for the JuTouch library we should have a pretty good grip on it.
https://www.jutouch.com/They say to contact sales for the driver software.
If we can get documentation for the JuTouch library we should have a pretty good grip on it.
I think it's easier for somebody to just open the device up and tell us the which chip is the touchscreen using, then just writing the driver for it (which for sure is already available in GitHub)
The JuTouch library will give important hints about what the rest of the code does.
My 20 years of experience in reverse engineering tells me that this is a table, not a code. But I will know for sure only when I reach that place.
My 5 minutes look at that part shows an incrementing pattern (with contiguous 0x400 bytes size blocks). That doesn't look like a unicode characters conversion table. I could be wrong...
It is still "as cute as a bug's ear", but it may be going back...
Imagine all the fun you'll miss out on.
My 5 minutes look at that part shows an incrementing pattern (with contiguous 0x400 bytes size blocks). That doesn't look like a unicode characters conversion table. I could be wrong...
Maybe we talk about different places?
Because I don't see any 0x400 bytes size blocks... In that case I will asume that this is a memory mapping table...
But this is what I see
PS: This is a Little Endian...
That section is broken up in chunks of various sizes delimited by zeros. This is strongly suggestive of a bitstream for the FPGA. If that's the case there will be a bit of assembly code that sits in loop incrementing a pointer through that section reading and then writing the contents to the FPGA load address.
But the fpga has another spi flash chip.
But the fpga has another spi flash chip.
I think that's an I2C EEPROM, judging by the two pull-up resistors on two of the pins.
It comes with a 2GB SDCard I think.
Might as well be booting from there, then, no?
I still don't have the scope with me, but I did read somewhere that the SDCard only contained the screenshots and saved data.
As originally designed and configured that is correct...
If that's the case there will be a bit of assembly code that sits in loop incrementing a pointer through that section reading and then writing the contents to the FPGA load address.
That is almost certainly wrong. The Zynq at least has it's own facility for loading the bitstream from flash.
But the fpga has another spi flash chip.
I think that's an I2C EEPROM, judging by the two pull-up resistors on two of the pins.
Well, maybe, but my point is/was, isn't that the eeprom that contains the fpga bitstream? And if so, it's not going to be in the other eeprom too, right?
This is strongly suggestive of a bitstream for the FPGA.
FPGA has another standalone chip... as wrote
@GeorgeOfTheJungleBut the fpga has another spi flash chip.
IC which you mark is I2C, name is erased...
and the IC a little bit left, is also SPI 25P16VP, and connectors on left (6pin top, and 4pin bottom is to program them)
Both of them connected to FPGA only...
By the way
Touch IC is GOODIX GT915
Well, maybe, but my point is/was, isn't that the eeprom that contains the fpga bitstream? And if so, it's not going to be in the other eeprom too, right?
Oh, the FPGA bitstream is definitely in the other SPI NOR located to the left of this misterious EEPROM. The Allwinner CPU does not send it.
But the fpga has another spi flash chip.
IC which you mark is I2C, name is erased...
and the IC a little bit left, is also SPI 25P16VP, and connectors on left (6pin top, and 4pin bottom is to program them)
Where will my glasses be?
That is almost certainly wrong. The Zynq at least has it's own facility for loading the bitstream from flash.
Yes but that would mean two flash chips.
(ie. more expensive)
But the fpga has another spi flash chip.
I think that's an I2C EEPROM, judging by the two pull-up resistors on two of the pins.
I2C EEPROM would be used for storing calibration, atc.
Well, I got Ghidra 9.1.2 to run, but it does not grok ARM V9. So where to from here?
Reg
Here is the dump of ST 25P16VP... (this is FPGA stream data and connected to dedicated FPGA pins)
I don't think that it is useful for anyone, just let it be for history...
I2C I guess for store settings.
Also for history, here is the parsing of this dump (.RBF file) header:
WARNING: the .RBF file has the bytes bit-reversed! Reversing...
FPGA - RBF/RPD (Raw Binary File) - Filesize: 16 777 216 bits (00200000 bytes)
00000000 - Start of File (Type 1)
[00000048 00000021]
Bit 7 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 6 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 5 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 4 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 3 - 1111111111111111111111111110111010000000 FFFFFFEE80
Bit 2 - 0000011100110011001011111000000000111111 07332F803F
Bit 1 - 1100000000000111100011000000010111111111 C0078C05FF
Bit 0 - 0000000000010101000100010110110111111111 0015116DFF
Bits 0080 - EPCS/EPCQ ID check: Enabled
Bits 005F - Stream size: 943 711 bits (0001CCCC bytes) Compression Bit ON (+1) Size NOT OK
Bits 0056 - 0000 0000 : 0x56-0x5D
Bits 004C - Programming Mode: Active Serial (AS x1)
Bits 003B - IDCode (Version+Part Number only): 0x020F1 (-> 0x024F1)
Bits 0008 - Usercode: 0015116D
00000049 - Header CRC-16_MODBUS: 0033 [00000021-00000048] CRC OK
0000004B - Data Framesize: 207 [0000004B-000000F1]
000000F2 - 4-byte words: 1260 [000000F2-000014A1]
00000000 - Stream Size (Uncompressed): 15 610 872 bits
000014A2 - CRC Framesize: 207+0 # Data Frames: 1727 [000014A2-00059D4F]
Start address: 00000000
00059D50 - Post-device bitstream pad bytes (0xFF): 1583407 [00059D50-001DC67E]
File Checksum: 1E469589
Blocks: (UPDATE)Offset: Size:
00000000 00003400 - SPL (secondary bootloader)
00006000 00007400 - 1st executable (OS part that deals with the SD card) (?)
00013000 0000E600 - bitmap
00027000 00193200 - 2nd executable (main app) (?)
(the 1st 32 bytes of each block are its header) In the header, at offset 0x10, there is the size of the block (including header).
SPL has a Load Address = 0x00000000
The executables have a Load Address = 0x80000000A teaser function in the attached file.
@ rhb
ARM V9 != ARM9
ARM9 is old architecture and it should be supported in Ghidra.
The latest architecture from ARM when I checked a couple of years ago was ARM v8.
Not sure if v9 is released yet.
Also note that ARM9 is also older than Cortex A9.
What's the architecture I should select? ARM's nomenclature has driven me crazy for years and I'm the kind of person who bought processor manuals for new chips e.g. R2000, i860, 68000.
What's the architecture I should select?
ARM Little endian with the load addresses that I've previously indicated, after stripping the 32 byte headers!