1654efc313
* Editing a bunch of drivers' thread routines in order to implement a new feature is tedious. * No matter the number of storage drivers, they share one thread. No extra threads needed for CONFIG_STORAGE_MULTI. * Each has an event callback called by the storage thread. * A default callback is provided to fake sleeping in order to trigger idle callbacks. It could also do other default processing. Changes to it will be part of driver code without editing each one. * Drivers may sleep and wake as they please as long as they give a low pulse on their storage bit to ask to go into sleep mode. Idle callback is called on its behalf and driver immediately put into sleep mode. * Drivers may indicate they are to continue receiving events in USB mode, otherwise they receve nothing until disconnect (they do receive SYS_USB_DISCONNECTED no matter what). * Rework a few things to keep the callback implementation sane and maintainable. ata.c was dreadful with all those bools; make it a state machine and easier to follow. Remove last_user_activity; it has no purpose that isn't served by keeping the disk active through last_disk_activity instead. * Even-out stack sizes partly because of a lack of a decent place to define them by driver or SoC or whatever; it doesn't seem too critical to do that anyway. Many are simply too large while at least one isn't really adequate. They may be individually overridden if necessary (figure out where). The thread uses the greatest size demanded. Newer file code is much more frugal with stack space. I barely see use crack 50% after idle callbacks (usually mid-40s). Card insert/eject doesn't demand much. * No forcing of idle callbacks. If it isn't necessary for one or more non-disk storage types, it really isn't any more necessary for disk storage. Besides, it makes the whole thing easier to implement. Change-Id: Id30c284d82a8af66e47f2cfe104c52cbd8aa7215 |
||
---|---|---|
android | ||
apps | ||
backdrops | ||
bootloader | ||
debian | ||
docs | ||
firmware | ||
flash | ||
fonts | ||
gdb | ||
icons | ||
lib | ||
manual | ||
packaging | ||
rbutil | ||
tools | ||
uisimulator | ||
utils | ||
wps | ||
.gitattributes | ||
.gitignore |
docs/README
__________ __ ___. Open \______ \ ____ ____ | | _\_ |__ _______ ___ Source | _// _ \_/ ___\| |/ /| __ \ / _ \ \/ / Jukebox | | ( <_> ) \___| < | \_\ ( <_> > < < Firmware |____|_ /\____/ \___ >__|_ \|___ /\____/__/\_ \ \/ \/ \/ \/ \/ Build Your Own Rockbox 1. Clone 'rockbox' from git (or extract a downloaded archive). $ git clone git://git.rockbox.org/rockbox or $ tar xjf rockbox.tar.bz2 2. Create a build directory, preferably in the same directory as the firmware/ and apps/ directories. This is where all generated files will be written. $ cd rockbox $ mkdir build $ cd build 3. Make sure you have sh/arm/m68k-elf-gcc and siblings in the PATH. Make sure that you have 'perl' in your PATH too. Your gcc cross compiler needs to be a particular version depending on what player you are compiling for. These can be acquired with the rockboxdev.sh script in the /tools/ folder of the source, or will have been included if you've installed one of the toolchains or development environments provided at http://www.rockbox.org/ $ which sh-elf-gcc $ which perl 4. In your build directory, run the 'tools/configure' script and enter what target you want to build for and if you want a debug version or not (and a few more questions). It'll prompt you. The debug version is for making a gdb version out of it. It is only useful if you run gdb towards your target Archos. $ ../tools/configure 5. *ploink*. Now you have got a Makefile generated for you. 6. Run 'make' and soon the necessary pieces from the firmware and the apps directories have been compiled, linked and scrambled for you. $ make $ make zip 7. unzip the rockbox.zip on your music player, reboot it and *smile*. If you want to build for more than one target, just create several build directories and create a setup for each target: $ mkdir build-fmrecorder $ cd build-fmrecorder $ ../tools/configure $ mkdir build-player $ cd build-player $ ../tools/configure Questions anyone? Ask on the mailing list. We'll be happy to help you!