Date   

Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Sebastian Boe
 

The multi-image approach in NCS will not make it's way into mainline Zephyr because
it was not accepted upstream unfortunately.

________________________________________
From: Marc Reilly <marc.reilly@gmail.com>
Sent: Tuesday, December 10, 2019 4:25 PM
To: Bolivar, Marti
Cc: Bøe, Sebastian; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Managing/structuring multi image/binary projects for (OTA updatable products etc)

Hi Marti, Sebastian, list

Thanks for the ideas, my replies are inline below.


Hi, I see you are using nrf.

Signing, building, and hex merging of multiple images in a single west command is supported
out-of-the box with the nRF Connect SDK, which uses a patched Zephyr.

This led me to find the "multiple images" documentation for the NCS Zephyr (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/application/index.html#building-and-configuring-multiple-images) ...


So if not using vanilla Zephyr is an option then see:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_application_update/README.html#http-application-update-sample
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html
I second Sebastian's suggestion to look at nRF Connect SDK (NCS).
It has useful features for building OTA binaries for nRF devices.


.. it looks like the NCS capabilities will do what I wanted with regard to building a bootloader + app in one go. I haven't had time to look at it properly, but it seems like the strategy is to make the bootloader an extra output of the primary 'app' project (ie extra targets in the app project cmake).
This is a different approach than what I was thinking of. I was envisaging that the bootloader and app were treated as more isolated projects, and were configured and glued together by another higher level _something_.

Traditionally, I tend away from relying too much on vendor 'BSP's for the long term, they've tend to stagnate or diverge too much from mainline as time goes on.

Does anyone know if there are any plans to bring NCS's 'multi-image' functionality into mainline zephyr?

--snip--


-----

West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:

west init -m git@gitlab.com:SomeManifestRepo.git
west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
west sign ...

However, it would be nice to be able to glue this all together with
some script etc to simplify the extra elements of the west commands
('theboard' 'BOARD_ROOT') etc.
No matter what you choose to use (mainline or NCS), though, you can
always tell 'west build' your default board like this:

west config build.board theboard

https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#configuration-options

The build.board value will be used if you don't provide --board
(provided BOARD is also unset in the calling environment).


This is useful to know, thanks !


I thought about your BOARD_ROOT question. I've gotten other similar
requests recently, and I agree it would be useful, so I've proposed a
new "build.cmake-args" config option:

https://github.com/zephyrproject-rtos/zephyr/pull/21251

With the patch from #21251, you can save your BOARD_ROOT like this:

west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Your one-time setup work would then be:

west init -m git@gitlab.com/SomeManifestRepo.git<http://git@gitlab.com/SomeManifestRepo.git>
west update
west config build.board theboard
west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Note that plain 'west config var val' sets configuration options locally
(just for your west installation). See the --global and --system options
in the 'west config' documentation for alternatives.

# build and flash
west build -d build-mcuboot -s mcuboot/boot/zephyr
west build -d build-app -s app
west sign ...

And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.

Alternatives:
- copy 'glue' script into west installation folder ?
- west commands ? in the manifest repo, or maybe another common lib etc.
I hope the above is what you're looking for.


I think what I was envisaging was something to glue together the above commands (and keep some separation between the specific 'app' and the bootloader), I thought this would be 'west', but maybe not.. to take this approach would mean having to invoke the build/sign/whatever commands from the 'west installation' folder, and it would only be available from the manifest repo folder.


Note 'west build' can only compile one Zephyr application at a time.
The NCS can build application and mcuboot binaries at once out of the
box, for reference.

Please test and comment in the PR if you get a chance.

Done!, thanks.

Cheers
Marc


Re: Why the default MAC address is not shown in the host when using hciconfig command in linux #hci #ble #nrf52 #nrf52840

Johan Hedberg
 

Hi Venkatesh,

On 10. Dec 2019, at 15.18, Venkatesh Dyagala <venkatesh.dyagala@ivativ.com> wrote:
Now when we insert into linux PC and when i check the device using the hciconfig command the MAC address of the dongle is 00:00:00:00:00:00
But when we used bluetoothctl show command a 6byte MAC address is shown.
hciconfig uses a legacy ioctl kernel interface which is only able to retrieve the public address of a controller. nRF controllers do not come with any public address by default, which is why you only see zeroes. What controllers do need is an identity address, and that can be either a public address or a static random address. It’s the latter that gets automatically set by bluetoothd and what bluetoothctl shows you. bluetoothctl is a D-Bus client that simply shows the “Address” property of the Adapter object. That needs to be combined with the “AddressType” property to know that type of address it is (in your case it would be “random”).

Johan


Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Marc Reilly
 

Hi Marti, Sebastian, list

Thanks for the ideas, my replies are inline below.


> Hi, I see you are using nrf.
>
> Signing, building, and hex merging of multiple images in a single west command is supported
> out-of-the box with the nRF Connect SDK, which uses a patched Zephyr.



 
> So if not using vanilla Zephyr is an option then see:
>
> https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_application_update/README.html#http-application-update-sample
> https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html

I second Sebastian's suggestion to look at nRF Connect SDK (NCS).
It has useful features for building OTA binaries for nRF devices.


 .. it looks like the NCS capabilities will do what I wanted with regard to building a bootloader + app in one go. I haven't had time to look at it properly, but it seems like the strategy is to make the bootloader an extra output of the primary 'app' project (ie extra targets in the app project cmake).
This is a different approach than what I was thinking of. I was envisaging that the bootloader and app were treated as more isolated projects, and were configured and glued together by another higher level _something_.

Traditionally, I tend away from relying too much on vendor 'BSP's for the long term, they've tend to stagnate or diverge too much from mainline as time goes on.
 
Does anyone know if there are any plans to bring NCS's 'multi-image' functionality into mainline zephyr?

--snip--


> -----
>
> West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:
>
> west init -m git@...:SomeManifestRepo.git
> west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
> west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
> west sign ...
>
> However, it would be nice to be able to glue this all together with
> some script etc to simplify the extra elements of the west commands
> ('theboard' 'BOARD_ROOT') etc.

No matter what you choose to use (mainline or NCS), though, you can
always tell 'west build' your default board like this:

  west config build.board theboard

https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#configuration-options

The build.board value will be used if you don't provide --board
(provided BOARD is also unset in the calling environment).
 

This is useful to know, thanks !

 
I thought about your BOARD_ROOT question. I've gotten other similar
requests recently, and I agree it would be useful, so I've proposed a
new "build.cmake-args" config option:

  https://github.com/zephyrproject-rtos/zephyr/pull/21251

With the patch from #21251, you can save your BOARD_ROOT like this:

  west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Your one-time setup work would then be:

  west init -m git@.../SomeManifestRepo.git
  west update
  west config build.board theboard
  west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Note that plain 'west config var val' sets configuration options locally
(just for your west installation). See the --global and --system options
in the 'west config' documentation for alternatives.

  # build and flash
  west build -d build-mcuboot -s mcuboot/boot/zephyr
  west build -d build-app -s app
  west sign ...

> And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.
>
> Alternatives:
>  - copy 'glue' script into west installation folder ?
>  - west commands ? in the manifest repo, or maybe another common lib etc.

I hope the above is what you're looking for.


I think what I was envisaging was something to glue together the above commands (and keep some separation between the specific 'app' and the bootloader), I thought this would be 'west', but maybe not.. to take this approach would mean having to invoke the build/sign/whatever commands from the 'west installation' folder, and it would only be available from the manifest repo folder.
 

Note 'west build' can only compile one Zephyr application at a time.
The NCS can build application and mcuboot binaries at once out of the
box, for reference.

Please test and comment in the PR if you get a chance.

Done!, thanks.
 
Cheers
Marc


API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will focus on API Changes and GPIO:

- Changing a stable API:
- https://github.com/zephyrproject-rtos/zephyr/pull/21013

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

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


Why the default MAC address is not shown in the host when using hciconfig command in linux #hci #ble #nrf52 #nrf52840

Venkatesh Dyagala
 

Hi,
We are willing to do the LE USB controller with the nrf52840 dongle
By looking into this case https://devzone.nordicsemi.com/f/nordic-q-a/46036/mac-address-ranges. I came to know that there will be random address loaded into the device in production of nrf52840 Dongle.
 
Then Make that as a controller followed this https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos and  https://docs.zephyrproject.org/latest/getting_started/index.html to compile and build an hex file. The respective build is done for the hci_usb.
 
The build is done and loaded to the dongle using nrfutil.
 
Now when we insert into linux PC and when i check the device using the hciconfig command the MAC address of the dongle is 00:00:00:00:00:00
But when we used bluetoothctl show command a 6byte MAC address is shown.
 
 
 
I can change the MAC address manually using hcitool commands. But my question is that
 
1-->The nordic assigned MAC address in production for every device. Why that MAC address cannot be seen when the dongle is acting as a controller. Why its showing all zeros ?
 
2--> The bluetoothctl is showing the MAC address of the device But it cannot be updated in the hciconfig ?
 
3--> If we have a MAC how we can burn it into the flash what was the memory locations ?
 
4--> The MAC that we seen using bluetoothctl show is zepher hardcoded ?
 
 

--

Thanks,
venkatesh


Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Jan Kloetzke <jan@...>
 

Hi Marc,

On Mon, Dec 09, 2019 at 07:38:53AM -0800, Marc Reilly wrote:
Hi all,

I've been looking at making product(s) which can do OTA updates, and
how to structure the overall project.
A basic aim is to be able to checkout and build (assuming toolchain
and environment is setup) with minimal commands, and also minimal
manual 'configuration' changes required for a default build.
I'm not really feeling like I'm seeing a nice solution, so was
wondering if anyone else has overcome a similar situation, or anyone
has any ideas to progress.

Following, I've tried to summarize the problem & design as I see it to
make sure I'm on the right track, and then I've got a few example
commands to further illustrate where the problem is for me.

Any and all suggestions welcome.
We faced similar problems when we had to make an IVI system that uses
bare metal + FreeRTOS + Linux in one SoC and requires a consistent build
for all of them. In the end we created our own meta-tool:

https://bobbuildtool.dev/

Now, Zephyr already came up with the west tool which solves some of the
problems and drives many Zephyr use cases better than Bob could at the
moment. Nonetheless I created some demo recipes a couple of weeks ago to
show how a multi-application-build could look like:

https://github.com/jkloetzke/zephyr-example-recipes

Now, I'm perfectly aware that it creates another layer of complexity.
The recipes effectively replace west to drive the build. But Bob is
meant to solve many other problems too that are constantly coming up
with such more-than-one-image embedded systems: variants management,
reliable incremental building, reproducibility, toolchain setup, Jenkins
integration and automatic artifact caching. Also building and running
unit tests from the same sources on the host in one command was a
requirement for us. The goal is to always execute just one build
command:

$ git clone <project>
$ cd <project>
$ bob build <image>

and start working from there on:

... hack on the source ...
bob build <image>
bob build <unit-tests>
git commit/push/pull
... repeat ...

We're currently expanding the public-visible recipes. There is another
example which shows how FreeRTOS and Linux share some code are built
together as AMP system:

https://github.com/BobBuildTool/bob-example-embedded

If your product stays in the nRF+mcuboot+zephyr world then sticking to
the nRF Connect SDK may be easier. Otherwise Bob might be worth a look
IMHO.

Regards,
Jan


Cheers,
Marc

-----

Overview:
The product acheives OTA updates, at a general level, by:
- use mcuboot as the bootloader
- app implements SMP service (eg mcumgr/smp_svr example)
- initially program the product with a combination of the mcuboot + app
- further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image.

Typical project elements/dependencies:
- app for the product/device
- board files are defined in the 'app' repo
- common libs (eg for our GATT services which most our devices have)
- zephyr framework
- dependent modules (eg nordic_hal, segger)
- mcuboot
- (references the app board file)

This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported]

