Date   

Re: Data Length Extension #ble #nrf52 #nrf52832 #nrf52840

Carles Cufi
 

Hi Henry,

 

Take a look at the configuration used in Nordic’s throughput sample:

https://github.com/tejlmand/fw-nrfconnect-nrf/blob/master/samples/bluetooth/throughput/prj.conf

 

I think you are missing several buffer length settings to achieve full speed.

 

Regards,

 

Carles

 

From: <devel@...> on behalf of "henry.wagner via Lists.Zephyrproject.Org" <henry.wagner=lairdtech.com@...>
Reply-To: "henry.wagner@..." <henry.wagner@...>
Date: Thursday, 7 March 2019 at 21:25
To: "devel@..." <devel@...>
Cc: "devel@..." <devel@...>
Subject: [Zephyr-devel] Data Length Extension #ble #nrf52 #nrf52832 #nrf52840

 

I am trying to enable data length extensions in a connection but am limited to the std 20 payload bytes.
I have a Nordic PCA10040 (nRF52832) running Zephyr v1.14rc1 as a central connected to a Laird BL654 module.  Both devices have what I believe to be DLE enabled.
On the Zephyr side I have enabled:

CONFIG_BT_PHY_UPDATE=y

CONFIG_BT_DATA_LEN_UPDATE=y

CONFIG_BT_CTLR_DATA_LENGTH=y

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_CTLR_PHY=y
On the BL654 side, the startup flags are set to enable 2M PHY and DLE.
Haven't found a lot of info (other than it should be enabled in the BT stack) or a working sample.  Any help/insight is appreciated.
Henry


Data Length Extension #ble #nrf52 #nrf52832 #nrf52840

henry.wagner@...
 

I am trying to enable data length extensions in a connection but am limited to the std 20 payload bytes.
I have a Nordic PCA10040 (nRF52832) running Zephyr v1.14rc1 as a central connected to a Laird BL654 module.  Both devices have what I believe to be DLE enabled.
On the Zephyr side I have enabled:
CONFIG_BT_PHY_UPDATE=y
CONFIG_BT_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_PHY=y
On the BL654 side, the startup flags are set to enable 2M PHY and DLE.
Haven't found a lot of info (other than it should be enabled in the BT stack) or a working sample.  Any help/insight is appreciated.
Henry


Re: How can I configure optimization_level for my project?

Andrei Gansari
 

Hello Kai,

 

I’ve previously used -DCONFIG_NO_OPTIMIZATIONS=y when compiling to use O0. (default zephyr_sdk, should work for gcc-arm-none-eabi)

Have a look at zephyr\cmake\compiler\gcc\target_optimizations.cmake and zephyr\CMakeLists.txt for options.

 

Andrei Gansari

 

From: devel@... <devel@...> On Behalf Of Kai Ren via Lists.Zephyrproject.Org
Sent: Thursday, March 7, 2019 7:23 AM
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] How can I configure optimization_level for my project?

 

Hello,

I'm using gcc-arm-none-eabi as the compiler, as I know, this compiler can be configured for optimization_level, like no-optimization, optimizing size or optimizing speed. 
I'm curious that how can I set it up?

Thanks. 

Kai


How can I configure optimization_level for my project?

Kai Ren
 

Hello,

I'm using gcc-arm-none-eabi as the compiler, as I know, this compiler can be configured for optimization_level, like no-optimization, optimizing size or optimizing speed. 
I'm curious that how can I set it up?

Thanks. 

Kai


BUGS (Zephyr v1.14.0-rc1) Mar 5 2019

Kumar Gala
 

193:bug

95:priority: low
93:priority: medium
4:priority: high

24:area: Networking
22:Coverity
13:area: Bluetooth
11:area: MISRA-C
11:area: Logging
10:platform: nRF
10:area: Drivers
9:platform: NXP
9:area: Tests
8:area: Xtensa
7:platform: ESP32
6:area: Samples
6:area: Memory Protection
6:area: I2C
6:area: File System
6:area: Counter
6:area: ARM
6:area: ARC
5:area: Watchdog
5:area: Sockets
5:area: Kernel
4:area: USB
4:area: Documentation
3:platform: STM32
3:area: UART
3:area: Other
3:area: NIOS2
3:area: Device Tree
3:area: Boards
2:in progress
2:good first issue
2:area: west
2:area: mcumgr
2:area: Toolchains
2:area: Testing
2:area: Shell
2:area: SPI
2:area: Power Management
2:area: Portability
2:area: PWM
2:area: GPIO
2:area: Ethernet
2:area: Display
2:area: Crypto / RNG
2:area: Conformance
2:area: CAN
1:to do
1:platform: ATMEL
1:area: Testing Suite
1:area: Security
1:area: POSIX
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: Networking Clients
1:area: LWM2M
1:area: Kconfig
1:area: IPC
1:area: Flash
1:area: Console
1:area: Configuration System
1:area: C Library
1:area: Build System
1:Trivial
1:LTS
1:EXT


