Date   

Event: Zephyr Memory Footprint - biweekly discussion #cal-invite

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

Zephyr Memory Footprint - biweekly discussion

When:
Monday, 26 April 2021
3:00pm to 4:00pm
(UTC-07:00) America/Los Angeles
Repeats: Every 2 weeks on Monday

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:
Working doc: https://docs.google.com/document/d/1bnQLJKVhgI3zkk3MsSXun8onEsA8z1Rf5ohdbCHASmU/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,546018126# United States, Orlando
Phone Conference ID: 546 018 126#
 
 
________________________________________________________________________________


Re: Dev-Review Meeting Agenda Apr 15

Bolivar, Marti
 


Zephyr Project: Dev Meeting - Thu, 04/15/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

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

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


BLE advertising device name in advert data (not scan data)

lairdjm
 

Hi,

I’m looking through the documentation to find a way (and playing with code) to try and work out how to have the device name advertised in the advert packets (on BLE) rather than scan response packets so that devices using passive scanning can determine the device name but not having any luck. The documentation for the BT_LE_ADV_OPT_USE_NAME bit states:

Include the GAP device name automatically when advertising.

By default the GAP device name is put at the end of the scan

response data.

When advertising using @ref BT_LE_ADV_OPT_EXT_ADV and not

@ref BT_LE_ADV_OPT_SCANNABLE then it will be put at the end of the

advertising data.

If the GAP device name does not fit into advertising data it will be

converted to a shortened name if possible.

 

The application can set the device name itself by including the

following in the advertising data.

@code

BT_DATA(BT_DATA_NAME_COMPLETE, name, strlen(name))

@endcode

 

So how would one put it in the advertising data without using extended advertising? The code I’m using is advertising using:

                static const struct bt_data ad[] = {

                                BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),

};

bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0);

Where the device name is 19 bytes which should fit in a normal non-extended adverts advertising packet. I do not want to use extended adverts and I’ve checked the bits that are set by using BT_LE_ADV_CONN_NAME which are bits 0 and 3, for BT_LE_ADV_OPT_CONNECTABLE and BT_LE_ADV_OPT_USE_NAME, the scan response bit is not set and a null pointer is suppled for scan response data to the advertising function, so why is it placing the device name in scan response data still?

Thanks,

Jamie


Dev-Review Meeting Agenda Apr 15

Kumar Gala
 

Here’s the agenda topics for this week:

doc: introduce doxyrunner extension
- https://github.com/zephyrproject-rtos/zephyr/pull/33934

board: hsdk: add cy8c95xx I/O expander support
- https://github.com/zephyrproject-rtos/zephyr/pull/33907


https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.


CFP Reminder -- Zephyr Developer Summit 2021

Brett Preston
 

Members of the Zephyr Community,

A reminder of the Call for Papers that remains open until Tuesday, April 20:

The Zephyr Developer Summit has been scheduled for Tuesday, June 8 - Thursday, June 10, 2021

This free virtual event will feature two tracks:

Track A: Mini-conference (each will be 120 minutes in length)
  • This track is designed to let the organizer(s) focus on discussing an open topic with the other key participants.  A successful mini-conference outlines a problem and provides sufficient background so participants can engage in effective discussion.   Examples where this style is used:  Linux Plumbers, Conference Fishbowl Sessions, extended BOF etc.  Goal here is to have an effective discussion session and make progress on an outstanding problem.
  • Some possible topic areas could include:
    • Firmware
    • Modules
    • Networking Stack
    • Power Management
    • Toolchain
    • Topics identified in 2020 developer survey
Track B: Presentations. (choice of 30 or 60 minutes in length or lighting talks)
  • This is designed for sharing knowledge and providing context for other discussions.
  • Some possible topic ideas include:
    • How is Zephyr being used in products
    • Demos of tools working with Zephyr
    • Overview of proposed technologies for inclusion
    • Summary of what’s happening in subsystems
    • Updates on west, modules, runtimes, etc.
    • Security & Safety team updates
    • Test infrastructure Improvements
    • BOF topics
    • Lightning talk on something cool in Zephyr you want to share

