release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Search | Go
Wiki > Main > IngenicX1000

Ingenic X1000

Overview

The X1000 is a low-cost IoT processor manufactured by Ingenic, sharing many similarities with the earlier JZ47xx series processors. The CPU is MIPS-based and clocked at 1 GHz, packaged with 32 MiB or 64 MiB of LPDDR RAM. Rockbox runs pretty stably on this platform with no reported major issues, although features like Bluetooth, WiFi, and USB DAC that are commonly available on original firmware are not currently supported under Rockbox.

The information on this page applies only to native ports of Rockbox (running directly on the hardware). There's also X1000-based hardware where Rockbox runs as a hosted port, on top of the original firmware's kernel.

Player Memory Rockbox support
AGPtEK Rocker 32M Hosted
AIGO Eros Q 32M Native, hosted
FiiO M3K 64M Native, hosted
Shanling Q1 64M Native
xDuuo X3ii 32M Hosted
xDuuo X20 32M Hosted

Using usbboot

The hardware boot ROM supports booting over USB using a simple protocol. The usbboot tool in utils/ingenic_tools implements this protocol and allows you to load Rockbox over USB, among other things. USB boot also provides a way to recover a player -- at least in theory -- if something should go horribly wrong, corrupt the bootloader or otherwise render it non-functional. (eg: due to a bug or power failure during a firmware update).

When connected in USB boot mode, an X1000-based player will show up like this in lsusb output:
Bus 001 Device 007: ID a108:1000 Ingenic Semiconductor Co.,Ltd X1000

Normally USB boot is activated by holding a certain button while powering on the player.
Player Button
FiiO M3K volume down
Shanling Q1 play
Eros Q menu

The most reliable way to do this is holding the button while the unit is off and then plugging in the USB cable -- indeed if the cable is not plugged at boot, then the USB interface might not be detected at all.

The USB boot mode is burned into the processor at an extremely low level, so it is impossible to "brick" the player in a way that renders USB boot inaccessible. If it does not work, make sure the device is powered off by holding the power button for at least 10 seconds -- on some players, there is no visible sign that the player is turned on if it happens to be stuck in USB boot mode.

usbboot can load "stage1" and "stage2" binaries (the hardware boot protocol differentiates between the two stages, but the actual difference is not clear). The SPL runs as a stage1 binary and exists solely to initialize RAM, making it available for the stage2 binary. The Rockbox app and bootloader run as a stage2 binary. usbboot has shortcuts for the common case of running the Rockbox SPL / bootloader / app to facilitate development.

To run a development build of Rockbox, for example on the FiiO M3K:
$ ./usbboot -c x1000 -1 <spl.m3k> --wait 1 -2 <rockbox.bin>

Or to run a development bootloader:
$ ./usbboot -c x1000 -1 <spl.m3k> --wait 1 -2 <bootloader.bin>

Also see usbboot --help.

Important: for the X1000, a stage1 binary is a padded SPL binary with 2 KB header. This file is generated by a bootloader build as spl.target where target is a short, target-specific file extension: m3k for the FiiO M3K, or erosq for the Eros Q. A stage2 binary must be a raw .bin image with no headers. You must use rockbox.bin / bootloader.bin as your stage2 files, not the files with a target extension.

Note: the more user-friendly jztool does pretty much the same thing as the "run a development bootloader" example above, except the SPL and bootloader binary are packed into a tarball for easy download and handling.

Known issues with Rockbox

  • Partial LCD updates are actually worse than full-frame updates because DMA can only (easily) transfer full frames, and we need to wait for the last frame to complete before sending a new one. This causes some themes to flicker as different layers are drawn in quick succession with partial updates.

  • Coalescing partial LCD updates in the driver could eliminate most flicker. Using the spare TCU timer IRQ would have less overhead & higher precision than the kernel-based timers. Coalescing would have to be bypassed during a panic, otherwise the LCD would never be updated.

  • Very rarely, the LCD driver might be causing a hang when the screen turns on after being off. This is almost certainly due to bugs in the complicated locking/synchronization design.

  • LCD's continuous DMA mode don't seem to respect the panel FPS even when the vsync signal is turned on. This appears to cause stuttering, which is why the driver uses one-shot DMA transfers.

  • Playback at 192 KHz with all DSP / EQ settings enabled puts the CPU to almost 100% usage, with frequent UI slowdown and audio underruns. Increasing the size of the PCM mix buffers may help, since there are huge numbers of DMA interrupts at this sample rate.

  • AIC fifo underruns aren't reported reliably. It's probably because the DMA interrupt is hogging the CPU so the underrun bit clears before we can see it.

  • USB doesn't operate correctly in the bootloader after a USB boot. The cable needs to be unplugged and re-plugged to make it work. This should be fixed since it could smooth bootloader installation with the Rockbox utility.