Build:
- We want 2 primary build artifacts:
- the app (configured as launched from a bootloader)
- bootloader mcuboot
- And then from this with can run a variety of commands to merge and/or sign the build artifacts.
- As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used.

-----

West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:

west init -m git@gitlab.com:SomeManifestRepo.git
west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
west sign ...

However, it would be nice to be able to glue this all together with some script etc to simplify the extra elements of the west commands ('theboard' 'BOARD_ROOT') etc. And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.

Alternatives:
- copy 'glue' script into west installation folder ?
- west commands ? in the manifest repo, or maybe another common lib etc.



Re: Firmware upgrade of hci_uart app by using bootloader in serial recovery mode #ble #hci #nrf52480 #uart

Bolivar, Marti
 

Hi Mayank,

I am surprised to say this doesn't appear to be covered in the MCUboot
documentation.

David, did I miss it somewhere?

Mayank: you need at least three pins connecting the i.MX and nRF chips:

- UART TX
- UART RX
- a "serial detect" GPIO

The i.MX chip also needs to be able to reset the nRF chip, e.g. with
another i.MX GPIO connected to the nRF reset pin.

(If you have already manufactured your PCB and don't have those required
features, then you're out of luck, I'm afraid. You'll have to use
something like the smp_svr app.)

You need to customize your MCUboot build for your board so the
bootloader reads your serial detect pin at reset and drops into serial
recovery mode if it is asserted. The mcumgr serial protocol is used to
do the update itself.