Other Key Dates
  • May 5 - Schedule announcement
  • May 5 - Registration opens

Thank you!


Brett


On Wed, Apr 7, 2021 at 4:16 PM Brett Preston <bpreston@...> wrote:
Members of the Zephyr Community,

The inaugural Zephyr Developer Summit has been scheduled for Tuesday, June 8 - Thursday, June 10, 2021.

Furthermore, the Call for Papers is Now Openhttps://forms.gle/i637wnnBp9ahrnc37 (closes April 20).

This free virtual event will feature two tracks:

Track A: Mini-conference (each will be 120 minutes in length)
  • This track is designed to let the organizer(s) focus on discussing an open topic with the other key participants.  A successful mini-conference outlines a problem and provides sufficient background so participants can engage in effective discussion.   Examples where this style is used:  Linux Plumbers, Conference Fishbowl Sessions, extended BOF etc.  Goal here is to have an effective discussion session and make progress on an outstanding problem.
  • Some possible topic areas could include:
    • Firmware
    • Modules
    • Networking Stack
    • Power Management
    • Toolchain
    • Topics identified in 2020 developer survey
Track B: Presentations. (choice of 30 or 60 minutes in length or lighting talks)
  • This is designed for sharing knowledge and providing context for other discussions.
  • Some possible topic ideas include:
    • How is Zephyr being used in products
    • Demos of tools working with Zephyr
    • Overview of proposed technologies for inclusion
    • Summary of what’s happening in subsystems
    • Updates on west, modules, runtimes, etc.
    • Security & Safety team updates
    • Test infrastructure Improvements
    • BOF topics
    • Lightning talk on something cool in Zephyr you want to share

Other Key Dates
  • May 5 - Schedule announcement
  • May 5 - Registration opens

Thank you,


Brett

--
Brett Preston
Sr. Program Manager
The Linux Foundation
+1 (971) 303-9030



--
Brett Preston
Sr. Program Manager
The Linux Foundation
+1 (971) 303-9030


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

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

Reminder: Zephyr Project: APIs

When: Tuesday, 13 April 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
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Re: [EXT] Re: [Zephyr-devel] Exclusive instruction LDAXR for ARM64 used by Zephyr SMP

Jiafei Pan
 

Thanks, the following patch fixed this issue, it is similar with my original
patch to avoid to use spin lock before enable MMU,

aarch64: mmu: don't touch the lock before the MMU is on

We can't do atomic memory operations before the MMU is on. Let's create
a code path to set up MMU page tables without any lock. There is
obviously no concurrency issues at this stage.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>

Best Regards,
Jiafei.

-----Original Message-----
From: Nicolas Pitre <npitre@baylibre.com>
Sent: Saturday, April 10, 2021 8:56 AM
To: Jiafei Pan <jiafei.pan@nxp.com>
Cc: devel@lists.zephyrproject.org
Subject: [EXT] Re: [Zephyr-devel] Exclusive instruction LDAXR for ARM64 used
by Zephyr SMP

Caution: EXT Email

Please re-test with the latest upstream. Incidentally, a fix was merged today
to solve this problem.


On Fri, 9 Apr 2021, Jiafei Pan wrote:

Hi, All,

I am debugging Zephyr SMP on ARM64, but currently I found arm64 LDAXR
instruction is used in spin lock function, but I found there is different behavior
on different platform.

Here is calling line:

__start --> z_arm64_prep_c --> z_arm64_mmu_init --> setup_page_tables
--> add_arm_mmu_flat_range --> add_map --> set_mapping --> key =
k_spin_lock(&xlat_lock);

The issue is on one ARM A72 platform, there will be "Unknown Exception"
(ECR.EC = 000000) with this calling flow, I found the exception is caused by
LDAXR instruction, and MMU is disabled when exception occurs. When I
enabled MMU firstly and then call LDAXR instruction, there will be no such
issue.

