You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Set ET_ARM_BAREMETAL_FAST_SCRATCH_TEMP_ALLOCATOR_POOL_SIZE depending
on Dedicated_Sram configuration.
- Refactor linker scripts to allow NOLOAD on zero-initialized sections,
reducing built binary size.
- Add functional output sections: - .sram.rodata / .ddr.rodata for
constant data. - .sram.bss / rename ddr_noload ->.ddr.bss for memory
arenas. These sections are NOLOAD.
- Add rom_model PHDR so model data has its own load segment.
- Change .heap and .stack from COPY to NOLOAD.
- Move input sections:
- network_model_sec: .sram/.ddr -> .sram.rodata/.ddr.rodata
- .bss.tensor_arena: .sram.bss/.ddr -> .sram.bss/.ddr.bss
- Make generated embedded PTE data const.
cc @digantdesai@freddan80@per@zingo@oscarandersson8218@mansnils@Sebastian-Larsson@robell@rascani
Signed-off-by: Erik Lundell <erik.lundell@arm.com>
Copy file name to clipboardExpand all lines: examples/arm/ethos-u-porting-guide.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,17 +85,17 @@ expected to place the scratch buffer and NN in the correct memory location.
85
85
For example, if you generate a pte file with compile specification for Shared Sram, the scratch buffer should be placed in the SRAM and the NN in the external memory in the runtime application code. You can see we are following
86
86
this approach in the `examples/arm/executor_runner/arm_executor_runner.cpp` example application. In the linker scripts for the application(`examples/arm/executor_runner/Corstone-320.ld` and
87
87
`examples/arm/executor_runner/Corstone-300.ld`) we check the value of `ETHOSU_ARENA` to determine whether the ethos-u scratch buffer is placed in the on-chip memory or in the external memory. In this
88
-
way, depending on the `ETHOSU_ARENA` parameter, the linker knows whether the symbol is to be placed in the .ddr or .sram.bss sections. The `ETHOSU_ARENA` parameter is set in the `backends/arm/scripts/corstone_utils.cmake` and
89
-
its value is derived based on the memory mode parameter that is passed to the `examples/arm/run.sh` shell script. Then, at link time, the .ddr section is always placed in the external memory and the .sram.bss is always placed in the SRAM.
88
+
way, depending on the `ETHOSU_ARENA` parameter, the linker knows whether the input section is to be placed in the .ddr.bss or .sram.bss sections. The `ETHOSU_ARENA` parameter is set in the `backends/arm/scripts/corstone_utils.cmake` and
89
+
its value is derived based on the memory mode parameter that is passed to the `examples/arm/run.sh` shell script. Then, at link time, the .ddr.bss section is always placed in the external memory and the .sram.bss is always placed in the SRAM.
90
90
Finally, note that in the `examples/arm/executor_runner/arm_executor_runner.cpp` application code, we place the buffers for the Ethos-u scratch and the neural network in the correct symbol from the linker script. For instance,
91
-
the Ethos-u scratch buffer corresponds to the the `.bss.tensor_arena` section in the linker script, In the application code, when we allocate memory for the Ethos-u scratch buffer, we place this array in the .bss.tensor_arena section in the memory map.
91
+
the Ethos-u scratch buffer corresponds to the the `.bss.tensor_arena`input section in the linker script, In the application code, when we allocate memory for the Ethos-u scratch buffer, we place this array in the .bss.tensor_arena section in the memory map.
and the `.bss.tensor_arena` section is placed in the correct location in the memory map thanks to
98
+
and the `.bss.tensor_arena`input section is placed in the correct location in the memory map thanks to
99
99
the `ETHOSU_ARENA` parameter.
100
100
101
101
There is a tight coupling between the memory mode for the Ethos-U and the placement of the ethos-u scratch buffer,
@@ -125,4 +125,4 @@ how we populate the input tensor depending on its data type.
125
125
The ExecuTorch project already provides an Arm Ethos-U backend in `executorch/backends/arm/runtime/` that you can reuse as is. The key steps to bring up a new platform is to reuse the Ethos-U driver
126
126
and ensure that the NPU base address and interrupt assignment matches your SoC. The `examples/arm/executor_runner/arm_executor_runner.cpp` is an example application running on the Corstone platform.
127
127
For the `arm_executor_runner.cpp` application, we are relying on the NPU initialization done in the core-platform project and we integrate core-platform in the
128
-
`backends/arm/scripts/corstone_utils.cmake` script. Then, we inherit the core-platform integration of the Ethos-U driver and the CMSIS boot code for the Cortex-M core.
128
+
`backends/arm/scripts/corstone_utils.cmake` script. Then, we inherit the core-platform integration of the Ethos-U driver and the CMSIS boot code for the Cortex-M core.
0 commit comments