Rockbox Technical Forums

Rockbox Development => New Ports => Topic started by: hd321kbps on December 13, 2015, 04:30:20 PM

Title: Xduoo x3
Post by: hd321kbps on December 13, 2015, 04:30:20 PM
Is Rockbox for the player Xduoo x3?
Maybe someone will take? Now such a stir on the forums!
Built on a powerful processor Ingenic JZ4760B and has an analog DAC CS4398 from Cirrus Logic, and operational amplifiers OPA1612 and LMH6643
More about him can be found here (http://www.xduoo.com/xduoo/EnProductShow.asp?ID=62).
Title: Re: Xduoo x3
Post by: saratoga on December 13, 2015, 06:18:37 PM
Is Rockbox for the player Xduoo x3?

No, just the devices on the front page. 

If you're interested in working on rockbox, see:

http://www.rockbox.org/wiki/NewPort
Title: Re: Xduoo x3
Post by: pamaury on December 15, 2015, 09:31:29 AM
Hi,
this is interesting. Me and Marcin Bukat are working on porting Rockbox to the Fiio X1 that uses the JZ4760B, PCM5142 DAC and OPA2322 + ISL28291 amplifiers: http://www.rockbox.org/wiki/FiioX1 (http://www.rockbox.org/wiki/FiioX1)

The first step would be to document the player on the wiki, in a similar fashion to the Fiio X1: describe components, upload PCB pictures if you have some. Then try to get the firmware, possibly using a firmware update and try to extract it using our packtools in our repository (utils/jz4760/packtools). You can also come on our IRC channel to discuss: see http://www.rockbox.org/irc/ (http://www.rockbox.org/irc/) and my peudo is pamaury.
Title: Re: Xduoo x3
Post by: pamaury on December 24, 2015, 06:37:53 PM
I have created a wiki page to gather some information about the device, it can be found at http://www.rockbox.org/wiki/XDuooX3 (http://www.rockbox.org/wiki/XDuooX3). I don't have the device so it's all based on the firmware update released.
Title: Re: Xduoo x3
Post by: charleski on December 25, 2015, 04:40:22 AM
If someone can add me to the Wiki users group I can edit there directly. No-one was available on IRC.

To get to recovery mode, turn the device off, press and hold the Esc/Home button and plug in a USB cable. The device appears in Windows Device Manager as a JZ4760 USB Boot Device, USB\VID_601A&PID_4760\7&1ea98c86&0&4 USB class FF USB protocol 50 (i.e vendor ID 601A, product ID 4760 as in the wiki). To return to normal operation, disconnect the USB cable and press the recessed reset button on the right side.

To update the device, navigate to TopMenu->Setting->Upgrade->Yes. The new firmware must be a file named 'update.zip' placed in the root directory of a uSD card formatted with FAT32.
Title: Re: Xduoo x3
Post by: nightgost on January 04, 2016, 04:09:18 PM
https://infinit.io/_/j7zJqy4

some inside pics.
Title: Re: Xduoo x3
Post by: pamaury on January 07, 2016, 12:18:30 PM
Hi,
I have updated the wiki page http://www.rockbox.org/wiki/XDuooX3 (http://www.rockbox.org/wiki/XDuooX3) to add the PCB scans. Using this and some binary reverse engineering, I have concluded that similarly to the Fiio X1, it uses a SLC NAND + mobile DDR RAM MCP. The RAM size is 64MiB and the NAND size is 128MB.
Title: Re: Xduoo x3
Post by: XVortex on January 08, 2016, 11:47:47 PM
Hi to all.
Hmm. It looks like a good platform for experiments on rockbox porting. But I do not see any uart pins on the board. Serial output is helpful for debugging.
Title: Re: Xduoo x3
Post by: pamaury on January 09, 2016, 07:54:20 AM
Hmm. It looks like a good platform for experiments on rockbox porting. But I do not see any uart pins on the board. Serial output is helpful for debugging.

MP3 players usually don't have any deug pins on retail versions.  The first part to a port is usually to make the screen work, to display some information. That's what I plan to do first anyway. I bought the player but I won't have it until another 10 to 15 days:
Title: Re: Xduoo x3
Post by: staeff on January 18, 2016, 03:27:24 AM
I'm very interested in this port. However, I have not much knowledge about embedded development.

Can I do anything to support this?
Title: Re: Xduoo x3
Post by: pamaury on January 20, 2016, 09:21:59 AM
Hi,
sorry I wanted to answer earlier. If you have no knowledge of embedded systems, it's gonna be tough for you to help with the development. However when (I hope) the port is in early stage, heavy testing and reporting problems is much appreciated.
Title: Re: Xduoo x3
Post by: XVortex on January 26, 2016, 06:30:21 AM
Is there any info about X3 GPIO's and OLED interface?
Title: Re: Xduoo x3
Post by: pamaury on January 26, 2016, 12:50:36 PM
Hi,
short answer: no.
So far I haven't played much with the X3. I sent an email to xDuoo to ask them for the source of the Linux Kernel, but I admit I am not overly confident.
Otherwise, the obvious way to go is to hack the firmware upgrade image to include a custom program (or possibly a remote shell) and basically poke in /sys or /proc to see what kind of information is there. I expect I'll have to do some reverse engineering of binary-only modules anyway but if I could avoid disassembling the kernel that would much better.
For the LCD, the nicest outcome would be to find the exact controller used and get the datasheet but this is not always possible, we'll see how it goes.
Another thing is that they are using uboot, so maybe they display some splash screen from uboot in which case some LCD code will be in uboot, which will be much easier to disassemble (again uboot is GPL but it's not clear if they will provide any source code).
Title: Re: Xduoo x3
Post by: XVortex on January 29, 2016, 03:45:25 AM
I've checked u-boot and I did not find any LCD/OLED code or any fonts/sprites in it.
This code is somewhere in internal kernel module.
Title: Re: Xduoo x3
Post by: nightgost on February 06, 2016, 07:57:24 AM
What kind of programmer do you guys need? C++ expert? C?

How about the answers from Xduoo? are they collaborating?

I'd like to apply for beta tester. also for paying some beers to those who can make this possible.



Title: Re: Xduoo x3
Post by: pamaury on February 07, 2016, 08:11:54 AM
Hi,
I didn't get any answer from Xduoo so I guess we will have to reverse engineer everything.
The first step will be to make the lcd display something. I always begin ports by playing with the device through a remote usb connection and some lua scripting. When we got that working, we will write some C code.
Title: Re: Xduoo x3
Post by: XVortex on February 07, 2016, 09:15:58 AM
Maybe it will help...
I did some RE on kernel and found a signs of SSD1305 (https://www.adafruit.com/datasheets/SSD1305.pdf) LCD driver.
Title: Re: Xduoo x3
Post by: XVortex on February 18, 2016, 01:54:19 PM
Hi All.
Here is remote script runner for X3. Now you can run various scripts on the device, play with gpio's, oled_ioctl etc.
How to use:
1) unzip x3_remote.zip to sd-card.
2) edit script.sh
(SD card mounted on /mnt/sdcard0/ so you can use it to get results or run external programs etc).
3) insert SD-card into SD1 slot and choose "Upgrade".
4) Player reboots into recovery mode then runs "script.sh".
5) When the script is completed, player reboots into normal mode.
Here is some findings.
uname -a
Code: [Select]
Linux (none) 2.6.31.3 #399 PREEMPT Fri Nov 20 17:31:16 CST 2015 mips GNU/Linux/proc/cpuinfo
Code: [Select]
system type : JZ4760B
processor : 0
cpu model : Ingenic JZRISC V4.15  FPU V0.0
BogoMIPS : 393.21
wait instruction : yes
microsecond timers : no
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
/proc/mtd
Code: [Select]
dev:    size   erasesize  name
mtd0: 00100000 00020000 "BOOT"
mtd1: 00100000 00020000 "MISC"
mtd2: 00400000 00020000 "KERNEL"
mtd3: 00600000 00020000 "RECOVERY"
mtd4: 00800000 00020000 "CONFIG_RO"
mtd5: 03200000 00020000 "ROOTFS"
mtd6: 02a00000 00020000 "CONFIG_RW"
mtd7: 00800000 00020000 "CACHE"

