All Projects

Use -std=gnu99 instead of default gnu89 to allow the use of some additional C99 constructs, like for(int i=0; i<n; i++)

Remove inline keyword from some inline non static functions
Add static to some other

Modify pitch_detector to not use a struct

Builds & runs without warnings for Clip+

Please test on nano2g to see if it still works

Also it doesn't seem to work correctly on Clip+

Gives ~ +20% battery life

Changes cpu freq by CGU_PROC instead of using fastbus/synchronous
Also removes setting for asynchronous

Tested on clipv1/fuzev1

Problem: long home press seems to be broken on fuzev1?

Voice doesn’t work on Clipv1/c200v2 & cie, the voice file is too big to fit entirely in RAM

Trying to use a voice file will give a panic on startup.

This patch reuses the code set up for the Ondios (which load the entire file in RAM but progressively), and will only load 64 (the size of the clips queue) clips maximum, (+ the “SILENCE” clip).

It reserves 64 * the_size_of_the_biggest_clip bytes, which is ~300kB for the default voice on Clipv1 (450kB audiobuffer left after that).

It works correctly at startup but later fails (easily seen when spelling a directory for example)

almost 21 hours runtime on fuzev2
almost 16 hours runtime on clipv2

Crashed 2 times on Clip+ so I couldn’t complete the bench (I don’t know if it’s related to the patch or not).

I did not run test_disk yet

LUA doesn’t implement any directory functions because those aren’t in ANSI C

There is an implementation on http://www.keplerproject.org/luafilesystem with :

attributes (filepath [, attributename]) (stat())
chdir (path)
currentdir () (getcwd)
dir (path) (readdir() iterator)
lock (fh, mode) ?
lfs.lock_dir (path) ?
mkdir (path)
rmdir (path)
setmode (filepath, mode) (TEXT/BINARY)
symlinkattributes (filepath [, attributename]) (lstat())
touch (filepath [, atime [, mtime]])
unlock (fh) ?

I only took the code for mkdir/rmdir and the directory iterator

The iterator returns 2 arguments: string (path) and bool (is directory), while the original code only returned a string relied on attributes/stat() to know if it was a directory.

It’s a new “luadir” module although I think it could be in rocklib
Tested in sim and target (fuzev1)

A lot of functions use return instructions which won’t set the T bit if the caller was running in thumb:

- ldm reg, { …, pc } works on armv5 but not armv4t

- ldr pc, function works on ARMv5 and +

- add/sub/bic/orr/mov pc, lr works on armv7 but not before

reference is http://webcache.googleusercontent.com/search?q=cache:saLD8BqZXhQJ:www.riscosopen.org/wiki/documentation/pages/ARMv7%2Bcompatibility%2Bprimer+thumb+interwork+ldm+ldr+armv7&cd=1&hl=fr&ct=clnk

DDI0100E (ARMv5 architecture reference manual) says of mov:
If <Rd> is R15, the SPSR of the current mode is copied to the CPSR

This patch changes all occurences of these instructions which could be run on armv4t (e.g. PP, AMSv1, ..).

I don’t think I have missed any, I used grep -E “1)pc” to find all the occurences.

I could have changed some code which would not run on ARMv4 though.

Cost of this change on ldm (the most used)
- 4 more bytes per return
- 1 more cycle on ARM7TDMI, no effect on newer CPUs

See  FS#6734  for how to build thumb code

Switch off DBOP (or SSP for Clip+) clocks when LCD is not in use.

7 minutes more runtime on Clipv1
10 minutes more runtime on Clip+
6 minutes more runtime on Clipv2

These numbers are really low so we need more benches to be sure there is an effect at all.

Works fine for me on Fuzev1 / v2 (tested mpegplayer too)

FlynDice reported plugin crashes on Fuzev2 with supposedly the same patch so I ask for more testing.

- Higher timeout set to 5 seconds when waiting for the card to be back at transmission state.