Assuming the mcuboot kconfig help is still accurate, you need to set
your MCUboot Kconfig knobs roughly like so:

CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=y
CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_0" # or GPIO_1 if your pin is on that port
CONFIG_BOOT_SERIAL_DETECT_PIN=<your-custom-board's-serial-detect-pin-number>
CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=<your-serial-detect-pin's-assert-logic-level>

Also make sure your zephyr,console chosen node in devicetree is the
nRF52840 UART you want to use, and that its TX/RX pins are set correctly
in DT as well.

Once configured in this way, you need to build and reflash MCUboot on the nRF.

On the i.MX side, to do an update, you need to do something like this:

1. assert the serial detect pin
2. reset the nRF SoC
3. use the mcumgr serial transport protocol to upload an update
firmware image
4. deassert the serial detect pin (this just needs to happen sometime
after mcuboot has read it out of reset)
5. use mcumgr to reset the nRF with serial detect deasserted,
to boot into the new image

You may find the west build + west sign + mcumgr command lines on this
page helpful:

https://docs.zephyrproject.org/latest/boards/arm/nrf52840_pca10059/doc/index.html#option-2-using-mcuboot-in-serial-recovery-mode

If you are running Linux and can get golang programs running on the
i.MX, you should be able to get mcumgr running and adapt the 'mcumgr ...
image upload' and 'mcumgr ... reset' lines from there.