x3_remote.zip (https://mega.nz/#!1982iBwa!KGfl7zeca2d7ee6IhlQcUKvaEfZhX1z7aUQGDwpGheY)
Title: Re: Xduoo x3
Post by: XVortex on February 23, 2016, 03:28:18 PM
I've found a UART TX pin on the X3 board. See the attached picture:

(http://i023.radikal.ru/1602/4b/efe54b8b23a7.png)

CPU UART1, TTL levels, 3.3V, 57600 8N1 for stock firmware.
Upper pin probably RX pin, does not checked exactly. Pulled-up to 3.3V, no out signals.
I think the UART should help us at the first time.

Here is stock fw boot log (boot-up / playing two songs / shutdown):
Code: [Select]
NAND Secondary Program Loader

X00000004
00000001
Starting U-Boot ...


U-Boot 1.1.6 (Nov 20 2015 - 17:24:35)

Board: Ingenic IDREAM (CPU Speed 492 MHz)
DRAM:  64 MB
Error: Unknown flash ID, force set to 'SST_ID_39SF040'
Flash: 512 kB
NAND:128 MiB

NORMAL Booting ...

*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   JZ ETHERNET
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x200000, size 0x300000
 3145728 bytes read: OK
## Booting image at 80600000 ...
   Image Name:   Linux-2.6.31.3
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    2824266 Bytes =  2.7 MB
   Load Address: 80010000
   Entry Point:  80015a20
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Starting udevd ...
[    4.210000] fat_get_cluster: invalid cluster chain (i_pos 0)
fat_get_cluster: invalid cluster chain (i_pos 0)
fat_get_cluster: invalid cluster chain (i_pos 0)
fat_get_cluster: invalid cluster chain (i_pos 0)
killall: ihifiplay: no process killed
~ # [PRT|libinicfg.c|139]:auxpath=
[PRT|libinicfg.c|140]:country=0
[PRT|libinicfg.c|141]:cycmode=0
[PRT|libinicfg.c|142]:volumes=75
[PRT|libinicfg.c|143]:ledtime=30
[PRT|libinicfg.c|144]:offtime=10
[PRT|libinicfg.c|145]:cyclist=2
[PRT|libinicfg.c|146]:baklight=4
[PRT|libinicfg.c|147]:gain=1
[PRT|libinicfg.c|148]:filter=1
[PRT|libinicfg.c|149]:slppower=0
[PRT|libinicfg.c|150]:autoup=0
[ERR|libioport.c|32]:access /sys/class/gpio/gpio48
fid0=1000, fid1=1001, fid2=1002
filetag.c|357 /mnt/sdcard0/44100.flac------------------------>0
[musicplay.c|1207]----------------->g_load_tid:3
filetag.c|357 /mnt/sdcard0/48000.flac------------------------>0
[musicplay.c|1207]----------------->g_load_tid:3
receive cmd: pause
no power connected!
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system poweroff
Title: Re: Xduoo x3
Post by: pamaury on February 24, 2016, 09:08:46 AM
Hi,
those are very interesting findings :) I am quite byst right now but I should try it by myself. Do you know if the update script executed as root ?
Title: Re: Xduoo x3
Post by: XVortex on February 24, 2016, 09:57:33 AM
Yes, there are all executed as root. But to dig out from Linux is not interesting.
Now I'm playing with SPL - peekpoking a GPIO's. Here is some findings:
Code: [Select]
Buttons:

47 - BTN_LOCK (0=unlock; 1=lock)
30 - BTN_POWER (1->0)
113 - BTN (1->0) BOOT_SEL0

SD card:

29 - SD1_INSERT (1->0)
28 - SD2_INSERT (1->0)

Other:

44 - LINEOUT_DETECT (1->0)
43 - HEADPHONE_DETECT (1->0) (?)
48 - MUTE_RELAY
Title: Re: Xduoo x3
Post by: XVortex on February 27, 2016, 05:27:24 AM
First steps on real device:
(http://s019.radikal.ru/i643/1602/96/4bd6ca476d46t.jpg) (http://s019.radikal.ru/i643/1602/96/4bd6ca476d46.png)
Title: Re: Xduoo x3
Post by: johny5 on February 27, 2016, 07:40:30 AM
OMG, First steps to rockbox on xduoo x3, I'm so happy with this :)
Title: Re: Xduoo x3
Post by: spudtater on February 27, 2016, 07:54:20 AM
Bravo! Your recent progress is very heartening. Wish I had the skills to help. Keep at it, cannot wait to have Rockbox of this fine little player.
Title: Re: Xduoo x3
Post by: markkkun on February 28, 2016, 05:02:48 PM
Good news and congratulations for the job.
Title: Re: Xduoo x3
Post by: Skeelsie on March 10, 2016, 02:33:26 PM
I have nothing technical to add but if you need hardware resources to aid this port please ask.

Thanks for your dedication to the cause, really great to see the progression!

This player has some great raw attributes but is let down by shocking software, I'd go as far as saying stock Sansa Fuse+ software is better than Xduoo's offering, a collaborative effort would benefit both sides so much especially the pitch issue.
Title: Re: Xduoo x3
Post by: 5evir on March 16, 2016, 04:30:10 PM
Quite sure you have probably looked over the datasheet for the cirrus logic cs4398, but figured it might help having it on the wiki. http://alsa-project.org/~james/datasheets/www.cirrus.com/en/pubs/proDatasheet/CS4398-2.pdf
Title: Re: Xduoo x3
Post by: XVortex on March 17, 2016, 06:26:17 AM
Yes. Thanks. The first public beta of the Rockbox for X3 will be released very soon.
Title: Re: Xduoo x3
Post by: Kokos on March 19, 2016, 12:18:26 PM
I will just leave it here: http://xvtx.ru/rockbox
Title: Re: Xduoo x3
Post by: saratoga on March 19, 2016, 12:39:05 PM
If you're going to link binaries, you should also provide the source code (ideally on the same page).  Otherwise it is very hard for other people to contribute. 
Title: Re: Xduoo x3
Post by: Kokos on March 20, 2016, 01:23:55 AM
I'm sure Vortex is arranging this via Bitbucket. :-)
Title: Re: Xduoo x3
Post by: wodz on March 20, 2016, 02:18:38 AM
I really appreciate the hard work on the port but forcing me to create account on bitbucket just to see the sources is impolite really.
Title: Re: Xduoo x3
Post by: svyr on March 20, 2016, 02:58:20 AM
I really appreciate the hard work on the port but forcing me to create account on bitbucket just to see the sources is impolite really.

at the moment the repo there is private but you can request access and the man page indicates XVertex will make it public soon enough

@XVertex, can we please have a build incorporating the SD card changes here (although i'm not sure they're applicable to x3)
http://git.rockbox.org/?p=rockbox.git;a=commit;h=a24abd2a4769b9217a584c46a0c23e26e1efe467
http://git.rockbox.org/?p=rockbox.git;a=shortlog (I'm not sure about the specific commits but Michael indicated these can help random track skipping mid song that I experience on X3 and clip+)

ps amazing work indeed.

Title: Re: Xduoo x3
Post by: pamaury on March 20, 2016, 07:25:04 AM
Hi,
I am sorry to insist but this is really quite impolite: you are using our source code, our logo, you are even accepting donations for yourself and distributing binaries, the least you could do is to make the source publicly available for download without having to request access or to create account on another website.
Title: Re: Xduoo x3
Post by: Kokos on March 20, 2016, 07:42:34 AM
Give him some time, as said we are pretty sure it's being arranged, so please calm down a wait a little.
Title: Re: Xduoo x3
Post by: Skeelsie on March 21, 2016, 11:55:48 AM
This is really cool. Very appreciative, there's always a but though...

Anyone else getting a lot of hiss/white noise on high res flac files? Tried adjusting the oversampling but no change, all other formats seem great.
Title: Re: Xduoo x3
Post by: XVortex on March 28, 2016, 12:11:58 AM
xDuoo X3 Rockbox source code has been released on Github (https://github.com/xvortex/rockbox).
I'll be glad if you join to improve the project.
Title: Re: Xduoo x3
Post by: saratoga on March 28, 2016, 11:01:13 AM
xDuoo X3 Rockbox source code has been released on Github (https://github.com/xvortex/rockbox).

Code quality looks excellent, but someone familiar with the JZ should review.

Also, the copyright notices should be your real/legal name, not your screen name. 
Title: Re: Xduoo x3
Post by: XVortex on March 28, 2016, 11:33:48 AM
Thanks. Nevertheless port still has some USB-stack issues and unfinished NAND ops.
Everything else works. A successful public launch this confirms.
Title: Re: Xduoo x3
Post by: uri92 on March 31, 2016, 06:51:25 AM
Thanks. Nevertheless port still has some USB-stack issues and unfinished NAND ops.
Everything else works. A successful public launch this confirms.

Hello,

Is it stable? Will it support Rockbox Utility? I currently have a Sansa Clip+ which I'd like to replace with something better with Rockbox, thinking about the Xduoo X3. If everything works as it should, I'll get it.
Title: Re: Xduoo x3
Post by: krachyon on April 03, 2016, 04:57:07 AM
Thanks. Nevertheless port still has some USB-stack issues and unfinished NAND ops.
Everything else works. A successful public launch this confirms.

Hi,
first off all, a big "thank you" for the port!

I installed the most recent version (7658c23-160321) and it worked very well for the most part. Some minor issues tough:
- There is about a 3 second delay between selecting a file and playback starting
- When using a 128 GB micro SD formatted to FAT32 things go a little bit off the hook:
I put about 80GB of music and the system folder on the card. The system boots and does not seem to misbehave. When trying to build the library, the system first panicked ("Stkov dircache"), on the second attempt a library was built but it contained only a single Artist. After a few attempts it successfully built the library, even tough navigation was rather sluggish (~2sec delay for selecting an entry)
Trying to play songs either from the folder-view or the library instantly skips about 90% of selected songs, only a few are playable.
This behaviour does not seem to change when the system is booted from a 32GB card in the first slot and the 128 GB card is inserted into the second.

Is the issue with 128 GB cards expected for this built? Any more information I could provide to help diagnose this further?

Edit April 03, 2016, 07:41:58: Just tried the same SD-card on a Sansa Clip Zip running Rockbox 3.13 and varying the partiton size. No change in the behaviour of Rockbox on xduoo, the clip zip has no issues tough. Also the stock firmware of the xduoo can read/play the files

Edit April 05: Regarding the issue with non-playable songs: I was jumping to conclusions regarding the memory card being at fault, this only happens (reliably) for ogg-files, no matter the medium. Mostly it will just skip them but for a particular speex-encoded file it panics with LTB refill handler at 0x83E045F4 [0x0]. mp3, aac, opus and wma work fine.
Title: Re: Xduoo x3
Post by: MandoBear on April 18, 2016, 06:30:19 AM
Please forgive my lack of understanding, but what happens now with XVortex's ROCKbox port - how does it become "officially" adopted by ROCKbox?
Title: Re: Xduoo x3
Post by: staeff on April 24, 2016, 09:02:05 AM
It looks good. Already. This was definitely worth a donation.

I noticed the start-play-delay , but I think that's hard too overlook.

Does the X3 hardware support USB Connections, or can it just charge? (Transfer also didn't work with the original firmware)
Title: Re: Xduoo x3
Post by: Kokos on April 25, 2016, 11:32:12 PM
Hi guys,

I'm not hurrying anyone, I'd just like to know how much work left.. Do you know how much time it can take until this port will be released for typical users and it will have stable status on wiki page?

Thank you!
K
Title: Re: Xduoo x3
Post by: Kokos on April 26, 2016, 03:29:46 AM
You are right, just switched to RB. It's works very well and in case of problem we can boot to original soft any time. I hope RSS will be available for soft updates so I could be notified. Definitely will donate after using some time.

K
Title: Re: Xduoo x3
Post by: Kokos on May 11, 2016, 02:57:51 AM
Hi guys,

I'm putting this here for visibility. I've raised some issues and proposals for enhancement here: https://github.com/xvortex/rockbox/issues

Also I can see sometimes I can access SD card while device is charging via USB and sometimes not.. This is quite strange, I will keep eye on it.

K
Title: Re: Xduoo x3
Post by: squonk on May 11, 2016, 08:32:36 AM
@XVortex,
Noob here. I just downloaded update-to-rockbox-d312ba8M-160316.zip and changed the name to update.zip.
I am stuck in boot screen saying
"Loading firmware...
Error: File not found"
Any help would be appreciated. Thanks.

You must have the SD card formatted with FAT32 and with 4096 (4KB) cluster, not important what is the SD capacity.
Title: Re: Xduoo x3
Post by: zinm on May 11, 2016, 08:42:29 AM
@XVortex,
Noob here. I just downloaded update-to-rockbox-d312ba8M-160316.zip and changed the name to update.zip.
I am stuck in boot screen saying
"Loading firmware...
Error: File not found"
Any help would be appreciated. Thanks.

You must have the SD card formatted with FAT32 and with 4096 (4KB) cluster, not important what is the SD capacity.

Thanks for the reply. Which format should I change to? Right now it stuck in error screen.
Title: Re: Xduoo x3
Post by: squonk on May 11, 2016, 08:57:59 AM
You must have the SD card formatted with FAT32 and with 4096 (4KB) cluster, not important what is the SD capacity.

Thanks for the reply. Which format should I change to? Right now it stuck in error screen.

What do you mean? Use a tool to format the SD card (I used succesfully the free AOMEI Partition Assistant Standard Edition 6.0) as I posted before...
Title: Re: Xduoo x3
Post by: Serenity on May 11, 2016, 09:14:34 PM
Bought one of these just because of this port! Rockbox runs very well on it, and it's SO good to have it on a nicer player again (my ailing iRiver H320 is unhappy these days).

I have run into a panic! error a few times where the player will freeze until I can reset it. It usually happens a few seconds after boot when I try pressing a button or two. It may have something to do with having recently connected via USB (under the OFW) to manage files. Once I reset, though, it behaves.

Thank you Vortex and everyone else who helped make this possible.
Title: Re: Xduoo x3
Post by: Serenity on May 19, 2016, 07:47:27 PM
Kokos, I think you're right--I set my player to boot into the WPS and have had no issues, probably because I don't try navigating the menu so soon on boot.

I have run into the issue where Ogg files won't play, though. This is less than ideal, since over half my music is Ogg Vorbis.  :-\  I'm going to try stripping the comments from a few and see if that helps. There's OFW for that I suppose, but compared to Rockbox, the OFW is very limited.
Title: Re: Xduoo x3
Post by: Kokos on May 23, 2016, 01:56:51 AM
I'm putting this here for visibility. I've raised some issues and proposals for enhancement here: https://github.com/xvortex/rockbox/issues
I'm still not sure developer can see these requests, whether this is right place to submit them.
Title: Re: Xduoo x3
Post by: Serenity on May 25, 2016, 11:15:47 PM
I'm assuming since this isn't an official Rockbox port (yet), xVortex is simply making his own port available for others to use/modify/review. If he doesn't use Ogg Vorbis, pause on headphone plug out, etc., it's likely he's not interested in troubleshooting these issues.

It is possible to contact him via his website, but he does refer Rockbox support questions to the Head-Fi forum devoted to the port. If I get sassy (or drunk) I may contact him and ask, but for now I'm just happy the X3 runs Rockbox.
Title: Re: Xduoo x3
Post by: Tacoboy on July 20, 2016, 08:58:42 PM
Does Rockbox currently work well with the Xduoo X3.
As I'm thinking of getting the Xduoo X3 (Rockboxed) as an improvement, over my Sony NWZ-E464 player.
Title: Re: Xduoo x3
Post by: Serenity on July 27, 2016, 07:47:16 PM
That depends on how forgiving your definition of "well" is. The Xduoo X3 is responsive, sounds great, and has very few issues running Rockbox.

The only two real bugs I've run into consistently are lack of Ogg Vorbis support (the X3 skips any .ogg files) and the "stkov dircache" panic error. If you don't use Ogg Vorbis for your music, then no problem there. And the panic error doesn't seem to happen often (usually when I try navigate the menu immediately on boot). All I have to do is let the X3 boot and leave it alone for five or ten seconds, then it's fine.

Another note: Use a card reader or boot into OFW to transfer music to the device. USB connectivity is a little strange with Rockbox. I use a card reader anyway, just for the speed boost.

If you can live with these bugs, then grab an X3. Even with the bugs, Rockbox is so much better than the original firmware.
Title: Re: Xduoo x3
Post by: Doghouse Riley on September 01, 2016, 06:49:02 AM
For those of you you are using a Rockboxed Xduoo, what is the largest capacity SDXC card you've used successfully?
Title: Re: Xduoo x3
Post by: squonk on September 01, 2016, 10:54:25 AM
For those of you you are using a Rockboxed Xduoo, what is the largest capacity SDXC card you've used successfully?

Now I use a 128Gb in slot 1 and a 64Gb in slot 2.
I don't think there is any problem with two 128Gb cards in both slot: many user on head-fi report that this is possible.
I don't know about larger microSd...
Title: Re: Xduoo x3
Post by: Ste- on September 02, 2016, 05:49:48 AM
I use 2x 128gb cards in mine no problem. I've read reports of 2x 200gb ones working.
Alas this has very little to do with Rockbox dev. so I shall run.
Title: Re: Xduoo x3
Post by: Massa on November 13, 2016, 04:29:41 PM
So what's the state of this port?

Are the source changes (re)integrated in the main rockbox repository?

Or are the source changes for the xduoo device only available at xvortex repository fork at github?
That would it make harder to reintegrate it to the "normal" rockbox repo because xvortex' changes are more than five months old...  :(

Is any dev with commit access here in contact with xvortex to reintegrate the changes?
Title: Re: Xduoo x3
Post by: gregsoir on November 29, 2016, 06:47:31 AM
So what's the state of this port?

Are the source changes (re)integrated in the main rockbox repository?

Or are the source changes for the xduoo device only available at xvortex repository fork at github?
That would it make harder to reintegrate it to the "normal" rockbox repo because xvortex' changes are more than five months old...  :(

Is any dev with commit access here in contact with xvortex to reintegrate the changes?
maybe try to mail the developer?
http://xvtx.ru/rockbox/contact.htm
Title: Re: Xduoo x3
Post by: woodnut on June 27, 2017, 05:44:24 AM
Hello folks,

I just purchased an Xduoo X3 and have successfully installed rockbox on the player as I really like this firmware on my old Sansa Clip+.

However there is a strange behaviour when moving down through the menus using the > arrow. The menus get automatically selected like I have pressed the play / select button. It happens fairly often so I have taken to just using the < arrrow to move upwards through the menus as it doesn't happen when I do that.

I booted into the stock firmware and this doesn't appear to happen in the stock firmware. Perhaps this is just a coincidence though and the cause is a problem with a dodgy play button that is too sensitive and is essentially getting randomly triggered for some reason when I use the > button.

Perhaps I got a defective unit?

Any thoughts or help would be greatly appreicated!

Cheers in advance.
Title: Re: Xduoo x3
Post by: rdtyphn on August 02, 2017, 07:32:35 PM
Hello folks,

I just purchased an Xduoo X3 and have successfully installed rockbox on the player as I really like this firmware on my old Sansa Clip+.

However there is a strange behaviour when moving down through the menus using the > arrow. The menus get automatically selected like I have pressed the play / select button. It happens fairly often so I have taken to just using the < arrrow to move upwards through the menus as it doesn't happen when I do that.

I booted into the stock firmware and this doesn't appear to happen in the stock firmware. Perhaps this is just a coincidence though and the cause is a problem with a dodgy play button that is too sensitive and is essentially getting randomly triggered for some reason when I use the > button.

Perhaps I got a defective unit?

Any thoughts or help would be greatly appreicated!

Cheers in advance.
This also happens to me occasionally. It's hard to determine what brings it about and for a while I thought the new version of the firmware solved the problem.
It'd probably be better to post this on the headfi page as the maintainer of the firmware seems to read it https://www.head-fi.org/threads/rockbox-xduoo-x3.803844/page-123
Thanks
Title: Re: Xduoo x3
Post by: speachy on June 27, 2018, 05:54:00 PM
I don't know if anyone cares or not, but I just rebased the seemingly-abandoned xvortex rockbox tree against master, cleaned up the commits a little bit, and ported the X3's sdcard driver to the new thread-free sdcard API.

This tree encompasses xvortex's unofficial ports for the xDuoo X3 (mipsel jz4760), as well as the Xuelin iHIFI 770, 770C, and 800 (arm rk27xx).  I don't have any of the hardware, so I have no way of actually testing this beyond basic compilation.  Anyone out there have one or more of these devices, and willing to be a guinea pig?

(It would be nice to get this merged into master; no sense in letting it bitrot and it's always nice to have targets that are still commercially relevant...)

Title: Re: Xduoo x3
Post by: __builtin on June 27, 2018, 08:08:01 PM
I don't think the author has given a real name to attribute his or her code to, and as such, we can't merge it yet.
Title: Re: Xduoo x3
Post by: saratoga on June 27, 2018, 09:50:50 PM
Should ask him for his name and add him to the credits. 
Title: Re: Xduoo x3
Post by: speachy on June 28, 2018, 05:42:52 AM
Should ask him for his name and add him to the credits. 

Email sent.  I guess we'll see if anything comes back..

Assuming that "vortex" supplies an attributable name, what's next?   Push the commits to gerrit for review?  (I'm assuming they'll need some further work, and I'm willing to do it..)
Title: Re: Xduoo x3
Post by: speachy on June 28, 2018, 06:14:28 AM
Email sent.  I guess we'll see if anything comes back..

I now have the author's real name, and his blessing to get this stuff mainlined.

How should I proceed?
Title: Re: Xduoo x3
Post by: wodz on June 28, 2018, 09:02:32 AM
Push to gerrit for review. However without device to test I don't think it is worth the hassle.
Title: Re: Xduoo x3
Post by: speachy on June 28, 2018, 10:24:49 AM
Push to gerrit for review. However without device to test I don't think it is worth the hassle.

For some time, I've wanted to meaningfully contribute something back to rockbox, and this seemed like a relatively simple way to get familiar with rockbox's codebase -- and one that will yield both immediately useful results and provide a stepping stone to other ports.

I'm no stranger to working with bare-metal embedded code, low-level OS tinkering, and writing device drivers after reverse-engineering efforts, so this sort of stuff is right up my alley.

I have a few more things to clean up and then I'll push the commits to gerrit so they can be bled on.
Title: Re: Xduoo x3
Post by: speachy on June 29, 2018, 05:57:47 AM
The patches are now in gerrit:

http://gerrit.rockbox.org/r/1854
http://gerrit.rockbox.org/r/1855

Should I add anyone specifically to do reviews?
Title: Re: Xduoo x3
Post by: wodz on June 29, 2018, 07:32:57 AM
For 1885 I can review the patch. For 1854 I think me (wodz) and pamaury.
Title: Re: Xduoo x3
Post by: wodz on June 29, 2018, 08:55:30 AM
I commented on gerrit.
Title: Re: Xduoo x3
Post by: mai0f on July 07, 2018, 06:21:41 PM
The patches are now in gerrit:

http://gerrit.rockbox.org/r/1854
http://gerrit.rockbox.org/r/1855

Should I add anyone specifically to do reviews?

If I understand correctly, these are updates to the 170609? If so, I'd be interested in testing it out. Please let me know what i need to do.
Thank you,
- m
Title: Re: Xduoo x3
Post by: saratoga on July 08, 2018, 01:36:50 PM
Those are patches that merge the source code into the rockbox tree.  No idea if this is even safe to try on a real device, but here is a binary for the x3:

http://mit.edu/mgg6/www/rockbox-x3.zip

Compiled using:

http://gerrit.rockbox.org/r/#/c/1747/
http://gerrit.rockbox.org/r/1854
Title: Re: Xduoo x3
Post by: speachy on July 19, 2018, 06:38:55 AM
Looks like the X3 has been succeeded:

https://www.xtenik.com/xduoo-x3-ii-lossless-music-player/

2.4" color screen, different DACs, bluetooth, and somewhat saner button layout.

(...I have a strong suspicion that this is another hibi_player-on-Linux device..)
Title: Re: Xduoo x3
Post by: gomezz on July 19, 2018, 12:16:04 PM
The claim of playback time being improved to more than 13 hours is the number that most interests me as that would mean being to able to use it for a whole work shift without recharging.
Title: Re: Xduoo x3
Post by: Ste- on July 25, 2018, 04:50:20 AM
Those are patches that merge the source code into the rockbox tree.  No idea if this is even safe to try on a real device, but here is a binary for the x3:

http://mit.edu/mgg6/www/rockbox-x3.zip

Compiled using:

http://gerrit.rockbox.org/r/#/c/1747/
http://gerrit.rockbox.org/r/1854

Tried your build and got an error.

*PANIC*
exception occured:
Reserved Instructi
on [0Xfffffff] at
0x800e0da8 (stack a
t 0x8000391c)
Title: Re: Xduoo x3
Post by: speachy on July 27, 2018, 01:53:11 PM

Tried your build and got an error.

*PANIC*
exception occured:
Reserved Instructi
on [0Xfffffff] at
0x800e0da8 (stack a
t 0x8000391c)

Well, crap, that was unexpected.

If I'm reading this correctly, it's trying to execute an instruction from an address within the scroll stack.  That doesn't sound right.

I just generated a new build, this time with full debug, from the current git HEAD plus the two commits that saratoga referenced.  Please let me know how this goes; I'll be better able to dig into whatever goes wrong with this one.

  http://www.shaftnet.org/~pizza/rockbox-x3-gf39149e834.zip

Title: Re: Xduoo x3
Post by: Ste- on August 06, 2018, 11:28:10 AM
*PANIC*
Exception occured:
Reserved Instructi
on [0xfffffffff] at
0x800e5b08 (stack a
t 0x8000391c)
no logf data
Title: Re: Xduoo x3
Post by: pm215 on August 19, 2018, 05:01:03 AM
Hi; I was looking at the code that's now been merged into rockbox master and trying to see how it lines up with the version that's downloadable from the xvtx.ru site. There seem to be some differences, so are we still missing some parts? In particular, the xvtx.ru rockbox.bin that you flash into the NAND starts with the expected 0xaaaaaaaa/0x55555555 headers that the JZ4760 requires to be able to do an initial boot-from-NAND, whereas the rockbox.x3 in the zipfile that pizza provided for download doesn't. I also can't find anything in either the rockbox-merged code or the https://github.com/xvortex/rockbox repo that's implementing the "if hold switch is in hold position, chainload the original firmware rather than booting rockbox" feature, which should be happening in the very-early-boot phase.

I'm probably missing something obvious here -- if somebody could point me in the right direction it would be appreciated.

(I'm playing about with writing a QEMU model for the XDuoo-X3, because it seemed like it might be a helpful debug tool. This would be easier if I had the sources corresponding to the binary I'm trying to get it to run :-)   I have the hardware and it runs the xvortex install fine, but it would be nice to be able to move to upstream at some point.)
Title: Re: Xduoo x3
Post by: speachy on August 19, 2018, 07:52:34 AM
The "rockbox.x3" image is chain-loaded by the bootloader, and is intended to be loaded into (and executed from) RAM.  The bootloader is a separate compilation target that is intended to be executed directly from flash by the SoC.

The code in bootloader/xduuox3.c doesn't seem to do any button checking/manipulation -- including USB mode and optional verbose output that is typically present.  It appears as if there is no dualboot support for the X3 anywhere in the xvortex sources. Most targets put their dualboot support under rbutil/, as part of the original firmware patching functionality.

The x3's bootloader build (bootloader-x3.bin) doesn't prepend the 64 bytes of AAAA/5555 headers either.  That is easily rectified, but I'm not sure I'd trust flashing the resulting image.
Title: Re: Xduoo x3
Post by: pm215 on August 19, 2018, 08:30:21 AM
Ah, that makes sense. So the xvortex "rockbox.bin" that goes into the NAND is actually the bootloader, and rockbox proper lives on the SD card. Looking at rockbox.bin with "strings" it seems like it's a combination of (a) an "SPL Stage 1" part that does some basic setup and figures out whether it's booting rockbox or the stock firmware (b) the "SPL Stage 2" rockbox bootloader from bootloader/xduoox3.c (c) a complete copy of u-boot for booting the stock firmware. If we're missing the sources for the most recent bootloader perhaps we could ask the original author for them?

Is there documentation for what the boot protocol for loading and starting rockbox.x3 is (where it needs to be loaded, CPU state, etc)? I might skip ahead from trying to get QEMU to be able to run the bootloader (which turns out to be painful because it expects to be able to execute directly out of dcache/icache and write to the SDRAM via the equivalent uncached address without overwriting itself, and QEMU doesn't emulate caches...)
Title: Re: Xduoo x3
Post by: wodz on August 20, 2018, 04:41:04 AM
Is there documentation for what the boot protocol for loading and starting rockbox.x3 is (where it needs to be loaded, CPU state, etc)? I might skip ahead from trying to get QEMU to be able to run the bootloader (which turns out to be painful because it expects to be able to execute directly out of dcache/icache and write to the SDRAM via the equivalent uncached address without overwriting itself, and QEMU doesn't emulate caches...)

You mean main rockbox binary? It is copied to ram @0x80000000 (KSEG0). First 16k (0x80000000 - 0x80003fff) is used for IRAM section which contains also iterrupt vectors. Consult https://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/target/mips/ingenic_jz47xx/app.lds;h=85c332b1820fd6421bfe0b9236bff3e63af5872f;hb=HEAD for details.

I think I know why X3 merged in rockbox crashes but I don't have device to test. If you want to help we may arrange IRC debug session.

Besides writing support for new SOC in qemu is huge task. I started such work for ATJ213x https://github.com/wodz/qemu-atj. Never finished but maybe one day I'll come back to this as writing emulator is fun.
Title: Re: Xduoo x3
Post by: speachy on August 20, 2018, 10:02:35 AM
I think I know why X3 merged in rockbox crashes but I don't have device to test. If you want to help we may arrange IRC debug session.

I just managed to snag a second-hand unit via eBay for half the price of a new unit.  Should be delivered before the end of the week.
Title: Re: Xduoo x3
Post by: pm215 on August 20, 2018, 02:11:26 PM
You mean main rockbox binary? It is copied to ram @0x80000000 (KSEG0). First 16k (0x80000000 - 0x80003fff) is used for IRAM section which contains also iterrupt vectors. Consult https://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/target/mips/ingenic_jz47xx/app.lds;h=85c332b1820fd6421bfe0b9236bff3e63af5872f;hb=HEAD for details.
Thanks. (I have a fair amount of experience with writing QEMU device/SoC emulation; I agree it's not a small task, but if you can live with not having complete coverage of functionality it's not too insurmountable. My prototype can currently boot SPL1 up to the point where it wants to load SPL2 off the NAND, which isn't bad for a couple of days' work. The datasheets are pretty good too as SoC datasheets go, though I haven't been able to find a spec for the JZ4760B-only extensions that aren't in the 4760.)

I just managed to snag a second-hand unit via eBay for half the price of a new unit.  Should be delivered before the end of the week.

I got mine cheap off eBay too -- it turned out to be new-old-stock so the version with the less-capacious battery, and also one of the internal screws holding the circuit board down was rattling around loose inside the case. It works fine now I've removed the loose screw, though :-)
Title: Re: Xduoo x3
Post by: wodz on August 21, 2018, 01:38:36 AM
Thanks. (I have a fair amount of experience with writing QEMU device/SoC emulation; I agree it's not a small task, but if you can live with not having complete coverage of functionality it's not too insurmountable. My prototype can currently boot SPL1 up to the point where it wants to load SPL2 off the NAND, which isn't bad for a couple of days' work. The datasheets are pretty good too as SoC datasheets go, though I haven't been able to find a spec for the JZ4760B-only extensions that aren't in the 4760.)

Would you mind publishing jz4760 qemu sources somewhere so I can have a look?
Title: Re: Xduoo x3
Post by: speachy on August 23, 2018, 05:05:13 AM
I just managed to snag a second-hand unit via eBay for half the price of a new unit.  Should be delivered before the end of the week.

It arrived.  I dropped in the last xvortex build to prove everything worked.  Tonight (or more likely, sometime over the weekend) I'll be able to start prodding.
Title: Re: Xduoo x3
Post by: speachy on August 23, 2018, 12:09:28 PM
It arrived.  I dropped in the last xvortex build to prove everything worked.  Tonight (or more likely, sometime over the weekend) I'll be able to start prodding.

During my lunch break, recreated the original panic with current rockbox master.  Just as a sanity check, I recompiled the pristine vortex sources, and that also blew up:

*PANIC*
TLB refill handler
at  0x800712A4!
[0x4]

This was with the GCC 4.9 toolchain from master, not the ancient GCC 4.1.2  that vortex was using.  Still need to rebuild that older toolchain to make sure the original sources are indeed complete/functional.
Title: Re: Xduoo x3
Post by: wodz on August 23, 2018, 04:15:08 PM
Newer compiler exposes bug in mips threading code. Thats why vortex's sources compiled with 4.9 crash. I fixed this bug in rockbox but I am almost sure something during agptek merge broke it again.
Title: Re: Xduoo x3
Post by: pm215 on August 25, 2018, 05:56:36 PM
Would you mind publishing jz4760 qemu sources somewhere so I can have a look?
https://github.com/pm215/qemu.git xduoo  (watch out, that branch will rebase in future).
That has enough to be able to get through SPL1 and into where SPL2 tries to talk to the SD card. There's some sd-controller code in there but it's half-finished. README.XDUOO gives a command line and how to sort out the various data files it wants.

If anybody knows the relation between the "rockbox.bin" bootloader file in the xvtx.ru installer and what actually ends up on the NAND that would be interesting. (I think "nprog" must be doing some equivalent of relocating segments of the .bin file into different parts of the first NAND partition.)
Title: Re: Xduoo x3
Post by: speachy on August 26, 2018, 10:54:28 AM
Newer compiler exposes bug in mips threading code. Thats why vortex's sources compiled with 4.9 crash. I fixed this bug in rockbox but I am almost sure something during agptek merge broke it again.

http://gerrit.rockbox.org/r/#/c/1905/

Lifted from the Fiio X1 WIP code.  It boots, but success was short-lived.  When attempting to play:

*PANIC*
Stkov codec

Work-in-progress, eh?  :)


Title: Re: Xduoo x3
Post by: wodz on August 26, 2018, 02:37:01 PM
http://gerrit.rockbox.org/r/#/c/1905/

Lifted from the Fiio X1 WIP code.  It boots, but success was short-lived.  When attempting to play:

*PANIC*
Stkov codec

Work-in-progress, eh?  :)

codec stack overflow - pretty easy to fix. Just increase codec stack size definition and check if that helps.
Title: Re: Xduoo x3
Post by: speachy on August 26, 2018, 04:48:12 PM
codec stack overflow - pretty easy to fix. Just increase codec stack size definition and check if that helps.

I bumped it from its default 9KB (ie 1KB "default" + 8KB codec) to a combined total of 24KB, and it's now playing music.  Working my way back down to find the threshold.  (EDIT:  10KB is too small, 11KB is okay)

Unfortunately, it's not able to sustain realtime playback, pausing for about 1 second roughly every 5 seconds on a 320KB mp3.  The entire player goes unresponsive during these pauses.

I'll keep poking at it next time I take a break from household cleaning.

EDIT:  Dropping the updated mips thread code onto the original vortex tree allows it to work, with realtime playback and a responsive UI.
EDIT2:  Just after I wrote said that, the player hung in the fft plugin, requiring a hard reset.
Title: Re: Xduoo x3
Post by: speachy on August 29, 2018, 10:25:28 AM
Unfortunately, it's not able to sustain realtime playback, pausing for about 1 second roughly every 5 seconds on a 320KB mp3.  The entire player goes unresponsive during these pauses.

From what I can tell, the inability to do realtime playback is due due to _very_ poor SD read speeds..

(Looking at the buffering thread debug output, it seems to take about ~1s to fill ~180KB of buffer data, even when starting a new track..)

Title: Re: Xduoo x3
Post by: saratoga on August 29, 2018, 02:19:35 PM
Could try some video game music.  NES or SNES files are a few kilobytes :)
Title: Re: Xduoo x3
Post by: speachy on August 29, 2018, 02:46:52 PM
Could try some video game music.  NES or SNES files are a few kilobytes :)

I tossed a couple of 25-year-old protracker .MODs on the X3, and it's puttering along with no effort whatsoever.  Granted, that's a lot less CPU-intensive than decoding mp3s, but it supports the theory that the SD driver is the culprit.

The X3's jz4760's SD code was something I substantially altered from the vortex sources when forward-porting to rockbox mainline -- necessary due to the SD/storage thread rework that landed a while back -- but the result was nearly identical to the jz4740 SD driver, with the differences due to the '60 having two SD controllers & slots.  Consequently, I suspect that the Onda VX7x7 and other '40 targets also share this SD problem.
Title: Re: Xduoo x3
Post by: speachy on August 30, 2018, 08:28:38 AM
Still poking.  Found out we're driving the SD peripheral off the wrong clock source and likely using the MAX divider too.  Fixing that seemed to improve things marginally.  Heavily updated the debug menu.  Accumulating a small pile of minor fixes things here and there that should be safe to apply..

Another data point is that the player can barely manage slightly better than realtime playback if we're on the final track of a folder (with repeat off).

It could still be the threading code isn't sane; taking to long to context switch or schedule, or perhaps not managing cache invalidation sanely.

(It would be really nice if we had someone with one of the jz7440 targets that could provide additional data points...)

Title: Re: Xduoo x3
Post by: speachy on September 01, 2018, 10:01:51 PM
Okay, found the culprit.  Part of the AGPTek Rocker merge was a change that disabled compiler optimizations for libmad, thus trashing mp3 decoding performance (and smashing its stack!)
 flac, wmv, m4a worked fine.  (vorbis is being stupid, but I'll get to that later..)

I have a series of patches in gerrit now, awaiting review and merging.   Two are essential,:

  http://gerrit.rockbox.org/r/1905
  http://gerrit.rockbox.org/r/1907   (EDIT:  #1907 has been committed)

but I think all of the patches in that series are worth applying.  I think that this fix from the X1 series is also advised:

  http://gerrit.rockbox.org/r/#/c/1797/

Gerrit won't let me add any reviewers, and I have no commit rights, so this is all I can do.
Title: Re: Xduoo x3
Post by: wodz on September 03, 2018, 06:03:36 AM
Threading error fixed in #1905 was spotted by me but who cares :-) Anyway I lost ability to merge patches from gerrit :-/
Title: Re: Xduoo x3
Post by: Dulus_No on September 04, 2018, 12:02:00 AM
xDuoo X3-II got a Rockbox port: https://vk.com/wall-85070453_8323
Title: Re: Xduoo x3
Post by: wodz on September 04, 2018, 02:08:39 AM
Pretty frustrating they didn't bother to contact rockbox team in any way.
Title: Re: Xduoo x3
Post by: wodz on September 04, 2018, 02:16:56 AM
If anybody knows the relation between the "rockbox.bin" bootloader file in the xvtx.ru installer and what actually ends up on the NAND that would be interesting. (I think "nprog" must be doing some equivalent of relocating segments of the .bin file into different parts of the first NAND partition.)

Here is reply from xvotex regarding bootloader update image:

Quote
Hi.

You're right, X3 boot combined from header, SPL1, rockbox bootloader and uBoot.
This was done manually in a binary editor and a very long time ago.
Unfortunately, I did not have any information on this except what already in repo. sorry.

Regards,
Roman.
Title: Re: Xduoo x3
Post by: speachy on September 05, 2018, 10:43:47 AM
(vorbis is being stupid, but I'll get to that later..)

The failure is in the ogg frame checksum code -- and the underlying cause is due to the mips asm memset() routine being defective.

Threading error fixed in #1905 was spotted by me but who cares :-) Anyway I lost ability to merge patches from gerrit :-/

I'm not trying to claim credit for code that's not mine.. but someone has to do the work to get things merged...
Title: Re: Xduoo x3
Post by: wodz on September 05, 2018, 02:45:26 PM
The failure is in the ogg frame checksum code -- and the underlying cause is due to the mips asm memset() routine being defective.

That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).
Title: Re: Xduoo x3
Post by: speachy on September 05, 2018, 03:07:25 PM
That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).

Be that as it may, the empirical evidence points to memset() not working properly.  Disabling the asm memset() allows the vorbis code to work.

(It's setting a 4 byte unaligned buffer to 0 before running a checksum algorithm)
Title: Re: Xduoo x3
Post by: wodz on September 06, 2018, 04:57:41 AM
That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).

Be that as it may, the empirical evidence points to memset() not working properly.  Disabling the asm memset() allows the vorbis code to work.

(It's setting a 4 byte unaligned buffer to 0 before running a checksum algorithm)


Could you pop up on IRC for live discussion?
Title: Re: Xduoo x3
Post by: speachy on September 10, 2018, 01:17:31 PM
Could you pop up on IRC for live discussion?

Just as a heads-up for the lurkers -- wodz fixed a bug in the mips memset() code, and also merged the threading fixes, so it is now possible to build a working Xduoo X3 rockbox image from git master.

(As I've been putting this thing through daily-use paces, I've accumulated a growing pile of additional improvements that IMO are worth merging.  Ah, progress..)
Title: Re: Xduoo x3
Post by: wodz on September 10, 2018, 03:11:16 PM
From my POV the main blocker now is the lack of SPL1 code vortex used to prepare bootloader install package. I disassembled this binary and it looks very similar to https://github.com/ingenic-src-android/xboot/blob/jz-4780-4775-common/spl/ so maybe we can cleanly recreate it. Interestingly SPL1 in vortex's package is different to anything I could grab from xduoo site.

I've accumulated a growing pile of additional improvements that IMO are worth merging.  Ah, progress..)

Do not do that. Put small changes in gerrit (or commit directly if you are brave). You can always abandon patch/revert commit. Big pile of changes is a pain to merge and even bigger to debug later if some bug surfaces.
Title: Re: Xduoo x3
Post by: speachy on September 10, 2018, 04:44:34 PM
I've accumulated a growing pile of additional improvements that IMO are worth merging.  Ah, progress..)
Do not do that. Put small changes in gerrit (or commit directly if you are brave). You can always abandon patch/revert commit. Big pile of changes is a pain to merge and even bigger to debug later if some bug surfaces.

No worries, I know to keep the individual patches as small and self-contained as possible.

(I have 15 patches staged in my tree, eight of which are already in Gerrit)
Title: Re: Xduoo x3
Post by: XVortex on September 12, 2018, 11:21:05 PM
Hi all. Finally I found it:
Here is sources/binaries/script for X3 stock+rockbox stage1: https://mega.nz/#!tlVzGAZK!8lMWGP0WEo_gnVuLLrS2q4yH2BnG2v6TNSTxeCU_LY8 (https://mega.nz/#!tlVzGAZK!8lMWGP0WEo_gnVuLLrS2q4yH2BnG2v6TNSTxeCU_LY8)
Title: Re: Xduoo x3
Post by: wodz on September 13, 2018, 04:56:34 AM
Great thanks!

I have a question however - the script simply concatenates spl1, r-boot and u-boot. In bootloader install file you provide there is definitely padding between spl1, r-boot and u-boot so r-boot starts @0x2000 and u-boot is aligned on nand blocksized offset. Since r-boot is searched @0x40000 and u-boot @0x60000 and nand blocksize is 0x20000 I think flasher puts 2 copies of spl1 @0x0 and @0x20000 (block0 and block1), rockbox bootloader is placed @0x40000 (block2) and u-boot @0x60000 (block3). Could you confirm my understanding of this?
Title: Re: Xduoo x3
Post by: XVortex on September 13, 2018, 07:39:34 AM
Yes there are couple of a spare spl areas at the begin of the flash and flasher deals with it automatically.
If you dump the NAND you will get them all. but only one (without errors) is used at boot time.
Title: Re: Xduoo x3
Post by: wodz on September 14, 2018, 08:19:40 AM
Interestingly provided spl1 code is terribly broken. gp is not initialized in startup code but is used since .sbss and .sdata sections are not empty.