I didn’t find a precise timeout in linux source code but this one should be enough.

- yield() while DATA_BUSY bit is set (the linux driver just busy loops)

- retry sending commands up to 6 times before failing

The linux code has a
#define SD_CMD_RETRIES (6) /*!< command retries */

in sd_config.h header

Didn’t run test_disk yet

Tested on Fuzev2

I hear a big hiss at the start, and the recordings sound really bad

When watching a silent recording in audacity I see a small bar at a frequency which is the calling rate of the DMA callback.

With attached patch I have 40 minutes more battery life on Clipv1.

I’ll test again on Fuzev1 and Clip+ to confirm.

SDRAM setup is done by the bootloader in sdram_init(), so I moved this code into system_init() so there is no need to update the bootloaders to benefit from this : are you OK with that ?

More testing and on other models would be fine too.

currently deadlocks when recording start.

deadlocks when entering the recording screen when a 8pixels font is selected?

Sets MCI_DATA_TIMER to a correct value (100ms for read, 250ms for write)

We should also calculate a timeout given what the card CSD reports, and take the lower between the calculated value and 100/250ms.

The OF doesn’t seem to do that so we just save some calculations at each boot and µSD insertion.

In the same process I started removing the duplicate tSDCardInfo structure and putting the 2 needed struct members into tCardInfo (designed for MMC iiuc).

I also let some crude debug code into the isr to detect infinite loops (I actually detected a timeout - status 0×8 - and I started working on this patch)

TODO:
- check if speed calculation is correct (didn’t bother)
- modify ata-sd-pp.c (tSDCardInfo → tCardInfo) - can wait release branching since we are now frozen

This extends UIE(), showing the fault address (the address where the fault occured is already displayed, but not the address causing the fault) and the raw status.

This works on all ARM cpus with coprocessor cp15, but here I don’t know if some supported targets don’t have it (I suppse targets without mmu won’t have it)

Note that we could extend it further to show a textual description of the fault. I didn’t do it since I use it on my Clip and the screen width is way too small, so you have to look at the technical reference manual to see the fault’s meaning.

I have splitted the diff in small patches for easier review/syncing.

- Move target specific code from timer.c into target tree, creating new timer-X.c files ; copyrighted by whoever wrote the code in timer.c