But on another A53 platform, there is no such issue both for the case MMU
is disabled or enabled.

So I am not sure whether there is some relation with MMU and LDAXR
instruction, and I don't find more information in ARM's document, I have
worked out one patch to avoid to use LDAXR and STLXR before enable MMU,
but I want to find out whether it is the root cause of the issue.

Any comments or suggestion is welcome, thanks.

Best Regards,
Jiafei.







Re: Exclusive instruction LDAXR for ARM64 used by Zephyr SMP

Nicolas Pitre
 

Please re-test with the latest upstream. Incidentally, a fix was merged
today to solve this problem.

On Fri, 9 Apr 2021, Jiafei Pan wrote:

Hi, All,

I am debugging Zephyr SMP on ARM64, but currently I found arm64 LDAXR instruction is used in spin lock function, but I found there is different behavior on different platform.

Here is calling line:

__start --> z_arm64_prep_c --> z_arm64_mmu_init --> setup_page_tables --> add_arm_mmu_flat_range --> add_map --> set_mapping --> key = k_spin_lock(&xlat_lock);

The issue is on one ARM A72 platform, there will be "Unknown Exception" (ECR.EC = 000000) with this calling flow, I found the exception is caused by LDAXR instruction, and MMU is disabled when exception occurs. When I enabled MMU firstly and then call LDAXR instruction, there will be no such issue.

But on another A53 platform, there is no such issue both for the case MMU is disabled or enabled.

So I am not sure whether there is some relation with MMU and LDAXR instruction, and I don't find more information in ARM's document, I have worked out one patch to avoid to use LDAXR and STLXR before enable MMU, but I want to find out whether it is the root cause of the issue.

Any comments or suggestion is welcome, thanks.

Best Regards,
Jiafei.







Exclusive instruction LDAXR for ARM64 used by Zephyr SMP

Jiafei Pan
 

Hi, All,

 

I am debugging Zephyr SMP on ARM64, but currently I found arm64 LDAXR instruction is used in spin lock function, but I found there is different behavior on different platform.

 

Here is calling line:

 

__start à z_arm64_prep_c à z_arm64_mmu_init à setup_page_tables à add_arm_mmu_flat_range à add_map à set_mapping à key = k_spin_lock(&xlat_lock);

 

The issue is on one ARM A72 platform, there will be Unknown Exception (ECR.EC = 000000) with this calling flow, I found the exception is caused by LDAXR instruction, and MMU is disabled when exception occurs. When I enabled MMU firstly and then call LDAXR instruction, there will be no such issue.

 

But on another A53 platform, there is no such issue both for the case MMU is disabled or enabled.

 

So I am not sure whether there is some relation with MMU and LDAXR instruction, and I dont find more information in ARMs document, I have worked out one patch to avoid to use LDAXR and STLXR before enable MMU, but I want to find out whether it is the root cause of the issue.

 

Any comments or suggestion is welcome, thanks.

 

Best Regards,

Jiafei.


Exclusive instruction LDAXR for ARM64 used by Zephyr SMP

Jiafei Pan
 

Hi, All,

 

I am debugging Zephyr SMP on ARM64, but currently I found arm64 LDAXR instruction is used in spin lock function, but I found there is different behavior on different platform.

 

Here is calling line:

 

__start à z_arm64_prep_c à z_arm64_mmu_init à setup_page_tables à add_arm_mmu_flat_range à add_map à set_mapping à key = k_spin_lock(&xlat_lock);

 

The issue is on one ARM A72 platform, there will be “Unknown Exception” (ECR.EC = 000000) with this calling flow, I found the exception is caused by LDAXR instruction, and MMU is disabled when exception occurs. When I enabled MMU firstly and then call LDAXR instruction, there will be no such issue.

 

But on another A53 platform, there is no such issue both for the case MMU is disabled or enabled.

 

