Support and General Use > Hardware

Xduoo x3

<< < (17/27) > >>

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:

--- Quote from: pm215 on August 19, 2018, 09:30:21 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...)

--- End quote ---

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:

--- Quote from: wodz on August 20, 2018, 05:41:04 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.

--- End quote ---

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:

--- Quote from: wodz on August 20, 2018, 05:41:04 AM ---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.
--- End quote ---
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.)


--- Quote from: pizza on August 20, 2018, 11:02:35 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.

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version