• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by shotofadds - 2009-11-11
Last edited by speachy - 2021-06-05

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

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.

Closed by  speachy
2021-06-05 18:57
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Perhaps things aren't "sufficiently dissimilar" but I haven't been able to recreate this on any current armv4 targets/builds.

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.

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.

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.


Available keyboard shortcuts


Task Details

Task Editing