Date   

#api #api

r.gokool@...
 

Hello, I am new to Zephyr. I have a need to write code that runs on both RTOS and linux. It is structured as an event loop that can monitor sockets, local queues and timers for Linux. When looking at the APIs in the RTOS I noticed that there is no common poll API. I see k_poll() can poll kernel objects while zsock_poll() can poll sockets. Is there a way to monitor sockets and kernel objects using the same event loop?
If not I am curious to understand why the API deviates from Linux. Is there an RTOS specific benefit to splitting the poll api this way?

Input and suggestions requested. Thanks.


Build size of bluetooth and ip stack #bluetooth #nrf51822

mdl.mailme@...
 

Hi, 

i am trying to build the bluetooth/ipsp/ example for the nrf51, but the build fails because the SRAM overflows (50kB usage with 32kB available on the nRF51). Also, the Flash usage is 98%. I checked the zephyr_prebuilt.map file to see the sizes of the single modules/libraries. It shows that only the bluetooth and ip modules use around 180kB of Flash and 32kB of SRAM. Is it normal for it to be this large? If yes, is there a possibility of reducing the size of those modules?

I attached the zephyr_prebuilt.map file, the output of my self built parser showing the ROM and RAM usage of the single modules and the build output.

Kind regards,

Marco Liess


Re: getting started with ssd1306 shield

Erwan Gouriou
 

Hi Trevor,

What is the error reported ?

Erwan

On Tue, 14 Apr 2020 at 16:06, Trevor Clarke <pythonpimp@...> wrote:
I'm new to zephyr and I'm trying to get a 128x32 SSD1306 display working with a stm32 black pill and I'm having trouble.
My prj.conf has CONFIG_DISPLAY=y
My CMakeLists.txt has set(SHIELD ssd1306_128x32) before the boilerplate include.

When configuring I get a "Label or path arduino_i2c not found" so I tried adding "arduino_i2c=&i2c1" to my app overlay file and that didn't help.

Am I missing something in my app code? Or do I need to modify the shield code to accommodate stm32? If so, where would I get started with that?


--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


getting started with ssd1306 shield

Trevor Clarke
 

I'm new to zephyr and I'm trying to get a 128x32 SSD1306 display working with a stm32 black pill and I'm having trouble.
My prj.conf has CONFIG_DISPLAY=y
My CMakeLists.txt has set(SHIELD ssd1306_128x32) before the boilerplate include.

When configuring I get a "Label or path arduino_i2c not found" so I tried adding "arduino_i2c=&i2c1" to my app overlay file and that didn't help.

Am I missing something in my app code? Or do I need to modify the shield code to accommodate stm32? If so, where would I get started with that?


--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


Re: API meeting: agenda

Carles Cufi
 

Two additional items:

- DAC API proposal
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/21805

- Auth API location
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/23465

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Cufi, Carles via lists.zephyrproject.org
Sent: 13 April 2020 19:33
To: users@...; devel@...
Cc: julien.dascenzio@...; jukka.rissanen@...;
@jhe; Andersson, Joakim
<Joakim.Andersson@...>
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Tomorrow's topics:

- Proposal to unify the "forever" timeout constant across subsystems
that take milliseconds as an input parameter
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/24267

- RTC API proposal review after comments from the author
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/

Additional items in the "Triage" column in the GitHub project may be
discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub
project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-
8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


MCP2515 Interrupt #can

turboaffe@...
 

Hello everybody, this is my first post.
I have a problem with the drivers/can/can_mcp2515.c interrupt configuration/the mcp2515 driver implementation.
I would like to send a can message with the can_send function. On my board, a stm32 is connected to the mcp2515.
The message is sent, i see it on the bus via candump, and my logic analyzer shows a falling edge on the mcp2515 interrupt output as soon as the mcp2515 is done with sending.
The OS does not react on that falling edge, and my program is stuck on the blocking can_send function.
I discovered that the whole thing works if i change the interrupt edge configuration/gpio flags as follows in can_mcp2515.c, lines 860 to 862:

