Date   

Re: SAME70 Xplained failed to build with ethernet networking

nandojve@...
 

Hi Sam Wong,

We define two SoC versions at boards/sam_e70_xplained, same for sam_v71_xult:
Version SoC rev A:  sam_e70_xplained
Version SoC rev B:  sam_e70b_xplained

> Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

> “Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

> Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

The range [1,3] is for SoC rev A.


Make sure you always use version B since your SoC is the last version and you will see range [1,6].

BR,
Gerson

Em qua., 8 de jul. de 2020 às 23:11, Sam Wong <sam@...> escreveu:

Tried many times. No change, still don’t have sam_e70b_xplained.

I even tried from scratch, ran

 

                West init ~/zephyr

                Cd ~/zephyr

                West update

                Cd zephyr

                West build -p auto -b sam_e70_xplained samples/net/telnet

 

Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

“Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

 

Thanks.

Sam

 

 

 

 

From: Stephanos Ioannidis <root@...>
Date: Wednesday, July 8, 2020 at 5:15 PM
To: Sam Wong <sam@...>, Gerson Fernando Budke <nandojve@...>
Cc: "users@..." <users@...>
Subject: RE: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Have you tried ‘west update’?

 

Stephanos

 

From: users@... <users@...> On Behalf Of Sam Wong via lists.zephyrproject.org
Sent: Thursday, July 9, 2020 7:47 AM
To: Gerson Fernando Budke <nandojve@...>
Cc: users@...
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Gerson,

 

My apology, I’m new to these.

 

I deleted the zephyr folder, re-clone from the master. Went to zephyr, type git fetch upstream and got

 

---------

fatal: 'upstream' does not appear to be a git repository

fatal: Could not read from remote repository.

 

Please make sure you have the correct access rights

and the repository exists.

---------

 

sam_e70b_xplained does not exist in the boards/arm folder. Is it part of the upstream repository?

 

Thanks.

Sam

 

From: Gerson Fernando Budke <nandojve@...>
Date: Wednesday, July 8, 2020 at 2:23 PM
To: Sam Wong <sam@...>
Cc: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @ Sam Wong,

 

I made a build test and it is working for me.

 

git checkout master

git fetch upstream

git rebase upstream/master

west update

 

west build -b sam_e70b_xplained samples/net/telnet

west build -t menuconfig

 

change

Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

 

Add more buffers:

Network -> Ip Stack ->

20 packages receive at same time

20 packages send

80 network buffer to receive

80 network buffer to send

 

You can ignore the 2 warnings.

Please, let me know if it works for you.

 

Gerson

 

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------

In file included from ../include/toolchain.h:39,

                 from ../include/sys/atomic.h:13,

                 from ../include/logging/log_msg.h:9,

                 from ../include/logging/log_core.h:9,

                 from ../include/logging/log.h:11,

                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:

../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"

   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)

      |                                    ^~~~~~~~~~~~~~

/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'

   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,

      | ^~~~~~~~~~~~

