This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#10776 - ROLO issues on ARM v4/v5 targets
Attached to Project:
Rockbox
Opened by Rob Purchase (shotofadds) - Thursday, 12 November 2009, 00:45 GMT+2
Opened by Rob Purchase (shotofadds) - Thursday, 12 November 2009, 00:45 GMT+2
|
DetailsROLO 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 app.lds 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
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.