1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Dev-Review Meeting Agenda May 5th

Kumar Gala
 

The agenda will focus on reviewing all PRs with a v2.6.0 milestone tag:

https://github.com/zephyrproject-rtos/zephyr/pulls?page=2&q=is%3Aopen+is%3Apr+milestone%3Av2.6.0

- k
SDK 0.13.0-alpha-1 Release

Kumar Gala
 

Hi all,

Just wanted to let people be aware few have an alpha release of the v0.13.0 SDK. The main focus of this alpha release is to enable ARC64 support in the toolchain.

Additionally we’ve updated gcc to be based on the GCC 10.3.0 release and pulled in QEMU 6.0.0.

I expect we will update OpenOCD to be based on a snapshot post the v0.11.0 release. Also, there’s expectation that ESP32 support will be added as well.

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.13.0-alpha-1

general:
Added support for ARC64. NOTE: GDB isn't currently supported
for ARC64.

qemu:
Updated to QEMU 6.0.0
Added arc64 support. NOTE: this update ARC support replaces
the machine (-M simhs) with (-M virt). This change will require
updates to boards/arc/qemu_arc/board.cmake in Zephyr to match.

gcc:
Update to gcc 10.3 release
Added support for ARC64

binutils:
Updated to add support for ARC64

newlib:
Updated to add support for ARC64

crosstool-ng:
sync with upstream. Upstream now supports newlib-nano so we drop
our Zephyr specific updates. This also pulls in gcc-10.3 and
initial support for ARC64.

yocto:
Update to yocto 3.2.3 baseline. This is in prep to support building
qemu-6.0.0

Thanks to all that contributed fixes and enhancements to this version of the SDK.

- k
RFC: API Change: USB HID remove get_protocol/set_protocol/get_idle/set_idle callbacks

Johann Fischer
 

Problem description:

The USB HID class API offers the possibility to register callbacks
for Get/SetIdle, Get/SetProtocol to the application.
Rules for these callbacks are neither obvious nor documented.

The Get/SetProtocol callbacks are redundant and do not provide any
additional value since the way to inform the application
about the change of the protocol exists via the callback
hid_protocol_cb_t protocol_change.

The core provides implementation to handle Get/SetIdle requests and
on idle reports. If this is not suitable in any way then the application
should implement everything itself.

Also the possibility to call unknown application code while processing
control requests should also be avoided or reduced to a minimum.

Example that it can be used all wrong:
https://github.com/zephyrproject-rtos/zephyr/pull/34400/files

The probability that someone will be affected by this change is very low, since
the usage is neither necessary nor obvious.

Github Issue for this API change:
https://github.com/zephyrproject-rtos/zephyr/issues/34426

Github PR:
https://github.com/zephyrproject-rtos/zephyr/pull/33659


Johann Fischer
Re: Zephyr x nRF52 Inquiry

David Rances <david@...>
 

Hi Jamie,

One of our team members came to the same conclusion as well. We'll need to check out memory usage and see if it's even possible for our situation. Assuming we can even attempt it, we'll test it out and experiment with it a bit.
I appreciate your help with this.

Thanks,
David


On Wed, May 5, 2021 at 3:13 AM Jamie Mccrae <Jamie.Mccrae@...> wrote:

Hi David,

You can package them up using nrfutil so that they can update over the old Nordic SDK bootloader, you would just need to adjust the kernel load offset to after the softdevice and you wouldn’t be able to erase the softdevice, and would then use nrfutil like you would packaging a Nordic SDK application. The issue you have is that you’re using an nRF52832 with 512 or 256KB of flash and the current S132 softdevice uses 152KB of flash, the bootloader was 48KB or so if I remember rightly so that’s 200KB of 256/512KB flash used, to which you want to add a zephyr application with it’s own Bluetooth stack… Depending on the application and if you have any non-volatile data, you might find there is insufficient space for it to fit.

Thanks,

Jamie

 

From: David Rances <david@...>
Sent: 03 May 2021 14:30
To: Jamie Mccrae <Jamie.Mccrae@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi Jamie,

 

Thanks for the response.

 

Does that mean that if I have devices out in the field running firmware built on older Nordic code (SoftDevice and nRF52 SDK), the only way to get firmware built on Zephyr onto those devices would be to bring them in and physically erase/flash them? Since any existing methods to update the bootloader/application would be dependent on tools from Nordic that utilize the SoftDevice (OTA DFU) or their serial DFU using SLIP.

 

