yashsingh1/xdaforums huggingface dataset:
[General Questions and Answers] mforce2:
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.
[General Questions and Answers] 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 :LOL:

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 :ROFLMAO:

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
[General Questions and Answers] mforce2:
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
[General Questions and Answers] ThegreatHAMbino:
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 😆
[General Questions and Answers] ThegreatHAMbino:
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..
[General Questions and Answers] mforce2:
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.
[General Questions and Answers] ThegreatHAMbino:
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.
[General Questions and Answers] mforce2:
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 :))
[General Questions and Answers] 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...
[General Questions and Answers] mforce2:
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 ?
[General Questions and Answers] 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.
[General Questions and Answers] 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 " :(
[General Questions and Answers] mforce2:
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.
[General Questions and Answers] o-marshmallow:
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...
[General Questions and Answers] mforce2:
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.
[General Questions and Answers] mforce2:
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
[General Questions and Answers] 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.
[General Questions and Answers] o-marshmallow:
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.
[General Questions and Answers] mforce2:
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.
[General Questions and Answers] o-marshmallow:
Indeed, I meant toolchain/compiler.

I thought you installed the modified firmware I gave above already. If that's not the case, how were you able to put your compiled program inside your Powkiddy? Was your system partition mounted when plugging it to the computer through USB?

If I recall correctly, the user partition doesn't have any *.desktop file nor binaries to play around with.
[General Questions and Answers] mforce2:
On the Powkiddy J6 ( I don't have the X16, sorry ) it's really easy as the NOR SPI is 16 MB and everything else , including many apps are on the SD card.

Just replace the binary for the calculator on the SD card and you can run anything your heart desires :).

The downside to it is that I couldn't find the firmware for the J6 to rewrite the SPI flash so this is why I want to dump what I can by running a program and dumping the file system.

I also tried to flash the binary for the X16 but of course it fails. I might reverse engineer the flashing tool to see where it fails and if I can use ADFU to make a dump for the NOR but that's for later.

I'd get the X16 if it were cheap but it got quite expensive and it doesn't have an IPS which is a real bummer for me.

Still the software developed for the J6 will run in the X16 without any major issues as the SDK is the same. I think so is the SOC). I think the ATS3603 is nothing more than a rebranded ATJ2279
[General Questions and Answers] o-marshmallow:
Oh I understand better! Then it is easier than the X16, which doesn't have any binary on the sdcard/user partition. The system partition is not mounted by default when plugging it to the computer.

I wonder whether uCOS works the same way as linux in term of block devices. Can you have a try opening the NOR Flash's block device, read from it and save the dump in the sdcard:

/* The following macros are defined in
* #define DEVICE_FLASH "/dev/flash"
* #define DEVICE_CARD "/dev/card"
* #define CARD_ROOT "/mnt/card"
*/

static buffer[1024];

void dump (void) {
int dump = sys_open(CARD_ROOT "/dump.bin", O_CREAT | O_WRONLY, 0644);
if (dump < 0) {
/* Handle error */
}

int flash = sys_open(DEVICE_FLASH, O_RDONLY);
if (flash < 0) {
/* Handle error */
}

int rd = 0;
do {
rd = sys_read(flash, buffer, 1024);
if (rd < 0) {
/* Handle error */
}
else if (rd == 0) {
break;
}
sys_write(dump, buffer, rd);
} while (rd != 0);

sys_close(dump);
sys_close(flash);
}

Honestly, I don't know the difference between sys_open and open, sys_close and close, sys_read and read, etc...

Moreover, I don't know whether we have to map the FLASH and/or SDCARD again with mknode or not. I do see such code in some examples.
[General Questions and Answers] mforce2:
What I'm struggling with this SDK though, it seems to kinda work but somehow it's not really OK and the screen just goes dark after which the board reboots.

I even tried to build the photo app from the SDK and I get the same result. I'm going to have the check the resulting binaries in IDA or Ghidra and compare them probably.

Still if I make it crash properly by doing a readdir of /dev/sdisk it seems to flush the stuff to the sdcard before it reboots.

