This page looks at the internal architecture of Rockbox
Application and firmware
Currently, Rockbox is split into two main sections, the firmware or operating system, which is architecture dependent, and the application which in theory at least is dependent on only the capabilities of the hardware (i.e. does it have a graphical display) rather than on specific pieces of hardware. One of the design goals of Rockbox is that there should be as few as possible calls from the firmware into the application itself, to ease porting of the application to new architectures.
Possibly, the Rockbox firmware would further be split into logical driver code and low level bit twiddling which is architecture dependent. This would require the creation of low level device driver APIs, but would then mean that porting to a new architecture would simply be a matter of reimplementing the API while the higher level firmware controls flow etc. Please comment - this is only speculation on my behalf
The Rockbox OS contains its own co-operative multi-threading scheduler. Currently this is used mainly in the firmware part of the code, the application itself being contained in a single thread also known as the Main thread.
Within the firmware, there are several functions split into different threads.
- ATA thread (harddisk based players) - handles disk spinup/spindown
- Backlight thread - turns the backlight on and off
- MMC thread (flash based players) - handles card hotswap
- Playback thread - handles low level recording / playback
- Power thread - handles power management and software recharging
- Scroll thread - handles scrolling
- USB thread - processes USB insertion and removal events.
Some of these threads pass messages to each other via means of an associated event queue.
Other information pages
discusses an alternative approach to the single Main thread we use today.
Copyright © by the contributing authors.