Date   

Re: LE pair disconnected

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Vinayak,

sorry to bother you again.

In your experience , what reason will cause CONNECTION TERMINATED BY LOCAL HOST”

 

 

 

> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                                                          

        Status: Success (0x00)

        Reason: Connection Terminated By Local Host (0x16)

@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                              

        LE Address: 7A:03:05:31:E7:E6 (Resolvable)

        Reason: Connection terminated by local host (0x02)

 

 

Thank You,

Tommy

From: Tommy Lin (林志聰)
Sent: Tuesday, March 5, 2019 11:29 AM
To: 'Chettimada, Vinayak Kariappa' <vinayak.kariappa.chettimada@...>; Isaac Chen (
陳尚航) <Isaac_Chen@...>; 'Ryan Erickson' <Ryan.Erickson@...>; 'Jamie Mccrae' <Jamie.Mccrae@...>; 'zephyr-devel@...' <zephyr-devel@...>
Cc: 'Hanyu.Hsu@...' <Hanyu.Hsu@...>; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Vinayak,

btmon logs has been put in Attachment.

 

 

Thank You.

Tommy

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, March 4, 2019 3:50 PM
To: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] LE pair disconnected

 

Hi,

 

Could you please provide the btmon HCI logs?

 

Regards,

Vinayak

 

From: "Isaac Chen (陳尚航)" <Isaac_Chen@...>
Date: Monday, 4 March 2019 at 8:01 AM
To: "Tommy Lin (
林志聰)" <Tommy.Lin@...>, Ryan Erickson <Ryan.Erickson@...>, Jamie Mccrae <Jamie.Mccrae@...>, Vinayak Chettimada <vinayak.kariappa.chettimada@...>, "zephyr-devel@..." <zephyr-devel@...>
Cc: "Hanyu.Hsu@..." <Hanyu.Hsu@...>, "Ryan Hsu (
徐振鋒)" <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Zephyr team,

 

We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

 

 

 

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Tommy Lin (林志聰)
Sent: Wednesday, February 27, 2019 4:03 PM
To: Ryan Erickson; Jamie Mccrae; Isaac Chen (
陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒)
Subject: [Zephyr-devel] LE pair disconnected

 

Hi Ryan Erickson,

We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

After then , we can find out device(named “2019bt”) in our phone , and we can pair it.

But “2019bt” will be disconnected after about two second at connected.

Could you give us some suggestions

Thank  You.

 


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Kai Ren
 

Hi Johan,
Thank so the reply!
I got the point and I built *mesh* application basing on microbit_gatt.conf, but the compiling console told me that RAM is oversize, 104.03%.

Memory region Used Size Region Size %age Used
FLASH: 105156 B 256 KB 40.11%
SRAM: 17044 B 16 KB 104.03%
IDT_LIST: 120 B 2 KB 5.86

The compiler I used is gcc-arm-none-eabi-8-2018-q4-major.
The commit is 3aa8443ab41202f978258810961dbc5a74ad2727

By the way, could you please share that what compiler you used and the specific version?


_____________________________
Regards,
Kai




On 2019/3/12, 10:54 PM, "Hedberg, Johan" <johan.hedberg@intel.com> wrote:

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@bluetooth.com> wrote:
> This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727
>
> I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
> I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.
> But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
>
> “This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”
>
> Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:
>
> CONFIG_BT_PERIPHERAL=y
> CONFIG_BT_MESH_GATT_PROXY=y
> CONFIG_BT_MESH_PB_GATT=y
> CONFIG_BT_MESH_PB_ADV=n
>
> Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?

It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


Re: Few questions regarding sockets/DTLS and net_offload

Benjamin Lindqvist
 

Hi Robert,

Thanks for a quick response :)

I don't have a strong preference regarding lazy handshaking, it's probably better the way you implemented it - I'd recommend elaborating the source code comment though, because the behavior differs from the net_app API.

Good info re: HOSTNAME. Would keeping it enable require working DNS? We haven't had time to verify that DNS works. Indeed we know that it was broken under net_app so we haven't really bothered.

Another thing that seemed slightly broken under net_app was re-initializing the DTLS handshake when we suspected a lost connection, do you know if this is still an issue?

On Tue, Mar 12, 2019 at 5:07 PM Lubos, Robert <Robert.Lubos@...> wrote:

