Skip to content

GitLab

Switch branch/tag
  1. 05 May, 2016 1 commit
    • Siarhei Siamashka's avatar
      fel: Move the temporary scratch buffer under the IRQ stack · 118dfa8e
      Siarhei Siamashka authored 
      

Doing certain operations may need uploading and executing code
on the device. For example, such operations right now are
reading/writing ARM CP15 coprocessor registers. Uploading the
code to the device is naturally overwriting some part of SRAM
as a side effect. Right now it is not a problem, because the
CP15 coprocessor registers are only accessed as part of uploading
and executing U-Boot SPL. They are nicely timed not to cause
problems and the temporary scratch area gets overwritten by
the SPL code anyway.

But if we decide to provide access to such operations via
command line interface, then any side effects may potentially
cause problems for the users. Consider the following scenario:

  sunxi-fel clear 0x2000 0x100 \
            advanced-command-which-uploads-and-executes-code \
            hexdump 0x2000 0x100

The user may rightfully expect that clearing a buffer in SRAM
to zero and then reading it back should show all zero bytes.
But inserting advanced commands in the middle may cause data
corruption.

In order to resolve this problem, just move the scratch area
away from the 0x2000-0x5BFF addresses range. These particular
addresses are already known to the users as a safe place for
their bare metal expariments in FEL mode. The "sunxi-fel spl"
command is a special case though and it is expected to
overwrite data in this area too.

A possible alternative would be to just backup & restore data
in the scratch area. But this has some disadvantages:
  1. Extra code in the sunxi-fel tool and extra roundtrips over
     USB to do the backup/restore job.
  2. If we allow the OpenRISC core to use the 0x2000-0x5C00
     range in SRAM A1, then this becomes unsafe and racy
     (we can't really backup & restore data without causing
     a temporarily glitch for the currently running code on
     the OpenRISC core).

To sum it up. With this patch we make it so that now the
0x2000-0x5BFF range is freely available for the users of the
sunxi-fel tool. The 0x1000-0x1FFF range is off limits (the
upper part of it is used by the FEL IRQ handler, the lower
part of it is reserved for internal use by the sunxi-fel
tool). The 0x0000-0x0FFF addresses range is reserved for
passing data from the SPL to the main U-Boot binary (via
the SPL header) and is also off limits.
Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
Tested-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>
      118dfa8e
  3. 04 May, 2016 10 commits
  5. 03 May, 2016 5 commits
  7. 20 Apr, 2016 11 commits
  9. 21 Mar, 2016 2 commits
  11. 20 Mar, 2016 2 commits
  13. 17 Dec, 2015 3 commits
  15. 16 Dec, 2015 6 commits