Date   

Zephyr SDK 0.12.0-beta-3 available for testing

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-beta-3

Please download and try things out and report any issues. Please report issues here:

https://github.com/zephyrproject-rtos/sdk-ng/issues

Known issues (these are on the Zephyr side):

* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]

* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]

Changes since the last release (beta-2):

• Fixed bug with ARM libgcc builds & CMSE
• Built newlib optimized

Current plan is to release SDK 0.12.0 towards the middle of next week.

- k


Dev-Review Meeting Agenda Dec 3

Kumar Gala
 

Here’s the agenda topics for this week:

* eth: stm32h7: use SRAM3 / MPU configuration
- https://github.com/zephyrproject-rtos/zephyr/pull/30403

* STM32H745 SRAM Sections Definition
- https://github.com/zephyrproject-rtos/zephyr/pull/29282

* Any PR/issues w/dev-review tag

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

* Any topics anyone else has.

- k


Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Katsuhiro Suzuki
 

Hello Carles,

Indeed, thanks for your positive opinion.
I'll continue to try to check (and also study :) ) existing issues or PRs.

Best Regards,
Katsuhiro Suzuki

On 2020/12/03 1:49, Cufi, Carles wrote:
Hi Katsuhiro,

Thank you for reply. I understand situation.
I will try to add myself as collaborator of watchdog.
Thank you, that will certainly help.

But it seems that Zephyr project rules need two or more reviewers to
proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will be as
collaborator. RISC-V area is also in same situation...
Of course, but there are things to consider here:
- If you indeed end up becoming a maintainer, you will be able to take certain decisions over questions or issues that show up in Pull Requests, effectively helping to move progress forward.
- As a consequence of that, if a Pull Request comes from the maintainer, then the requirement for two approvals stands, but the approvals are obviously automatically assumed to come from non-maintainers, so that means you don't need to wait for a maintainer that is non-existent if there are disagreements
In general, it is my opinion that having a maintainer or at least a collaborator will help in getting things merged, regardless of whether the patches come from that maintainer or anybody else.
Carles


Best Regards,
Katsuhiro Suzuki

On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,

The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would
be much appreciated.

Regards,

Carles


-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog
with WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki















Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Carles Cufi
 

Hi Katsuhiro,

Thank you for reply. I understand situation.
I will try to add myself as collaborator of watchdog.
Thank you, that will certainly help.

But it seems that Zephyr project rules need two or more reviewers to
proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will be as
collaborator. RISC-V area is also in same situation...
Of course, but there are things to consider here:

- If you indeed end up becoming a maintainer, you will be able to take certain decisions over questions or issues that show up in Pull Requests, effectively helping to move progress forward.
- As a consequence of that, if a Pull Request comes from the maintainer, then the requirement for two approvals stands, but the approvals are obviously automatically assumed to come from non-maintainers, so that means you don't need to wait for a maintainer that is non-existent if there are disagreements

In general, it is my opinion that having a maintainer or at least a collaborator will help in getting things merged, regardless of whether the patches come from that maintainer or anybody else.

Carles



Best Regards,
Katsuhiro Suzuki

On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,

The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would
be much appreciated.

Regards,

Carles


-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog
with WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki
















Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Katsuhiro Suzuki
 

Hello Carles,

Thank you for reply. I understand situation.
I will try to add myself as collaborator of watchdog.

But it seems that Zephyr project rules need two or more reviewers
to proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will
be as collaborator. RISC-V area is also in same situation...

Best Regards,
Katsuhiro Suzuki

On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,
The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would be much appreciated.
Regards,
Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog with
WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling back
the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is immediate
and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add emulated
SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki








Zephyr Project: APIs - Tue, 12/01/2020 5:00pm-6:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 1 December 2020, 5:00pm to 6: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, 12/01/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Networking Forum

When: Tuesday, 1 December 2020, 4:00pm to 5: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
 
 
________________________________________________________________________________


Re: API meeting: agenda

Carles Cufi
 

A late addition to the agenda today:

- usbh: add experimental support
- PR https://github.com/zephyrproject-rtos/zephyr/pull/30361

Carles

-----Original Message-----
From: Cufi, Carles
Sent: 01 December 2020 15:12
To: devel@lists.zephyrproject.org; users@lists.zephyrproject.org
Subject: API meeting: agenda

Hi all,