From: if (gpio_pin_interrupt_configure(dev_data->int_gpio, dev_cfg->int_pin, GPIO_INT_EDGE_TO_ACTIVE)) { return -EINVAL; }
To: if (gpio_pin_interrupt_configure(dev_data->int_gpio, dev_cfg->int_pin, GPIO_INT_EDGE_TO_INACTIVE)) { return -EINVAL; }

Can somebody point me to somebody who I could discuss this problem with? I am not sure if this is a bug or how it can work on the other boards, like the DF Robot CAN Shield one.

Thank you!


NFC Support #nxp #i2c #nvs

nanjunneo@...
 

Hello guys,

I would like to implement an application with NFC tag reader via NXP PN532 or other NFC controllers, which communicates with board via I2C, is there any suggestion or sample to follow how to start it?

Thanks for kind reply in advance.

Best regards,
Neo


API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow's topics:

- Proposal to unify the "forever" timeout constant across subsystems that take milliseconds as an input parameter
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/24267

- RTC API proposal review after comments from the author
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: issues with devicetree in 2.2

Bolivar, Marti
 

"Trevor Clarke via lists.zephyrproject.org"
<pythonpimp=gmail.com@...> writes:

'm using Zephyr 2.2 for stm32 through platformio. I'm trying to use the
newer device tree API to configure hardware through an overlay.
I've got an overlay with:

&usart3 { current-speed = <31250>; };
/ { aliases { midi-port = &usart2; }; };

In devicetree_unfixed.h I get defines like DT_ALIAS_MIDI_PORT_BASE_ADDRESS
so I know my overlay is being processed.

In my C code I do:

#define MIDI_DEV DT_ALIAS(midi_port)
...
struct device* midiin = device_get_binding(MIDI_DEV);
In the zephyr master branch, it would be DT_LABEL(MIDI_DEV).

https://docs.zephyrproject.org/latest/guides/dts/howtos.html#get-a-struct-device-from-a-devicetree-node

However: this won't work in 2.2.



When I compile (complete clean and rebuild which re-runs cmake, etc.) I see:

warning: implicit declaration of function 'DT_ALIAS';

A search through my build artifacts and through the zephyr source shows no
definie for DT_ALIAS. I'm following the examples in the documentation. Am I
missing something?
This new DT API is only in the master branch, not Zephyr 2.2.

Since you're on 2.2, use the old API:

https://docs.zephyrproject.org/2.2.0/guides/dts/index.html

HTH,
Marti


--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


issues with devicetree in 2.2

Trevor Clarke
 

'm using Zephyr 2.2 for stm32 through platformio. I'm trying to use the newer device tree API to configure hardware through an overlay. 
I've got an overlay with:

&usart3 { current-speed = <31250>; };
/ { aliases { midi-port = &usart2; }; };

In devicetree_unfixed.h I get defines like DT_ALIAS_MIDI_PORT_BASE_ADDRESS so I know my overlay is being processed.

In my C code I do:

#define MIDI_DEV DT_ALIAS(midi_port)
...
struct device* midiin = device_get_binding(MIDI_DEV);


When I compile (complete clean and rebuild which re-runs cmake, etc.) I see:

warning: implicit declaration of function 'DT_ALIAS';

A search through my build artifacts and through the zephyr source shows no definie for DT_ALIAS. I'm following the examples in the documentation. Am I missing something?

--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
retrev@...
http://www.csh.rit.edu/~retrev/


HWINFO API clarification

Steven Slupsky <sslupsky@...>
 

