Question powkiddy x16 SoC droid clone?

[godkingofcanada]

Anyone seen these handheld retro units from China? Gba, gb, gbc, nes, snes, Sega, psx, cps1+2.

I'm trying to locate firmware. Factory or otherwise, trying to figure out what this is running.

 

[ThegreatHAMbino]

The emulators are all in common. There's an emulator app called ... emulator.app which uses some emulator lib that doesn't actually do much and then also these different libs that I mentioned above.
In the emulator.app of the Powkiddy X6 at least there's this function:
judge_gametype_byname(char *name)
which looks at the file extension I assume and based on this decides what type of game it is. For the .bin extension though it seems to look at something else also.
Once it determines this it assigns the gametype global variable a value ( 1 is NES , 6 is PS1 and there's like 7 numbers all till 10 ). There's some other variables I think to detect if it supports this emulator and what type of library it needs.
Then still in the emulator.app there's the function that loads the right emulator based on gametype and it loads one of the libs I mentioned above.
All of these libs have a common interface from what I can tell , probably something like save game, pause game, exit game and the emulator app transfers control to the appropriate lib ( based on gametype ) which then does its thing as it needs to.

I'm not sure what improvements are made to these emulation libraries, most seem to rely on quite old code even on the X16 which is quite a new device. In theory they could synchronize with the upstream emulator code but sometimes upstream is abandoned or semi-abandoned. Also depending on how much the needed to modify the emulator to fit into their framework it might not be trivial to pick up the newer changes especially if it diverged quite a bit.

There's also the question of the license , most of these emulators are licensed under GPL or LGPL so there's the obligation to publish the source code but I'm not sure there's any way to enforce this, especially in China. We could try though. Getting the source code to the emulators could allow either to synchronize them with upstream or to completely replace the emulation core while keeping only the interfaces.

Hope that answers your question

Thanks for the breakdown, that completely makes sense based on how the system works. I agree, using commercially available open source emulators should give us the right to make changes and keep them updated. Can you see any advantage as to why they chose a software/UI like this considering how much different it is compared to any other emulation handheld?..

 

[mforce2]

Thanks for the breakdown, that completely makes sense based on how the system works. I agree, using commercially available open source emulators should give us the right to make changes and keep them updated. Can you see any advantage as to why they chose a software/UI like this considering how much different it is compared to any other emulation handheld?..

If you mean why not use Dingux or some Linux I've wondered myself but digging through all this I got the answer. Actions was into making mp3 and what the Chinese called mp4 and mp5 players. Those were video players actually. The ATK2279 was initially developed for this and it seems like their newer ATS3603 is a rebrand or this.

Since these video players ( some of which even had a touch screen ) are no longer popular these days with people just using their mobile phone I guess Actions tried to get into different markets. They tried the toys market with the ATS3603 ( https://www.programmersought.com/article/18267220/ ).

I think Powkiddy saw the opportunity and actions still had plenty of chips ( maybe even boards ) that they were willing to sell cheap. The video players that Actions had were all running UCOS ( from Micrium which is now open source ) due to legacy reasons I assume and also cost. UCOS seems to have lower requirements than Linux as far as RAM and Flash go.

I did see some mentions of Linux for ATJ3603 and even for ATJ2279 but I never really found any code or products actually running Linux on these SOCs.

To sum it up, Powkiddy got cheap leftover Actions SOCs and Actions had the SDK for UCOS that they just gave to Powkiddy with everything , it seems even including the emulator libs. It's likely Powkiddy did some small adaptations for their hardware but it would have been really hard for them to use anything other than the Actions SDK based on UCOS. They also probably don't have the rights ( from Actions ) to publish any code but also they most likely are unwilling to do so anyway.

 

[o-marshmallow]

Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one

 

[mforce2]

Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one

Yeah, got that , thanks a lot. Well in the meantime I kinda figured it out, all except the modify the bit in the encrypted firmware, that didn't occur to me. I guess based on the decrypt software we could write one that does the encryption back.

I also sent you an email ( because I didn't know if you'll be back around here ) telling that I've found the SDE and looking at the debug symbols in the files it's the same version of SDE gcc that was used to build the binaries on my Powkiddy J6.
Both the Powkiddy J6 and the X16 were built under cygwin by this misterious Mr Huang , we really need to find him.
Anyway the SDE is here: https://drive.google.com/file/d/1HWbOy6a19PbnGPQ_crRHC-a6Y-O7P1Em/view?usp=sharing

 

[ThegreatHAMbino]

Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one

I'll help out anyway I can. That's really why that first thread was so crucial because that's where the debugger and development pdf came from. I really appreciate the feedback and help you've given so far. Wasn't there for the first thread, but I'll damn sure be there for the second one

 

[ThegreatHAMbino]

Yeah, got that , thanks a lot. Well in the meantime I kinda figured it out, all except the modify the bit in the encrypted firmware, that didn't occur to me. I guess based on the decrypt software we could write one that does the encryption back.

I also sent you an email ( because I didn't know if you'll be back around here ) telling that I've found the SDE and looking at the debug symbols in the files it's the same version of SDE gcc that was used to build the binaries on my Powkiddy J6.
Both the Powkiddy J6 and the X16 were built under cygwin by this misterious Mr Huang , we really need to find him.
Anyway the SDE is here: https://drive.google.com/file/d/1HWbOy6a19PbnGPQ_crRHC-a6Y-O7P1Em/view?usp=sharing

Awesome job, that confirmed a lot of my suspicions right there. The firmware version listed might be different or in this case even the model(j6+x16) but in reality there almost the same thing with a few small interface/menu changes. Sounds like we're making some headway, I would love to see this project come to fruition. Keep up the good work guys! I'll post anymore updates on my end as they come..

 

[mforce2]

I'll help out anyway I can. That's really why that first thread was so crucial because that's where the debugger and development pdf came from. I really appreciate the feedback and help you've given so far. Wasn't there for the first thread, but I'll damn sure be there for the second one

I'm not sure the debugger is doing much unfortunately. I couldn't get it to work myself but it mostly seems to show the contents or something ....
I did find in some Actions SDK the other part of the debugger, what it's supposed to talk to.
Hang around , we might get somewhere with this thread too.
All these Actions devices seem to share the same SDK, the functions are the ones here: https://github.com/uli/actsemi/blob/master/libactsemi/actsemi.c

They're all exactly the same addresses.

 

[ThegreatHAMbino]

I'm not sure the debugger is doing much unfortunately. I couldn't get it to work myself but it mostly seems to show the contents or something ....
I did find in some Actions SDK the other part of the debugger, what it's supposed to talk to.
Hang around , we might get somewhere with this thread too.
All these Actions devices seem to share the same SDK, the functions are the ones here: https://github.com/uli/actsemi/blob/master/libactsemi/actsemi.c

They're all exactly the same addresses.

I hadn't played around with it to know if it was going to work out or not. At that time I was just trying to gather any/all info that I could before I started to get deeper into the project. I'm not going anywhere, I'm gonna see this thru till the end. Truthfully, it's good to have you aboard. This time around seems just as promising as the last, but now we have a little more information to go off of. I'm excited to see what we all come up with.

 

[mforce2]

Hello @mforce2 and @ThegreatHAMbino !

You just gave a lot of info, I had never found the PDF explaining the whole dev process before, I wish you were here few years ago when we started the first thread
There are still some issues because we don't have the toolchain they are using (SDE). SDE has been replaced and I was not able to find it back.

Regarding the modified firmware, I did the step step as you did: I used the atjboottool you found, it gave me an SQL database. I guess it's the role of the flasher to go through the tables and flash the files one by one to the NAND flash. Anyway, I checked all the table with a classic SQL database explorer, then I checked the configuration files (txt), and there was a single flag called "mount system partition = 0" or something like that. My goal was to find the bit in the encrypted firmware in order to modify it. The fact is the encryption used by ATJ is quiet simple, each byte is encoded by using a XOR with a specific value, the good thing is each byte is encoded independently. This means that changing encrypted byte X will not affected byte X+1 encryption/decryption.

Anyway, after understanding this, and after finding the byte to modify, it was quiet simple, so I used a hex editor (dhex on linux) to modify directly the encrypted firmware.

I hope it was not too confusing

I haven't tried modifying/adding a whole file to the SQL database and re-encrypting it. In that case, we'd need to write an ATJEncryptTool as I couldn't find one

One more question , where did you get that SDK , usdk213f ? Seems almost the same as the one we need but not really. I was wondering if maybe we could get this one that was actually used :

/cygdrive/h/Mr_huang_work/ATJ2279B/ch7968_v1/usdk227c/case_tp/apps/desktop/emulator
Powkiddy

I'm also putting a ransom out for finding Mr Huang, $10 , I know it's not a lot but we can contribute and maybe make it worth it )

 

[o-marshmallow]

@mforce2 If I recall correctly, I found it here: https://forums.rockbox.org/index.php?topic=51071.30

I looked for this SDK but I was unable to find it. The only way we have is to ask Powkiddy for it. I sent them multiple emails but never got any reply...

 

[mforce2]

@mforce2 If I recall correctly, I found it here: https://forums.rockbox.org/index.php?topic=51071.30

I looked for this SDK but I was unable to find it. The only way we have is to ask Powkiddy for it. I sent them multiple emails but never got any reply...

Yeah , I asked the guy who posted the SDK there. He said he got it from a badly configured FTP that Actions had at the time. I don't even know if they still have it.
Actions will have this SDK, I'm pretty sure, I emailed them about it but nothing so far.
Gamesir also realeased a device similar to the Powkiddy J6 , the GC 1 I think it's called and I asked them but they wouldn't send neither the SDK or either the .fw file.
I'm not sure why even the .fw file is such a secret. Maybe they just don't have it . Could it be that because SPI NOR flash is used it's just pre-programmed and there's no .fw file like for the NAND flash devices ?

 

[mforce2]

One more thing, it seems Powkiddy is more of a shell or something. The realy manufacturer of th X16 seems to actually be Subor and it's called the Subor Q700 ( which is why the firmware has this name too ).
@o-marshmallow Maybe try to contact Subor directly , you might have more luck.

 

[o-marshmallow]

@mforce2 I just did. I directly contacted Subor's after sale service, the guy was named Huang, what a coincidence. I asked for the SDK, he said he doesn't have it/cannot provide it. He advised me to contact the resellers directly. This is what I did, unfortunately, the sellers don't seem to know what I mean by "SDK "

 

[mforce2]

@mforce2 I just did. I directly contacted Subor's after sale service, the guy was named Huang, what a coincidence. I asked for the SDK, he said he doesn't have it/cannot provide it. He advised me to contact the resellers directly. This is what I did, unfortunately, the sellers don't seem to know what I mean by "SDK "

Neah resellers won't know anything about the SDK.

I've also found out who makes the "Powkiddy J6" , it's these guys : http://www.szrenshun.com/about.asp?ids=8

It would make sense since the board has "CB" on it. If you speak Chinese could you try contacting them please and ask about the .fw file to flash for the Powkiddy X3 I think they call it but internally it's called the "D3560_V4" on the PCB and the "CD3670" in the software.

It could be that the only guys who have the SDK are Actions Semiconductors but they'll never release it. Previous one which you have was leaked from their FTP site ... I wonder if they still have a FTP , haha.

 

[o-marshmallow]

Neah resellers won't know anything about the SDK.

I've also found out who makes the "Powkiddy J6" , it's these guys : http://www.szrenshun.com/about.asp?ids=8

It would make sense since the board has "CB" on it. If you speak Chinese could you try contacting them please and ask about the .fw file to flash for the Powkiddy X3 I think they call it but internally it's called the "D3560_V4" on the PCB and the "CD3670" in the software.

It could be that the only guys who have the SDK are Actions Semiconductors but they'll never release it. Previous one which you have was leaked from their FTP site ... I wonder if they still have a FTP , haha.

No luck unfortunately, I contacted the person directly, he told me he doesn't know this device (X16), it's not his company's, then I asked about the D3560_v4 and Powkiddy more generally, he said he doesn't know that company...

 

[mforce2]

No luck unfortunately, I contacted the person directly, he told me he doesn't know this device (X16), it's not his company's, then I asked about the D3560_v4 and Powkiddy more generally, he said he doesn't know that company...

Thanks for trying, it's really strange how these products are made. No one really knows who makes them , they can't even decide on the name , haha.
I'm pretty sure Powkiddy is just rebranding them though.

 

[mforce2]

No luck unfortunately, I contacted the person directly, he told me he doesn't know this device (X16), it's not his company's, then I asked about the D3560_v4 and Powkiddy more generally, he said he doesn't know that company...

Attempted to get some more info but couldn't find much from Actions. As I don't have any relations or anything in China maybe you could get some info about the Actions FTP , it seems to be not public anymore .
They also seem to have some CS thingy but that's not working sadly .... At least not for me, maybe it's working in China: https://cs.actions-semi.com/Login.aspx

 

[mforce2]

Good news, I managed to get a demo application working on the board.
The source is here: https://github.com/mcirsta/ActSDK/tree/master/case/apps/desktop/demo
I've just replaced the calculat.app with this one and I got the writing to file working perfectly.
I've used the SDE that I mentioned.

 

[o-marshmallow]

Good news, I managed to get a demo application working on the board.
The source is here: https://github.com/mcirsta/ActSDK/tree/master/case/apps/desktop/demo
I've just replaced the calculat.app with this one and I got the writing to file working perfectly.
I've used the SDE that I mentioned.

That's some great news !
Then I guess the SDK I used to use was definitely not suitable for the device

In the previous SDK I linked, you have some examples that should work on our devices. (edit: my bad, I didn't see yours also have these examples)
uCOS system is based on message passing to perform communication between the system and the applications (so in order to launch a new applicaiton, the launcher application receives a message and itnerpret it). Have a try compiling one of them with the toolchain you got.

 

[mforce2]

That's some great news !
Then I guess the SDK I used to use was definitely not suitable for the device

In the previous SDK I linked, you have some examples that should work on our devices. (edit: my bad, I didn't see yours also have these examples)
uCOS system is based on message passing to perform communication between the system and the applications (so in order to launch a new applicaiton, the launcher application receives a message and itnerpret it). Have a try compiling one of them with the toolchain you got.

The SDK was not the issue, it's the one you shared. Maybe the compiler was the problem.
First thing I want to do is to dump the contents of the partitions on my Powkiddy J6 as I don't have the firmware for it.
Also of interest to me is how to add another library in the system. They seem to have some fixed addresses.
For the launcher I'm not that concerned, right now I'm happy to just use the calculator app to launch my stuff, it's not like I'm going to use the calculator anyway.