From: Heikki Hannikainen <hessu_at_hes.iki.fi>
Date: Wed, 10 Jul 2002 02:07:11 +0300 (EEST)

  Hi,

  I got my Recorder 20 from the shop yesterday and got more than slightly
interested in writing some code to run on it. Found the rockbox project
source code very pretty, clean and incredibly cool. Got the compiling
environment set up today, and to get my hands wet started looking at the
44 bytes of battery-backed RAM space available on the RTC, which is used
for configuration storage on the original firmware. Thanks to Björn for
the tips on IRC.

  Has the RTC space been reverse-engineered before? I added a new
debugging menu item for displaying and modifying the RTC RAM (code in
firmware/debug.c), did a little rebooting from rockbox to the stock
firmware 1.27d and back, and found the following:

  All of the 44 bytes (starting from 0x14) seems to be used for a
configuration block.

  The first 4 bytes are set to 55aa5506 on 1.27d, and 55aa5505 on 1.26
(which resides on the flash rom of my box). It would seem the fourth byte
is a config version number. The last 4 bytes (from 0x3c) are always set to
55aa55ff.

  The second 4 bytes from 0x18 are used for the sound parameters: volume,
bass, treble, loudness, balance, bass boost. They vary like this:

flat, Vol 0 0x18: 00000000
flat, Vol full 0x18: 14000000
flat, vol 0, Bass 0 0x18: 00d80000
flat, vol 0, Bass full 0x18: 00280000
flat, vol 0, Trebl 0 0x18: 0006c000
flat, vol 0, Trebl full 0x18: 00014000
flat, vol 0, Loudn full 0x18: 00002800
flat, vol 0, bAl left 0x18: 000002c0
flat, vol 0, bAl right 0x18: 00000140
flat, vol 0, bassb full 0x18: 00000014

  From this one can derive the bits used for each parameter. For example,
the volume is in byte 0x18, in 21 steps, 0x0 to 0x14. The other parameters
seem to have about 5 bits each as well.

  I didn't dig in to the other data quite yet. I suspect there is a
checksum in the four bytes starting from 0x38.

  If I alter any of the data in the config block, the next time I boot the
stock firmware the config block is reset to factory defaults, probably
since I'm not fixing the checksum. The same happens if i clear the config
block to all-zeroes (whew!).

  The questions, before I dig in further, are:

- Has this been discussed in depth before? Couldn't find anything with a
  quick visual grep in the mailing list archives.

- If configuration in rockbox would be saved to the RTC RAM, would it make
  sense to try to reverse-engineer the whole config block and store
  the config in that? The same settings would be then used on both rockbox
  and the bog standard firmware (good for dual-booting). Of course this
  wouldn't permit rockbox to extend the config block format
  (though extended settings could be stored on the disk).

- Is there any real advantage to using the RTC RAM for configuration
  storage, over using a config file on the disk? The config file would
  also work on the players (no separate code would be needed for the
  Recorder). Also, the RTC RAM contents will be lost if the device runs
  out of battery power, or the batteries are replaced (if the
  supplied documentation is right on this). RTC RAM would not need to be
  debugged and config data stored by the stock firmware would not be
  overwritten.

- Implementing a config file would require working FAT writing. What is
  the status of this, I see it would _seem_ to be at least partly
  implemented but disabled?

- Should I post the (rather simple) patch for the RTC RAM viewer?

  - Hessu
Received on 2002-07-10