Hello Benjamin,

 

I’ll try to address part of your questions:

 

  • First, regarding delayed handshakes. In sockets_tls.c:

 

    • if (net_context_get_type(ctx) == SOCK_STREAM) {
      • /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

 

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

 

  • The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

 

  • Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

 

Best regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, March 12, 2019 16:47
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

First, regarding delayed handshakes. In sockets_tls.c:

 

               if (net_context_get_type(ctx) == SOCK_STREAM) {

                              /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?


The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

Best regards,

Benjamin


Re: Few questions regarding sockets/DTLS and net_offload

Lubos, Robert
 

Hello Benjamin,

 

I’ll try to address part of your questions:

 

  • First, regarding delayed handshakes. In sockets_tls.c:

 

    • if (net_context_get_type(ctx) == SOCK_STREAM) {
      • /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

 

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

 

  • The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

 

  • Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

 

Best regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, March 12, 2019 16:47
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Few questions regarding sockets/DTLS and net_offload

 

First, regarding delayed handshakes. In sockets_tls.c:

 

               if (net_context_get_type(ctx) == SOCK_STREAM) {

                              /* Do the handshake for TLS, not DTLS. */

 

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?


The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

 

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

 

Best regards,

Benjamin


Few questions regarding sockets/DTLS and net_offload

Benjamin Lindqvist
 

First, regarding delayed handshakes. In sockets_tls.c:

if (net_context_get_type(ctx) == SOCK_STREAM) {
/* Do the handshake for TLS, not DTLS. */

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

Best regards,
Benjamin


Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Johan Hedberg
 

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@bluetooth.com> wrote:
This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.
But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

“This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PB_ADV=n

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?
It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


[Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Kai Ren
 

This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

 

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit, https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.

But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide, https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

 

This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.

 

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

 

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_MESH_GATT_PROXY=y

CONFIG_BT_MESH_PB_GATT=y

CONFIG_BT_MESH_PB_ADV=n

 

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?

 

Thanks.

Kai

 

 

 

 


Re: Unable to install zephyr in Windows following the getting started guide #gettingstartedguide

Carles Cufi
 

Hi Bo,

 

Glad to hear you got this working.

 

The recommended mechanism to install Git in the Zephyr Getting Started guide is to use Chocolatey, which does update the PATH with the Git folder (unless something has changed recently).

That is why we do not have a specific note regarding this in the documentation.

 

Carles

 

From: devel@... <devel@...> On Behalf Of Bo.Kragelund via Lists.Zephyrproject.Org
Sent: 12 March 2019 14:21
To: devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] Unable to install zephyr in Windows following the getting started guide #gettingstartedguide

 

Hi Carles,

And thank you very much for the very quick answer.

I have installed git version 2.20.1 on my Windows and for some reason git doesn't add the path of its binary folder to the PATH environment variable.

After manually adding the git path "C:\Program Files\Git\bin" everything works fine :-)
west can now be used to install zephyr and also update west by following the below commands from the getting started guide.

west init zephyrproject
cd zephyrproject
west update


It might be a good idea to add a note in the getting started guide, that you have to make sure the path for git is added to the Windows PATH environment variable to make it work in Windows.

Best regards,
Bo


Re: Unable to install zephyr in Windows following the getting started guide #gettingstartedguide

Bo.Kragelund@...
 

Hi Carles,

And thank you very much for the very quick answer.

I have installed git version 2.20.1 on my Windows and for some reason git doesn't add the path of its binary folder to the PATH environment variable.

After manually adding the git path "C:\Program Files\Git\bin" everything works fine :-)
west can now be used to install zephyr and also update west by following the below commands from the getting started guide.

west init zephyrproject
cd zephyrproject
west update

It might be a good idea to add a note in the getting started guide, that you have to make sure the path for git is added to the Windows PATH environment variable to make it work in Windows.

Best regards,
Bo


Re: Unable to install zephyr in Windows following the getting started guide #gettingstartedguide

Carles Cufi
 

Hi Bo,

 

I notice 2 issues with your screenshots:

 

  1. You are running `west init` in c:\. I certainly would not recommend that. My recommendation would be to initialize zephyr in your user folder (typically c:\Users\<username>)
  2. `git` does not seem to be in your PATH. If you add `git` to your path the error should go away. In my computer, git.exe is in C:\Program Files\Git\bin

 

Carles

 

From: devel@... <devel@...> On Behalf Of Bo.Kragelund via Lists.Zephyrproject.Org
Sent: 12 March 2019 12:20
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Unable to install zephyr in Windows following the getting started guide #gettingstartedguide

 

Hi zephyr,

I am not able to install the latest zephyr on Windows following the getting started guide.

I have previously installed zephyr on Windows without any issues.
But following the latest getting started guide, where west is now used as a part of installing zephyr, I get some problems with west.

I have forced installation of west again, which can be seen on the first attached picture "clone zephyr using west.png".
In this picture, I then verify the west version, and finally try to install zephyr with west, as explained in the getting started guide.
The errors I get can be seen on this first picture.

Then I try another approach.
I manually clone zephyr to a location using git bash in Windows without any problems.
Then I again follow the getting started guide and create an empty folder named "zephyrproject".
I copy my manually cloned zephyr into this folder.
As seen on the second attached picture "clone zephyr manually and use west after.png", I now have a "zephyr" folder below "zephyrproject" as displayed by the dir command.
Then I use the west init command as explained in the getting started guide and get the same errors, which can also be seen on this second picture.

I hope you can help me fix this issue.

In Linux, everything works fine following the getting started and using west for installing zephyr :-)

Best regards,
Bo Kragelund


Unable to install zephyr in Windows following the getting started guide #gettingstartedguide

Bo.Kragelund@...
 

Hi zephyr,

I am not able to install the latest zephyr on Windows following the getting started guide.

I have previously installed zephyr on Windows without any issues.
But following the latest getting started guide, where west is now used as a part of installing zephyr, I get some problems with west.

I have forced installation of west again, which can be seen on the first attached picture "clone zephyr using west.png".
In this picture, I then verify the west version, and finally try to install zephyr with west, as explained in the getting started guide.
The errors I get can be seen on this first picture.

Then I try another approach.
I manually clone zephyr to a location using git bash in Windows without any problems.
Then I again follow the getting started guide and create an empty folder named "zephyrproject".
I copy my manually cloned zephyr into this folder.
As seen on the second attached picture "clone zephyr manually and use west after.png", I now have a "zephyr" folder below "zephyrproject" as displayed by the dir command.
Then I use the west init command as explained in the getting started guide and get the same errors, which can also be seen on this second picture.

I hope you can help me fix this issue.

In Linux, everything works fine following the getting started and using west for installing zephyr :-)

Best regards,
Bo Kragelund


Re: Error when using './boards/x86/common/scripts/build_grub.sh x86_64' on Clear Linux

Boie, Andrew P
 

Ø  Should I submit this to Zephyr (as a PR)?

 

Assuming this works in your testing, we would appreciate a patch. :)

 