Hope this helps!

"Mayank via Lists.Zephyrproject.Org"
<mayank7117=gmail.com@lists.zephyrproject.org> writes:

Hello,

I have nrf52840_pca10056 chip connected to imx6ul processor via uart (Both are embedded on my custom board) as shown in attached image.
I'm using mcuboot bootloader on nrf52840 chip, now i want to flash hci_uart app over UART by keeping mcuboot in serial recovery mode.

NOTE: I do not want to go with other way of upgrading the firmware (Using smp_svr application).

Q: So what i need to do to upgrade the firmware using bootloader's serial recovery mode ?

(I do not have any physical access to the pin for nrf52840 chip).


Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Bolivar, Marti
 

Sorry for the double-post, but I realized that the latter half of my
inline responses might be easy to ignore, so I'm going to hang a lantern
on them with this email:

"Bolivar, Marti via Lists.Zephyrproject.Org"
<marti.bolivar=nordicsemi.no@lists.zephyrproject.org> writes:
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Marc Reilly via Lists.Zephyrproject.Org <marc.reilly=gmail.com@lists.zephyrproject.org>
However, it would be nice to be able to glue this all together with
some script etc to simplify the extra elements of the west commands
('theboard' 'BOARD_ROOT') etc.
No matter what you choose to use (mainline or NCS), though, you can
always tell 'west build' your default board like this:

west config build.board theboard

https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#configuration-options

The build.board value will be used if you don't provide --board
(provided BOARD is also unset in the calling environment).

I thought about your BOARD_ROOT question. I've gotten other similar
requests recently, and I agree it would be useful, so I've proposed a
new "build.cmake-args" config option:

https://github.com/zephyrproject-rtos/zephyr/pull/21251

With the patch from #21251, you can save your BOARD_ROOT like this:

west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Your one-time setup work would then be:

west init -m git@gitlab.com/SomeManifestRepo.git
west update
west config build.board theboard
west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Note that plain 'west config var val' sets configuration options locally
(just for your west installation). See the --global and --system options
in the 'west config' documentation for alternatives.

# build and flash
west build -d build-mcuboot -s mcuboot/boot/zephyr
west build -d build-app -s app
west sign ...
Please make sure you see this part ^^.

Martí


Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Bolivar, Marti
 

Hello Marc,

"Sebastian Boe via Lists.Zephyrproject.Org"
<Sebastian.Boe=nordicsemi.no@lists.zephyrproject.org> writes:

Hi, I see you are using nrf.

Signing, building, and hex merging of multiple images in a single west command is supported
out-of-the box with the nRF Connect SDK, which uses a patched Zephyr.

So if not using vanilla Zephyr is an option then see:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_application_update/README.html#http-application-update-sample
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html
I second Sebastian's suggestion to look at nRF Connect SDK (NCS).
It has useful features for building OTA binaries for nRF devices.


________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Marc Reilly via Lists.Zephyrproject.Org <marc.reilly=gmail.com@lists.zephyrproject.org>
Sent: Monday, December 9, 2019 4:38 PM
To: devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Managing/structuring multi image/binary projects for (OTA updatable products etc)

Hi all,

I've been looking at making product(s) which can do OTA updates, and how to structure the overall project.
A basic aim is to be able to checkout and build (assuming toolchain and environment is setup) with minimal commands, and also minimal manual 'configuration' changes required for a default build.
I'm not really feeling like I'm seeing a nice solution, so was wondering if anyone else has overcome a similar situation, or anyone has any ideas to progress.

Following, I've tried to summarize the problem & design as I see it to make sure I'm on the right track, and then I've got a few example commands to further illustrate where the problem is for me.

Any and all suggestions welcome.

Cheers,
Marc

-----

Overview:
The product acheives OTA updates, at a general level, by:
- use mcuboot as the bootloader
- app implements SMP service (eg mcumgr/smp_svr example)
- initially program the product with a combination of the mcuboot + app
- further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image.

Typical project elements/dependencies:
- app for the product/device
- board files are defined in the 'app' repo
- common libs (eg for our GATT services which most our devices have)
- zephyr framework
- dependent modules (eg nordic_hal, segger)
- mcuboot
- (references the app board file)

This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported]

Build:
- We want 2 primary build artifacts:
- the app (configured as launched from a bootloader)
- bootloader mcuboot
- And then from this with can run a variety of commands to merge and/or sign the build artifacts.
- As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used.

-----

West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:

west init -m git@gitlab.com:SomeManifestRepo.git
west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
west sign ...

