All Projects

This patch is a continuation of r29286 to make RaaA builds more similar to regular targets.

It changes tools/configure to use a unique “modelname” for each target, instead of them all being called “application”. It also splits the config/application.h file into separate files for each target, with the same name as $modelname.

tools/buildzip.pl checked for ($modelname eq ‘application’) so this has been changed to pass a –app parameter instead. When this is set to “yes”, then buildzip.pl should behave the same as when $modelname was set to “application”.

However, there seems to be a bug in my changes to buildzip.pl - “make zip” for an android build now fails, with wpsbuild.pl (called from buildzip.pl) trying to create a “/.rockbox” directory. I haven’t had time to fix this yet - help welcome.

NOTE: Due to SVN not dealing with my use of “svn cp”, you need to do the following before applying this patch:

cp firmware/export/config/application.h firmware/export/config/android.h
cp firmware/export/config/application.h firmware/export/config/nokian900.h
cp firmware/export/config/application.h firmware/export/config/nokian8xx.h
cp firmware/export/config/application.h firmware/export/config/sdlapp.h

This patch changes tools/configure to list the available RaaA targets in the main list of targets, instead of using a generic “Application” option with a follow-up question.

This also uses different target_id values for the different targets. The implication of this (I think) is that separate voice/lang files are required for each RaaA. IMO this is correct as they can potentially differ in the available features.

I’ll commit this after it is confirmed I haven’t broken anything - I don’t have the Android or Maemo SDKs installed yet.

[NOTE: I haven’t experienced this bug myself, I’m just adding a task to collect info about it]

It has been confirmed that HID mode (fully enabled in 3.4, but also present in 3.3, so this affects both of those releases) causes OS X 10.4 to fail to mount a PP Sansa when in Rockbox USB mode.

Building a version of Rockbox without HID support is known to fix the problem.

Some examples from a OS X 10.4 syslog experiencing this problem:

USBF: 6214.718 AppleUSBEHCI[0×2724800]::Found a transaction past the completion deadline on bus 75, timing out!
USBF: 6225.728 AppleUSBEHCI[0×2724800]::DoIOTransfer - error 0xe000404f queueing request

This patch is the start of work on adding ipodpatcher support for the 2nd generation ipod Nano

There is currently no functional Rockbox bootloader for Nano 2G (NAND/FTL drivers are yet to be written), so this is being tested with “iloader” from the linux4nano project:

http://l4n.clustur.com/index.php/iLoader

The intended installation method is that the “osos” image in the firmware partition (the main Apple firmware) is renamed to “osbk” and that the bootloader (iloader or, in the future, a Rockbox bootloader) is written to the firmware partition as a new “osos” image.

The “osbk” image will remain unchanged (and still encrypted), and dual-booting will involve the bootloader reading that osbk image into RAM and using the Nano’s hardware crypto unit to decrypt it. This functionality is already in iloader will need to be ported to the Rockbox bootloader.

This first patch just implements the “-wf” and related options (-wfb -rf -rfb) to ipodpatcher - this replaces “osos” with the file to be installed. The generic features like –read-partition, –write-partition, –list etc should all be working as well.

The next step is to implement the main “-a” (add bootloader) functionality which will rename osos and create a new osos with the file to be installed.

Note that any bootloader to be installed on the Nano 2G needs to be encrypted before being passed to ipodpatcher. This needs to be done on an actual ipod, but can then be installed on any ipod (the encryption is generic, and not specific to a device). “iBugger” can be used to perform this task:

http://l4n.clustur.com/index.php/IBugger

The attached patch performs on-the-fly fixing of the "Active" flag in the Gigabeat S's partition table.

Without this fixing, at least the Linux kernel considers it an invalid partition table and doesn't present the /dev/sdXN partition device nodes.

When reading sector 0, the validate_mbr() function is called. Writes to sector 0 are unaffected.

I'm not completely happy that it hacks target-specific code into the usb storage driver, but it's relatively unobtrusive. If any more such hacks are needed, then a better way should probably be found.

I would like to commit this before an official Gigabeat S bootloader is released.

Attached is my work-in-progress implementation of viewports.