Andrew

 

From: devel@... [mailto:devel@...] On Behalf Of Geoffroy Van Cutsem
Sent: Monday, March 11, 2019 10:31 AM
To: VanCutsem, Geoffroy <geoffroy.vancutsem@...>; devel@...
Subject: Re: [Zephyr-devel] Error when using './boards/x86/common/scripts/build_grub.sh x86_64' on Clear Linux

 

Quick update following some more testing I did. I hit the same "packed-not-aligned" issue on Fedora 29. I applied the same fix and subsequently hit another issue (see error below), which got resolved by cherry-picking another commit from Grub2 that's in their master but not in 2.02. Here is the diff that allowed be to build the GRUB2 boot loader image (not tested yet on real hardware):

 

[gvancuts@geoffroy-nuc-fedora zephyr]$ git diff

diff --git a/boards/x86/common/scripts/build_grub.sh b/boards/x86/common/scripts/build_grub.sh

index 8b628ab809..7247a904c2 100755

--- a/boards/x86/common/scripts/build_grub.sh

+++ b/boards/x86/common/scripts/build_grub.sh

@@ -23,6 +23,8 @@ prepare() {

   pushd src

   git checkout grub-2.02

   git cherry-pick c36c2a86404f373100775305f532c09d46f3c6ce

+  git cherry-pick 563b1da6e6ae7af46cc8354cadb5dab416989f0a

+  git cherry-pick 842c390469e2c2e10b5aa36700324cd3bde25875

   git clean -fdx

   popd

}

 

