Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#10776 : ROLO issues on ARM v4/v5 targets



FS#10776 - ROLO issues on ARM v4/v5 targets

Attached to Project: Rockbox
Opened by Rob Purchase (shotofadds) - Wednesday, 11 November 2009, 23:45 GMT
Task Type Bugs
Category Operating System/Drivers
Status New
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


ROLO currently fails on these targets unless a Rockbox image is being loaded that is sufficiently similar to the one already in memory.

The sequence goes like this:

- rolo_load() loads the new image to audiobuf
- rolo_restart() copies the new image to the start of DRAM (to achieve this without crashing, this function is in .icode)
- rolo_restart() tries to call invalidate_idcache(), but since invalidate_idcache() is in DRAM this fails as the function has been overwritten.

There are several solutions to this:

1) Move invalidate_idcache() into .icode (easy but won't fix all targets, esp. those that don't use IRAM)

2) Create a new .safecode section at the end of DRAM, and move these functions into it (lots of work to update every and crt0.S, and test every target)

3) Introduce target-specific rolo_restart() functions, as per imx31/rolo_restart.S (less work, as only one should be required per architecture, eg ARMv4/5 etc.)

I'm not sure which of those options is "best". 1) is certainly the easiest, but 2) and 3) should also allow ROLO to work on targets that don't use IRAM.
This task depends upon

Comment by Karl Kurbjun (kkurbjun) - Friday, 18 December 2009, 05:41 GMT
The gigabeat F has code in crt0.s so that the build can load in the "wrong" area of memory and then can copy itself to the right location once you jump to the new build. This allows it to copy the new firmware image to an offset of some size (I can't remember what it is offhand) and then jump into the "wrong" location. crt0.s copies the firmware to the right location and jumps to it's new copy.

I think that doing option 1 would be the easiest and probably makes sense for most targets. For targets that do not have iram we can either do something similar to the gigabeatf or come up with another method. The iram fix will work for most targets.

Thanks for figuring this out by the way, I was wondering why the MR500 ROLO loads were so intermittent.
Comment by Thomas Martitz (kugel.) - Wednesday, 27 January 2010, 07:47 GMT
I think the .safecode solution is the most robust one. For targets that have iram it could be the as iram; FX could use the unused 4k IRAM for that.
Comment by Karl Kurbjun (kkurbjun) - Wednesday, 27 January 2010, 15:29 GMT
I have not been able to get the F/X IRAM working once cache and the MMU are enabled. If you try writing to it and then reading in a main build you won't get the values back you attempted to write. It may be a setup problem, but it never worked for me.