"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
 

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:
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

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Diego Sueiro
 

Hello Michael,

On 7 February 2018 at 19:27, Michael Hope <michaelh@...> wrote:
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.

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
Sent: Wednesday, February 7, 2018 11:59 PM
To: Michael Hope <michaelh@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] "dummy-flash" device tree possible bug?

 

Hello Michael,

 

On 7 February 2018 at 19:27, Michael Hope <michaelh@...> wrote:

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.

 

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
 

Hello Maureen,

On 8 February 2018 at 15:08, Maureen Helm <maureen.helm@...> wrote:

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.

 


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
 

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:
Hello Michael,

On 7 February 2018 at 19:27, Michael Hope <michaelh@...> wrote:
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.

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
 

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@gmail.com> wrote:

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.
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?
Rather than ‘dummy-flash’ we need to handle the use case correctly.

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. 


Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/

On 9 March 2018 at 14:16, Kumar Gala <kumar.gala@...> wrote:

> On Mar 9, 2018, at 12:00 AM, Diego Sueiro <diego.sueiro@...> wrote:
>
> 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.
>

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