• Status New
  • 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 Rob Purchase - 2009-11-11

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
rolo_restart() copies the new image to the start of DRAM (to achieve this without crashing, this function is in
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.

Karl Kurbjun commented on 2009-12-18 05:41

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.

Thomas Martitz commented on 2010-01-27 07:47

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.

Karl Kurbjun commented on 2010-01-27 15:29

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