I'm not sure it will be able to dump all the flash before being rebooted but I can give it a shot. I'm not even sure my J6 has /dev/flash or something else...
[General Questions and Answers] mforce2:
Not working unfortunately. Here's the log:

Start of log

error when open file

error when open flash

error when read

All done

I was able to copy one individual file from /mnt/diska/sys , it's called config.bin.
[General Questions and Answers] o-marshmallow:
Alright! Check whether you have a file called config.txt on not in your /mnt/diska folder. This file is part of the firmware for X16, I hope they kept it on the J6.

Within this file, you will find:

usb_show_manufacturer_disk = 0;

By replacing 0 by 1, your system partition should be mounted whenever you plug your device to the PC, so you should see your /mnt/diska. Maybe you'll find the kernel modules, system binaries, etc...

I hope you have this file
[General Questions and Answers] o-marshmallow:
I don't know what is the difference between sys_open and open, maybe you can try open instead.

Were you able to backup the mounted partitions' (/mnt/*/) content (files and folders) with the demo you published on your github?
[General Questions and Answers] mforce2:
I was able to get the structure of diska : https://drive.google.com/file/d/1FA9cXwWLlGLojSG0lVUf3fEIBlbRnPAs/view?usp=sharing

As you can see no config.txt but I do suspect that the txt gets transformed into that config.bin which is probably then read by the config app.

I'll now try and dump the files themselves.
[General Questions and Answers] mforce2:
OK, further progress, you can see the demo I used to dump the structure and files here ( it's quite primitive with lots of hard-coded stuff as I didn't feel like using the builtin functions too much: https://github.com/mcirsta/ActSDK/blob/master/case/apps/desktop/demo/demo.c

The file copy is based largely on your flash dump. Note however the missing 0644 , with that one added the open functions were failing.

Here's the dumped files from diska of my Powkiddy J6 : https://drive.google.com/file/d/1ddgzLMNaXejmaEf5JyrWcdiii6uVmFMT/view?usp=sharing
[General Questions and Answers] mforce2:
Some interesting things that I've found in the SDK :

./psp_rel/include/config_api.h

This one seems to deal with the configs, they can be read and set using these functions on the board. This seems to confirm that the config is in binary form on the board.

Also :

./case/apps/config/config_main.c

Contains an example of sys_read.
[General Questions and Answers] mforce2:
In the meantime I also managed to dump some system files:

copySysFile("/mnt/sdisk/libgb1.so", "/mnt/card/libgb1.so");

copySysFile("/mnt/sdisk/libemu.so", "/mnt/card/libemu.so");

However opening /dev/flash or /dev/flashu fails. I'm thinking that maybe they are just not there but not sure how to check.

For sure only system functions can access /ment/sdisk and while there's a sys_readdir it's strange and there's not sys_opendir ....

I think for now these are still quite decent results though.
[General Questions and Answers] The_YongGrand:
Hello @mforce2 and @o-marshmallow , thanks for the effort on trying to look into the firmware.

Being the owner of one of those Actions Semi based handhelds, I had been struggling to put a piece of the customized software into the system.

Many years ago in 2014 I bought this "Gameplayer" thing with a fake PSP shell. This thing, I believe, the SOC is the ATJ2259 and most of the firmware structure are identical to the ones you have mentioned in this thread. Unfortunately, this one "fake PSP thingy" is very difficult to work with - it is not responsive when using the ATJ tools to upload the firmware, and it's not possible to expose the system partitions inside. Searching on how to do this in Google yield very little results - and in conclusion, I ended up bricking the device. Now this thing is inside the drawer, waiting to rot away while I find a better alternative. :ROFLMAO:

The toy has been pretty fun to use if the firmware or the software inside is swappable. The onboard NES emulator isn't really comfortable to use (doesn't support certain NES games), and there are no GB emulator despite this processor is capable of emulating it. (but it has GBA!)

This "fake PSP thingy" doesn't contain an SPI flash to keep its firmware unlike the J6. It has a parallel NOR flash instead. I believe this J6 could be a newer incarnation to this thing.

I'm hoping this SPI flash (if it's really that) inside the J6, it should be dumped immediately, and dissected. This mystery had to be solved once and for all!