RFC: Changing the `west build` command-line interface

Carles Cufi
 

Hi there,

As you know, west now allows users to build Zephyr applications with it, and many among us have started making use of this new functionality.

The signature for `west build` currently reads (and has done so from its introduction):

usage: west build [-h] [-b BOARD] [-s SOURCE_DIR] [-d BUILD_DIR] [-t TARGET]
[-c] [-f]
[cmake_opt [cmake_opt ...]]

Which means that, in order to specify the source directory (i.e. the sample that you want to build) you either invoke `west build` directly from it or you use the `-s` optional argument like so:

west build -b reel_board -s samples/hello_world

Since we anticipate `west build` to be widely used in the future, I am proposing a change whereby the source directory would be specified as the first optional argument:

west build -b reel_board samples/hello_world

to save some typing and also to be consistent with CMake, which is invoked automatically by west when required.

The new signature would look like:

usage: west build [-h] [-b BOARD] [-d BUILD_DIR]
[-t TARGET] [-c] [-f] [source_dir]
-- [cmake_opt [cmake_opt ...]]

This has a few implications worth discussing:

1. The change is not entirely backwards-compatible but we have kept the `-s` option (as a hidden one) in order to break as few existing scripts as possible
2. `west build` allows you to pass on additional arguments to CMake. Before this change, those were all and any positional arguments present in the invocation line. Now however, the first positional argument is always treated as the source directory, unless a `--` separator is present, in which case the source directory is assumed as implicit (CWD) and all arguments after `--` are treated as CMake options to be passed on to it.

Additional information can be found in the PR and its review comments:
https://github.com/zephyrproject-rtos/zephyr/pull/13635

Please add your feedback in the PR and let us know what you think of the proposed change.

Thanks,

Carles


Re: BLE Central max concurrent connections #uart #ble #hci #nrf52480

Carles Cufi
 

Hi Josef,

 

There is no maximum, neither as a central nor as a peripheral, nor combined.

Whatever you can fit in RAM and in multiplexed time (depending on connection intervals, use of slave latency, etc).

 

Carles

 

From: devel@... <devel@...> On Behalf Of josef via Lists.Zephyrproject.Org
Sent: 05 March 2019 10:05
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] BLE Central max concurrent connections #ble #hci #nrf52480 #uart

 

Hi,

I am evaluating the use of nRF52 (HCI with BlueZ/Linux) as BLE central device. Does anyone know the maximum number of concurrent connections which Zephyr supports?

Many thanks,
Jos


BLE Central max concurrent connections #uart #ble #hci #nrf52480

josef@...
 

Hi,

I am evaluating the use of nRF52 (HCI with BlueZ/Linux) as BLE central device. Does anyone know the maximum number of concurrent connections which Zephyr supports?

Many thanks,
Jos


Re: LE pair disconnected

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

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: LE pair disconnected

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

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: Seeing and running what CI does (was: CODEOWNERS check in CI)

Marc Herbert
 

On 3 Mar 2019, at 09:09, Nashif, Anas <anas.nashif@intel.com> wrote:

2. As the opposite experience, I also got for another work in progress / hack / draft PR:
Documentation build with 'make htmldocs' failed.
... and that's it; no logs or error message whatsoever, just this line. I have some guesses of what fails in CI while everything works for me (it is a documentation _hack_) but zero information on what exactly or how.
2. & 3. https://github.com/zephyrproject-rtos/zephyr/pull/13805

Still unclear.

A python exception happens in this case, you can always reproduce it locally by running 'make htmldocs'.

As I wrote above "make htmldocs" works for me, this PR is actually
an htmldocs demo.


I am not sure how useful would it be putting the python exception...


It would point at the difference(s) between my environment and
CI = the vast majority of CI failures when testing locally and
thoroughly first.