There were two recent issues (#23444, #24103) that identified a byte ordering issue with the hwinfo API.  A PR (#24203) has been submitted to clarify the hwinfo API identifier data structure.  This clarification has resulted in changes to the sam0 and nordic drivers.  Moreover, some components that depend on the hwinfo api may have implemented work arounds for this issue. Issue #24103 identified the USB identifier was affected and issue #23444 identified Bluetooth may be affected.

A summary of the commit is provided below.  Please note other drivers may be affected by this issue.
  
The identifier data structure for hwinfo drivers is clarified.  Drivers are responsible for ensuring that the identifier data structure is a sequence of bytes. The returned ID value is not supposed to be interpreted based on  vendor-specific assumptions of byte order and should express the identifier as a raw byte sequence.

The changes have an impact on users that use the hwinfo API to identify their devices.

The sam0 driver byte swaps each 32 bit word of the 128 bit identifier to big endian. The nordic driver byte swaps the entire 64 bit word to big endian.


Zephyr networking testing in LAVA, was: Re: Network forum agenda

Paul Sokolovsky
 

Hello,

On Mon, 6 Apr 2020 21:44:27 +0300
"Paul Sokolovsky via lists.zephyrproject.org"
<paul.sokolovsky=linaro.org@...> wrote:

[]

If there is time, I'd like to share some progress on setting up CI
for network testing with real hardware, on which I've been working
last time.
I appreciate being able to present my work quickly and the discussion
of testing matters which followed. As it was just a quick spoken
presentation, I'd like to share a few links showing more details, with
the idea to keep wider community in loop of testing efforts around
Zephyr.

So, in this work Linaro LITE team uses the LAVA system (Linaro
Automation and Validation Architecture), which is an open source
project at https://www.lavasoftware.org/ (we run a particular
deployment at https://lite.validation.linaro.org/).

How it works is that we build Zephyr tests/samples in Jenkins (using
the standard Zephyr "sanitycheck" tool), then submit binaries to LAVA,
accompanied by a "test job definition", which is a YAML file like
https://lite.validation.linaro.org/scheduler/job/960800/multinode_definition#defline1 .

The job is then being run, with log of interaction recorded and
analyzed for success/failure. In this case it's a networking test which
involves 2 "nodes": a DUT (device under test) per se (FRDM-K64F board):
https://lite.validation.linaro.org/scheduler/job/960800.0 and a docker
container representing "a host":
https://lite.validation.linaro.org/scheduler/job/960800.1#L56 . Here,
the actual test interaction happens on the host, which starts with
easy-pinging a device, then pings more with full Ethernet frames, then
does a "poorman's flood ping" of pinging 1000 times with full packets
and 10ms interval. All these actions are encoded in the YAML definition
and are easily reconfigurable.

LAVA checks that individual actions outcome satisfies success criteria
and records overall results, e.g.
https://lite.validation.linaro.org/results/960801/0_ping .

The biggest value of such a system would come from early notifications
of failures, and ability to compare results over time. The best ways to
achieve that is so far under investigation (the whole work is largely a
prototype at this stage).

As discussed yesterday, we all by now should be aware that "Zephyr
testing" bastion is being stormed by multiple stakeholders in different
ways, and I just wanted to share Linaro's approach and progress with
wider community. While the primary drivers for this works are
requirements of our members interested in Zephyr, who already adopted
the LAVA system, the work itself is open-source, results are public, and
hopefully useful for a wider Zephyr community. (And different teams
working on testing definitely should reuse results of each other's work,
and further the best practices for making Zephyr more testable and
quality-assured).


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


API meeting cancelled today

Carles Cufi
 

Hi all,

Due to several people being away and needing a bit more time to discuss some of the items offline I am cancelling this week's API meeting.
Next week the meeting will take place as usual.

Thanks,

Carles


Re: Network forum agenda

Paul Sokolovsky
 

Hello,

On Mon, 06 Apr 2020 15:01:40 +0300
"Jukka Rissanen" <jukka.rissanen@...> wrote:

Hi all,

There is a network forum meeting tomorrow 7 Apr at 8AM PDT / 17.00 CET

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#networking-forum
Thanks for the reminder, appreciated!

Preliminary agenda:

* Network stack status

* k_timeout_t changes in networking stack. Initial PR can be found at
https://github.com/zephyrproject-rtos/zephyr/pull/24071

* Review help needed for GSM 07.10 mux PR at
https://github.com/zephyrproject-rtos/zephyr/pull/23422

If you have anything you want to discuss, please let me know.
Will there be any status update on TCP2? I see recently there're
multiple patches from different developers, so would be nice to hear a
summary of where it stands and if it's ready to be explored by wider
community.

If there is time, I'd like to share some progress on setting up CI
for network testing with real hardware, on which I've been working last
time.


Cheers,
Jukka

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow 7 Apr at 8AM PDT / 17.00 CET

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#networking-forum

Preliminary agenda:

* Network stack status

* k_timeout_t changes in networking stack. Initial PR can be found at
https://github.com/zephyrproject-rtos/zephyr/pull/24071

* Review help needed for GSM 07.10 mux PR at
https://github.com/zephyrproject-rtos/zephyr/pull/23422

If you have anything you want to discuss, please let me know.


Cheers,
Jukka


Re: Assert in sched.c

Boie, Andrew P
 

Check for stack overflows, enable CONFIG_STACK_SENTINEL if you don't have an MPU.

 

From: users@... <users@...> On Behalf Of erik.johnson@...
Sent: Wednesday, April 1, 2020 4:24 PM
To: users@...
Subject: [Zephyr-users] Assert in sched.c

 

I'm running v2.1.99-ncs1, which is a downstream minimal fork provided by Nordic Semiconductor. For the purposes of this bug, I can't find any difference between their code and the upstream Zephyr source.

There's no tag for it, but we're using the nRF9160 from Nordic.

 

Anyway, I'm having an assertion in the tick sleep code. It seems that the assert is trying to make sure the resuming context isn't marked as "suspended", but somehow that assertion is getting hit...

 

I'm unfortunately just not familiar enough with the kernel yet to know what's going on, so I was hoping to get some help on it. In particular, if there are any kind of known "gotcha" cases that would cause this assertion.

 

I'm happy to provide as much information as I can, with the caveat that part of the source code impacted by this is not available: we're using a binary library from Nordic Semiconductor that runs code inside of a thread we're creating in our own source code.

The function being used is k_sleep(), and the function is successfully used a number of times. But, as soon as I do a particular other thing with a download client, I suddenly get the assert. Running the additional code will successfully do its stuff without issues a few times, but eventually the condition gets hit. As far as I can tell, it's not a race condition but rather based on some sort of state in the Nordic library.

 

Here's the assertion in the debug log:

ASSERTION FAIL [!z_is_thread_state_set(_kernel.current, ((1UL << (4))))] @ ZEPHYR_BASE/kernel/sched.c:1096

 

[00:05:05.932,373] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000457 r2/a3: 0x00000001

[00:05:05.941,314] <err> os: r3/a4: 0x00063757 r12/ip: 0x00000030 r14/lr: 0x00054c2b

[00:05:05.950,256] <err> os: xpsr: 0x61040000

[00:05:05.955,657] <err> os: s[ 0]: 0x00000001 s[ 1]: 0x00000001 s[ 2]: 0x00000001 s[ 3]: 0x00000001

[00:05:05.966,400] <err> os: s[ 4]: 0x00000001 s[ 5]: 0x00000001 s[ 6]: 0x00000001 s[ 7]: 0x00000001

[00:05:05.977,172] <err> os: s[ 8]: 0x00000001 s[ 9]: 0x00000001 s[10]: 0x00000001 s[11]: 0x00000001

[00:05:05.987,915] <err> os: s[12]: 0x00000001 s[13]: 0x00000001 s[14]: 0x00000001 s[15]: 0x00000001

[00:05:05.998,657] <err> os: fpscr: 0x00000000

[00:05:06.004,028] <err> os: Faulting instruction address (r15/pc): 0x00058806

[00:05:06.012,176] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0

[00:05:06.020,111] <err> os: Current thread: 0x200276c4 (unknown)

[00:05:06.027,099] <err> fatal_error: Resetting system


Assert in sched.c

erik.johnson@...
 

I'm running v2.1.99-ncs1, which is a downstream minimal fork provided by Nordic Semiconductor. For the purposes of this bug, I can't find any difference between their code and the upstream Zephyr source.

There's no tag for it, but we're using the nRF9160 from Nordic.
 
Anyway, I'm having an assertion in the tick sleep code. It seems that the assert is trying to make sure the resuming context isn't marked as "suspended", but somehow that assertion is getting hit...
 
I'm unfortunately just not familiar enough with the kernel yet to know what's going on, so I was hoping to get some help on it. In particular, if there are any kind of known "gotcha" cases that would cause this assertion.
 
I'm happy to provide as much information as I can, with the caveat that part of the source code impacted by this is not available: we're using a binary library from Nordic Semiconductor that runs code inside of a thread we're creating in our own source code.

The function being used is k_sleep(), and the function is successfully used a number of times. But, as soon as I do a particular other thing with a download client, I suddenly get the assert. Running the additional code will successfully do its stuff without issues a few times, but eventually the condition gets hit. As far as I can tell, it's not a race condition but rather based on some sort of state in the Nordic library.
 
Here's the assertion in the debug log:
ASSERTION FAIL [!z_is_thread_state_set(_kernel.current, ((1UL << (4))))] @ ZEPHYR_BASE/kernel/sched.c:1096
 
[00:05:05.932,373] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000457 r2/a3: 0x00000001
[00:05:05.941,314] <err> os: r3/a4: 0x00063757 r12/ip: 0x00000030 r14/lr: 0x00054c2b
[00:05:05.950,256] <err> os: xpsr: 0x61040000
[00:05:05.955,657] <err> os: s[ 0]: 0x00000001 s[ 1]: 0x00000001 s[ 2]: 0x00000001 s[ 3]: 0x00000001
[00:05:05.966,400] <err> os: s[ 4]: 0x00000001 s[ 5]: 0x00000001 s[ 6]: 0x00000001 s[ 7]: 0x00000001
[00:05:05.977,172] <err> os: s[ 8]: 0x00000001 s[ 9]: 0x00000001 s[10]: 0x00000001 s[11]: 0x00000001
[00:05:05.987,915] <err> os: s[12]: 0x00000001 s[13]: 0x00000001 s[14]: 0x00000001 s[15]: 0x00000001
[00:05:05.998,657] <err> os: fpscr: 0x00000000
[00:05:06.004,028] <err> os: Faulting instruction address (r15/pc): 0x00058806
[00:05:06.012,176] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:05:06.020,111] <err> os: Current thread: 0x200276c4 (unknown)
[00:05:06.027,099] <err> fatal_error: Resetting system