Best,

David

 

On Fri, Apr 30, 2021 at 4:51 PM Jamie Mccrae <Jamie.Mccrae@...> wrote:

Hi David,

Zephyr does not use the Nordic SDK softdevice, it comes with its own Bluetooth stack which gets compiled into your application hex file. You would get rid of the code on your module and flash just the zephyr hex file, or you could also flash mcuboot if you want a boot loader.

If you are using the nRF connect SDK which uses zephyr then the ‘softdevice’ mentioned there has no relation to the Nordic SDK softdevice, it is Nordic’s proprietary lower link layer Bluetooth stack but similar to if using the one in zephyr, it gets statically linked to your output application and so you do not need the Nordic SDK softdevice

Thanks,

Jamie

 

From: devel@... <devel@...> on behalf of David Rances via lists.zephyrproject.org <david=strongarmtech.com@...>
Sent: Friday, April 30, 2021 8:54 pm
To: devel@...
Subject: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi,

 

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

 

Thanks,

David

 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.



--

________________________
David Rances   |   Embedded Engineer
Email: david@...
Cell: +1 917 476 3696

NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.
Re: Zephyr x nRF52 Inquiry

lairdjm
 

Hi David,

You can package them up using nrfutil so that they can update over the old Nordic SDK bootloader, you would just need to adjust the kernel load offset to after the softdevice and you wouldn’t be able to erase the softdevice, and would then use nrfutil like you would packaging a Nordic SDK application. The issue you have is that you’re using an nRF52832 with 512 or 256KB of flash and the current S132 softdevice uses 152KB of flash, the bootloader was 48KB or so if I remember rightly so that’s 200KB of 256/512KB flash used, to which you want to add a zephyr application with it’s own Bluetooth stack… Depending on the application and if you have any non-volatile data, you might find there is insufficient space for it to fit.

Thanks,

Jamie

 

From: David Rances <david@...>
Sent: 03 May 2021 14:30
To: Jamie Mccrae <Jamie.Mccrae@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi Jamie,

 

Thanks for the response.

 

Does that mean that if I have devices out in the field running firmware built on older Nordic code (SoftDevice and nRF52 SDK), the only way to get firmware built on Zephyr onto those devices would be to bring them in and physically erase/flash them? Since any existing methods to update the bootloader/application would be dependent on tools from Nordic that utilize the SoftDevice (OTA DFU) or their serial DFU using SLIP.

 

Best,

David

 

On Fri, Apr 30, 2021 at 4:51 PM Jamie Mccrae <Jamie.Mccrae@...> wrote:

Hi David,

Zephyr does not use the Nordic SDK softdevice, it comes with its own Bluetooth stack which gets compiled into your application hex file. You would get rid of the code on your module and flash just the zephyr hex file, or you could also flash mcuboot if you want a boot loader.

If you are using the nRF connect SDK which uses zephyr then the ‘softdevice’ mentioned there has no relation to the Nordic SDK softdevice, it is Nordic’s proprietary lower link layer Bluetooth stack but similar to if using the one in zephyr, it gets statically linked to your output application and so you do not need the Nordic SDK softdevice

Thanks,

Jamie

 

From: devel@... <devel@...> on behalf of David Rances via lists.zephyrproject.org <david=strongarmtech.com@...>
Sent: Friday, April 30, 2021 8:54 pm
To: devel@...
Subject: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi,

 

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

 

Thanks,

David

 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.
Re: Zephyr x nRF52 Inquiry

Eric Mohlenhoff
 

If you take a look at the supported board documentation for the nRF52840 Dongle (PCA10059), there is a section that describes loading/using a Zephyr application with the Nordic bootloader. I don't know if this is the same bootloader as the one you are using from the Nordic SDK, but it might be worth checking out as a starting place to see what might be possible for your situation.

--Eric
Zephyr Project: APIs - Tue, 05/04/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 4 May 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________
Zephyr: Networking Forum - Tue, 05/04/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Networking Forum

When: Tuesday, 4 May 2021, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: tsc@...

Description:


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 458 216 365#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________
API meeting: agenda

Carles Cufi
 

