"dummy-flash" device tree possible bug?
|
Diego Sueiro
Hi there, I'm currently working on porting Zephyr to i.MX7 SoC and I'm facing an error with cmake when it is generating the generated_dts_board.h. I want to use only the sram and in my dts I removed the "zephyr,flash" property. I'm not sure if I'm doing this correctly. If I don't want a flash should I need to set it to a specific entry or just remove the property from the dts? Error message: Makefile:854: recipe for target 'cmake_check_build_system' failed make: *** [cmake_check_build_system] Error 1 -- Selected BOARD colibri_imx7d_m4 Zephyr version: 1.10.99 Parsing Kconfig tree in <snip>/Kconfig Using <snip>/tests/shell/build/colibri_imx7d_m4/zephyr/.config as base -- Generating zephyr/include/generated/generated_dts_board.h Traceback (most recent call last): File "<snip>/scripts/dts/extract_dts_includes.py", line 906, in <module> main() File "<snip>/scripts/dts/extract_dts_includes.py", line 896, in main insert_defs(chosen['zephyr,flash'], defs, load_defs, {}) KeyError: 'zephyr,flash' CMake Error at <snip>/dts/dts.cmake:111 (message): command failed with return code: 1 Call Stack (most recent call first): <snip>/cmake/app/boilerplate.cmake:227 (include) CMakeLists.txt:1 (include) I managed to fix the error with this change: diff --git a/scripts/dts/extract_dts_includes.py b/scripts/dts/extract_dts_includes.py index e917deb..c03f236 100755 --- a/scripts/dts/extract_dts_includes.py +++ b/scripts/dts/extract_dts_includes.py @@ -889,11 +889,13 @@ def main(): load_defs['CONFIG_FLASH_LOAD_SIZE'] = \ lookup_defs(part_defs, chosen['zephyr,code-partition'], 'PARTITION_SIZE') + node_address = chosen['zephyr,flash'] else: load_defs['CONFIG_FLASH_LOAD_OFFSET'] = 0 load_defs['CONFIG_FLASH_LOAD_SIZE'] = 0 + node_address = 'dummy-flash' - insert_defs(chosen['zephyr,flash'], defs, load_defs, {}) + insert_defs(node_address, defs, load_defs, {}) Regards, *dS Diego Sueiro
|
|
|
|
Michael Hope <michaelh@...>
Hi Diego. zephyr,flash sets where the main code is stored and is used to calculate the address and size of the code section. In your case it probably doesn't make sense as you'll probably store things in DRAM on the i.MX7. If I was you I'd leave a fake flash entry in the dts file and use it to set the RAM load address. -- Michael
On Wed, 7 Feb 2018 at 20:19 Diego Sueiro <diego.sueiro@...> wrote:
|
|
|
|
Diego Sueiro
Hello Michael, On 7 February 2018 at 19:27, Michael Hope <michaelh@...> wrote:
You mean setting the same entry for the flash and sram? Something like that? chosen { zephyr,flash = &ocram; zephyr,sram = &ocram; zephyr,console = &uart2; }; What is the usage and purpose of "dummy-flash"? I belive it can be used when you want to use a debugger to load and execute the code directly in the sram. Getting the elf header of this 2 different approaches we have: 1) zephyr,flash = zephyr,sram: Memory region Used Size Region Size %age Used FLASH: 16388 B 128 KB 12.50% SRAM: 7332 B 128 KB 5.59% IDT_LIST: 36 B 2 KB 1.76% Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x20200000 0x20200000 0x0343a 0x0343a RWE 0x4 LOAD 0x0034f0 0x20200000 0x20200000 0x00000 0x01ba8 RW 0x8 LOAD 0x0034f0 0x2020343c 0x2020343c 0x00acc 0x00acc RW 0x4 LOAD 0x003fbc 0x20201ba8 0x20203f08 0x000fc 0x000fc RW 0x4 Section to Segment mapping: Segment Sections... 00 text bss noinit 01 bss noinit 02 devconfig rodata 03 datas initlevel initshell 2) no zephyr,flash in dts (and with my "fix"): Memory region Used Size Region Size %age Used FLASH: 0 GB 0 GB -nan% SRAM: 23348 B 112 KB 20.36% IDT_LIST: 36 B 2 KB 1.76% Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000078 0x20200000 0x20200000 0x03e90 0x05a38 RWE 0x8 LOAD 0x003f08 0x20205a38 0x20205a38 0x000fc 0x000fc RW 0x4 Section to Segment mapping: Segment Sections... 00 text devconfig rodata bss noinit 01 datas initlevel initshell
|
|
|
|
Maureen Helm
Hi Diego, Take a look at the mimxrt1050_evk board. The SoC doesn’t have embedded flash, so I mapped the flash entry to ITCM which is in SRAM. “zephyr,sram” is mapped to DTCM, which is a different region in SRAM.
You can then use a debugger to load code directly into SRAM.
Maureen
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...]
On Behalf Of Diego Sueiro
Hello Michael,
On 7 February 2018 at 19:27, Michael Hope <michaelh@...> wrote:
You mean setting the same entry for the flash and sram? Something like that?
chosen { zephyr,flash = &ocram; zephyr,sram = &ocram; zephyr,console = &uart2; };
What is the usage and purpose of "dummy-flash"? I belive it can be used when you want to use a debugger to load and execute the code directly in the sram.
Getting the elf header of this 2 different approaches we have:
1) zephyr,flash = zephyr,sram: Memory region Used Size Region Size %age Used FLASH: 16388 B 128 KB 12.50% SRAM: 7332 B 128 KB 5.59% IDT_LIST: 36 B 2 KB 1.76%
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x20200000 0x20200000 0x0343a 0x0343a RWE 0x4 LOAD 0x0034f0 0x20200000 0x20200000 0x00000 0x01ba8 RW 0x8 LOAD 0x0034f0 0x2020343c 0x2020343c 0x00acc 0x00acc RW 0x4 LOAD 0x003fbc 0x20201ba8 0x20203f08 0x000fc 0x000fc RW 0x4
Section to Segment mapping: Segment Sections... 00 text bss noinit 01 bss noinit 02 devconfig rodata 03 datas initlevel initshell
2) no zephyr,flash in dts (and with my "fix"): Memory region Used Size Region Size %age Used FLASH: 0 GB 0 GB -nan% SRAM: 23348 B 112 KB 20.36% IDT_LIST: 36 B 2 KB 1.76%
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000078 0x20200000 0x20200000 0x03e90 0x05a38 RWE 0x8 LOAD 0x003f08 0x20205a38 0x20205a38 0x000fc 0x000fc RW 0x4
Section to Segment mapping: Segment Sections... 00 text devconfig rodata bss noinit 01 datas initlevel initshell
|
|
|
|
Diego Sueiro
Thanks for the suggestion. This is an interesting approach as well. I still want to understand how to use the "dummy-flash" and if I can assign the same memory node for the flash and sram because looking at the elf headers it seems that it can work. I'll be able to make some tests this weekend and see how they go.
|
|
|
|
Michael Hope <michaelh@...>
Hi Diego. Looks like Maureen has pointed you in the right direction. Thanks Maureen! -- Michael
On Thu, 8 Feb 2018 at 06:59 Diego Sueiro <diego.sueiro@...> wrote:
|
|
|
|
Diego Sueiro
Just to give you an update on this. It works when using 2 different RAMs regions for flash and. But I still want to understand the usage of the "dummy-flash" and if I'm setting it correctly because I'm having configuration issues #6365 (for now I submitted the PR #6366 to fix this problem). There will be use cases where just one RAM will be available in the system for Zephyr and this RAM will have to accommodate both code and data. And to get this working I had to apply the mentioned PR and omit the "zephyr,flash" property from dts. Regards, *dS Diego Sueiro
|
|
|
|
Kumar Gala
On Mar 9, 2018, at 12:00 AM, Diego Sueiro <diego.sueiro@...> wrote:When you are using one RAM region for both memory & code, are you splitting the region up some how from Zephyr’s perspective? Rather than ‘dummy-flash’ we need to handle the use case correctly. - k
|
|
|
|
Diego Sueiro
Kumar, When you are using one RAM region for both memory & code, are you splitting the region up some how from Zephyr’s perspective? From the source code itself, there is no difference. For now, I'm only testing the shell subsys sample application. I'm not storing anything. The linker does all the necessary job to generate a working/bootable binary. I tried to use the same memory region for both flash and sram in the dts but the zephyr binary doesn't boot. I compared the elf header between the two approaches and they are different, but since I'm not an expert in linker and program memory layout I haven't looked into it in detail. On 9 March 2018 at 14:16, Kumar Gala <kumar.gala@...> wrote:
|
|
|