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-0x1FFF 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: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
fel.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fel.c b/fel.c
index 40cb82a..a597e11 100644
--- a/fel.c
+++ b/fel.c
@@ -505,51 +505,51 @@ sram_swap_buffers ar100_abusing_sram_swap_buffers[] = {
soc_sram_info soc_sram_info_table[] = {
{
.soc_id = 0x1623, /* Allwinner A10 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en = 1,
},
{
.soc_id = 0x1625, /* Allwinner A13 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en = 1,
},
{
.soc_id = 0x1651, /* Allwinner A20 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
},
{
.soc_id = 0x1650, /* Allwinner A23 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1633, /* Allwinner A31 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x22E00, .thunk_size = 0x200,
.swap_buffers = a31_sram_swap_buffers,
},
{
.soc_id = 0x1667, /* Allwinner A33 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1673, /* Allwinner A83T */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1680, /* Allwinner H3 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.mmu_tt_addr = 0x8000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
--
2.4.10
