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

[amachronic]

Normally the hold switch is a slider that you can flip back & forth, it locks the other keys so you don't accidentally press them in your pocket. It's like a screen lock, but for physical buttons. Mostly you see it on older devices. It seems it's not very popular anymore.

[rayjgu3]

Got me a surfans f20. Rockbox loaded, it boots and plays fine on everything I plugit into headphones speakers but I have a pair of speakers it just won't work with. Changed the cord several times, each time original firmware  plays just fine but rockbox won't. Any ideas I am stumped.

[dconrad]

I can't find a way to set repeat, shuffle and so on on the fly rather than having to go through the playback menu which is kinda cumbersome. Am I just not understanding Rockbox, or is this something that simply hasn't been implemented for this player yet? It doesn't have that many buttons so I guess it would need to be implemented through some button combination.
EDIT: Some themes seem to specify functionality mapped to a "hold button", does that have a mapping yet?

Oktan, you might be interested in this patch that was merged the other day: Gerrit #3408.

This implements Quickscreen, so to change the quick settings, hold down play on the while playing screen and then scroll left/right with the scrollwheel or up/down with the seek buttons. You can add any option in the settings to the quickscreen from the context menu when you're hovered over them in the settings (if that makes sense). I think by default it has shuffle and repeat on left and right.

Otherwise, Stop was moved to holding the power button, and the hotkey (by default, this shows the playlist) can be brought up by moving the scroll wheel on the while playing screen.

Sidenote, I wonder if themes which do something when the hold switch is activated generally do the same action when the softlock (press power) is activated?

[dconrad]

Got me a surfans f20. Rockbox loaded, it boots and plays fine on everything I plugit into headphones speakers but I have a pair of speakers it just won't work with. Changed the cord several times, each time original firmware  plays just fine but rockbox won't. Any ideas I am stumped.

How do the speakers connect? If it is via the headphone or line out, it should work just fine. If it is via USB, rockbox doesn't do any sort of audio over USB to my knowledge.

[Oktan]

I can't find a way to set repeat, shuffle and so on on the fly rather than having to go through the playback menu which is kinda cumbersome. Am I just not understanding Rockbox, or is this something that simply hasn't been implemented for this player yet? It doesn't have that many buttons so I guess it would need to be implemented through some button combination.
EDIT: Some themes seem to specify functionality mapped to a "hold button", does that have a mapping yet?

Oktan, you might be interested in this patch that was merged the other day: Gerrit #3408.

This implements Quickscreen, so to change the quick settings, hold down play on the while playing screen and then scroll left/right with the scrollwheel or up/down with the seek buttons. You can add any option in the settings to the quickscreen from the context menu when you're hovered over them in the settings (if that makes sense). I think by default it has shuffle and repeat on left and right.

Otherwise, Stop was moved to holding the power button, and the hotkey (by default, this shows the playlist) can be brought up by moving the scroll wheel on the while playing screen.

Sidenote, I wonder if themes which do something when the hold switch is activated generally do the same action when the softlock (press power) is activated?

Fantastic, now all we need is something like the hold button for themes that use that to show the album artwork, but I guess that's partly on the theme designers.

[speachy]

Fantastic, now all we need is something like the hold button for themes that use that to show the album artwork, but I guess that's partly on the theme designers.

The theme engine already treats softlock the same as a physical lock switch, so if the theme was set up to do something when the screen is locked, then it should work as expected on the ErosQ series.

[Oktan]

Fantastic, now all we need is something like the hold button for themes that use that to show the album artwork, but I guess that's partly on the theme designers.

The theme engine already treats softlock the same as a physical lock switch, so if the theme was set up to do something when the screen is locked, then it should work as expected on the ErosQ series.

Something seems to be off with how the theme engine is working in this build then. Nearly every single theme gives a very bare-bones now playing-screen that looks nothing like it's supposed to.

EDIT: Just discovered that this error was caused by missing fonts. A lot of the default fonts are apparently not distributed with the daily builds, but adding them manually fixed it all up.