Also, would you guys be okay if I can help on this work? I do not have a J6 yet (only have that other powkiddy with the Allwinner SOC F1C100S) to experiment on. :)
[General Questions and Answers] o-marshmallow:
@mforce2 I think I understand what is /dev/udiska, and unfortunately, that's not what we want. If you take a look at X16 decrypted firmware, you'll see a bunch of binary files (stripped, no debug symbols) which represents the kernel, the system itself, the kernel modules. Near them, you'll have a HideDisk.img, this is an image of the "system" (FAT32) disk. This one contains the (unstripped binary) applications, the desktop files, the user libraries. This is the partition that is mounted in the custom firmware I made. And that this is what you see in /mnt/diska folder (you have lot less data but that's because it's a J6, not X16). Indeed, it is HideDisk.img mounted inside this folder. We won't find anything interesting inside. Well, I mean, we won't find any low-level system things in there.

However, looking deeper at the SDK in your github, I notice the include files talk about an /mnt/udisk0 path. I think this is what we are looking for. I still don't have a Powkiddy J6 but I am really considering buying one now :ROFLMAO:

Few things to try that comes to my mind:

- Try dumping (reading + writing for my previous example) /dev/flashu and /dev/flasha In fact in the code, DEV_FLASH macro is always followed by "a" or "u"!

- Listing /dev folder thanks to opendir, readdir, etc...

- Try listing /mnt/disk0 folder. If it doesn't exist, try mounting it the same way it is done in usb_main.c with sys_mount and/or sys_mknod

@The_YongGrand I think all of us agree on one thing: these devices have a very bad software but the hardware is pretty cool for the price! 😄

Of course we would be ok, our messages are public to help anyone interested ;)

I think if we don't manage to dump anything using the software, there is still the hardware way: connects the NOR pins to a microcontroller to dump the content of it. This could be painful as it could harms the chip mainly if we have to desolder it. This should be the last thing to do.

Maybe getting a J6 would be a good option as it's pretty cheap, I guess it also depends on whether we can get far enough with it or not
[General Questions and Answers] mforce2:
From what I can tell so far the sys_ functions are for accessing the system part of the fs, I was able to dump stuff in /mnt/sdisk using sys_open and sys_read. I am pretty sure just using open and read would fail for that.

There's a dump of the SPI on the J6, it's here: https://github.com/steward-fu/powkiddy-x3/releases/tag/v1.0

The same guy put some pictures somewhere ( can't find it anymore ) , I think in Chinese with some pictures of the flash chip for the X3 as it's called in China. I remember it's a small chip with only 8 data lines so from what I understand it's really just a 16MB SPI NOR flash chip ... I'm not a hardware guy though.

In this SPI dump you can clearly see the beginning of the dump contains ActBrm, just like is described here:

https://www.rockbox.org/wiki/ATJ213xFirmware

And there's also the checksums mentioned.

I am also wondering how this test binaries would work ... I think we can get them working:

atj2137 « utils - rockbox.git - The Rockbox source code.

git.rockbox.org
[General Questions and Answers] mforce2:
I would really encourage you to get the Powkiddy J6 or the X3 as it's called in China. It's really cheap , it's $20 shipped in EU and it's got a good nice 800x480 IPS screen , controls are decent. It's really a nice machine to play with.

It would be great if we could all try the stuff on the J6, it has a lot of potential and it's still on sale at a good price. Having an easily removable SD card where you can add binaries to test also really helps a lot.

The SDK that we have is for an earlier MIPS 4kEc SOC : https://www.rockbox.org/wiki/ActionsATJ

so there may be some subtle differences but binaries made work at least to some extent.

I'm also going to try and reverse the tool that does the flashing to get the dump of the NOR SPI flash through it. If we can dump and then flash back the SPI flash using some open source tool that would make the J6 unbreakable as you can just always enter hardware ADFU mode ( hold down Vol+ ) and flash back the SPI.
[General Questions and Answers] mforce2:
Ah , there we go, found the teardown from the same guy that did the dump:

司徒的教學網站

A valid, XHTML 1.0 template

steward-fu.github.io

You can see the flash chip is a W25Q128