However, it would be nice to be able to glue this all together with
some script etc to simplify the extra elements of the west commands
('theboard' 'BOARD_ROOT') etc.
No matter what you choose to use (mainline or NCS), though, you can
always tell 'west build' your default board like this:

west config build.board theboard

https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#configuration-options

The build.board value will be used if you don't provide --board
(provided BOARD is also unset in the calling environment).

I thought about your BOARD_ROOT question. I've gotten other similar
requests recently, and I agree it would be useful, so I've proposed a
new "build.cmake-args" config option:

https://github.com/zephyrproject-rtos/zephyr/pull/21251

With the patch from #21251, you can save your BOARD_ROOT like this:

west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Your one-time setup work would then be:

west init -m git@gitlab.com/SomeManifestRepo.git
west update
west config build.board theboard
west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app

Note that plain 'west config var val' sets configuration options locally
(just for your west installation). See the --global and --system options
in the 'west config' documentation for alternatives.

# build and flash
west build -d build-mcuboot -s mcuboot/boot/zephyr
west build -d build-app -s app
west sign ...

And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.

Alternatives:
- copy 'glue' script into west installation folder ?
- west commands ? in the manifest repo, or maybe another common lib etc.
I hope the above is what you're looking for.

Note 'west build' can only compile one Zephyr application at a time.
The NCS can build application and mcuboot binaries at once out of the
box, for reference.

Please test and comment in the PR if you get a chance.

Thanks,
Martí





Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)

Sebastian Boe
 

Hi, I see you are using nrf.

Signing, building, and hex merging of multiple images in a single west command is supported
out-of-the box with the nRF Connect SDK, which uses a patched Zephyr.

So if not using vanilla Zephyr is an option then see:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_application_update/README.html#http-application-update-sample
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Marc Reilly via Lists.Zephyrproject.Org <marc.reilly=gmail.com@lists.zephyrproject.org>
Sent: Monday, December 9, 2019 4:38 PM
To: devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Managing/structuring multi image/binary projects for (OTA updatable products etc)

Hi all,

I've been looking at making product(s) which can do OTA updates, and how to structure the overall project.
A basic aim is to be able to checkout and build (assuming toolchain and environment is setup) with minimal commands, and also minimal manual 'configuration' changes required for a default build.
I'm not really feeling like I'm seeing a nice solution, so was wondering if anyone else has overcome a similar situation, or anyone has any ideas to progress.

Following, I've tried to summarize the problem & design as I see it to make sure I'm on the right track, and then I've got a few example commands to further illustrate where the problem is for me.

Any and all suggestions welcome.

Cheers,
Marc

-----

Overview:
The product acheives OTA updates, at a general level, by:
- use mcuboot as the bootloader
- app implements SMP service (eg mcumgr/smp_svr example)
- initially program the product with a combination of the mcuboot + app
- further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image.

Typical project elements/dependencies:
- app for the product/device
- board files are defined in the 'app' repo
- common libs (eg for our GATT services which most our devices have)
- zephyr framework
- dependent modules (eg nordic_hal, segger)
- mcuboot
- (references the app board file)

This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported]

Build:
- We want 2 primary build artifacts:
- the app (configured as launched from a bootloader)
- bootloader mcuboot
- And then from this with can run a variety of commands to merge and/or sign the build artifacts.
- As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used.

-----

West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:

west init -m git@gitlab.com:SomeManifestRepo.git
west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
west sign ...

However, it would be nice to be able to glue this all together with some script etc to simplify the extra elements of the west commands ('theboard' 'BOARD_ROOT') etc. And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.

Alternatives:
- copy 'glue' script into west installation folder ?
- west commands ? in the manifest repo, or maybe another common lib etc.


Managing/structuring multi image/binary projects for (OTA updatable products etc)

Marc Reilly
 

Hi all,