[dconrad]

In the interests of maybe someday doing a native port to this, I went ahead and tore mine apart to see what was inside. I think I've identified most of the ICs, though GPIO Pin #'s, etc. on the processor are still a mystery.

Here's a zip file of all the pics: https://www.dropbox.com/s/63ww77dj3qp0dgj/erosq%20photos.zip?dl=1

Here's what I have so far:

SoC: X1000 (no E, well yeah we already knew that...) w/ 24.000 MHz crystal
DAC: PCM5102A
PMU: AXP192

And a few that I think I've ID'd:

ATO25D1GA-10ED: 1Gbit NAND Flash

AIG
BCB   --> Possibly Maxim MAX97220 Diff. Headphone Amp?

GAD
SJN   --> Possibly ISL54405IRUZ-T Stereo 2:1 Multiplexer (w/ click/pop elimination)

And a few that I believe to be LDO regulators - 4XXK, LPFG

86200S, near the battery pads - possibly FDC8602 Dual N-Channel MOSFET?


There's still a couple I haven't ID'd:

- The LCD controller, integrated with the panel itself.
- A seemingly unmarked IC near the power button
- The bluetooth module
- A handful of probably-unimportant transistors


Is there anything else I should look at before I put it back together?

[amachronic]

Try getting a look at the LCD controller if possible. it's a tough one to deal with if you don't know exactly what it is, especially if it does not follow the standardized MIPI DCS command numbering. It is probably attached to the LCD module (it's essentially a PHY for the panel, AIUI, so it has to be nearby).

My guess is that bluetooth is underneath that silver case by the flash... it looks like there's an antenna nearby. If you're careful those cases can sometimes be peeled off and clipped back on, but sometimes they are soldered to the board. You can probably figure it out via the OF kernel, even without getting a look at it though.

Unfortunately you probably need to figure out GPIOs the hard way. Buttons are easy since you can poll for them in software, but internal stuff like reset and power pins for accessory ICs are difficult without accurate source code. Since you've got the case open, some of those pins might be accessible, others probably not. You can reverse engineer the OF's kernel, since it is virtually guaranteed to follow the ingenic blob for >99% of the code, and the GPIOs will be encoded in data tables or code that you can eventually dig out if you are persistent enough.

[dconrad]

Try getting a look at the LCD controller if possible. it's a tough one to deal with if you don't know exactly what it is, especially if it does not follow the standardized MIPI DCS command numbering. It is probably attached to the LCD module (it's essentially a PHY for the panel, AIUI, so it has to be nearby).

My guess is that bluetooth is underneath that silver case by the flash... it looks like there's an antenna nearby. If you're careful those cases can sometimes be peeled off and clipped back on, but sometimes they are soldered to the board. You can probably figure it out via the OF kernel, even without getting a look at it though.

Unfortunately you probably need to figure out GPIOs the hard way. Buttons are easy since you can poll for them in software, but internal stuff like reset and power pins for accessory ICs are difficult without accurate source code. Since you've got the case open, some of those pins might be accessible, others probably not. You can reverse engineer the OF's kernel, since it is virtually guaranteed to follow the ingenic blob for >99% of the code, and the GPIOs will be encoded in data tables or code that you can eventually dig out if you are persistent enough.

Thanks for the wisdom!

I'm not quite familiar with what I'm looking for re: LCD controller, but I don't see any ICs that are obviously involved. The ribbon cable connects directly between the PCB and the panel itself (I did take it out of the holder very carefully, but didn't get any pics because it seemed very fragile). See: https://www.dropbox.com/s/l8fyx02fuldlpzb/erosq%20photos2.zip?dl=1

Is it possible there isn't an LCD controller and it's driven directly from the SoC?

The bluetooth module's cover sure looks firmly attached to me, I tried and I don't think it's coming off.

Bummer about the GPIOs, but it makes sense.

[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]

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.

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]

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!

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

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