Again I do have a couple of educated guesses about these differences
(help NOT desired here yet) but they're just that: guesses. No proof.

... in the comments.

Not in the comments but behind some kind of "Details" button with all
the rest of the logs and commands that produced them; exactly like
Shippable (and only Shippable now) does.

Having some smart "error analyzer" summarizing in the github comments
how it understood the unexpected failure would be cool. However it's not
mutually exclusive with sharing complete logs and commands as most
successful CIs do.


Re: LE pair disconnected

Carles Cufi
 

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 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

Chettimada, Vinayak Kariappa
 

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: Seeing and running what CI does (was: CODEOWNERS check in CI)

Nashif, Anas
 

2. As the opposite experience, I also got for another work in progress / hack / draft PR:
>> Documentation build with 'make htmldocs' failed.
>> ... and that's it; no logs or error message whatsoever, just this line. I have some guesses of what fails in CI while everything works for me (it is a documentation _hack_) but zero information on what exactly or how.
>>

> Still unclear.

A python exception happens in this case, you can always reproduce it locally by running 'make htmldocs'. This used to generate no reports at all previously, so progress. I am not sure how useful would it be putting the python exception in the comments.

Anas

On 01/03/2019, 20:03, "Herbert, Marc" <marc.herbert@intel.com> wrote:

Quick update.



> 1. [*] "yay!"... except it's not clear why tests run by Shippable are not deterministic: https://github.com/zephyrproject-rtos/zephyr/pull/13803 randconfig maybe? I digress.

Non-determinism found and explained: https://github.com/zephyrproject-rtos/zephyr/pull/13973

Thanks to the reviewers for the very quick reviews.



> 2. As the opposite experience, I also got for another work in progress / hack / draft PR:
> Documentation build with 'make htmldocs' failed.
> ... and that's it; no logs or error message whatsoever, just this line. I have some guesses of what fails in CI while everything works for me (it is a documentation _hack_) but zero information on what exactly or how.
>

Still unclear.


> 3. In the same draft PR as 2. I "forgot" a license header in a temporary file. While it does not provide the command and log, the zephyrbot told me in very nice terms what was wrong. What's still confusing however is why the zephyr-ci-tools/scripts/check_compliance.py [-m Licence] script which I did run before pushing keeps telling me everything is fine and didn't save me the round trip time (and embarrassment). A typo would also cost (another) round-trip. This script really looks like the check zephyrbot runs but... it's apparently not or not quite?
>

Mystery solved: https://github.com/zephyrproject-rtos/ci-tools/pull/25


Another mystery being fixed by Ulf: CODEOWNERS failing locally but not in CI
https://github.com/zephyrproject-rtos/ci-tools/pull/23
https://github.com/zephyrproject-rtos/zephyr/pull/13978



>
> Any layer of indirection in CI creates distance between developers and CI and makes developers care less about failures that don't affect them directly. Developers are not "consumers" and the vast majority seems to prefer having too much information than too little and solve problems by themselves but if the only option they have is not to care about some failures then they don't.
>
> There may be reasons for not all CI details to be available and/or easy to reproduce but they don't apply to stuff like building docs or license checks or other simple sanitycheck.
>
>
> 1. https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/35577
> 2. & 3. https://github.com/zephyrproject-rtos/zephyr/pull/13805
>
>
>


Re: BUGS (Zephyr v1.14.0-rc1) Feb 26 2019

Marti Bolivar <marti@...>
 

Hi Kumar,
On Tue, Feb 26, 2019 at 7:39 AM Kumar Gala <kumar.gala@linaro.org> wrote:

256:bug

121:priority: medium
103:priority: low
8:priority: high
This list is useful -- would you mind also including links to the
relevant GitHub filters in these emails, so devs can drill down on
what they need to fix individually?

I think those are in here:
https://github.com/zephyrproject-rtos/zephyr/wiki/Filters

I'm not 100% sure, though, since wiki pages tend to go stale.

Thanks,
Marti

