Rockbox Development > New Ports

AIGO EROS Q / AIGO EROS K / IRULU Surfans F20 / AGPTek H3 / HIFI WALKER H2

<< < (18/18)

amachronic:
No chance that the SoC drives the panel directly. Take look at the pinout on the ST7789V which is probably the M3K's LCD controller. The panel has 240 pins (this should be true of all 320x240 panels, I believe) and your ribbon cable is 18 pins, so there's definitely a controller present.

The ST7789V is about 15.1x0.7mm... your controller is probably same or similar dimensions. Actually, looking at DSCF2985.JPG from your first batch of photos, it would likely be hidden underneath that black plastic or sticker below the panel, where the ribbon cable is going into. Personally, I'd be afraid of destroying the LCD module by peeling that off.

You can pick the LCD controller initialization command table out of the kernel -- you'd likely have to do this even if you do identify the controller IC -- and the command set might give you a way to identify the controller indirectly.

dconrad:
Another small tidbit I think - the 6 pin IC near the battery pads marked 86200S might possibly be FDC8602 Dual N-Channel MOSFET. I'll edit the post above.

dconrad:

--- Quote from: amachronic on June 09, 2021, 05:42:09 AM ---No chance that the SoC drives the panel directly. Take look at the pinout on the ST7789V which is probably the M3K's LCD controller. The panel has 240 pins (this should be true of all 320x240 panels, I believe) and your ribbon cable is 18 pins, so there's definitely a controller present.

The ST7789V is about 15.1x0.7mm... your controller is probably same or similar dimensions. Actually, looking at DSCF2985.JPG from your first batch of photos, it would likely be hidden underneath that black plastic or sticker below the panel, where the ribbon cable is going into. Personally, I'd be afraid of destroying the LCD module by peeling that off.

You can pick the LCD controller initialization command table out of the kernel -- you'd likely have to do this even if you do identify the controller IC -- and the command set might give you a way to identify the controller indirectly.

--- End quote ---

Any chance you can give some guidance on extracting/decompiling/comparing the kernel to the generic ingenic blob? I haven't ever done anything like that, and I'd like to give it a shot. I can stumble my way through assembly code given enough time, but I could hardly be called proficient at it. Any resources to get started?