[RFC] flash API: extend API by write/erase calls with flash content check and re-write

Puzdrowski, Andrzej
 

Usually flash drivers/controllers doesn't check whether what was requested to be write was written. As flash driver API implements just write, it doesn't mean that corruption of written data will be detected as error by the driver.

Most of FS and storage system implementation assumes that write/erase operations are reliable (and they usually are).
If corrupted write or corrupted erase occurred then this is not visible for the storage layer. So storage need to read and check the content o its own, which actually is common problem. Also If a flash driver (or flash controller under it) already does the check, the read operation will be just a waste of time. Looks like suitable will be to move that functionality to layer bellow.

solution part 1
Write with check and erase with check functions API can be introduced.
For flash drivers without write/erase verification build-in this API should read back procedures for check the content.
For drivers which already support checks under write API almost nothing needs to be done. This especially preferred for flash controller with check build-in.

flash driver glue layer might be able to decide which way is the case for the driver and works accordingly basing of a new callbacks fields in API table structures provided by shims.

Current flash_write() API shouldn't be extended by write check silently - read operation might be time costly as for seral flashes are.

solution part 2
Write with check and rewrite on corruption attempt function API
This would be extension to the Write with check API which perform another try of data write if flash content doesn't match (and the flash controller allows rewrites to same location).

I creating ticked for tracking input on the subject which anyone can provided.

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

 

Andrzej Puzdrowski

 
Re: Network forum agenda

Jukka Rissanen
 

One topic emerged:

- WiFi and wpa supplicant support in Zephyr


Cheers,
Jukka

On Mon, 2021-05-03 at 17:57 +0300, Jukka Rissanen wrote:
Hi all,

There is a network forum meeting tomorrow Tue 4 May at 8AM PST /
17.00
CEST.

Currently the agenda is empty, so if there is anything network
related
topics you want to discuss, please let me know, otherwise I will
cancel
the meeting.

Live Agenda/Minutes:
https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0/edit?usp=sharing

Shared Folder:
https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

___________________________________________________________
Join Microsoft Teams Meeting (
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d
)
+1 321-558-6518 ( tel:+1 321-558-6518,,458216365# ) United States,
Orlando (Toll)
Conference ID: 458 216 365#
Local numbers (
https://dialin.teams.microsoft.com/325d775d-c910-441e-90d0-353ebaa56cdd?id=458216365
) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) |
Learn
more about Teams ( https://aka.ms/JoinTeamsMeeting ) | Meeting
options
(
https://teams.microsoft.com/meetingOptions/?organizerId=841a7c92-7816-4faf-9887-5e334e88f6d8&tenantId=af0096d9-700c-411a-b795-b3dd7122bad2&threadId=19_meeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw@thread.v2&messageId=0&language=en-US
)


Cheers,
Jukka
Attempting to assign value to undefined symbol error

Mike Marks
 

I am trying to work through the solved examples in the Bluetooth Mesh Developer Study Guide found here: Bluetooth Mesh Developer Study Guide v2.0 | Bluetooth® Technology Website
The code examples use Zephyr as a foundation for Bluetooth Mesh introductory examples. The Study Guide includes both starting point and solution code, and my focus is on getting the solution code examples for Switch and Light to compile.  For switch, I see this error message: "C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch/prj.conf:34: warning: attempt to assign the value '36' to the undefined symbol BT_MESH_RX_SDU_MAX" which appears to break the build. Complete build output here:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
C:\Projects\BluetoothMeshDeveloperStudyGuideV2_0_0\code\solution\Switch>west build -b nrf52840dk_nrf52840 --pristine
-- west build: making build dir C:\Projects\BluetoothMeshDeveloperStudyGuideV2_0_0\code\solution\Switch\build pristine
-- west build: generating a build system
-- Application: C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch
-- Using NCS Toolchain 1.5.0 for building. (C:/Users/mmarks/ncs/v1.5.0/toolchain/cmake)
-- Zephyr version: 2.4.99 (c:/users/mmarks/ncs/v1.5.0/zephyr)
-- Found Python3: C:/Users/mmarks/ncs/v1.5.0/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Cache files will be written to: C:\Users\mmarks\AppData\Local/.cache/zephyr
-- Found dtc: C:/Users/mmarks/ncs/v1.5.0/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/Users/mmarks/ncs/v1.5.0/toolchain/opt)
-- Found BOARD.dts: C:/Users/mmarks/ncs/v1.5.0/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Generated zephyr.dts: C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch/build/zephyr/include/generated/device_extern.h
 