[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj

ninja: build stopped: subcommand failed.

FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Accessing ADC on Adafruit Feather nrf52832

Tomas McGuinness
 


Hi,

Does anyone know if it’s possible to access the ADC on the Adafruit Feather nRF52832 board?

I want to access pin 31 to read the battery level.

Regards,
Tom


Re: SAME70 Xplained failed to build with ethernet networking

Sam Wong
 

Tried many times. No change, still don’t have sam_e70b_xplained.

I even tried from scratch, ran

 

                West init ~/zephyr

                Cd ~/zephyr

                West update

                Cd zephyr

                West build -p auto -b sam_e70_xplained samples/net/telnet

 

Don’t know what’s change between now and last week. When I ran menuconfig after building telnet,

“Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues” showed a valid range of [1,0].

Before I re-cloned zephyr, that range used to be [1,3]. How do you fix that?

 

Thanks.

Sam

 

 

 

 

From: Stephanos Ioannidis <root@...>
Date: Wednesday, July 8, 2020 at 5:15 PM
To: Sam Wong <sam@...>, Gerson Fernando Budke <nandojve@...>
Cc: "users@..." <users@...>
Subject: RE: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Have you tried ‘west update’?

 

Stephanos

 

From: users@... <users@...> On Behalf Of Sam Wong via lists.zephyrproject.org
Sent: Thursday, July 9, 2020 7:47 AM
To: Gerson Fernando Budke <nandojve@...>
Cc: users@...
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Gerson,

 

My apology, I’m new to these.

 

I deleted the zephyr folder, re-clone from the master. Went to zephyr, type git fetch upstream and got

 

---------

fatal: 'upstream' does not appear to be a git repository

fatal: Could not read from remote repository.

 

Please make sure you have the correct access rights

and the repository exists.

---------

 

sam_e70b_xplained does not exist in the boards/arm folder. Is it part of the upstream repository?

 

Thanks.

Sam

 

From: Gerson Fernando Budke <nandojve@...>
Date: Wednesday, July 8, 2020 at 2:23 PM
To: Sam Wong <sam@...>
Cc: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @ Sam Wong,

 

I made a build test and it is working for me.

 

git checkout master

git fetch upstream

git rebase upstream/master

west update

 

west build -b sam_e70b_xplained samples/net/telnet

west build -t menuconfig

 

change

Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

 

Add more buffers:

Network -> Ip Stack ->

20 packages receive at same time

20 packages send

80 network buffer to receive

80 network buffer to send

 

You can ignore the 2 warnings.

Please, let me know if it works for you.

 

Gerson

 

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------

In file included from ../include/toolchain.h:39,

                 from ../include/sys/atomic.h:13,

                 from ../include/logging/log_msg.h:9,

                 from ../include/logging/log_core.h:9,

                 from ../include/logging/log.h:11,

                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:

../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"

   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)

      |                                    ^~~~~~~~~~~~~~

/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'

   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,

      | ^~~~~~~~~~~~

[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj

ninja: build stopped: subcommand failed.

FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Re: SAME70 Xplained failed to build with ethernet networking

Stephanos Ioannidis
 

Have you tried ‘west update’?

 

Stephanos

 

From: users@... <users@...> On Behalf Of Sam Wong via lists.zephyrproject.org
Sent: Thursday, July 9, 2020 7:47 AM
To: Gerson Fernando Budke <nandojve@...>
Cc: users@...
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi Gerson,

 

My apology, I’m new to these.

 

I deleted the zephyr folder, re-clone from the master. Went to zephyr, type git fetch upstream and got

 

---------

fatal: 'upstream' does not appear to be a git repository

fatal: Could not read from remote repository.

 

Please make sure you have the correct access rights

and the repository exists.

---------

 

sam_e70b_xplained does not exist in the boards/arm folder. Is it part of the upstream repository?

 

Thanks.

Sam

 

From: Gerson Fernando Budke <nandojve@...>
Date: Wednesday, July 8, 2020 at 2:23 PM
To: Sam Wong <sam@...>
Cc: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @ Sam Wong,

 

I made a build test and it is working for me.

 

git checkout master

git fetch upstream

git rebase upstream/master

west update

 

west build -b sam_e70b_xplained samples/net/telnet

west build -t menuconfig

 

change

Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

 

Add more buffers:

Network -> Ip Stack ->

20 packages receive at same time

20 packages send

80 network buffer to receive

80 network buffer to send

 

You can ignore the 2 warnings.

Please, let me know if it works for you.

 

Gerson

 

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------

In file included from ../include/toolchain.h:39,

                 from ../include/sys/atomic.h:13,

                 from ../include/logging/log_msg.h:9,

                 from ../include/logging/log_core.h:9,

                 from ../include/logging/log.h:11,

                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:

../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"

   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)

      |                                    ^~~~~~~~~~~~~~

/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'

   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,

      | ^~~~~~~~~~~~