API meeting: agenda

Carles Cufi
 

Hi all,

Note: Today we go back to our usual 9AM PDT / 18h CET.

Today's topics:

- Template to document a driver implementation: discussion as to what it should include

- API Terminology refinements
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23867

- onoff service refactor conclusion
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23601

- async notify service redesign conclusion
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23898

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


FW: Zephyr CMake package / find_package(Zephyr)

Carles Cufi
 

 

 

From: announce@... <announce@...> On Behalf Of Rasmussen, Torsten via Lists.Zephyrproject.Org
Sent: 30 March 2020 15:32
To: announce@...
Cc: announce@...
Subject: [Zephyr-announce] Zephyr CMake package / find_package(Zephyr)

 

Hi All,

 

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

 

This means a simple Zephyr application now looks as:

# Find Zephyr. This also loads Zephyr's build system.

cmake_minimum_required(VERSION 3.13.1)

find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

project(my_zephyr_app)

 

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

 

For this to work, it is necessary to execute a new west command: `west zephyr-export`

This command only needs to be executed once, for example after a `west init`

 

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

 

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

 

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,

but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

 

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

 

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

 

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):

https://docs.zephyrproject.org/latest/getting_started/index.html

https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html

 

 

Best regards

 

Torsten

 


Re: Changing partitions in a DTS overlay