22:Coverity
21:platform: NXP
18:area: Networking
17:area: Bluetooth
14:platform: nRF
14:area: Logging
13:area: MISRA-C
12:area: Drivers
11:area: Tests
11:area: Kernel
10:area: ARM
8:platform: ESP32
8:area: Xtensa
8:area: Memory Protection
7:area: Watchdog
7:area: Documentation
6:area: Shell
6:area: Samples
6:area: ARC
5:area: USB
5:area: Sockets
5:area: I2C
4:area: Toolchains
4:area: Testing
4:area: Power Management
4:area: File System
3:area: west
3:area: UART
3:area: Timer
3:area: PWM
3:area: POSIX
3:area: NIOS2
3:area: Device Tree
3:area: Counter
3:API
2:platform: STM32
2:good first issue
2:area: Security
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Display
2:area: Conformance
2:area: Boards
1:to do
1:platform: ATMEL
1:area: mcumgr
1:area: Testing Suite
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: Memory Management
1:area: LWM2M
1:area: Kconfig
1:area: IPC
1:area: Flash
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:area: C Library
1:area: Build System
1:LTS
1:EXT




Re: debug with mcuboot

Marti Bolivar <marti@...>
 

On Fri, Mar 1, 2019 at 9:12 AM David Brown <david.brown@linaro.org> wrote:

On Wed, Aug 22, 2018 at 01:46:18AM -0700, robert.konc@controlmatik.eu wrote:

How could I create image that will be signed that mcuboot will recognise it as
valid image.
I wuild like to sign image with imgtool.py in ninja script after build (target
all) was succesfull.
This seems to have gone unanswered.
I somehow have trouble believing the date stamp on the original email.
Clogged internet pipes, perhaps.


For my use, I've always had an "outer" makefile that invokved the
cmake and ninja build on the Zephyr target (as well as mcuboot), and
then used imgtool.py and possibly assemble.py to make my resulting
image.

This probably could be added to the Zephyr build, at least the signing
part, but solving the multi-image build is possibly more an area for
something like West to solve.
Multi-image build is a build system issue, not a west issue. Nordic is
working on this, for reference:

https://github.com/zephyrproject-rtos/zephyr/compare/master...hakonfam:mulit_image_mcuboot_support

Also just FYI, west already supports building, signing, and flashing
MCUboot images. For example:

# Build and flash MCUboot itself for reel_board
west build -b reel_board -s mcuboot/boot/zephyr/ -d build-mcuboot
west flash -d build-mcuboot/

# Build and flash hello_world as an MCUboot chain-loadable image
west build -b reel_board -s zephyr/samples/hello_world/ -d build-hello
-- -DCONFIG_BOOTLOADER_MCUBOOT=y
west sign -t imgtool -d build-hello/ -- --key mcuboot/root-rsa-2048.pem
west flash --hex-file zephyr.signed.hex -d build-hello/

The above assumes your runner prefers flashing .hex files, which is
true of nrfjprog and pyocd at least. You can do it with .bin files too
but it's a little more annoying and I'd like to deprecate some of the
command line flags.

The value of "west sign -t imgtool" compared to using imgtool directly
is that it pulls the values for the --align, --header-size, and
--slot-size options out of the build directory by inspecting Kconfig
and device tree output files.


This will become even more of an issue with multiple images beyond
just the bootloader, such as multiple CPUs or a trusted execution
environment (TF-M style).
Hopefully something like the above can continue working in these
contexts, suitably extended if necessary.

Thanks,
Marti


David