Currently, they are only implemented in the lcd-16bit.c LCD driver - so this patch only compiles on targets with a colour screen and no LCD remote.

This patch adds a test_viewports.c plugin, plus a new %V WPS tag to allow use of viewports in the WPS.

The format of the %V tag is:

%V|x|y|width|height|fgcolor|bgcolor|

e.g.

%V|100|50|125|125|FF0000|00FF00|

All lines in the WPS up to the first %V tag are displayed in the default (full-screen) viewport. Lines following a %V are drawn in the new viewport - giving pixel-accurate positioning, left/right scrollmargins and custom colours.

Note that if the WPS specifies a backdrop, the bgcolor is ignored - backdrops are still global and the viewport will be transparent.

As an example of how viewports can be used, I’m attaching a modified version of jClix_Night adapted to use viewports - note that this is 220×176, so will currently only work on the iPod Color (the H300 has a remote).

Work left to do:

Finalise API - this implementation is still a work-in-progress
Adapt other LCD drivers
Modify the core Rockbox UI code to use viewports

The attached patch adds an optional parameter to the %s tag to specify the left scroll margin - e.g. %s|100|

This is implemented without changing the LCD drivers - it makes use of the existing ability to set a left margin in scrolling lines.

I’m hoping this patch can be committed to enable people to design album-art WPSs that can work with official Rockbox builds - album art isn’t very usable without it.

It’s partly based on the existing scrollmargins patch, but removes all the parts related to the right margin, which causes the most intrusion into the rest of Rockbox - this patch only modifies the WPS code.

The current Rockbox FLAC codec rejects files (in apps/metadata/flac.c) where the “samplecount” field in the header is 0. However, the FLAC specification says that this is a valid value and should be interpreted as “unknown”.

The only encoder I’ve seen which generates such files is ffmpeg.

This patch (hopefully) improves the USB detection on PortalPlayer targets, fixing the following bugs:

1) MENU needed to be held for a long time (10 seconds or more) in order to prevent Rockbox rebooting into disk mode.

2) Windows would display an “unknown usb device” message

It also changes the target-tree function usb_detect() on all targets from bool to int, returning USB_INSERTED or USB_EXTRACTED instead of true or false.

This change was made to enable the PP usb_detect() function to check for USB_POWER and return that as a third value.

The PP usb_detect() function also checks for USB_POWER_BUTTON being held, and will not call dr_controller_run if MENU is held.

I’ve tested this patch on an iPod Color and a Gigabeat F, but would like it to be tested more widely (especially on different PP targets connecting to different host operating systems) before committing.

LANG FIEL FOR AOL UESRS!1!!!1 OMG

THX 2 http://ssshotaru.homestead.com/files/aolertranslator.html

This patch implements a Monkey’s Audio (.ape files) decoder for Rockbox.

The decoder itself (libdemac) was written from scratch by me and is licensed under the GNU GPL. The exception is the majority of rangecoding.h, which is (C) 1997, 1998, 1999, 2000 Michael Schindler and is also licensed under the GPL. See that source file for full details.

The decoder only handles modern variants (v3.97 and later) of Monkey’s Audio (the format has gone through lots of incompatible changes during its life).

Monkey’s Audio files can be compressed at one of 5 compression levels (1000 - fast, 2000 - normal, 3000 - high, 4000 - extra high and 5000 - insane) and current performance in Rockbox for those 5 compression levels (1000 to 5000) is:

Gigabeat F (300MHz ARM) - 413%, 291%, 203%, 76%, 17%
H140 (124MHz Coldfire) - 175%, 105%, 63%, 21%, ??
iPod Color (75MHz PP5020) - 86%, 55%, 32%, 11%, ??

(-c5000 is extremely slow on Coldfire because the filter history buffer is too big to fit in IRAM. -c1000 doesn’t have any filters, and -c2000 to -c4000 make use of IRAM. I didn’t bother testing -c5000 on PP).

The percentages are (file duration / decoding time) - i.e. 100% is realtime, and the higher the percentage, the faster the decoding is. Smooth playback in Rockbox requires at least around 120% realtime.