C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch/prj.conf:34: warning: attempt to assign the value '36' to the undefined symbol BT_MESH_RX_SDU_MAX
Parsing c:/users/mmarks/ncs/v1.5.0/zephyr/Kconfig
Loaded configuration 'C:/Users/mmarks/ncs/v1.5.0/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'
Merged configuration 'C:/Projects/BluetoothMeshDeveloperStudyGuideV2_0_0/code/solution/Switch/prj.conf'
 
error: Aborting due to Kconfig warnings
 
CMake Error at C:/Users/mmarks/ncs/v1.5.0/zephyr/cmake/kconfig.cmake:262 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  C:/Users/mmarks/ncs/v1.5.0/zephyr/cmake/app/boilerplate.cmake:534 (include)
  CMakeLists.txt:3 (include)
 
 
-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-DWEST_PYTHON=c:\python39\python.exe' '-BC:\Projects\BluetoothMeshDeveloperStudyGuideV2_0_0\code\solution\Switch\build' '-SC:\Projects\BluetoothMeshDeveloperStudyGuideV2_0_0\code\solution\Switch' -GNinja -DBOARD=nrf52840dk_nrf52840
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The symbol that it complains is undefined, BT_MESH_RX_SDU_MAX, is listed in prj.conf. Is there something I'm missing why the symbol shows up as undefined?

Thanks,
Mike Marks
Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow Tue 4 May at 8AM PST / 17.00
CEST.

Currently the agenda is empty, so if there is anything network related
topics you want to discuss, please let me know, otherwise I will cancel
the meeting.

Live Agenda/Minutes:
https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0/edit?usp=sharing

Shared Folder:
https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