So I am not sure whether there is some relation with MMU and LDAXR instruction, and I don’t find more information in ARM’s document, I have worked out one patch to avoid to use LDAXR and STLXR before enable MMU, but I want to find out whether it is the root cause of the issue.

 

Any comments or suggestion is welcome, thanks.

 

Best Regards,

Jiafei.

 


Re: Dev-Review Meeting Agenda Apr 8

Bolivar, Marti
 


Zephyr Project: Dev Meeting - Thu, 04/08/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

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

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


Re: how to describe a peripheral with power enable pin

Peter A. Bigot
 

"Si7021-pwr" is not a GPIO device, it's a regulator device.  You don't need to configure the GPIO; the regulator device does that.  Use the `regulator_enable()` and `regulator_disable()` API with the device.


Re: how to describe a peripheral with power enable pin

Rafael Dias
 

ok, ok.

I have to enable the regulator device driver.
Now it is working.

My overlay is as below:
/ {
Si7021_pwr: Si7021-pwr-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021-pwr";
};
};


But when I'll try to use the pin, I'm getting a EINVAL error after the gpio_pin_config function:   
const struct device* pwr = device_get_binding( "Si7021-pwr" );
if (NULL == pwr )
{
printf( "Could not get pwr port\n" );
return;
}

rc = gpio_pin_configure(pwr, 9, GPIO_OUTPUT_ACTIVE | GPIO_OUTPUT_INIT_HIGH );
if (rc < 0) {
printk("Failed to configure gpio pin\n");
return;
}

if I use the same sequence, but opening the gpiod port, everything works fine:
const struct device* gpiod = device_get_binding( DT_LABEL( DT_NODELABEL( gpiod ) ) );
if (NULL == gpiod )
{
printf( "Could not get gpiod port\n" );
return;
}

rc = gpio_pin_configure(gpiod, 9, GPIO_OUTPUT_ACTIVE | GPIO_OUTPUT_INIT_HIGH );
if (rc < 0) {
printk("Failed to configure gpio pin\n");
return;
}

I don't know where the error is..


On Thu, 8 Apr 2021 at 07:15, Rafael Dias via lists.zephyrproject.org <rdmeneze=gmail.com@...> wrote:
Hi,
I was performing tests with my board, and the label Si7021pwr didn't appear at the device list...

On Thu, 8 Apr 2021 at 06:31, Rafael Dias via lists.zephyrproject.org <rdmeneze=gmail.com@...> wrote:
I found a solution:

/ {
si7021_pwr: si7021-pwr-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

si7021_pwr2: si7021-pwr2-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

On Thu, 8 Apr 2021 at 06:03, Rafael Dias via lists.zephyrproject.org <rdmeneze=gmail.com@...> wrote:
Hi Peter,
thank you.

I was performing some tests here and I have a question: if I want to enable two or more supply-regulators in device three, how to proceed?

I tried this approach and it doesn't work:

/ {
regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin test";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

Using this declarations, only the second definition,  Si7021pwr2, appears on ./zephyr/include/generated/devicetree_unfixed.h

On Fri, 2 Apr 2021 at 13:08, Peter A. Bigot <pab@...> wrote:
The regulators API was designed for this purpose.  For a simple GPIO you should just be able to use a supply-gpios property in the devicetree node.  See https://docs.zephyrproject.org/latest/reference/peripherals/regulators.html

Peter



--
Rafael Dias Menezes
tel.:
+436507008854



--
Rafael Dias Menezes
tel.:
+436507008854



--
Rafael Dias Menezes
tel.:
+436507008854



--
Rafael Dias Menezes
tel.:
+436507008854


Dev-Review Meeting Agenda Apr 8

Kumar Gala
 

Here’s the agenda topics for this week:


RFC: memory regions from devicetree & explicit code locations
- https://github.com/zephyrproject-rtos/zephyr/pull/33656

[RFC] kernel: rework kobject metadata generation not to use gperf
- https://github.com/zephyrproject-rtos/zephyr/pull/33719

[RFC] kernel: generate placeholders for kobj tables before final build
- https://github.com/zephyrproject-rtos/zephyr/pull/33687

doc: introduce doxyrunner extension
- https://github.com/zephyrproject-rtos/zephyr/pull/33934

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


Re: how to describe a peripheral with power enable pin

Rafael Dias
 

Hi,
I was performing tests with my board, and the label Si7021pwr didn't appear at the device list...

On Thu, 8 Apr 2021 at 06:31, Rafael Dias via lists.zephyrproject.org <rdmeneze=gmail.com@...> wrote:
I found a solution:

/ {
si7021_pwr: si7021-pwr-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

si7021_pwr2: si7021-pwr2-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

On Thu, 8 Apr 2021 at 06:03, Rafael Dias via lists.zephyrproject.org <rdmeneze=gmail.com@...> wrote:
Hi Peter,
thank you.

I was performing some tests here and I have a question: if I want to enable two or more supply-regulators in device three, how to proceed?

I tried this approach and it doesn't work:

/ {
regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin test";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

Using this declarations, only the second definition,  Si7021pwr2, appears on ./zephyr/include/generated/devicetree_unfixed.h

On Fri, 2 Apr 2021 at 13:08, Peter A. Bigot <pab@...> wrote:
The regulators API was designed for this purpose.  For a simple GPIO you should just be able to use a supply-gpios property in the devicetree node.  See https://docs.zephyrproject.org/latest/reference/peripherals/regulators.html

Peter



--
Rafael Dias Menezes
tel.:
+436507008854



--
Rafael Dias Menezes
tel.:
+436507008854



--
Rafael Dias Menezes
tel.:
+436507008854


Re: how to describe a peripheral with power enable pin

Rafael Dias
 

I found a solution:

/ {
si7021_pwr: si7021-pwr-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

si7021_pwr2: si7021-pwr2-ctrl {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

On Thu, 8 Apr 2021 at 06:03, Rafael Dias via lists.zephyrproject.org <rdmeneze=gmail.com@...> wrote:
Hi Peter,
thank you.

I was performing some tests here and I have a question: if I want to enable two or more supply-regulators in device three, how to proceed?

I tried this approach and it doesn't work:

/ {
regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin test";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

Using this declarations, only the second definition,  Si7021pwr2, appears on ./zephyr/include/generated/devicetree_unfixed.h

On Fri, 2 Apr 2021 at 13:08, Peter A. Bigot <pab@...> wrote:
The regulators API was designed for this purpose.  For a simple GPIO you should just be able to use a supply-gpios property in the devicetree node.  See https://docs.zephyrproject.org/latest/reference/peripherals/regulators.html

Peter



--
Rafael Dias Menezes
tel.:
+436507008854



--
Rafael Dias Menezes
tel.:
+436507008854


Re: how to describe a peripheral with power enable pin

Rafael Dias
 

Hi Peter,
thank you.

I was performing some tests here and I have a question: if I want to enable two or more supply-regulators in device three, how to proceed?

I tried this approach and it doesn't work:

/ {
regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin";
enable-gpios = < &gpiod 9 0 >;
label = "Si7021pwr";
};

regulator {
compatible = "regulator-fixed";
regulator-name = "Si7021 enable pin test";
enable-gpios = < &gpiod 10 0 >;
label = "Si7021pwr2";
};
};

Using this declarations, only the second definition,  Si7021pwr2, appears on ./zephyr/include/generated/devicetree_unfixed.h

On Fri, 2 Apr 2021 at 13:08, Peter A. Bigot <pab@...> wrote:
The regulators API was designed for this purpose.  For a simple GPIO you should just be able to use a supply-gpios property in the devicetree node.  See https://docs.zephyrproject.org/latest/reference/peripherals/regulators.html

Peter



--
Rafael Dias Menezes
tel.:
+436507008854

121 - 140 of 7807