- TIMER_REGISTER / TIMER_UNREGISTER / TIMER_SET macros are removed, and timer_s{top,tart,et} declared in timer.h. The functions themselves are target-specific (in target/*/timer-*.c)

- Remove int_prio argument from timer_register(), and move the only use for it into the SH7034 specific alpine_cdc plugin

- Put TIMER_FREQ definition in CPU-specific headers, and completely remove timer-target.h since it was its only content.

TODO : bump plugin API when it’s committed

cosmetics:

indent dualboot.S properly
remove trailing spaces

add some comments in dualboot.S
correct some comments in mkamsboot.c

move back extract_fw.c to utils/AMS/hacking

modify bin2c.c to produce only one pair of .c/.h files with several files embedded in it

move files needing to be built by an ARM cross compiler into dualboot/

commit produced .c/.h files (containing nrv2e_d8.S and dualboot.S built for Clip, Fuze, e200v2, c200v2, m200v4)

Build tested on linux i386, OSX intel, mingw cross compiler hosted on linux.

Produces the same bootloaders (bitexact) than current SVN.

Bump version to 1.0

Real README

I am waiting for approval from the mkamsboot author linuxstb ;)

The patch also add some comments for clarity.

I couldn’t test in depth since I only have a 4GB Fuze and 2GB Clip.

A good test on a 8GB model would be to write known data at the border between the 2 banks (with ‘dd’ command for example) and calculate a sum of it on the player, or even write it back to a file (using a plugin or debug menu).

I think it could be reused as-is for e200v2 as well.

Playback skips some frames, a bit less without audio (probably because of the speed problem noticed with codecs as well)

Stable mp3 decoding on Fuze

some codecs (mad_iram.h for example) use .icode section and not ICODE_ATTR

This caused a problem because we defined incorrectly IRAMSIZE to be >0 in plugin.lds for these targets

Fix fuze backdrop/wps corruption
md5sum plugin works correctly
test_disk passes

Transfer is a bit slower on unaligned access because al lthe data has to be memcpyed (1.25 times slower on 4096bytes transfers)

Run ascodec_init() in system_init()

Reboot on a button press in panicf() (system_exception_wait())
Set the CPU & Peripherals clock frequencies in bootloader and loaded rockbox
Reset all peripherals in system_init() (except IDE peripheral)

I don’t know how to find the real capacity but we don’t need it until we have USB driver.

Please test on Fuze/e200 etc and as well on 1GB / 2GB models to see if issuing cmd6 causes a problem (it shouldn’t)

I also removed the panicf() and used unique error codes.

Add Clipv2 support in mkamsboot & bootloader

Drivers are now separated from Sansa Clip (v1) for easier modifications but should (hopefully) be concatenated as it appears only the physical connections (GPIO) change, and some registers values.

Test on Clipv2 1GB

Attached patch makes plugins build and load on Clip.

I used the unmodified c200 keymap when possible.
I replaced the REC key of c200 with HOME key of Clip when needed.

I used archos graphics when possible.

Problems are:
* pegbox shows corrupted graphics but not in the simulator.
* chessbox loader is disabled, I’m not sure how to do that correctly, the comment mentions it’s needed on archos, but use if (MEMORYSIZE ⇐ 8)
* greylib doesn’t work
* I had to use a 512kB buffer for codecs to allow 512kB buffer for the plugins (not sure if it’s a real problem though)

Comments on how to fix these are welcome, I would like to commit when the 2 first problems are fixed (work on greylib can wait, and we don’t need codecs at the moment).

This patch adds the ability for the simulator to draw the top X (configurable) lines in a different color.

I add an extra argument to sdl_set_gradient() which is the extra color, which will get added to the end of the palette.

sdl_gui_update() then checks each pixel of the specified zone, and sets them to the extra color if they are set.

This approach only works for monochrome, since there is no obvious reason to have a screen with different color zones on a colored display.

Please comment if you think this is not the right approach.

Basic port with only bootloader support.

LCD driver for SSD1303 controller

Note that you need a modified version of mkamsboot to run this bootloader.

The patch also shortens a bit the string in show_logo.c to make it fit on the Clip screen.

Currently we are limited for our code to 512 bytes - what is used by the original firmware.
This value varies depending the firmware version, but it’s clear that it’s not enough for a bootloader.

This patch aims to make extra room for code in the firmware, the current program will use memmove to relocate the firmware but it’s confirmed to produce buggy files (tested on e200v2)

The button mapping figured so far is valid for Clip & E200v2 only (other models not tested)

You may want to remove also the code which makes the buttons led blink, because this has been tested only on E200 & Clip (this is GPIO pin D7), and there is no indication that driving this pin high will not damage other models.

How this works:
We find the largest block of aligned 32 bits words filled with the same value (most of the time it’s 0)

We will write the stage2 at this offset, and the stage1 will copy the ROM content into RAM, and overwrite this area with the original word before branching back to the OF; because we don’t know if it’s meaningful or not.
We write offset, size, and word in the “data” segment of stage1.

What the code does:

Check GPIO A3 & A6, if set: clean the RAM, resume OF
(A3 is hold on the Clip & USB on the E200, A6 is USB on the Clip)
Continue to stage2, which will make the led blink (D7)
Return to stage1, which will clean the RAM and resume OF.

The button check can be used as software recovery mode.
Hackers can only modify stage2.S , mkamsinfo will check if it fits in the area we found, and will refuse to write the firmware if so.