Should I submit this to Zephyr (as a PR)?

 

Thanks,

Geoffroy

 

* Second error after cherry-picking the fix for "packed-not-aligned":

<snip>

make[2]: Entering directory '/home/gvancuts/work/zephyrproject/zephyr/boards/x86/common/scripts/grub/src/util/bash-completion.d'

../../config.status --file=grub:grub-completion.bash.in

config.status: creating grub

make[2]: Leaving directory '/home/gvancuts/work/zephyrproject/zephyr/boards/x86/common/scripts/grub/src/util/bash-completion.d'

make[1]: Leaving directory '/home/gvancuts/work/zephyrproject/zephyr/boards/x86/common/scripts/grub/src'

./grub-mkimage: error: relocation 0x4 is not implemented yet.

 

From: devel@... [mailto:devel@...] On Behalf Of Geoffroy Van Cutsem
Sent: Monday, March 11, 2019 4:42 PM
To: devel@...
Subject: [Zephyr-devel] Error when using './boards/x86/common/scripts/build_grub.sh x86_64' on Clear Linux

 

Hi folks,

I am trying to build a GRUB2 bootloader image following these steps on a Clear Linux system (version 28230). I ran into the problem below (see output at [1]). That is a problem with gcc 8.x that has since been resolved upstream (but not in the 2.02 version used by Zephyr), I cherry-picked that change and applied it (see [2]), but now I'm running into a new, different issue:
<snip>
    -e "/OUTPUT_TERMINAL_LIST_MARKER *( *\"/{s/.*( *\"\([^\"]*\)\".*/o\1: $b/;p;}" $pp; \
done) | sort -u > terminal.lst
In file included from ../include/grub/dl.h:29,
                 from loader/i386/bsd.c:26:
loader/i386/bsd.c: In function ‘grub_cmd_openbsd’:
../include/grub/misc.h:71:10: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   return grub_memmove (dest, src, n);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
loader/i386/bsd.c:264:9: note: ‘ptr’ was declared here
   void *ptr;
         ^~~
In file included from ../include/grub/dl.h:29,
<snip>

Has anyone seen this?

Thanks,
Geoffroy

[1] Error when running the upstream build_grub.sh script on Clear Linux:
In file included from grub-core/partmap/gpt.c:26:
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:6490: grub-core/partmap/libgrubkern_a-gpt.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f grub-core/lib/.deps-util/grub_mkrescue-reed_solomon.Tpo grub-core/lib/.deps-util/grub_mkrescue-reed_solomon.Po
mv -f grub-core/osdep/.deps-util/grub_mkrescue-random.Tpo grub-core/osdep/.deps-util/grub_mkrescue-random.Po
mv -f grub-core/osdep/.deps-util/grub_mkrescue-ofpath.Tpo grub-core/osdep/.deps-util/grub_mkrescue-ofpath.Po
In file included from grub-core/disk/ldm.c:26:
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:6462: grub-core/disk/libgrubkern_a-ldm.o] Error 1
make[2]: Leaving directory '/home/gvancuts/work/zephyr/boards/x86/common/scripts/grub/src'
make[1]: *** [Makefile:11295: all-recursive] Error 1
make[1]: Leaving directory '/home/gvancuts/work/zephyr/boards/x86/common/scripts/grub/src'
make: *** [Makefile:3515: all] Error 2
./boards/x86/common/scripts/build_grub.sh: line 39: ./grub-mkimage: No such file or directory
~/work/zephyr/boards/x86/common/scripts/grub ~/work/zephyr
cp: cannot stat 'src/grub_x86_64.efi': No such file or directory

[2] Fix for "packed-not-aligned" error
$ git diff
diff --git a/boards/x86/common/scripts/build_grub.sh b/boards/x86/common/scripts/build_grub.sh
index 8b628ab809..a38cd93faa 100755
--- a/boards/x86/common/scripts/build_grub.sh
+++ b/boards/x86/common/scripts/build_grub.sh
@@ -23,6 +23,7 @@ prepare() {
   pushd src
   git checkout grub-2.02
   git cherry-pick c36c2a86404f373100775305f532c09d46f3c6ce
+  git cherry-pick 563b1da6e6ae7af46cc8354cadb5dab416989f0a
   git clean -fdx
   popd
 }


