Support and General Use > Hardware
Xduoo x3
gomezz:
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.
Ste-:
--- Quote from: saratoga on July 08, 2018, 02: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
--- End quote ---
Tried your build and got an error.
*PANIC*
exception occured:
Reserved Instructi
on [0Xfffffff] at
0x800e0da8 (stack a
t 0x8000391c)
speachy:
--- Quote from: Ste- on July 25, 2018, 05:50:20 AM ---
Tried your build and got an error.
*PANIC*
exception occured:
Reserved Instructi
on [0Xfffffff] at
0x800e0da8 (stack a
t 0x8000391c)
--- End quote ---
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
Ste-:
*PANIC*
Exception occured:
Reserved Instructi
on [0xfffffffff] at
0x800e5b08 (stack a
t 0x8000391c)
no logf data
pm215:
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.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version