Skip to content

GitLab

Switch branch/tag
  1. 05 May, 2016 2 commits
    • Bernhard Nortmann's avatar
      fel: Add "readl" and "writel" commands · 3269b963
      Bernhard Nortmann authored 
      
Signed-off-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>

Squashed commit of the following:

commit 95f3614357446c4a35ec541bb2c21503c54d3fac
Author: Bernhard Nortmann <bernhard.nortmann@web.de>
Date:   Fri Apr 8 09:10:17 2016 +0200

    fel: Add support for multiple sequential readl/writel

    There are cases where "long" reads/writes might be used to transfer
    multiple values from/to sequential addresses.

    When doing so, we can avoid having to setup and upload the entire
    scratch buffer (ARM code) every time, by making the underlying
    functions auto-increment the address on each invocation.

    The patch implements this functionality, and maps the existing
    aw_fel_readl() and aw_fel_writel() to special cases (count == 1).
Signed-off-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>

commit 20ececdfc7f3c4070469a7b74ba77bb74e01f876
Author: Bernhard Nortmann <bernhard.nortmann@web.de>
Date:   Fri Apr 8 09:00:20 2016 +0200

    fel: Modify handling of command line args for "readl"/"writel"

    Most other commands use their decoded argument values directly,
    without storing them to local vars first. Also "writel" needs
    an (argc > 3).
Signed-off-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>

commit b4216371b97e9f1dd19f7fc2ce720b9cb8e2434e
Author: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date:   Sat Dec 19 08:22:26 2015 +0200

    fel: Add "readl" and "writel" commands

    The read/write operations done by FEL are not suitable for accessing
    hardware registers. For example, trying to read a SID value using
    the "read" or "hexdump" commands results in the following:

      $ sunxi-fel hexdump 0x01c23800 4
      01c23800: 87 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __

    Apparently, FEL tries to read data one byte at a time and this does
    not always work correctly. Introducing new commands to explicitly
    do 32-bit reads and writes helps:

      $ sunxi-fel readl 0x01c23800
      0x16254187
Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
Tested-by: default avatarBernhard Nortmann <bernhard.nortmann@web.de>
      3269b963
    • 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 5 commits