Re: Error when using './boards/x86/common/scripts/build_grub.sh x86_64' on Clear Linux

Geoffroy Van Cutsem
 

Quick update following some more testing I did. I hit the same "packed-not-aligned" issue on Fedora 29. I applied the same fix and subsequently hit another issue (see error below), which got resolved by cherry-picking another commit from Grub2 that's in their master but not in 2.02. Here is the diff that allowed be to build the GRUB2 boot loader image (not tested yet on real hardware):

 

[gvancuts@geoffroy-nuc-fedora zephyr]$ git diff

diff --git a/boards/x86/common/scripts/build_grub.sh b/boards/x86/common/scripts/build_grub.sh

index 8b628ab809..7247a904c2 100755

--- a/boards/x86/common/scripts/build_grub.sh

+++ b/boards/x86/common/scripts/build_grub.sh

@@ -23,6 +23,8 @@ prepare() {

   pushd src

   git checkout grub-2.02

   git cherry-pick c36c2a86404f373100775305f532c09d46f3c6ce

+  git cherry-pick 563b1da6e6ae7af46cc8354cadb5dab416989f0a

+  git cherry-pick 842c390469e2c2e10b5aa36700324cd3bde25875

   git clean -fdx

   popd

}

Should I submit this to Zephyr (as a PR)?

 

Thanks,

Geoffroy

 

* Second error after cherry-picking the fix for "packed-not-aligned":

<snip>

make[2]: Entering directory '/home/gvancuts/work/zephyrproject/zephyr/boards/x86/common/scripts/grub/src/util/bash-completion.d'

../../config.status --file=grub:grub-completion.bash.in

config.status: creating grub

make[2]: Leaving directory '/home/gvancuts/work/zephyrproject/zephyr/boards/x86/common/scripts/grub/src/util/bash-completion.d'

make[1]: Leaving directory '/home/gvancuts/work/zephyrproject/zephyr/boards/x86/common/scripts/grub/src'

./grub-mkimage: error: relocation 0x4 is not implemented yet.

 

From: devel@... [mailto:devel@...] On Behalf Of Geoffroy Van Cutsem
Sent: Monday, March 11, 2019 4:42 PM
To: devel@...
Subject: [Zephyr-devel] Error when using './boards/x86/common/scripts/build_grub.sh x86_64' on Clear Linux

 

Hi folks,

I am trying to build a GRUB2 bootloader image following these steps on a Clear Linux system (version 28230). I ran into the problem below (see output at [1]). That is a problem with gcc 8.x that has since been resolved upstream (but not in the 2.02 version used by Zephyr), I cherry-picked that change and applied it (see [2]), but now I'm running into a new, different issue:
<snip>
    -e "/OUTPUT_TERMINAL_LIST_MARKER *( *\"/{s/.*( *\"\([^\"]*\)\".*/o\1: $b/;p;}" $pp; \
done) | sort -u > terminal.lst
In file included from ../include/grub/dl.h:29,
                 from loader/i386/bsd.c:26:
loader/i386/bsd.c: In function ‘grub_cmd_openbsd’:
../include/grub/misc.h:71:10: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   return grub_memmove (dest, src, n);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
loader/i386/bsd.c:264:9: note: ‘ptr’ was declared here
   void *ptr;
         ^~~
In file included from ../include/grub/dl.h:29,
<snip>

Has anyone seen this?

Thanks,
Geoffroy

[1] Error when running the upstream build_grub.sh script on Clear Linux:
In file included from grub-core/partmap/gpt.c:26:
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:6490: grub-core/partmap/libgrubkern_a-gpt.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f grub-core/lib/.deps-util/grub_mkrescue-reed_solomon.Tpo grub-core/lib/.deps-util/grub_mkrescue-reed_solomon.Po
mv -f grub-core/osdep/.deps-util/grub_mkrescue-random.Tpo grub-core/osdep/.deps-util/grub_mkrescue-random.Po
mv -f grub-core/osdep/.deps-util/grub_mkrescue-ofpath.Tpo grub-core/osdep/.deps-util/grub_mkrescue-ofpath.Po
In file included from grub-core/disk/ldm.c:26:
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:6462: grub-core/disk/libgrubkern_a-ldm.o] Error 1
make[2]: Leaving directory '/home/gvancuts/work/zephyr/boards/x86/common/scripts/grub/src'
make[1]: *** [Makefile:11295: all-recursive] Error 1
make[1]: Leaving directory '/home/gvancuts/work/zephyr/boards/x86/common/scripts/grub/src'
make: *** [Makefile:3515: all] Error 2
./boards/x86/common/scripts/build_grub.sh: line 39: ./grub-mkimage: No such file or directory
~/work/zephyr/boards/x86/common/scripts/grub ~/work/zephyr
cp: cannot stat 'src/grub_x86_64.efi': No such file or directory