Re: CMake comments to HTML? (PR #9947 CMake build architecture documentation)

Marc Herbert
 

There's an actual (and draft) PR now in case anyone else is interested in following this: https://github.com/zephyrproject-rtos/zephyr/pull/13805

 

Still just a demo.

 

Off the list now.

 

From: <devel@...> on behalf of Marc Herbert <marc.herbert@...>
Date: Monday, 11 February 2019 at 20:46
To: "Nashif, Anas" <anas.nashif@...>, "devel@..." <devel@...>
Cc: "Kinder, David B" <david.b.kinder@...>
Subject: Re: [Zephyr-devel] CMake comments to HTML? (PR #9947 CMake build architecture documentation)

 

Thanks Anas!

 

Correct no PR yet, sorry for the confusion. This is still at the early prototype stage however there's already a demo git commit - the one that produced the screenshot - linked from https://github.com/zephyrproject-rtos/zephyr/issues/9947 and it should work "out of the box" on Linux. Ideas, suggestions and any other kind of feedback from anyone somewhat familiar with CMake or Sphinx and brave enough to review a few TODOs, FIXMEs and other question marks would be great already, thanks in advance. Github supports commenting on volatile commits for implementation details but higher level discussions are probably best "centralized" in an issue: 9947 or some (new?) other?

 

Cheers,

 

Marc

 

 

From: "Nashif, Anas" <anas.nashif@...>
Date: Monday, 11 February 2019 at 16:50
To: Marc Herbert <marc.herbert@...>, "devel@..." <devel@...>
Cc: "Kinder, David B" <david.b.kinder@...>
Subject: RE: CMake comments to HTML? (PR #9947 CMake build architecture documentation)

 

I think this looks great.

 

9947 is not a PR, it is an enhancement issue, got me confused for a second. So it is an open enhancement issue with not PR associated with it, if you have something , send a PR please.

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of Marc Herbert
Sent: Monday, February 11, 2019 7:45 PM
To: devel@...
Cc: Kinder, David B <david.b.kinder@...>
Subject: [Zephyr-devel] CMake comments to HTML? (PR #9947 CMake build architecture documentation)

 

I tried the “moderncmakedomain” sphinx extension to prototype extracting CMake comments into html and it seems to work, see screenshot and PR below.

 

 

Dave (cc:) seems to like it.

 

Just a quick hack for now, Linux only. Two questions:

- Is the approach generally acceptable? Notably: is sphinx-moderncmakedomain acceptable as an additional pip3 requirement?

- If yes then is Sebastian's PR #9947 the correct place for this? I asked him privately but he’s either off or busy. If yes then let’s discuss there and not on the mailing-list.

 

 

Cheers,

 

Marc

 





Begin forwarded message:

 

Subject: Re: [zephyrproject-rtos/zephyr] CMake build architecture documentation (#9947)

Date: 11 February 2019 at 16:21:45 GMT-8

 

 

This is what the above commit produces:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

 


Re: Seeing and running what CI does (was: CODEOWNERS check in CI)

Marc Herbert
 

Quick update.



1. [*] "yay!"... except it's not clear why tests run by Shippable are not deterministic: https://github.com/zephyrproject-rtos/zephyr/pull/13803 randconfig maybe? I digress.
Non-determinism found and explained: https://github.com/zephyrproject-rtos/zephyr/pull/13973

Thanks to the reviewers for the very quick reviews.



2. As the opposite experience, I also got for another work in progress / hack / draft PR:
Documentation build with 'make htmldocs' failed.
... and that's it; no logs or error message whatsoever, just this line. I have some guesses of what fails in CI while everything works for me (it is a documentation _hack_) but zero information on what exactly or how.
Still unclear.


3. In the same draft PR as 2. I "forgot" a license header in a temporary file. While it does not provide the command and log, the zephyrbot told me in very nice terms what was wrong. What's still confusing however is why the zephyr-ci-tools/scripts/check_compliance.py [-m Licence] script which I did run before pushing keeps telling me everything is fine and didn't save me the round trip time (and embarrassment). A typo would also cost (another) round-trip. This script really looks like the check zephyrbot runs but... it's apparently not or not quite?
Mystery solved: https://github.com/zephyrproject-rtos/ci-tools/pull/25


Another mystery being fixed by Ulf: CODEOWNERS failing locally but not in CI
https://github.com/zephyrproject-rtos/ci-tools/pull/23
https://github.com/zephyrproject-rtos/zephyr/pull/13978




Any layer of indirection in CI creates distance between developers and CI and makes developers care less about failures that don't affect them directly. Developers are not "consumers" and the vast majority seems to prefer having too much information than too little and solve problems by themselves but if the only option they have is not to care about some failures then they don't.

There may be reasons for not all CI details to be available and/or easy to reproduce but they don't apply to stuff like building docs or license checks or other simple sanitycheck.


1. https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/35577
2. & 3. https://github.com/zephyrproject-rtos/zephyr/pull/13805



Re: debug with mcuboot

David Brown
 

On Wed, Aug 22, 2018 at 01:46:18AM -0700, robert.konc@controlmatik.eu wrote:

How could I create image that will be signed that mcuboot will recognise it as
valid image.
I wuild like to sign image with imgtool.py in ninja script after build (target
all) was succesfull.
This seems to have gone unanswered.

For my use, I've always had an "outer" makefile that invokved the
cmake and ninja build on the Zephyr target (as well as mcuboot), and
then used imgtool.py and possibly assemble.py to make my resulting
image.

This probably could be added to the Zephyr build, at least the signing
part, but solving the multi-image build is possibly more an area for
something like West to solve.

This will become even more of an issue with multiple images beyond
just the bootloader, such as multiple CPUs or a trusted execution
environment (TF-M style).

David

2001 - 2020 of 7756