___________________________________________________________
Join Microsoft Teams Meeting (
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d
)
+1 321-558-6518 ( tel:+1 321-558-6518,,458216365# ) United States,
Orlando (Toll)
Conference ID: 458 216 365#
Local numbers (
https://dialin.teams.microsoft.com/325d775d-c910-441e-90d0-353ebaa56cdd?id=458216365
) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) | Learn
more about Teams ( https://aka.ms/JoinTeamsMeeting ) | Meeting options
(
https://teams.microsoft.com/meetingOptions/?organizerId=841a7c92-7816-4faf-9887-5e334e88f6d8&tenantId=af0096d9-700c-411a-b795-b3dd7122bad2&threadId=19_meeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw@thread.v2&messageId=0&language=en-US
)


Cheers,
Jukka
Re: Zephyr x nRF52 Inquiry

David Rances <david@...>
 

Hi Jamie,

Thanks for the response.

Does that mean that if I have devices out in the field running firmware built on older Nordic code (SoftDevice and nRF52 SDK), the only way to get firmware built on Zephyr onto those devices would be to bring them in and physically erase/flash them? Since any existing methods to update the bootloader/application would be dependent on tools from Nordic that utilize the SoftDevice (OTA DFU) or their serial DFU using SLIP.

Best,
David

On Fri, Apr 30, 2021 at 4:51 PM Jamie Mccrae <Jamie.Mccrae@...> wrote:
Hi David,
Zephyr does not use the Nordic SDK softdevice, it comes with its own Bluetooth stack which gets compiled into your application hex file. You would get rid of the code on your module and flash just the zephyr hex file, or you could also flash mcuboot if you want a boot loader.
If you are using the nRF connect SDK which uses zephyr then the ‘softdevice’ mentioned there has no relation to the Nordic SDK softdevice, it is Nordic’s proprietary lower link layer Bluetooth stack but similar to if using the one in zephyr, it gets statically linked to your output application and so you do not need the Nordic SDK softdevice
Thanks,
Jamie

From: devel@... <devel@...> on behalf of David Rances via lists.zephyrproject.org <david=strongarmtech.com@...>
Sent: Friday, April 30, 2021 8:54 pm
To: devel@...
Subject: [Zephyr-devel] Zephyr x nRF52 Inquiry

Hi,

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

Thanks,
David

--

________________________
David Rances   |   Embedded Engineer
Email: david@...
Cell: +1 917 476 3696

NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.



--

________________________
David Rances   |   Embedded Engineer
Email: david@...
Cell: +1 917 476 3696

NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.
REMINDER - merge window closes this Friday - May 7th, 2021.

Kumar Gala
 

Hi,

This is a reminder that the v2.6.0 merge window for new features closes this Friday, 7th of May. After that, only bug fixes and documentation will be merged until the final release is tagged, which is targeted for Friday, May 28th. Exceptions require TSC approval. New feature PRs may still be submitted while the merge window is closed, but please keep in mind that maintainers will have less time to review them during the release stabilization period.

Please add the v2.6.0 milestone to PRs that need to be included in the release, and do not wait until Friday, May 7th to submit them.

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management
https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+milestone%3Av2.6.0

Please try to help fix bugs, test release candidates, and write release notes to minimize the time the merge window is closed so we can all quickly get back to adding fun new things to Zephyr!

Thank you for your contributions!

- k
Re: Zephyr x nRF52 Inquiry

lairdjm
 

Hi David,
Zephyr does not use the Nordic SDK softdevice, it comes with its own Bluetooth stack which gets compiled into your application hex file. You would get rid of the code on your module and flash just the zephyr hex file, or you could also flash mcuboot if you want a boot loader.
If you are using the nRF connect SDK which uses zephyr then the ‘softdevice’ mentioned there has no relation to the Nordic SDK softdevice, it is Nordic’s proprietary lower link layer Bluetooth stack but similar to if using the one in zephyr, it gets statically linked to your output application and so you do not need the Nordic SDK softdevice
Thanks,
Jamie

From: devel@... <devel@...> on behalf of David Rances via lists.zephyrproject.org <david=strongarmtech.com@...>
Sent: Friday, April 30, 2021 8:54 pm
To: devel@...
Subject: [Zephyr-devel] Zephyr x nRF52 Inquiry

Hi,

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

Thanks,
David

--

________________________
David Rances   |   Embedded Engineer
Email: david@...
Cell: +1 917 476 3696

NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.
Zephyr x nRF52 Inquiry

David Rances <david@...>
 

Hi,

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

Thanks,
David

--

________________________
David Rances   |   Embedded Engineer
Email: david@...
Cell: +1 917 476 3696

NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.
Re: Support for Ambiq Apollo chips #bluetooth #ambiq

Keith Short
 

Hi Michał -

You want the devicetree organization to match the hardware description.  So in the case of the Ambiq GPIO controller, I think your best bet is to create only GPIOA and GPIOB controllers.  This matches the register layout for the common runtime operations: read GPIO input (via RDA abd RDB), write GPIO output (via WTA/WTB, WTSA/WTSB, WTCA/WTCB).

GPIOA will set ngpios = <32> and GPIOB will set ngpios = <18>.

As for the registers, you would map the PADREGA-H, and CFGA-D to the GPIOA controller, PADREGI-M and CFGE-G to the GPIOB controller.

My approach would probably look something like this:

gpioa: gpio@40010000 {
compatible = "ambiq,apollo3-gpio";
gpio-controller;
reg = <0x40010000 0x20   /* PADREGA-H */
      0x40010040 0x10   /* CFGA-D */
      0x40010080 4   /* RDA (input read) */
      0x40010088 4   /* WTA (output write) */
      0x40010090 4   /* WTSA (output set) */
      0x40010098 4   /* WTCA (clear) */
      0x400100a0 4   /* ENA (enable) */
      0x400100a8 4   /* ENSA (set) */
      0x400100b4 4   /* ENCA (clear) */
      >;
ngpios = <32>;
label = "GPIOA";
#gpio-cells = <2>;
};

The actual driver code can define macros to convert the GPIO pin number (0-31) to the correct PADREGx register offset, and subfield within the register.

Keith



On Wed, Apr 28, 2021 at 7:03 AM Michał Ciesielski <ciesielskimm@...> wrote:
Hey Keith,

Thanks for the lead. This certainly helps. I still have some
questions, hope that's ok.

Lets say I'm describing the bytes that relate to gpio controller A:

```
gpioa: gpio@40010000 {
compatible = "ambiq,apollo3-gpio";
gpio-controller;
reg = <0x40010000 4   /* PADREG */
      0x40010040 2   /* CFGA */
      0x400100e0 4   /* ALTPADCFGA */
      0x40010080 1   /* RDA (input read) */
      0x40010088 1   /* WTA (output write) */
      0x40010090 1   /* WTSA (output set) */
      0x40010098 1   /* WTCA (clear) */
      0x400100a0 1   /* ENA (enable) */
      0x400100a8 1   /* ENSA (set) */
      0x400100b4 1   /* ENCA (clear) */
      >;
ngpios = <4>;
label = "GPIOA";
#gpio-cells = <2>;
};
```

RDA register is an input register to read the input state of the first
32 pins. RDB register holds the input state of the next 18 pins.
How would I describe that in this gpio controller? Do I describe
specific pins at this stage or is that the register I specify,
combined
with its size, should include all the bytes that refer to the
controlled pins? Meaning that this memory description can include more
than just bits referring to the pins connected to the gpio controller
A and more specific pin description happens in another node.
So the aforementioned RDA register is described here with its address
and size of 32bits. That memory range 0x40010080 - 0x40010081
describes a register that is used by 32 pins.

Another example is the ALTPADCFGA. It describes 32 pins using 4 32bits
registers. Should I specify its size as 4 (entire register) or
only 1 as the first byte of that register is the only one that
references gpio controller A.

I guess my problems come from the lack of understanding what exactly
am I describing here.

Thanks again,
Michal



On Mon, Apr 26, 2021 at 10:29 PM Keith Short <keithshort@...> wrote:
>
> The GPIO driver for the ITE IT8xxx2 family also interleaves the register space.
>
> You could follow the model used for that driver - create multiple reg phandles for the individual registers.
>
> https://github.com/zephyrproject-rtos/zephyr/blob/a3469a04978540b1d1cf0173bc557aeb9c0453be/dts/riscv/it8xxx2.dtsi#L93
>
> Keith
>
> On Sun, Apr 25, 2021 at 4:19 PM <ciesielskimm@...> wrote:
>>
>> Hello,
>>
>> I'm trying to add support for the Ambiq Apollo series chips. I'm new to the Zephyr and not very experienced with Device Tree format.
>> Currently I'm working on the zephyr/dts/arm/ambiq/apollo.dtsi. I'm trying to add the GPIO control registers. I'm modyfing
>> the STM32 dtsi file. STM32's define the GPIO control in a different way. All the Pad A registers are defined in a continous memory block.
>> In Ambiq SOCs those they are interleaved. The image below shows the memory map.
>>
>>
>>
>> First its the Pad configuration registers. Then its GPIO configuration register. I'm wondering how should I implement this
>> memory layout in the dtsi.

STM32: Clock control configuration moved from Kconfig to device tree

Erwan Gouriou
 

Hi,

We've started to transition STM32 clock system configuration from Kconfig to dts.

The main change (that introduces the whole mechanism) has been merged earlier this week,
making it available to L4/F4 and WB series:
It was followed by another change continuing the transition for remaining series 
(F0/F1/F2/F3/F7/G0/G4/L0/L1/L5/WL) and was merged earlier today.
The last change impacts H7 and is currently under review:

This series of changes allows to configure the whole stm32 clock system using
device tree, but for now, no extra modification is done in stm32 clock_control drivers. 

Kconfig style configuration is still functional but will be tagged as deprecated.
For now, only a couple of in tree boards have been converted to the new dts based
method.

I've raised an issue to track the mass conversion of the existing in tree boards
By the way, we're welcoming community contributions for this task!

Once all boards are converted, we'll be able to deprecate the Kconfig part,
which I hope could be done in DV2.6.0 timeframe.

During deprecation period, the stm32 clock_control developments involving 
device tree will be limited in order to keep backward compatibility with Kconfig.
This is done as a convenience for out of tree users. But for instance, code additions
like support of new series or PLLs will be implemented directly using device tree.

After the deprecation period, STM32 Kconfig clock_control part will be removed
and we'll be able to rework STM32 clock_control driver deeper and take advantage
of the benefits provided by device tree.

Don't hesitate to reach me on slack if you have questions.

Cheers
Erwan
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 29 April 2021 #cal-cancelled

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

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 29 April 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

Calendar
Calendar

901 - 920 of 8631