GitLab

Detail:
  Previously the RTSupport routine would execute in SYS mode, and use assembler veneers to make direct calls to the buffer manager.
  Despite being against the buffer manager spec (only IRQ or SVC should be used, according to PRM 5a), the buffer manager was coping with SYS mode calls fine. However the buffer manager would call DeviceFS, and DeviceFS would then call USBDriver, entering the module via one of CMHG's generic veneers.
  These veneers attempt to switch to SVC mode on entry, but they do so by only interacting with the bottom two bits of the PSR - so the CPU was remaining in SYS mode.
  Although this isn't a problem in and of itself, immediately after the mode change comes some code to set up the static relocation offsets at the SVC stack limit.
  This is done by aligning the stack pointer to a MB boundary. If we were in SVC mode this would be fine, but since we're still in SYS mode we're using a stack that was allocated by SCSISoftUSB and isn't aligned to a boundary at all; thus resulting in two words of RMA being swapped out with something completely different while the USBDriver code executes.
  With RTSupport in ROM this will most likely end up being the first two words of the heap - which is enough to stop OS_Module from manipulating the heap (the heap manager will see it as corrupt), but without causing any lasting damage.
  To solve this issue we now run the entire routine in SVC mode, using the MB-aligned SVC stack that RTSupport provides for us.
  File changes:
  c/global, c/cmodule, h/global - Get rid of the SYS mode stack since we no longer need it
  c/glue, h/glue - Extern RTSupportWrapper so it can be called from the assembler veneer. Tweak RT_Register parameters to pass in the relocation offsets (and no SYS stack)
  s/asm, h/asm - Added asm_RTSupportWrapper to get us into and out of SVC mode around the call to RTSupportWrapper. Also sets up our stack limit & relocation offsets within the SVC stack.
Admin:
  Tested in BCM2835 ROM


Version 0.16. Tagged as 'SCSISoftUSB-0_16'