I've been looking at making product(s) which can do OTA updates, and how to structure the overall project.
A basic aim is to be able to checkout and build (assuming toolchain and environment is setup) with minimal commands, and also minimal manual 'configuration' changes required for a default build.
I'm not really feeling like I'm seeing a nice solution, so was wondering if anyone else has overcome a similar situation, or anyone has any ideas to progress.

Following, I've tried to summarize the problem & design as I see it to make sure I'm on the right track, and then I've got a few example commands to further illustrate where the problem is for me.

Any and all suggestions welcome.

Cheers,
Marc

-----

Overview:
The product acheives OTA updates, at a general level, by:
 - use mcuboot as the bootloader
 - app implements SMP service (eg mcumgr/smp_svr example)
 - initially program the product with a combination of the mcuboot + app
 - further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image.

Typical project elements/dependencies:
 - app for the product/device
  - board files are defined in the 'app' repo
 - common libs (eg for our GATT services which most our devices have)
 - zephyr framework
  - dependent modules (eg nordic_hal, segger)
 - mcuboot
  - (references the app board file)

This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported]

Build:
 - We want 2 primary build artifacts:
   - the app (configured as launched from a bootloader)
   - bootloader mcuboot
 - And then from this with can run a variety of commands to merge and/or sign the build artifacts.
 - As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used.

-----

West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example:

west init -m git@...:SomeManifestRepo.git
west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app
west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app
west sign ...

However, it would be nice to be able to glue this all together with some script etc to simplify the extra elements of the west commands ('theboard' 'BOARD_ROOT') etc. And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.

Alternatives:
 - copy 'glue' script into west installation folder ?
 - west commands ? in the manifest repo, or maybe another common lib etc.


Firmware upgrade of hci_uart app by using bootloader in serial recovery mode #ble #hci #nrf52480 #uart

Mayank <mayank7117@...>
 

Hello,

I have nrf52840_pca10056 chip connected to imx6ul processor via uart (Both are embedded on my custom board) as shown in attached image.
I'm using mcuboot bootloader on nrf52840 chip, now i want to flash hci_uart app over UART by keeping mcuboot in serial recovery mode.

NOTE: I do not want to go with other way of upgrading the firmware (Using smp_svr application).

Q: So what i need to do to upgrade the firmware using bootloader's serial recovery mode ?

(I do not have any physical access to the pin for nrf52840 chip).


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 2 January 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <devel@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 2 January 2020
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/993312203

Organizer: devel@...

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 26 December 2019 #cal-cancelled

devel@lists.zephyrproject.org Calendar <devel@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 26 December 2019
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/993312203

Organizer: devel@...

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 19 December 2019 #cal-cancelled

devel@lists.zephyrproject.org Calendar <devel@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 19 December 2019
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/993312203

Organizer: devel@...

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Zephyr 2.1 Released

David Leach
 

Hi,

We are excited to announce the release of Zephyr RTOS version 2.1.0!

 

Major enhancements with this release include (but are not limited to):

 

  • Normalized APIs across all architectures.
  • Expanded support for ARMv6-M architecture.
  • Added support for numerous new boards and shields.
  • Added numerous new drivers and sensors.
  • Added new TCP stack implementation (experimental).
  • Added BLE support on Vega platform (experimental).
  • Memory size improvements to Bluetooth host stack.

 

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.1.0

I would like to thank the community members who contributed to this release. In total 219 contributors provided PRs in the development of 2.1 with a total of 350+ community members providing issues, PRs, and comments. It has taken a lot of hard work from everyone in the Zephyr community!

Starting now, the tree is open for new features targeting 2.2 release, which is tentatively scheduled for February 28th 2020.

 

Thank you again,

 

David Leach

 

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 


libstdc++ / thread safety

Markus
 

Dear all,

as I can't find any extensions to GCC for Zephyr, I am wondering if C++ / strings can already be used safely on Zephyr?

Please have a look at the "Porting to New Hardware or Operating Systems" section of libstdc++ 