amachronic:
For disassembling the kernel you can use Ghidra. Ghidra's quite powerful and it has analyzers and a decompiler which will do a ton of work for you, I really can't recommend it enough. You don't need to read much assembly code or understand it "by hand" in most cases, thanks to the decompiler. It occasionally breaks down, but usually that's a sign you need to provide some extra annotation manually to stop it getting confused (it isn't perfect after all). But be warned: I lost some work a handful of times to crashes/hiccups, although the project reloaded fine afterward. So you probably want to save often. Of course if you have access to any other reverse engineering tools, by all means use them. But none of the free ones I've seen are as good as Ghidra.

Kernel sources and datasheets can be found here: https://github.com/YuanhuanLiang/X1000. I didn't take a close look at it but it seems right. (vitt13 posted that link on the M3K thread.) It seems the Ingenic FTP servers are no longer accessible and they've changed all the links on their main site to point to a baidu drive which apparently won't let you download unless you have an account... I think (it's all in Chinese).

You can probably grab the kernel binary from the update package; otherwise you need to dump your device's NAND (a good idea anyway). Often nanddump is present on the OF's filesystem and with that you can take dumps using a script. Make sure you take normal dumps and dumps including OOB data; the OOB data will let you know if there is any ECC scheme in use.

Once you get the kernel image, it is likely in xImage format, with a 32-byte header prepended to the kernel binary / decompressor stub. You can pick that apart manually if you want, but I was lazy and used 'binwalk -e' to extract the vmlinuz image automagically.

When importing the vmlinuz image into a ghidra project, you should pick MIPS LE 32 bit architecture and map the base address as 0x80010000. It's possible they're using another base address, but I doubt it. (You will be able to tell if it's wrong because all the jump targets would be messed up and not pointing to proper function prologues.)

I also have some notes from my own kernel disassembly which might help you in locating certain functions, platform_data structs, & other tables that'll tell you GPIOs and other useful things, but I have to clean them up first so they're intelligible. Would you be interested in them?

I'm not too sure about resources on reverse engineering as such. I wasn't able to find a whole lot myself, but I have enough background knowledge of C/systems programming/low level stuff in general, that once I discovered Ghidra, I was able to make good headway on my own. With vaguely accurate source code, it wasn't too hard to piece things together, although somewhat time consuming at first due to not knowing what I'm doing.

PS: porting Rockbox to the M3K was the first time I ever did anything serious with operating systems, hardware drivers, or the like; ie. beyond the level of a 'hello world' OS. It also took me about a year to piece everything together... So don't get discouraged if things are hard going at first. You just have to keep at it, and eventually things will start to make sense.

Good luck!

dconrad:

--- Quote from: amachronic on June 13, 2021, 04:22:28 PM ---For disassembling the kernel you can use Ghidra. Ghidra's quite powerful and it has analyzers and a decompiler which will do a ton of work for you, I really can't recommend it enough. You don't need to read much assembly code or understand it "by hand" in most cases, thanks to the decompiler. It occasionally breaks down, but usually that's a sign you need to provide some extra annotation manually to stop it getting confused (it isn't perfect after all). But be warned: I lost some work a handful of times to crashes/hiccups, although the project reloaded fine afterward. So you probably want to save often. Of course if you have access to any other reverse engineering tools, by all means use them. But none of the free ones I've seen are as good as Ghidra.

Kernel sources and datasheets can be found here: https://github.com/YuanhuanLiang/X1000. I didn't take a close look at it but it seems right. (vitt13 posted that link on the M3K thread.) It seems the Ingenic FTP servers are no longer accessible and they've changed all the links on their main site to point to a baidu drive which apparently won't let you download unless you have an account... I think (it's all in Chinese).

You can probably grab the kernel binary from the update package; otherwise you need to dump your device's NAND (a good idea anyway). Often nanddump is present on the OF's filesystem and with that you can take dumps using a script. Make sure you take normal dumps and dumps including OOB data; the OOB data will let you know if there is any ECC scheme in use.

Once you get the kernel image, it is likely in xImage format, with a 32-byte header prepended to the kernel binary / decompressor stub. You can pick that apart manually if you want, but I was lazy and used 'binwalk -e' to extract the vmlinuz image automagically.

When importing the vmlinuz image into a ghidra project, you should pick MIPS LE 32 bit architecture and map the base address as 0x80010000. It's possible they're using another base address, but I doubt it. (You will be able to tell if it's wrong because all the jump targets would be messed up and not pointing to proper function prologues.)

I also have some notes from my own kernel disassembly which might help you in locating certain functions, platform_data structs, & other tables that'll tell you GPIOs and other useful things, but I have to clean them up first so they're intelligible. Would you be interested in them?

I'm not too sure about resources on reverse engineering as such. I wasn't able to find a whole lot myself, but I have enough background knowledge of C/systems programming/low level stuff in general, that once I discovered Ghidra, I was able to make good headway on my own. With vaguely accurate source code, it wasn't too hard to piece things together, although somewhat time consuming at first due to not knowing what I'm doing.

PS: porting Rockbox to the M3K was the first time I ever did anything serious with operating systems, hardware drivers, or the like; ie. beyond the level of a 'hello world' OS. It also took me about a year to piece everything together... So don't get discouraged if things are hard going at first. You just have to keep at it, and eventually things will start to make sense.

Good luck!

--- End quote ---

Thank you so much, that's an amazing explanation! It helps a ton to know a general roadmap with what tools I can use. Now to try to extract that kernel image... 8)

EDIT for my own or somebody else's future reference: wow, the .upt file is really just an ISO with a different file extension - change it to .iso and it can be mounted like any other iso file, at least on macos... see here

Navigation

[0] Message Index

[*] Previous page

Go to full version