[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj

ninja: build stopped: subcommand failed.

FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Re: SAME70 Xplained failed to build with ethernet networking

Sam Wong
 

Hi Gerson,

 

My apology, I’m new to these.

 

I deleted the zephyr folder, re-clone from the master. Went to zephyr, type git fetch upstream and got

 

---------

fatal: 'upstream' does not appear to be a git repository

fatal: Could not read from remote repository.

 

Please make sure you have the correct access rights

and the repository exists.

---------

 

sam_e70b_xplained does not exist in the boards/arm folder. Is it part of the upstream repository?

 

Thanks.

Sam

 

From: Gerson Fernando Budke <nandojve@...>
Date: Wednesday, July 8, 2020 at 2:23 PM
To: Sam Wong <sam@...>
Cc: "users@..." <users@...>
Subject: Re: [Zephyr-users] SAME70 Xplained failed to build with ethernet networking

 

Hi @ Sam Wong,

 

I made a build test and it is working for me.

 

git checkout master

git fetch upstream

git rebase upstream/master

west update

 

west build -b sam_e70b_xplained samples/net/telnet

west build -t menuconfig

 

change

Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

 

Add more buffers:

Network -> Ip Stack ->

20 packages receive at same time

20 packages send

80 network buffer to receive

80 network buffer to send

 

You can ignore the 2 warnings.

Please, let me know if it works for you.

 

Gerson

 

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------

In file included from ../include/toolchain.h:39,

                 from ../include/sys/atomic.h:13,

                 from ../include/logging/log_msg.h:9,

                 from ../include/logging/log_core.h:9,

                 from ../include/logging/log.h:11,

                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:

../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"

   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)

      |                                    ^~~~~~~~~~~~~~

/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'

   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,

      | ^~~~~~~~~~~~