Hardware information

This section is work in progress and more information needs to be added.

Memory mapping

Start End Notes
0xf4000000 0xf4003fff tightly coupled shared memory (TCSM)
0x80000000 0x8Xffffff mapped DRAM (32M: X=1, 64M: X=3)
0xbfc00000 0xbfc03fff hardware boot ROM
0xb3050000   LCD controller register base
0xb3060000   CIM camera module register base
0xb0020000   AIC/icodec register base
0xb0071000   PCM register base
0xb34f0000   DDR controller AHB register base
0xb3012000   DDR controller APB register base
0xb3011000   DDR PHY APB register base
0xb3440000   SPI flash controller (SFC) register base
0xb0000000   CPM register base
0xb0002000   Timer/PWM unit register base
0xb2000000   OS timer register base
0xb0001000   Interrupt controller register base (NOTE: the datasheet has this one wrong)
0xb0002000   Watchdog timer register base
0xb3420000   DMA controller register base
0xb3422000 0xb3423fff TCSM of DMA controller's programmable MCU
0xb0003000   RTC register base
0xb3540000   EFUSE register base
0xb0010X00   GPIO port register base (X = 0,1,2,3 or 7)
0xb005X000   I2C controller register base (X = 0,1,2)
0xb0040000   Smart cart controller register base
0xb0043000   Synchronous serial interface register base
0xb003X000   UART register base (X = 0,1,2)
0xb34X0000   SD/MMC/CE-ATA controller register base (X = 5,6)
0xb3500000   USB controller register base

Note: you can use the usbboot tool to dump the boot ROM, TCSM, or registers using usbboot --upload and passing the relevant address.

Boot process

After a power-on reset, the CPU jumps to the boot ROM at the standard MIPS reset vector (0xbfc00000). DRAM is not accessible at this time, so the bootrom loads a small binary called the SPL (secondary program loader) into TCSM and calls it to handle DRAM initialization and continue booting, either by loading an OS kernel directly, or a more capable bootloader such as U-Boot.

Initially the bootrom sets the stack pointer to 0xf4001000, copies other r/w data into the lower 4k region of the TCSM, then polls some GPIO pins to decide how to continue.

  • GPIOB30 is used to indicate the external oscillator frequency: 1 for 26 MHz, 0 for 24 MHz.
  • GPIOB28 and GPIOB29 (aka boot_sel[0] and boot_sel[1]) determine where the bootrom looks for the SPL.
    • B29=1, B28=1 -> NAND/NOR boot
    • B29=0, B28=1 -> MSC boot
    • B29=1, B28=0 -> USB boot

For USB boot, the bootrom sets APLL frequency to EXCLK*26 (576 or 624 MHz) and the CPU and other system clocks are switched to APLL. Under a "normal" boot from storage system clocks are left running directly from EXCLK. The SPL needs to take care not to change APLL or the system clocks if used with USB boot -- otherwise USB communication with the host can be disrupted.

The SPL consists of a 512 byte header, a 1.5k "secure boot" key, and up to 10k of code. The whole thing, headers included, gets loaded at 0xf4001000 so the code begins at 0xf4001800. The bootrom does seem to use the key somehow using an undocumented hardware feature, but on all currently supported players the secure boot mode is apparently deactivated and the header key is left zeroed.

Useful links

Source code

Documentation
r2 - 28 Nov 2021 - 18:46:15 - AidanMacDonald

Copyright © by the contributing authors.