https://gcc.gnu.org/onlinedocs/libstdc++/manual/internals.html#internals.thread_safety

Best Regards
Markus


Re: bt_gatt_is_subscribed - any examples?

Lawrence King
 

Adding devel@... to the email address.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Lawrence King
Sent: Thursday, December 5, 2019 4:00 PM
To: users@...
Subject: [Zephyr-users] bt_gatt_is_subscribed - any examples?

 

Dear All:

 

I have a similar problem to what Frank Viren is seeing in his thread “bt_gatt_notify multiple characteristics”. How to determine the pointer to the right characteristic.

 

When my central connects to my device I want to send it several notifications. My device has several characteristics under the primary service. When the central connects (in this case the central is either an iPhone, or an Android phone), if I simply wait 200mS after the connection and sent the notifications with bt_gatt_notify() it ‘almost’ always works. Unfortunately sometimes Android or iOS take a little longer to subscribe for notifications, hence I would like to determine if the phone is ready to receive notifications rather than simply waiting 200mS.

 

I hunted through the bt_ apis and found bt_gatt_is_subscribed() which looks like I can loop testing to see if the central is ready and then send the notifications. Much better than blindly waiting 200mS.

 

 

bool bt_gatt_is_subscribed(struct bt_conn *connconststructbt_gatt_attr *attr, u16_t ccc_value)

Check if connection have subscribed to attribute.

Check if connection has subscribed to attribute value change.

The attribute object can be the so called Characteristic Declaration, which is usually declared with BT_GATT_CHARACTERISTIC followed by BT_GATT_CCC, or the Characteristic Value Declaration which is automatically created after the Characteristic Declaration when using BT_GATT_CHARACTERISTIC, or the Client Characteristic Configuration Descriptor (CCCD) which is created by BT_GATT_CCC.

Return

true if the attribute object has been subscribed.

Parameters

·        conn: Connection object.

·        attr: Attribute object.

·        ccc_value: The subscription type, either notifications or indications.

 

OK, based on the documentation, this seems to be what I want, but the parameters are difficult for a newbie to understand:

conn – yes I did declare this with BT_GATT_CHARACTERISTIC I know where it is in my source code, but how do I find a pointer to it?

attr –  this was automatically created with BT_GATT_CCC in the same place, but again how do I get a pointer to the attr?

ccc_value – this is obviously an int, probably with definitions for the bits, but what symbolic enums or defines can I put in this parameter?

 

 

 

Unfortunately a google search of “bt_gatt_is_subscribed” only finds 8 results, the source code, the documentation (on the zephyr site, and on the nordic site), and 2 content aggregators. I did not find a single piece of code that calls this function, but there must be at least one call to the function in at least some test suite. bt_gatt_is_subscribed is never called in any of the zephyr/samples…

 

Can someone point me to an example please?

 

 

 

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.

 

 

 


LPC55S28JBD100 Zephyr OS

Wu, Hubert <Hubert.Wu@...>
 

 

Hello,

I have promoted NXP MCU LPC55S28JBD100 to our customer MOXA and I would like to propose them to use Zephyr OS but the LPC55S28JBD100 has not been supported to run the Zephyr OS. Would you advise me when the LPC55S28JBD100 will be supported?

 

Hubert Wu

Hubert.Wu@...

Staff Field Application Engineer

Avnet Electronics Marketing

 

 

5F., No. 3, YuanCyu Street. (NanKang Software Park)

Taipei 115, Taiwan

O +886.2.2655.8688 5628

M +886.939.862.238

F +886.2.2655.8666

avnet.com/apac

 

 


Re: Persistent memory issue (NVS and FCB) - Zephyr V1.X versus V2 #ble #nrf52

frv
 

Hi Carles,

Thanks for the tip. I would be really surprised that I already have a stack issue, as the application is still very simple... Nevertheless it can't harm to have this option enabled.

Br,
Frank

1481 - 1500 of 8046