[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj

ninja: build stopped: subcommand failed.

FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Re: SAME70 Xplained failed to build with ethernet networking

nandojve@...
 

Hi @ Sam Wong,

I made a build test and it is working for me.

git checkout master
git fetch upstream
git rebase upstream/master
west update

west build -b sam_e70b_xplained samples/net/telnet
west build -t menuconfig

change
Device driver -> Ethernet Driver -> Atmel SAM -> Number of active TX queues to 6 (max)

Add more buffers:
Network -> Ip Stack ->
20 packages receive at same time
20 packages send
80 network buffer to receive
80 network buffer to send

You can ignore the 2 warnings.
Please, let me know if it works for you.

Gerson

Em qua., 8 de jul. de 2020 às 14:54, Sam Wong via lists.zephyrproject.org <sam=bbinet.com@...> escreveu:

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------
In file included from ../include/toolchain.h:39,
                 from ../include/sys/atomic.h:13,
                 from ../include/logging/log_msg.h:9,
                 from ../include/logging/log_core.h:9,
                 from ../include/logging/log.h:11,
                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:
../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"
   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
      |                                    ^~~~~~~~~~~~~~
/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'
   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,
      | ^~~~~~~~~~~~
[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


Re: [Zephyr-devel] Post 2.3.0 PR merging

Simon Glass <sjg@...>
 

Hi Anas,

Less scientifically I just did some reviews and perhaps half of them already had one approval. So presumably they were blocked. I guess you are saying it's only a third. OK. But that's a lot. Also with two reviewers, people can be somewhat less careful...

How do you deal with the case of people being happy with it but wanting review from someone else before approving? I saw a few where it seemed no one would take the plunge.

Regards,
SImon


On Tue, 7 Jul 2020 at 12:57, Nashif, Anas <anas.nashif@...> wrote:

Hi,

 

Here some data…

 

What I have just posted on slack…

 

 

So, go do some reviews please 😊

 

 

Thanks

Anas

 

From: <devel@...> on behalf of Carles Cufi <carles.cufi@...>
Date: Tuesday, 7 July 2020 at 06:42
To: Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

 

Carles 



Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:

Hi Carles,

 

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

 

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

 

Regards,

SImon

 

 

On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


SAME70 Xplained failed to build with ethernet networking

Sam Wong
 

I bought a new SAME70 Xplained board last week and pulled down the latest from Master. 
Sample projects work as long as networking is not involved. Network projects compiled and run but debugging showed that packet reception is fine but nothing got transmitted. 
Did some digging and saw some patches added for Rev.B chip that fixed the problem. I ran config to specify Rev.B chip. However, network projects now failed to build. 

-----------------------------
In file included from ../include/toolchain.h:39,
                 from ../include/sys/atomic.h:13,
                 from ../include/logging/log_msg.h:9,
                 from ../include/logging/log_core.h:9,
                 from ../include/logging/log.h:11,
                 from /home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac.c:26:
../include/toolchain/gcc.h:62:36: error: static assertion failed: "GMAC_QUEUE_NUM doesn\'t match soc header"
   62 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
      |                                    ^~~~~~~~~~~~~~
/home/sam/zephyr/zephyr/drivers/ethernet/eth_sam_gmac_priv.h:37:1: note: in expansion of macro 'BUILD_ASSERT'
   37 | BUILD_ASSERT(ARRAY_SIZE(GMAC->GMAC_TBQBAPQ) + 1 == GMAC_QUEUE_NUM,
      | ^~~~~~~~~~~~
[58/162] Building C object zephyr/arch...rm__core__aarch32.dir/irq_manage.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/sam/zeph
---------------------------------------

Further digging showed that GMAC_QUEUE_NUM is set to 3 but GMAC->GMAC_TBQBAPQ is 5 for Rev.B chip according to the declaration in the SDK. GMAC->GMAC_TBQBAPQ is 2 for Rev.A chip and so it won't trigger the BUILD_ASSERT. 

num_queue is in auto-generated devicetree_unfixed.h in the build directory. I don't know enough to figure out where to look for the origin of num_queue.
Any help would be appreciated.

Sam


#bluetooth #ble #nrf52832 #bluetooth #ble #nrf52832

edyta.bosacka@...
 

I would like to advertise and scan ONLY on one bluetooth channel (for example channel 37). Is there any way to do this in Zephyr? I tried to search parametr responsibles for it in this structure:
struct bt_le_scan_param scan_param = {
.type = BT_HCI_LE_SCAN_PASSIVE,
.options = BT_LE_SCAN_OPT_NONE,
.interval = 0x0010,
.window = 0x0010,}
but i dont think that this is solution.

I also found a file lll_chan in zephyrproject\zephyr\subsys\bluetooth\controller\ll_sw\nordic\lll. TI includes channel selection algorithms, but i dont see where can i select just one advertising channel?


Communication between native_posix board and external hardware via router

Lei Xu <lei.xu@...>
 

Hi everyone!


I'm trying to setup the communication between a native_posix board and a sensor. The sensor is connected to my router, and the native_posix program is running on my Linux host, which is also connected to the same router.


I have tried to setup a zeth interface using the provided net-tools. The configuration file used for setup zeth is as follows:

INTERFACE="$1"
HWADDR="00:00:5e:00:53:21"
IPV6_ADDR_1="2001:db8:2100::1"
IPV6_ROUTE_1="2001:db8:2100::/64"
IPV4_ADDR_1="192.168.1.104/24"
IPV4_ROUTE_1="192.168.1.0/24"
ip link set dev $INTERFACE up
ip link set dev $INTERFACE address $HWADDR
ip -6 address add $IPV6_ADDR_1 dev $INTERFACE nodad
ip -6 route add $IPV6_ROUTE_1 dev $INTERFACE
ip address add $IPV4_ADDR_1 dev $INTERFACE
ip route add $IPV4_ROUTE_1 dev $INTERFACE > /dev/null 2>&1


Correspondingly, the configurations in my native_posix project are as follows:

CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.168.1.105"
CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.1.1"
#CONFIG_ETH_NATIVE_POSIX_STARTUP_AUTOMATIC=y
CONFIG_ETH_NATIVE_POSIX_RANDOM_MAC=n
CONFIG_ETH_NATIVE_POSIX_MAC_ADDR="00:00:5e:00:53:22"
CONFIG_ETH_NATIVE_POSIX_DRV_NAME="zeth"

where "192.168.1.1" is the router's address.


After building and running the native_posix program, it can only communicate with the local host but cannot communicate with my sensors. May someone figure out what's the problem?


Best regards,

Lei


Scan and advertise on single channel - Bluetooth, Zephyr

edyta.bosacka@...
 

I would like to advertise and scan ONLY on one bluetooth channel (for example channel 37). Is there any way to do this in Zephyr? I tried to search parametr responsibles for it in this structure:
struct bt_le_scan_param scan_param = {
.type = BT_HCI_LE_SCAN_PASSIVE,
.options = BT_LE_SCAN_OPT_NONE,
.interval = 0x0010,
.window = 0x0010,}
but i dont think that this is solution.

I also found a file lll_chan in zephyrproject\zephyr\subsys\bluetooth\controller\ll_sw\nordic\lll. TI includes channel selection algorithms, but i dont see where can i select just one advertising channel?


Scan and advertise only on single bluetooth channel

Edyta Bosacka <edyta.bosacka@...>
 

Hi, Is it possible in Zephyr to advertise and scan through Bluetooth only on single channel ( for example channel37)? I found some file III_chan with channel selection algorithms and I wonder: do i need to change this file somehow or theere is some simple way to do this?


Re: [Zephyr-devel] SDK 0.11.4 Release

Wu, Wentong <wentong.wu@...>
 

Any plan to have 1.14 LTS branch upgrading SDK as master does? IMHO, we should do that because we claim it's LTS branch.

Thanks

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Kumar Gala
Sent: Friday, June 26, 2020 10:46 AM
To: zephyr-users@...; zephyr-devel <zephyr-devel@...>; announce@...
Subject: [Zephyr-devel] SDK 0.11.4 Release

Hi,

Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files)

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4

Please download and try things out and report any issues.

- General:
* Fixed issue with cmake files not being installed in arch specific
toolchan packages

- newlib:
* Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds
* Set march=pentium for 32-bit x86 build

- k


Re: [Zephyr-devel] Post 2.3.0 PR merging

Nashif, Anas
 

Hi,

 

Here some data…

 

What I have just posted on slack…

 

 

So, go do some reviews please 😊

 

 

Thanks

Anas

 

From: <devel@...> on behalf of Carles Cufi <carles.cufi@...>
Date: Tuesday, 7 July 2020 at 06:42
To: Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

 

Carles 



Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:

Hi Carles,

 

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

 

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

 

Regards,

SImon

 

 

On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: [Zephyr-devel] Post 2.3.0 PR merging

Carles Cufi
 

Hi Simon,

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

Carles 

Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:


Hi Carles,

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

Regards,
SImon



On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: [Zephyr-devel] Post 2.3.0 PR merging

Simon Glass <sjg@...>
 

Hi Carles,

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

Regards,
SImon



On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: [Zephyr-devel] Post 2.3.0 PR merging

Nashif, Anas
 

Agreed. Those who can merge, should take 2 approvals and all other checks as a sign that it is ready to merge, no need for the approval of the person who merges, although a 3rd approval might give the PR a strong “Go”. This is actually what we agreed on 😊

 

Anas

 

 

From: <users@...> on behalf of Lawrence King <lawrence.king@...>
Date: Monday, 6 July 2020 at 15:41
To: Carles Cufi <carles.cufi@...>, Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Charles:

 

This just my personal opinion on the subject. Two approvals is the right thing to do and what the TSC approved earlier this year.

 

BUT, if the second +1 is just a rubber stamp approval of the maintainer’s +1 then there is no point having two approvals.

 

The second +1 should come from someone who is: knowledgeable in the area, has studied the changes, and approves.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Carles Cufi
Sent: Monday, July 6, 2020 2:23 PM
To: Simon Glass <sjg@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: [Zephyr-devel] Post 2.3.0 PR merging

Lawrence King
 

Hi Charles:

 

This just my personal opinion on the subject. Two approvals is the right thing to do and what the TSC approved earlier this year.

 

BUT, if the second +1 is just a rubber stamp approval of the maintainer’s +1 then there is no point having two approvals.

 

The second +1 should come from someone who is: knowledgeable in the area, has studied the changes, and approves.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Carles Cufi
Sent: Monday, July 6, 2020 2:23 PM
To: Simon Glass <sjg@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: [Zephyr-devel] Post 2.3.0 PR merging

Carles Cufi
 

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: [Zephyr-devel] Post 2.3.0 PR merging

Simon Glass <sjg@...>
 

Hi Carles,

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:
Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

Perhaps given the situation this should be reversed?

Regards,
Simon 
 

Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles



981 - 1000 of 3076