There is still potential for optimisation in all parts of the decoder, but Monkey’s Audio (especially at the higher compression levels, where high-order filters are used, meaning large numbers of multiplications per sample) is by design complex to decode. However, -c1000 to -c3000 are very usable on the Gigabeat already.

There are two attachments:

demac-0.1.tgz - the standalone ANSI C libdemac, and an example decoding application.

rockbox-ape-0.1.diff - a patch incorporating libdemac from the above archive, and implementing a Rockbox codec. You only need this file to patch Rockbox.

Apart from the obvious need for optimisation, there is still work to do on both the decoder and the Rockbox codec, including:

1) Testing with a larger variety of test files (especially v3.97 testing) including different bitdepths (8/16/24).

2) Implement seeking in Rockbox

3) Improve the code in parser.c (it’s a mess at the moment)

The attached patch is a first attempt at a standalone checkwps tool.

Compile it by typing “make checkwps” in the tools/ directory, and then you can use it to parse and debug a WPS using the command “./checkwps filename.wps”

The code itself needs cleaning up before it’s suitable for committing (there are too many hacks) but I’m posting the patch to get feedback on the idea and if people think it would be useful and worth committing.

The uninstall section tells users to remove the .rockbox directory first, and then goes on to mention the device-specific process of removing any bootloader.

IMO, the user should be instructed to remove the bootloader first, with the final step being to delete the .rockbox directory. This way there is no problem if a user only completes the first step of uninstallation before disconnecting their device and rebooting.

Also, maybe a reminder (on applicable targets) of Rockbox's dual-boot feature could be added as well - to make sure people know they don't have to do a full uninstall in order to continue using the original firmware.

Steps to reproduce:

1) Write a .cfg file called “config01.cfgA” 2) Write a second .cfg file called “config01.cfg” (this should have different content to the first - change at least one setting, or just export a theme .cfg)

Accessing the device (I’ve tested with both an ipod 5g and h140) from Linux and Mac OS X will show two entries with identical filesizes and timestamps. A diff between the two files will show no differences.

Mounting the device in Linux with “-t msdos” doesn’t show the same problem - the two files have different shortnames, and the filesizes and timestamps are different, and a diff will show differences.

In WinXP, the files show different sizes and dates, but when displaying them (I used “type config.cfg” in a cmd prompt), they are both showing the content of the first file written.

This problem appears to affect the 4G Grayscale and both generations of mini - the latest bootloader installed with the latest version of ipodpatcher fails to start the Apple firmware.

To help isolate the problem, it would be useful if users of the above devices could try the following tests, restoring a clean firmware partition before each attempt. Please report your findings here.

1) Install the latest bootloader with the latest ipodpatcher.

2) Install the old bootloader-????.bin bootloader from http://download.rockbox.org/bootloader/ipod/ using the latest ipodpatcher. You need to use the “-ab” option instead of “-a” to add a .bin format bootloader.

3) Install the ipodlinux loader2 with the latest ipodpatcher (again, the -ab option is needed).

4) Install the latest SVN bootloader, but using the old ipod_fw/ipodpatcher installation method. Use the links on the old IpodInstallation / IpodInstallationFromMacOSX / IpodInstallationFromLinux wiki pages for the executables. These instructions require a bootloader in “.bin” format, which if you build it yourself from SVN, you can find in the bootloader/ sub-directory in your build directory (called bootloader.bin).

For each test, does Rockbox load correctly, and does the original firmware load correctly? If the original firmware fails, can you note if it seems to fail in the same way, or if it looks like a different problem?

The attached patch is based on Barry Wardell’s USB debug code in FS #6494 and attempts to correctly distinguish between a USB connection to a PC and a USB connection to an AC adapter. Currently Rockbox thinks they are both a connection to a PC and reboots into disk mode.

It’s been tested successfully on an iriver H10 and the following ipods: Color, Video, Nano and 2nd Gen Mini. Test results from other PP targets would be useful before it’s committed.

This is a first, proof-of-concept patch to load wps .bmp files from a .tar file.

This doesn’t include patches to the build system, so to create an appropriate .tar file, you need to do something like:

