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

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)

[speachy]

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

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

[speachy]

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.

[pm215]

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

[wodz]

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.

[speachy]

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.

[pm215]

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

[wodz]

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?

[speachy]

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.

[speachy]

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.

[wodz]

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.

[pm215]

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