[2] Fix for "packed-not-aligned" error
$ git diff
diff --git a/boards/x86/common/scripts/build_grub.sh b/boards/x86/common/scripts/build_grub.sh
index 8b628ab809..a38cd93faa 100755
--- a/boards/x86/common/scripts/build_grub.sh
+++ b/boards/x86/common/scripts/build_grub.sh
@@ -23,6 +23,7 @@ prepare() {
   pushd src
   git checkout grub-2.02
   git cherry-pick c36c2a86404f373100775305f532c09d46f3c6ce
+  git cherry-pick 563b1da6e6ae7af46cc8354cadb5dab416989f0a
   git clean -fdx
   popd
 }


Re: Default LED Pin for STM32 min dev board

Erwan Gouriou
 

Hi,

So, actually, what you request is a revert of https://github.com/zephyrproject-rtos/zephyr/pull/11736,
which was fixing LED pinmux from PB12 to PC13, thought which missed doc update.
As you mention, there are actually two versions of that board, one based on stm32f103C8 using PC13 and the other one based on stm32f103C6 (led on PB12), which appears to be a "fake/alternate" one.(https://embeddedtronicsblog.wordpress.com/2018/12/29/fake-stm32-blue-pill-boards/)
So, since the board version in zephyr today is based on stm32f103C8, it makes sense to keep LED on PC13.
But, it would be nice to get the doc updated at least.

Erwan


On Mon, 11 Mar 2019 at 17:18, Eghonghon Eigbe <E.Eigbe@...> wrote:

Hello!


We are a group of four Embedded Systems graduate students from TU Delft who are working on analyzing the architecture of the Zephyr project for our Software Architecture class. We want to contribute to the project as well. 


  • When we tried to build Zephyr's blinky example for STM32 minimum development board we found a bug where in the default pin for the on board LED is mapped to PC13 whereas the Zephyr documentation as well as the board's data sheet says it is on PB12 (there is some variability depending on the exact version of the board). Should we open an issue which describes this (along with a solution)?

 

Thanks and Regards,

Eghonghon, Jure, Oxana & Suryansh


Re: Default LED Pin for STM32 min dev board

Marti Bolivar <marti@...>
 

Hi Eghongon (et al),

Welcome to Zephyr!

This sounds like a quick fix - mind just sending a patch? You can link to the datasheet in the GitHub comments for your pull request. Please look at the contributing guide in the docs for details on the procedure.

Thanks,
Marti


On Mon, Mar 11, 2019, 10:18 AM Eghonghon Eigbe <E.Eigbe@...> wrote:

Hello!


We are a group of four Embedded Systems graduate students from TU Delft who are working on analyzing the architecture of the Zephyr project for our Software Architecture class. We want to contribute to the project as well. 


  • When we tried to build Zephyr's blinky example for STM32 minimum development board we found a bug where in the default pin for the on board LED is mapped to PC13 whereas the Zephyr documentation as well as the board's data sheet says it is on PB12 (there is some variability depending on the exact version of the board). Should we open an issue which describes this (along with a solution)?

 

Thanks and Regards,

Eghonghon, Jure, Oxana & Suryansh


Default LED Pin for STM32 min dev board

E.Eigbe@...
 

Hello!


We are a group of four Embedded Systems graduate students from TU Delft who are working on analyzing the architecture of the Zephyr project for our Software Architecture class. We want to contribute to the project as well. 


  • When we tried to build Zephyr's blinky example for STM32 minimum development board we found a bug where in the default pin for the on board LED is mapped to PC13 whereas the Zephyr documentation as well as the board's data sheet says it is on PB12 (there is some variability depending on the exact version of the board). Should we open an issue which describes this (along with a solution)?

 

Thanks and Regards,

Eghonghon, Jure, Oxana & Suryansh


Error when using './boards/x86/common/scripts/build_grub.sh x86_64' on Clear Linux

Geoffroy Van Cutsem
 

Hi folks,

I am trying to build a GRUB2 bootloader image following these steps on a Clear Linux system (version 28230). I ran into the problem below (see output at [1]). That is a problem with gcc 8.x that has since been resolved upstream (but not in the 2.02 version used by Zephyr), I cherry-picked that change and applied it (see [2]), but now I'm running into a new, different issue:
<snip>
    -e "/OUTPUT_TERMINAL_LIST_MARKER *( *\"/{s/.*( *\"\([^\"]*\)\".*/o\1: $b/;p;}" $pp; \
done) | sort -u > terminal.lst
In file included from ../include/grub/dl.h:29,
                 from loader/i386/bsd.c:26:
loader/i386/bsd.c: In function ‘grub_cmd_openbsd’:
../include/grub/misc.h:71:10: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   return grub_memmove (dest, src, n);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
loader/i386/bsd.c:264:9: note: ‘ptr’ was declared here
   void *ptr;
         ^~~
In file included from ../include/grub/dl.h:29,
<snip>

Has anyone seen this?

Thanks,
Geoffroy

[1] Error when running the upstream build_grub.sh script on Clear Linux:
In file included from grub-core/partmap/gpt.c:26:
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:6490: grub-core/partmap/libgrubkern_a-gpt.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f grub-core/lib/.deps-util/grub_mkrescue-reed_solomon.Tpo grub-core/lib/.deps-util/grub_mkrescue-reed_solomon.Po
mv -f grub-core/osdep/.deps-util/grub_mkrescue-random.Tpo grub-core/osdep/.deps-util/grub_mkrescue-random.Po
mv -f grub-core/osdep/.deps-util/grub_mkrescue-ofpath.Tpo grub-core/osdep/.deps-util/grub_mkrescue-ofpath.Po
In file included from grub-core/disk/ldm.c:26:
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:6462: grub-core/disk/libgrubkern_a-ldm.o] Error 1
make[2]: Leaving directory '/home/gvancuts/work/zephyr/boards/x86/common/scripts/grub/src'
make[1]: *** [Makefile:11295: all-recursive] Error 1
make[1]: Leaving directory '/home/gvancuts/work/zephyr/boards/x86/common/scripts/grub/src'
make: *** [Makefile:3515: all] Error 2
./boards/x86/common/scripts/build_grub.sh: line 39: ./grub-mkimage: No such file or directory
~/work/zephyr/boards/x86/common/scripts/grub ~/work/zephyr
cp: cannot stat 'src/grub_x86_64.efi': No such file or directory

[2] Fix for "packed-not-aligned" error
$ git diff
diff --git a/boards/x86/common/scripts/build_grub.sh b/boards/x86/common/scripts/build_grub.sh
index 8b628ab809..a38cd93faa 100755
--- a/boards/x86/common/scripts/build_grub.sh
+++ b/boards/x86/common/scripts/build_grub.sh
@@ -23,6 +23,7 @@ prepare() {
   pushd src
   git checkout grub-2.02
   git cherry-pick c36c2a86404f373100775305f532c09d46f3c6ce
+  git cherry-pick 563b1da6e6ae7af46cc8354cadb5dab416989f0a
   git clean -fdx
   popd
 }


Re: Zephyr SDK 0.10.0 available

Zephyr Project
 

Hi Luiz,
The Zephyr SDK can be found on the Developers page in the Downloads section here: https://www.zephyrproject.org/developers/#downloads

We'll re-work the page so its easier to find!

Best,
Thea


On Mon, Mar 11, 2019 at 11:36 AM Luiz Augusto von Dentz <luiz.dentz@...> wrote:
Hi Kumar,

It seems there is no link for it in the developers page:

https://www.zephyrproject.org/developers/