Lawrence King
 

Hi Martin:

 

Excellent, thank you. The bit I missed was the correct syntax for /delete-node/

 

I put the following 3 lines just before &flash0

 

/delete-node/ &slot0_partition;

/delete-node/ &slot1_partition;

/delete-node/ &scratch_partition;

 

After this the other changes work correctly.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Martin Kozusky <news@...>
Sent: Saturday, March 28, 2020 2:58 AM
To: users@...
Cc: Lawrence King <lawrence.king@...>
Subject: Re: [Zephyr-users] Changing partitions in a DTS overlay

 

Hi,
this is how my overlay looks like (and it's working) - I wanted to make storage partition smaller and add 2 more partitions. Since I didn't change image0,1 and scratch size, I didn't have to use overlay when compiling mcuboot. Changing slot0 and 1 size should be similar, but I think this time you will have to use the overlay also when compiling mcuboot.

 

/delete-node/ &storage_partition;

&flash0 {
 partitions {
  compatible = "fixed-partitions";
 
   info_partition: partition@7a000 {
    label = "info";
    reg = <0x0007a000 0x00001000>;
   };
   
    nvs_partition: partition@7b000 {
    label = "nvs";
    reg = <0x0007b000 0x00002000>;
   };
   
   storage_partition: partition@7d000 {
    label = "storage";
    reg = <0x0007d000 0x00003000>;
   };
 
  };
 };

 

Martin

 

Dne 27.03.2020 v 22:33 Lawrence King napsal(a):

Dear all:

 

I am trying to change the partition table from the default as defined in the board file inside Zephyr to a slightly different configuration. Obviously I could do this by editing the file in the zephyr tree but this has the disadvantage that I have to redo the change each time I upgrade the kernel. Hence I would like to make the change in the overlay. Here is what I did in the overlay:

 

&flash0 {

        /*

         * For more information, see:

         * http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions

         */

        partitions {

                compatible = "fixed-partitions";

                #address-cells = <1>;

                #size-cells = <1>;

 

                boot_partition: partition@0 {

                        label = "mcuboot";

                        reg = <0x000000000 0x0000C000>;

                };

/*

                slot0_partition: partition@c000 {

                        label = "image-0";

                        reg = <0x0000C000 0x000067000>;

                };

                slot1_partition: partition@73000 {

                        label = "image-1";

                        reg = <0x00073000 0x000067000>;

                };

                scratch_partition: partition@da000 {

                        label = "image-scratch";

                        reg = <0x000da000 0x0001c000>;

                };

*/

                slot0_partition: partition@c000 {

                        label = "image-0";

                        reg = <0x0000C000 0x000075800>;

                };

                slot1_partition: partition@81800 {

                        label = "image-1";

                        reg = <0x00081800 0x000075800>;

                };

 

                /*

                 * The flash starting at 0x000f8000 and ending at (32kB)

                 * 0x000fffff is reserved for use by the application.

                 */

 

                /* Storage partition will be used by FCB/NFFS/NVS if enabled. */

                storage_partition: partition@f8000 {

                        label = "storage";

                        reg = <0x000f8000 0x00008000>;

                };

        };

};

 

As you can see I commented out the definitions of slot0, slot1 and scratch, then I added in new definitions for slot0 and slot1. When I attempt to compile this I get a fatal error:

 

nrf52840_mdk.dts.pre.tmp:546.50-549.19: ERROR (duplicate_label): /soc/flash-controller@4001e000/flash@0/partitions/partition@81800: Duplicate label 'slot1_partition' on /soc/flash-controller@4001e000/flash@0/partitions/partition@81800 and /soc/flash-controller@4001e000/flash@0/partitions/partition@73000

ERROR: Input tree has errors, aborting (use -f to force output)

 

The device tree compile didn’t mind changing the size of the slot0 partition, but it hated changing the base address of the slot1 partition.

 

I tried leaving the partition address at 73000, it compiles, but the device tree compiler complains “warning: unit-address and first reg (0x81800) don't match for partition@73000” and mcuboot complains “<wrn> mcuboot: Cannot upgrade: slots don't have same amount of sectors”.

I also tried many variations on adding /delete-node/ and /delete-property/ in front of the definitions but this just gave me other errors.

 

Obviously I am going about this incorrectly. What is the right way to change the partition table in a device tree overlay?

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 -
                linkedin  3 -
                instagram  4 -
                youtube  6
                - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.