Hi all,

MCUboot is now part of the upstream Zephyr manifest. We maintain a mirror of MCUboot, which serves as the current reference version that is tested with Zephry, here:

https://github.com/zephyrproject-rtos/mcuboot

If you take the latest master and run 'west update' on it you will find MCUboot in bootloaders/mcuboot.

MCUboot is also built by CI on every Pull Request, and that should help alleviate the compatibility problems between Zephyr and MCUboot that have often appeared in the past.

Thanks,

Carles

Hi all,

I have created an RFC following our new procedure for proposing changes to stable APIs regarding our proposed changes to the PWM API:
https://github.com/zephyrproject-rtos/zephyr/issues/21384

Please review and comment on the GitHub issue.

Best regards,
Brix
--
Henrik Brix Andersen

Reminder: Zephyr Project: Dev Meeting

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

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

An RSVP is requested. Click here to RSVP

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

Hello Guillaume,

Hello Zephyr Community,

I found where something is wrong.

Indeed in net_context_get function, I saw that I reached CONFIG_NET_MAX_CONTEXTS (equal to 10 in my prj.conf).
For your information, I use UBLOX sara r4 driver (on zephyr 1.14.1 as I mentionned in my previous mail) and I wonder if contexts are well managed in this revision, especially when socket is closed ?

There could certainly be a bug in the socket offloading layer for UBLOX Sara R4 (I'm the maintainer for the current modem layer in Zephyr):
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/modem/ublox-sara-r4.c

Can you open an issue here:

https://github.com/zephyrproject-rtos/zephyr/issues

Please include as much information as you can (from this email series):
- Zephyr version: 1.14.1

- Sample used: samples/net/mqtt_publisher

- Firmware version on SARA R4 modem

- etc

And add me as "Assignee"

Thanks!

- Mike

Thanks in advance for your help

Best Regards,

Guillaume

---

De : devel@... <devel@...> de la part de Guillaume Paquet via Lists.Zephyrproject.Org <guillaume.paquet=stimio.fr@...>
Envoyé : mercredi 11 décembre 2019 16:24
À : Guillaume Paquet <guillaume.paquet@...>; devel@... <devel@...>
Cc : devel@... <devel@...>
Objet : Re: [Zephyr-devel] [TCP/MQTT] Connection issue

 

And just to add some precision, I work on zephyr 1.14.1.

 

Rgds

 

Guillaume

 

De : devel@... <devel@...> De la part de Guillaume Paquet via Lists.Zephyrproject.Org
Envoyé : mercredi 11 décembre 2019 13:50
À : devel@...
Cc : devel@...
Objet : [Zephyr-devel] [TCP/MQTT] Connection issue

 

Hello Zephyr community,

 

I contact you because I have an issue when I run mqtt_publisher example

https://docs.zephyrproject.org/1.13.0/samples/net/mqtt_publisher/README.html

 

I have the following issue when I have multiple mqtt connection/disconnection (through tcp transport_connect function)

[try_to_connect:233] mqtt_connect: -2 <ERROR>

 

I have this issue after 10 connection/disconnection. The eleventh one is always failing.

As I said you I saw that this is failing when I try to run mqtt_transport_connect(client); in client_connect.

 

My configuration is the following one :

• MQTT (not secured)
• TCP/IPv4
• Broker on external server (not any issue on this one)

 

If you have any idea to help me

 

Thanks in advance

 

Best Regards

 

Guillaume

 

   www.stimio.fr

Guillaume  PAQUET – IoT Engineer

guillaume.paquet@...  -  02 40 18 50 91

1 Avenue Professeur Jean Rouxel – ZAC Fleuriaye

44470 CARQUEFOU – FRANCE                

 

-- 
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: mike@...
W: https://www.foundries.io

---

See https://github.com/zephyrproject-rtos/zephyr/pull/13672#issuecomment-550203475

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


Hi,

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

Is there some record of the rationale behind this? (eg PR #).
I'm wondering that if its rejected from mainline zephyr for reasons like 'out of scope' etc then maybe there is some existing consensus for alternative ways - or if it was due to lack of demand then maybe that can be reappraised... But that's a lot of "maybes" and "wonderings".

Thanks again!

Cheers
Marc

Reminder: Zephyr Project: APIs

When: Tuesday, 10 December 2019, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

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

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY

---

 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

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

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

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