diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/MAINTAINERS | 8 | ||||
-rw-r--r-- | docs/PLUGIN_API | 88 | ||||
-rw-r--r-- | docs/TECH | 203 |
3 files changed, 1 insertions, 298 deletions
diff --git a/docs/MAINTAINERS b/docs/MAINTAINERS index 4928bb5a85..52ac7fb0db 100644 --- a/docs/MAINTAINERS +++ b/docs/MAINTAINERS @@ -25,13 +25,6 @@ NOTE: Port maintainers are simply developers who use a particular target on a daily basis and are therefore able to report issues specific to that target. -:Archos Player/Studio: Jens Arnold -:Archos Recorder v1: Jens Arnold -:Archos Recorder 8MB: -:Archos FM Recorder: Linus Nielsen Feltzing -:Archos Recorder v2: Linus Nielsen Feltzing -:Archos Ondio FM: Jens Arnold, Marianne Arnold -:Archos Ondio SP: :Creative Zen Vision: :Creative Zen Vision:M: Maurus Cuelenaere :Creative Zen Vision:M 60GB: @@ -299,7 +292,6 @@ Build Tools :rdf2binary: :convbdf: Daniel Stenberg :codepages: -:player_unifont: :uclpack: :wavtrim: Linus Nielsen Feltzing :voicefont: diff --git a/docs/PLUGIN_API b/docs/PLUGIN_API index 768342bd80..b2fb94ed7e 100644 --- a/docs/PLUGIN_API +++ b/docs/PLUGIN_API @@ -810,25 +810,6 @@ enum yesno_res gui_syncyesno_run(const struct text_message * main_message, const \return \description -void i2c_begin(void) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) && ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \description - -void i2c_end(void) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) && ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \description - -int i2c_write(int address, const unsigned char* buf, int count ) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) && ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \param address - \param buf - \param count - \return - \description - void invalidate_icache(void) \conditions (defined(CACHE_FUNCTIONS_AS_CALL)) \description @@ -1433,56 +1414,6 @@ const unsigned long *rec_freq_sampr \return \description -int mas_codec_readreg(int reg) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) && ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \param reg - \return - \description - -int mas_codec_writereg(int reg, unsigned int val) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) && ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \param reg - \param val - \return - \description - -int mas_readmem(int bank, int addr, unsigned long* dest, int len) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) - \param bank - \param addr - \param dest - \param len - \return - \description - -int mas_readreg(int reg) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) - \param reg - \return - \description - -int mas_writemem(int bank, int addr, const unsigned long* src, int len) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) - \param bank - \param addr - \param src - \param len - \return - \description - -int mas_writereg(int reg, unsigned int val) - \group MAS communication - \conditions (!defined(SIMULATOR) && (CONFIG_CODEC != SWCODEC)) - \param reg - \param val - \return - \description - void *memchr(const void *s1, int c, size_t n) \group strings and memory \param s1 @@ -1709,23 +1640,6 @@ void pcm_stop_recording(void) \conditions (CONFIG_CODEC == SWCODEC) && (defined(HAVE_RECORDING)) \description -bool peak_meter_get_use_dbfs(void) - \conditions ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \return 1 if the meter currently is displaying dBfs values, 0 if the meter is displaying percent values - \description - -unsigned short peak_meter_scale_value(unsigned short val, int meterwidth) - \conditions ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \param val is the volume value (range: 0 <= val < MAX_PEAK) - \param meterwidth is the width of the meter in pixel - \return a value between 0 and meterwidth - \description Scales a peak value as read from the MAS to the range of =meterwidth=. The scaling is performed according to the scaling method (dBfs / linear) and the range (peak_meter_range_min .. peak_meter_range_max). - -void peak_meter_set_use_dbfs(bool use) - \conditions ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F)) - \param use If =use= is 0 use linear percent scale, else use dBfs - \description Specifies whether the values displayed are scaled as dBfs or as linear percent values - int playlist_amount(void) \group playback control \return the number of tracks in current playlist @@ -2208,7 +2122,7 @@ void sound_set(int setting, int value) void sound_set_pitch(int pitch) \group playback control - \conditions ((CONFIG_CODEC == MAS3587F) || (CONFIG_CODEC == MAS3539F) || (CONFIG_CODEC == SWCODEC)) + \conditions (CONFIG_CODEC == SWCODEC) \param pitch \description diff --git a/docs/TECH b/docs/TECH deleted file mode 100644 index 9ae71eec15..0000000000 --- a/docs/TECH +++ /dev/null @@ -1,203 +0,0 @@ - Rockbox From A Technical Angle - ============================== - -Background - - [Most, if not all, of this document is completely outdated. You should rather - hunt down this info in the Rockbox wiki or source code!] - - Björn Stenberg started this venture back in the late year 2001. The first - Rockbox code was committed to CVS end of March 2002. Rockbox 1.0 was - released in June. - -Booting and (De)Scrambling - - The built-in firmware in the Archos Jukebox reads a file from disk into - memory, descrambles it, verifies the checksum and then runs it as code. When - we build Rockbox images, we scramble the result file to use the same kind of - scrambling that the original Archos firmware uses so that it can be loaded - by the built-in firmware. - - 1) The built-in firmware starts - 2) It looks in the root directory for a file called "archos.mod" (player) - or "ajbrec.ajz" (recorder) - 3) If it finds one, it loads the file, descrambles it and runs it - -CPU - - The CPU in use is a SH7034 from Hitachi, running at 11.0592MHz (recorder) - or 12MHz (player). - Most single instructions are executed in 1 cycle. There is a 4KB internal RAM - and a 2MB external RAM. - -Memory Usage - - All Archos Jukebox models have only 2MB RAM. The RAM is used for everything, - including code, graphics and config. To be able to play as long as possible - without having to load more data, the size of the mpeg playing buffer must - remain as big as possible. Also, since we need to be able to do almost - everything in Rockbox simultaneously, we use no dynamic memory allocation - system at all. All sub-parts that needs memory must allocate their needs - staticly. This puts a great responsibility on all coders. - -Playing MPEG - - The MPEG decoding is performed by an external circuit, MAS3507D (for the - Player/Studio models) or MAS3587F (for the Recorder models). - - The CPU has a serial connection to the MAS for MP3 playback, using serial - port 0 at approx. 1mbit/s. The MAS has a handshake signal called DEMAND, - that informs the CPU when it wants more MP3 data. Whenever the DEMAND - signal goes high, it wants data sent over the serial line, and it wants it - quickly, within ~1ms. When the MAS has received enough data, it negates the - DEMAND signal and expects the incoming data stream to stop within 1ms. - - The DEMAND signal is connected to a port pin on the CPU which can generate - an IRQ, but only on the falling edge. That means that the mpeg driver code - must poll the DEMAND signal every ms to keep the MAS happy. The mpeg code - does use the IRQ to detect the falling edge when the MAS is "full". - - Unfortunately, the serial port on the CPU sends the LSB first, and the MAS - expects the MSB first. Therefore we have to revers the bit order in every - byte in the loaded MP3 data. This is referred to as "bit swapping" in the - Rockbox code. - - The internal DMA controller is used to feed the serial port with data. The - driver works roughly like this: - - 1) Load MP3 data into the RAM buffer - 2) Bitswap the data - 3) Load the DMA source pointer to the next 64Kbyte block to be transferred - 4) Wait until DEMAND is high - 5) Enable the DMA - 6) Wait until the falling DEMAND pin generates an IRQ - 7) Disable the DMA - 8) Go to 4 - - The DMA generates an IRQ when the 64Kbyte block is transferred, and the - IRQ handler updates the DMA source pointer. - - - _____________________________ - | | - DEMAND __________| |_____________ - _ _ _ _ _ _ _ _ _ - SC0 _____________/ \/ \/ \/ \/ \/ \/ \/ \/ \____________ - \_/\_/\_/\_/\_/\_/\_/\_/\_/ - ^ ^ - | | - Poll sees the DEMAND The DEMAND pin generates - signal go high and an IRQ that in turn disables - enables the DMA the DMA again - -Spinning The Disk Up/Down - - To save battery, the spinning of the harddrive must be kept at a minimum. - Rockbox features a timeout, so that if no action has been performed within N - seconds, the disk will spin-down automaticly. However, if the disk was used - for mpeg-loading for music playback, the spin-down will be almost immediate - as then there's no point in timing out. The N second timer is thus only used - when the disk-activity is trigged by a user. - -FAT and Mounting - - Rockbox scans the partitions of the disk and tries to mount them as fat32 - filesystems at boot. - -Directory Buffer - - When using the "dir browser" in Rockbox to display a single directory, it - loads all entries in the directory into memory first, then sorts them and - presents them on screen. The buffer used for all file entries is limited to - maximum 16K or 400 entries. If the file names are longish, the 16K will run - out before 400 entries have been used. - - This rather limited buffer size is of course again related to the necessity - to keep the footprint small to keep the mpeg buffer as large as possible. - -Playlist Concepts - - One of the most obvious limitations in the firmware Rockbox tries to - outperform, was the way playlists were dealt with. - - When loading a playlist (which is a plain text file with file names - separated by newlines), Rockbox will scan through the file and store indexes - to all file names in an array. The array itself has a 10000-entry limit (for - memory size reasons). - - To play a specific song from the playlist, Rockbox checks the index and then - seeks to that position in the original file on disk and gets the file name - from there. This way, very little memory is wasted and yet very large - playlists are supported. - -Playing a Directory - - Playing a full directory is using the same technique as with playlists. The - difference is that the playlist is not a file on disk, but is the directory - buffer. - -Shuffle - - Since the playlist is a an array of indexes to where to read the file name, - shuffle modifies the order of these indexes in the array. The algorithm is - pretty much like shuffling a deck of cards, and it uses a pseudo random - generator called the Mersenne Twister. The randomness is identical for the - same random seed. This is the secret to good resume. Even when you've shut - down your unit and re-starts it, using the same random seed as the previous - time will give exactly the same random order. - -Saving Config Data - - The Player/Studio models have no battery-backuped memory while the Recorder - models have 44 bytes battery-backuped. - - To save data to be persistent and around even after reboots, Rockbox uses - harddisk sector 63, which is outside the FAT32 filesystem. (Recorder models - also get some data stored in the battery-backuped area). - - The config is only saved when the disk is spinning. This is important to - realize, as if you change a config setting and then immediately shuts your - unit down, the new config is not saved. - - DEVELOPERS: - The config checksum includes a header with a version number. This version - number must be increased when the config structure becomes incompatible. - This makes the checksum check fail, and the settings are reset to default - values. - -Resume Explained - - ... - -Charging - - (Charging concerns Recorder models only, the other models have hardware- - controlled charging that Rockbox can't affect.) - - ... - -Profiling - - Rockbox contains a profiling system which can be used to monitor call count - and time in function for a specific set of functions on a single thread. - - To use this functionality: - 1) Configure a developer build with profiling support. - 2) Make sure that the functions of interest will be compiled with the - PROFILE_OPTS added to their CFLAGS - 3) On the same thread as these functions will be run, surround the relevent - running time with calls to profile_thread and profstop. (For codecs, - this can be done in the codec.c file for example) - 4) Compile and run the code on the target, after the section to be profiled - exits (when profstop is called) a profile.out file will be written to - the player's root. - 5) Use the tools/profile_reader/profile_reader.pl script to convert the - profile.out into a human readable format. This script requires the - relevent map files and object (or library) files created in the build. - (ex: ./profile_reader.pl profile.out m68k-elf-objdump vorbis.map libtremor.a 0) - - There is also a profile_comparator.pl script which can compare two profile - runs as output by the above script to show percent change from optimization - - profile_reader.pl requires a recent binutils that can automatically handle - target object files, or objdump in path to be the target-objdump. |