On Sun, Mar 10, 2019 at 2:00 AM Kumar Gala <kumar.gala@...> wrote:
>
> The is the first release of the Zephyr SDK that utilizes crosstool-ng to build the toolchains. We utilize crosstool-ng-1.24.0-rc2.
>
> Toolchain version:
>
>         • GCC 8.3
>         • GDB 8.2.1
>         • BINUTILS 2.32
>         • NEWLIB 3.1.0 (except on xtensa)
>
> We continue to utilize yocto to build the hosts tools:
>
>         • Qemu 3.1.0 (SHA: 32a1a94dd324d33578dca1dc96d7896a0244d768)
>         • OpenOCD 0.10.0 - snapshot from 20190226 (SHA: f21c12abecb9df244f147740166378ede7ea398e)
>         • bossa 1.9.1 (SHA: 3279031813093aa404b8561c8dd7a39dd24ebc70)
>         • dtc 1.4.7+ (SHA: 78e113e81c9d33d0f33704b187a46399d5a75419)
>
>


--
Luiz Augusto von Dentz




Re: LE pair disconnected

Isaac Chen (陳尚航) <Isaac_Chen@...>
 

Hi Carles,

 

We are using 1.13.

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Monday, March 04, 2019 7:40 PM
To: Isaac Chen (
陳尚航); Tommy Lin (林志聰); Ryan Erickson; Jamie Mccrae; Chettimada, Vinayak Kariappa; zephyr-devel@...
Cc: devel@...
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi there,

 

Which version of Zephyr are you using? 1.13 or the latest master?

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of via Lists.Zephyrproject.Org
Sent: 04 March 2019 08:01
To: Tommy Lin (
林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; zephyr-devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] LE pair disconnected
Importance: High

 

Hi Zephyr team,

 

We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

 

 

 

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Tommy Lin (林志聰)
Sent: Wednesday, February 27, 2019 4:03 PM
To: Ryan Erickson; Jamie Mccrae; Isaac Chen (
陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒)
Subject: [Zephyr-devel] LE pair disconnected

 

Hi Ryan Erickson,

We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

After then , we can find out device(named “2019bt”) in our phone , and we can pair it.

But “2019bt” will be disconnected after about two second at connected.

Could you give us some suggestions

Thank  You.

 


Re: LE pair disconnected

Isaac Chen (陳尚航) <Isaac_Chen@...>
 

Hi Vinayak,

 

Do you find any cue on btmon logs?

 

 

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Tommy Lin (林志聰)
Sent: Tuesday, March 05, 2019 11:29 AM
To: Chettimada, Vinayak Kariappa; Isaac Chen (
陳尚航); Ryan Erickson; Jamie Mccrae; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒)
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Vinayak,

btmon logs has been put in Attachment.

 

 

Thank You.

Tommy

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, March 4, 2019 3:50 PM
To: Isaac Chen (
陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; Ryan Erickson <Ryan.Erickson@...>; Jamie Mccrae <Jamie.Mccrae@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] LE pair disconnected

 

Hi,

 

Could you please provide the btmon HCI logs?

 

Regards,

Vinayak

 

From: "Isaac Chen (陳尚航)" <Isaac_Chen@...>
Date: Monday, 4 March 2019 at 8:01 AM
To: "Tommy Lin (
林志聰)" <Tommy.Lin@...>, Ryan Erickson <Ryan.Erickson@...>, Jamie Mccrae <Jamie.Mccrae@...>, Vinayak Chettimada <vinayak.kariappa.chettimada@...>, "zephyr-devel@..." <zephyr-devel@...>
Cc: "Hanyu.Hsu@..." <Hanyu.Hsu@...>, "Ryan Hsu (
徐振鋒)" <Ryan.Hsu@...>
Subject: RE: [Zephyr-devel] LE pair disconnected

 

Hi Zephyr team,

 

We can find this issue on nRF51 DK and our custom board with zephyr source code(samples/bluetooth/hci_uart). Could you give us your advice on how to solve this issue?

 

 

 

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Tommy Lin (林志聰)
Sent: Wednesday, February 27, 2019 4:03 PM
To: Ryan Erickson; Jamie Mccrae; Isaac Chen (
陳尚航); Chettimada, Vinayak Kariappa; zephyr-devel@...
Cc: Hanyu.Hsu@...; Ryan Hsu (
徐振鋒)
Subject: [Zephyr-devel] LE pair disconnected

 

Hi Ryan Erickson,

We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

After then , we can find out device(named “2019bt”) in our phone , and we can pair it.

But “2019bt” will be disconnected after about two second at connected.

Could you give us some suggestions

Thank  You.

 

1981 - 2000 of 7760