cd wps/iCatcher
awk -vFS=”|” ‘(/^%x[l]?\\|/) {print $3}’ ../iCatcher.220x176x16.wps | tar cvf ../iCatcher.tar -T -

and then copy the resulting iCatcher.tar file to the .rockbox/wps/ directory on your player.

As you can see from the above command, this only places the %x[l] bitmaps into the .tar file. The background .bmp file, and the progress bar .bmp files (if they exist) should still go in the normal directory.

The patch has very little error checking at the moment, and has one major limitation which we may or may not wish to retain - the .bmp files in the .tar file must be in the same order as they are referenced in the .wps file.

But if you test, you will see it vastly reduces the loading time for a bitmap-heavy wps.

The attached patch adds a target-specific default theme - currently iCatcher, which only affects the font and wps settings.

The intention is to give new users a better first impression of Rockbox than the current default font/wps. However, the downside is the increased boot time due to the .bmp files used by iCatcher.

Attached is a work-in-progress patch to implement recording on the ipods.

I first implemented this a couple of months ago, and have now resynced it to CVS following the major reworking of the Rockbox recording code. I have only tested the resynced version of the patch on a 5g, but it should also be working on the 4g (greyscale) and Photo/Color.

On the 5g, recording is via the line-in pins hidden in the dock connector. On the 4g/Photo, recording is either via the line-in pins, or via the the right channel in the headphone socket which doubles as a mic input.

Remaining issues/unimplemented features:

1) Playback is broken after recording
2) No gain control
3) mp3 codec is untested, wavpack codec doesn’t work. WAV is OK.
4) Only 16-bit/44.1KHz is implemented - the recording hardware should be able to handle a variety of samplerates up to 24-bit/96KHz.

1) Apple have changed the layout of the firmware partition on the Nano. Users running v1.2 of the Apple firmware need to follow verbatim the instructions for the ipod 5g. I’ve updated the IpodInstallation wiki page. If users don’t do this, the Apple firmware refuses to display any music.

2) (as pointed out by bgmrk in IRC), the first paragraph in the “Running Rockbox” section in installation.tex doesn’t make sense for ipods. The Apple firmware doesn’t have on/off features - users can’t turn their ipod off. Advice on rebooting the ipod (holding MENU+SELECT for 4g and later ipods, MENU+PLAY for 3g and earlier) should probably replace it.

The attached patch removes all code from IRAM on the PP502x ipods (but leaves it there for the 3g) and removes the -mlong-calls GCC option. This reduces the size of rockbox.ipod from 376692 bytes to 323704 bytes.

Some brief testing with an MP3 file on my 4G Color ipod gave about 74% boost ratio with CVS Rockbox, 75% boost with this patch, and about 90% boost if I disabled the use of IRAM completely, but more thorough testing would be useful before deciding if this is to be committed to CVS.

When deleting directories with an extremely high number of files (my test was with about 30000 files - the High Voltage SID Collection), the Rockbox recursive directory delete feature immediately displays “Deleted: NameOfDirectory” and then attempts to delete the files/folders - which in my example has taken 40 minutes so far and is still running…

Two small improvements could be made to handle large folders:

1) Update the display to reassure the user that Rockbox is still runniing - e.g. display “Deleting: NameOfCurrentDirectory” as the delete function recurses through the folders.

2) Enable the user to press a button to abort to the process if he/she realises this is going to take too long.

I’m uploading this patch on behalf of the author, Rainer Sinsch.

The codec is working in realtime on both Coldfire and ARM targets. The only real issue is track running time - currently all tracks are hard-coded to display a 2 minute running time, and they never stop - you need to manually press NEXT to go to the next track.

I have a brand new Recorder 20 with Archos firmware
1.28 in ROM. I am using Rockbox Firmware 1.3.

I have tried two "layer 2" audio files from two
different sources, and they both exhibit the same audio
problem. They are both 48KHz, 192kbit/s Stereo
Mpeg-1, Layer 2 files.

In both files, approximately every 12 seconds, the
sound is very briefly corrupted - i.e. on 12 seconds,
24 seconds, 36 seconds etc. The same files play back
fine on a PC, and also with the Archos Firmware.

12 seconds of audio in these files is 288,000 bytes (if
that helps!).