Agenda for today.

- device: refactor declare/define macros to support device definition and
reference from devicetree nodes
- PR https://github.com/zephyrproject-rtos/zephyr/pull/30196

- Add API context page
- PR https://github.com/zephyrproject-rtos/zephyr/issues/21061


If you have additional items please let me know.


Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

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


API meeting: agenda

Carles Cufi
 


Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Carles Cufi
 

Hi Katsuhiro,

The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would be much appreciated.

Regards,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog with
WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling back
the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is immediate
and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add emulated
SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki








Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Katsuhiro Suzuki
 

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki

On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,
I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.
But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.
Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.
Best Regards,
Katsuhiro Suzuki


Zephyr: Toolchain Working Group - Mon, 11/30/2020 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Monday, 30 November 2020
4:00pm to 5:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

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


Zephyr: Toolchain Working Group - Mon, 11/30/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Monday, 30 November 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Maureen Helm

Description:

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


Zephyr Toolchain Working Group Meeting – 30 November 2020

Rasmussen, Torsten
 

Agenda

  • Thomas: IAR: Updates ?
  • Zephyr SDK, 0.12 status.
  • GNU ld/binutils dependencies cleanup
    • ALIGN_WITH_INPUT
    • GAP_FILL
  • LLVM toolchain
    • CI integration
    • armclang updates
  • Milestones for 2.5, news

 

/torsten

 


Network forum agenda

Jukka Rissanen
 


Re: building my first project --- can't compile (no _exit)

marty leisner
 

Thanks....downgrading cmake to 3.18.4 and clearing the cache helped...

marty


On Sat, Nov 28, 2020 at 3:19 AM Alexander Wachter <alexander.wachter@...> wrote:
Hi Marty,

There is a problem with CMake 3.19 and Zephyr. Downgrade CMake and try again.
The related issue is tracked here:


Cheers,
Alex

Am 27.11.2020 um 23:03 schrieb marty leisner <maleisner@...>:


I started with zephyr off the instructions at:


I'm using ubuntu 18.04.

Executing:
west -v build -p auto -b sam_v71b_xult samples/hello_world

compiling empty files can't find _exit -- here's the CMakeError.log.

I followed the instructions twice (removed the first install)

marty


<CMakeError.log>


New Manifest GitHub Action

Carles Cufi
 

Hi all,

We've recently merged and enabled a new GitHub Action to help with manifest (west.yml) updates.
The Action runs on every Pull Request and automatically detects any changes made to west.yml, adding labels accordingly and displaying a summary in table form:
https://github.com/zephyrproject-rtos/zephyr/pull/30297#issuecomment-734987280

What this means for you if you are a module maintainer or submit updates to module repositories:

- You do not need to manually "link" the PR to the module and the PR to the main tree anymore, this will be done by the GitHub action
- You do not need to set or remove a "DNM" label anymore, this will be done by the action
- You can check if the new revision matches the tip of a branch by checking the comment posted by the action
- Everything else needs to be done just like before, the action will not create Pull Requests for you (yet)

If you are interested in running this action in your own downstream or west-based repository, you can find the relevant info here:
https://github.com/zephyrproject-rtos/zephyr/blob/master/.github/workflows/manifest.yml
https://github.com/zephyrproject-rtos/action-manifest

Thanks,

Carles


What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Katsuhiro Suzuki
 

Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki


Re: building my first project --- can't compile (no _exit)

Alexander Wachter <alexander.wachter@...>
 

Hi Marty,

There is a problem with CMake 3.19 and Zephyr. Downgrade CMake and try again.
The related issue is tracked here:


Cheers,
Alex

Am 27.11.2020 um 23:03 schrieb marty leisner <maleisner@...>:


I started with zephyr off the instructions at:


I'm using ubuntu 18.04.

Executing:
west -v build -p auto -b sam_v71b_xult samples/hello_world

compiling empty files can't find _exit -- here's the CMakeError.log.

I followed the instructions twice (removed the first install)

marty


<CMakeError.log>


building my first project --- can't compile (no _exit)

marty leisner
 

I started with zephyr off the instructions at:


I'm using ubuntu 18.04.

Executing:
west -v build -p auto -b sam_v71b_xult samples/hello_world

compiling empty files can't find _exit -- here's the CMakeError.log.

I followed the instructions twice (removed the first install)

marty


341 - 360 of 7815