1. 01 Oct, 2019 1 commit
  2. 24 Aug, 2019 1 commit
  3. 20 Aug, 2019 2 commits
  4. 18 Aug, 2019 1 commit
    • Rahix's avatar
      fix(api): Reset FPU before loading a new payload · e924ecee
      Rahix authored
      Without resetting the FPU we get spurious failures in Pycardium.  These
      manifest in many different forms, ranging from HardFaults and triggered
      assertions to "syntax errors" in loaded scripts while said script does
      not contain any.
      These failures stem from the FPU still containing state from the last
      loaded payload and thus sometimes corrupting stack locations where the
      previous payload had floating point state.
      Closes #72.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
  5. 16 Aug, 2019 1 commit
  6. 15 Aug, 2019 5 commits
    • Rahix's avatar
      feat(epicardium): Add core 1 lifecycle · b7c0b608
      Rahix authored
      This commit introduces a lifecycle for core 1.  Based on the new loading
      system, a few APIs are made available to control the payload running on
      core 1.  These are:
      1. From core 1 (Pycardium, L0dable):
          - `epic_exec(name)` API Call:  Request loading of a new payload by
            name.  If the file does not exist, the call will return with an
            error code.  Otherwise, control will go to the new payload.
          - `epic_exit(retcode)` API Call:  Return from payload
            unconditionally.  This call should be called whenever a payload is
            done or when it has hit an unrecoverable error.  On `epic_exit`,
            Epicardium will reset the core back into the menu.
      2. From inside Epicardium:
          - `epic_exec(name)`: This is **not** the same as the API call, as it
            needs a different implementation underneath.  It will load a new
            payload and wait until this load actually completed (synchroneous).
          - `return_to_menu()`: Return core 1 to the menu script no matter
            what it is currently doing.  This call is asynchroneous and will
            return immediately after scheduling the lifecycle task.  This task
            will then take care of actually performing the load.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      feat(epicardium): Implement basic core 1 lifecycle · 3b9393fe
      Rahix authored
      This commit introduces a way to control core 1.  This is archieved by a
      predefined API-Interrupt:  The reset interrupt.  When triggered, it will
      bring the core back into its default state and wait for a new vector
      address from Epicardium.  Once this vector address is transferred, it
      will start the new payload.
      This method only works as long as core 1 is responsive to the API
      interrupts.  Cases where this might not be the case:
        - During times where core 1 has interrupts disabled
        - When in a higher priority exception handler
        - When core 1 has corrupted its IVT
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      fix(api): Make reset interrupt non-maskable · bf88fd75
      Rahix authored
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      fix(api): Change interrupt idle value to -1 · 941fb5c4
      Rahix authored
      Previously 0 was used but as 0 is also the ID of the reset interrupt,
      this could lead to weird behaviors.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      feat(api): Add initial argument passing · b8940bcd
      Rahix authored
      This allows pycardium to learn which script it should start once it
      boots.  Arguments can only be read before any API calls are made.
      Afterward they are lost.
      To ensure they won't collide with anything during a core 1 restart,
      they are offset by 0x20 from the start of the API buffer.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
  7. 05 Aug, 2019 1 commit
  8. 31 Jul, 2019 1 commit
  9. 21 Jul, 2019 2 commits
  10. 20 Jul, 2019 4 commits
  11. 18 Jul, 2019 1 commit
  12. 06 Jul, 2019 2 commits
  13. 04 Jul, 2019 3 commits
  14. 24 Jun, 2019 1 commit
  15. 23 Jun, 2019 4 commits
  16. 18 Jun, 2019 1 commit