Date   

Re: Any plan for OTA support?

David Brown
 

No decision has been made, but I'm certainly going to be investigating
Mynewt's serial protocol.

The intent is that the bootloader won't be upgradeable. Ideally, it should
be protected so that even debug pins won't be able to update it. Without it
being protected, there really isn't any security to the rest of the boot
process.

David

On Thu, Jan 19, 2017 at 5:46 AM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
wrote:

Hi David,



If I’m not mistaken the Mynewt bootloader includes support for serial
“DFU” (more like app image management and transfer). Are you planning to
port that as well as part of the mcuboot project? The reason I ask is that
there have been some conversations regarding the future protocol that will
be used to provide DFU over the different transports (serial, USB, BLE,
15.4, etc) and it would be good to know if you have taken any sort of
decision in this regard.

If I’m not mistaken the serial code in the Mynewt bootloader uses parts of
what’s called the Newt management protocol currently, so it’d be
interesting to know if you plan to incorporate that into the project.

Also could you confirm that the mcuboot image will only be able to be
overwritten using debug pins? (i.e. no DFU, OTA or otherwise of the
bootloader itself).



Thanks,



Carles



*From:* David Brown [mailto:david.brown(a)linaro.org]
*Sent:* Wednesday, January 18, 2017 19:32
*To:* Cufi, Carles <Carles.Cufi(a)nordicsemi.no>; nvl1109(a)gmail.com;
devel(a)lists.zephyrproject.org
*Subject:* Re: [devel] Re: Any plan for OTA support?



We are working on the Mynewt bootloader (which is going to be its own
project, called mcuboot). I have the OTA update as something that needs to
be done, but I'm not aware of currently plans to implement anything.



David



On Sat, Jan 14, 2017 at 12:10 PM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
wrote:

Hi Linh,



I was actually asking myself the same question recently. I think Linaro
has started working on making the Mynewt bootloader usable with Zephyr, but
that is only the first step I assume.



Also, to add a bit to your question, are there plans for IP-based OTA
only, or is “regular” BLE OTA support also planned? By regular I mean
similar to the proprietary solutions that vendors offer today, where one
can update the firmware using only GATT, without requiring IPSP or LE
Connection-Oriented Channels.



Thanks,



Carles



*From:* nvl1109(a)gmail.com [mailto:nvl1109(a)gmail.com]
*Sent:* Saturday, January 14, 2017 15:43
*To:* devel(a)lists.zephyrproject.org <devel(a)lists.zephyrproject.org>
*Subject:* [devel] Any plan for OTA support?



Hi all,



Do you have any plans to support OTA framework on Zephyr?



Thank & Regards,
Linh Nguyen




Re: uint32_t typedef differences causes issues

Oliver Hahm <oliver.hahm@...>
 

Hi!

Generally I'm a big fan of doing things correctly & properly, but this
stuff just uglifies the format strings too much IMO :)
Unless you don't want to exclude the possibility to run Zephyr on 8-bit and
16-bit architectures.

Cheers,
Oleg


Re: uint32_t typedef differences causes issues

Johan Hedberg
 

Hi Anas,

On Thu, Jan 19, 2017, Anas Nashif wrote:
On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.
I'd just like to add to this that while working with Linux and BlueZ
we've used %u extensively for uint8_t, uint16_t and uint32_t without any
issues (I'd think those projects have been run on a larger set of
architectures and C libraries than what Zephyr supports). The only case
where we've had resort to PRI* is uint64_t, and if you check the actual
definition of these in your /usr/include/inttypes.h you'll see that it's
the only one that evaluates to something else than just "u".

Generally I'm a big fan of doing things correctly & properly, but this
stuff just uglifies the format strings too much IMO :)

Johan


Re: git describe of v1.5.0-3830-gecd209f

Anas Nashif
 

On Tue, Jan 17, 2017 at 11:58 AM, Paul Sokolovsky <
paul.sokolovsky(a)linaro.org> wrote:

Hello Anas,

On Tue, 17 Jan 2017 16:34:15 +0000
"Nashif, Anas" <anas.nashif(a)intel.com> wrote:

<snip>


I see, apparently, we used a local release branch based on
v1.6.0-branch, that's why I saw "v1.6.0-27-gb6fb798" previously.

I know git describe won’t work with this model, we need to find an
alternative way. Probably when we change the version to 1.x.99, we
could tag master so we can get something like: v1.6.99-1772-g003a46a
Yes, that would be nice. I'm just afraid that makes the release process
more and more complicated, but I guess as Zephyr grows, it would become
such anyway.

It is just a tag we will put on master the minute we create the release
branch basically.

Anas



Anas
Thanks for the reply!

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: SSH on Galileo

Anas Nashif
 

On Wed, Jan 18, 2017 at 5:34 PM, Fábio Iaione <fabio.iaione(a)gmail.com>
wrote:

Dear Sirs,
Does Zephyr have SSH support?
No. Zephyr does not support SSH.

Anas




Thank you.


Re: [RFC] STM32 pinmux - simplify pinmux logic

Erwan Gouriou
 

Hi Christer,


The above pin definition would look like this:

#define STM32F4_PINMUX_FUNC_PA9_USART1_TX (STM32F4X_PIN_FUNC_AF |
STM32F4X_PIN_PULL_UP | STM32_PINMUX_FUNC_ALT_7)

It's a bit more verbose, but it's obvious what it does, especially if
you look at the corresponding definitions in the data sheet since this
is how the hardware registers look.
I agree this might be clearer for users. Since pinmux is something users
might
have to play with, the easier to read, the better.


If we do this we can rip out stm32_get_pin_config completely and also
simplify the __func_to_foo functions in soc_gpio.c

It might also be a good idea to unify these defines between STM32
families. If I recall correctly many STM32F1xx, STM32F2xx and STMF4xx
packages are mostly pin compatible. The same PCB could have a STM32Fxx
or STM32F4xx MCU mounted on it (with a zero ohm resistor or capacitor to
account for any differences between them) and it would be nice if they
could use the same board file.
I can only agree here. It will help a lot on maintenance and porting of new
families.
There could be unexpected differences between quite similar boards, but
these could
be handled easily.


Some functions might not be supported on all families, for example, I
don't think the STM32F1xx can have a pull-up/pull-down at the same tie
as a pin is an output or alternate function, but that shouldn't be problem.

Btw, I think that you could submit your RFC as a patch in Gerrit, so we
can
better appreciate the differences and comment easily.
I'll see if I can clean up my ideas and push a few patches for review in
gerrit.

Thanks a lot for your contribution!

/Christer


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 19 January 2017 at 15:39, Anas Nashif <nashif(a)gmail.com> wrote:


On Thu, Jan 19, 2017 at 10:03 AM, Johan Hedberg <johan.hedberg(a)intel.com>
wrote:

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.
We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.
We will likely find either immediately, or with future additions to
/ext that each blob of third party code does something different:
- Some will use %u for uint32_t
- Some will use %lu for uint32_t
- Some might even actually use the inttypes.h defs.
- Some will have hacked the problem already with stuff like "%lu",
(long int) some_uint32_variable
...

Clearly we can't appease the first two simultaneously by futzing with
newlib, gcc etc

If we want to get diagnostic clean from the compiler we may end up
needing to explicitly disable -Wformat on /ext

Cheers
/Marcus


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-1597] no good way to include library code outside of $(PROJECT_BASE)
https://jira.zephyrproject.org/browse/ZEP-1597

[ZEP-1594] 0.9.0 IAMCU compiler doesn't support __attribute__((interrupt)) on x86
https://jira.zephyrproject.org/browse/ZEP-1594

[ZEP-1595] arch-specific inline functions cannot manipulate _kernel
https://jira.zephyrproject.org/browse/ZEP-1595

[ZEP-1591] wiki: add Networking section and point https://wiki.zephyrproject.org/view/Network_Interfaces
https://jira.zephyrproject.org/browse/ZEP-1591


UPDATED JIRA items within last 24 hours: 6
[ZEP-1474] BLE Connection Parameter Request/Response Processing
https://jira.zephyrproject.org/browse/ZEP-1474

[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

[ZEP-1251] Abstract driver re-entrancy code
https://jira.zephyrproject.org/browse/ZEP-1251

[ZEP-513] extern declarations of small microkernel objects in designated sections require __attribute__((section)) in gp-enabled systems
https://jira.zephyrproject.org/browse/ZEP-513

[ZEP-723] Sanity Crashes with "FileNotFound" exception when running samples/static_lib/test
https://jira.zephyrproject.org/browse/ZEP-723

[ZEP-1460] Sanity check reports some qemu step failures as 'build_error'
https://jira.zephyrproject.org/browse/ZEP-1460


CLOSED JIRA items within last 24 hours: 3
[ZEP-1428] (Won't Do) support ARC V1
https://jira.zephyrproject.org/browse/ZEP-1428

[ZEP-1564] (Done) 6lo uncompress_IPHC_header overwrites IPHC fields
https://jira.zephyrproject.org/browse/ZEP-1564

[ZEP-1584] (Cannot Reproduce) Fail to connect IPSP node on Arduino101
https://jira.zephyrproject.org/browse/ZEP-1584


RESOLVED JIRA items within last 24 hours: 0


Re: uint32_t typedef differences causes issues

Anas Nashif
 

On Thu, Jan 19, 2017 at 10:03 AM, Johan Hedberg <johan.hedberg(a)intel.com>
wrote:

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.


Anas





Johan


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 9:15 AM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:

#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus
Not having much luck there, but its possible I’m missing something obvious because of lack of sleep:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:24:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:388:33: error: expected ')' before 'PRIu32'
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
^

That would be my fault, my example above is missing:

#include <inttypes.h>

Cheers
/Marcus
Ah, that fixes things.

Now to the question about how uint32_t should be defined ;)

- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus
Not having much luck there, but its possible I’m missing something obvious because of lack of sleep:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:24:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:388:33: error: expected ')' before 'PRIu32'
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
^

That would be my fault, my example above is missing:

#include <inttypes.h>

Cheers
/Marcus


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10172 : board: add nucleo_401re board documentation
- https://gerrit.zephyrproject.org/r/10235 : net: nbuf: Fix debug prints for memory allocations
- https://gerrit.zephyrproject.org/r/10236 : net: context: Add status to connect callback
- https://gerrit.zephyrproject.org/r/10234 : net: zperf: Add bluetooth support
- https://gerrit.zephyrproject.org/r/10225 : net: samples: Add ENC28J60 pin numbers to documentation
- https://gerrit.zephyrproject.org/r/10226 : net: samples: Print assigned address from DHCPv4 server
- https://gerrit.zephyrproject.org/r/10233 : net: zoap-client: Add bluetooth support
- https://gerrit.zephyrproject.org/r/10189 : Xtensa port: Added kernel arch dependent structs and functions.
- https://gerrit.zephyrproject.org/r/10230 : Makefile (arc/soc/quark_se): New compiler options
- https://gerrit.zephyrproject.org/r/10229 : Makefile (arc/soc/em*): New compiler options
- https://gerrit.zephyrproject.org/r/10228 : arc: add -fno-delete-null-pointer-checks
- https://gerrit.zephyrproject.org/r/10227 : Makefile.toolchain.zephyr: Modifications for SDK 0.9
- https://gerrit.zephyrproject.org/r/10231 : samples: sensor: fxos8700: use floating point for printing sensor values
- https://gerrit.zephyrproject.org/r/10232 : sensor: fxos8700: fix missing dependency in Kconfig
- https://gerrit.zephyrproject.org/r/10224 : arm: cortex-m: Implement CONFIG_TEXT_SECTION_OFFSET
- https://gerrit.zephyrproject.org/r/10223 : build: have sysgen create SPDX license identifiers
- https://gerrit.zephyrproject.org/r/10190 : samples/net/http: Move http write functionality to its own files
- https://gerrit.zephyrproject.org/r/10219 : samples/net/http: Add the It works! web page
- https://gerrit.zephyrproject.org/r/10220 : samples/net/http: Modify data pool size
- https://gerrit.zephyrproject.org/r/10218 : samples/net/http: Increase the max number of network contexts
- https://gerrit.zephyrproject.org/r/10178 : samples/net/http: Introduce routines to handle multiple contexts
- https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition
- https://gerrit.zephyrproject.org/r/10212 : net/ip: Do not modify the address for failure cases
- https://gerrit.zephyrproject.org/r/10215 : scripts: quick script to determine candidates to own Coverity issues
- https://gerrit.zephyrproject.org/r/10213 : doc: Fix :lines: references in docs
- https://gerrit.zephyrproject.org/r/10188 : Xtensa port: Added Xtensa header generic files.
- https://gerrit.zephyrproject.org/r/10176 : Add support for STM32Cube HAL_PCD USB driver
- https://gerrit.zephyrproject.org/r/10175 : cdc_acm - Use endpoint 3 instead of endpoint 4 for IN BULK endpoint
- https://gerrit.zephyrproject.org/r/10192 : x86: implement direct interrupts
- https://gerrit.zephyrproject.org/r/10194 : sanity: switch sdk depending on branch
- https://gerrit.zephyrproject.org/r/10187 : test
- https://gerrit.zephyrproject.org/r/10186 : Zephyr 1.6-rc2
- https://gerrit.zephyrproject.org/r/10185 : Zephyr 1.6.0-rc1
- https://gerrit.zephyrproject.org/r/10181 : kernel.h: add prototype for private idle exit function
- https://gerrit.zephyrproject.org/r/10184 : gen_idt: show vector assignments in debug output
- https://gerrit.zephyrproject.org/r/10182 : kernel_event_logger: add additional function prototypes
- https://gerrit.zephyrproject.org/r/10177 : samples: pwm: move pwm samples into one directory

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/9974 : Xtensa port: Added support for XCC, the Cadence Systems Inc compiler
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9920 : arm: cortex-m: Implement CONFIG_TEXT_SECTION_OFFSET
- https://gerrit.zephyrproject.org/r/10093 : samples/net/http: Add the server sample application
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level
- https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux
- https://gerrit.zephyrproject.org/r/9986 : k64: Change the default spi driver to the mcux shim
- https://gerrit.zephyrproject.org/r/9985 : spi: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9984 : spi: Add shared default configs
- https://gerrit.zephyrproject.org/r/10132 : samples/zoap_server: Also listen on the unicast address
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running
- https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure
- https://gerrit.zephyrproject.org/r/7492 : Bluetooth: A2DP: Added Preset Structure
- https://gerrit.zephyrproject.org/r/6720 : Bluetooth: A2DP: Stream End Point Registration
- https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/9989 : spi: k64: Remove the k64 spi driver
- https://gerrit.zephyrproject.org/r/8922 : scripts: Add device tree parser script
- https://gerrit.zephyrproject.org/r/7664 : second: test
- https://gerrit.zephyrproject.org/r/9678 : http: add server sample
- https://gerrit.zephyrproject.org/r/4457 : DONT: MERGE - cause checkpatch warnings
- https://gerrit.zephyrproject.org/r/10136 : drivers: QMSI RTC: simplify driver reentrancy code using IS_ENABLED
- https://gerrit.zephyrproject.org/r/10135 : drivers: QMSI SOC flash: simplify driver reentrancy code using IS_ENABLED
- https://gerrit.zephyrproject.org/r/10134 : drivers: QMSI PWM: simplify driver reentrancy code using IS_ENABLED macro
- https://gerrit.zephyrproject.org/r/4541 : DONT MERGE - break checkpatch
- https://gerrit.zephyrproject.org/r/5475 : DONT MERGE - break sanity AND checkpatch
- https://gerrit.zephyrproject.org/r/9981 : samples: spi_flash: remove an unnecessary config symbol
- https://gerrit.zephyrproject.org/r/10117 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/9951 : net: tcp: don't assume TCP_FIN buffers are NET_DROP
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/10142 : net: tcp: fix buffer leak in tcp_synack_received
- https://gerrit.zephyrproject.org/r/10144 : net: tcp: add timeout wait in net_context_connect
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: Convert DO_REBOOT to use CMSIS
- https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: Convert systick to CMSIS
- https://gerrit.zephyrproject.org/r/9971 : timer: nrf_rtc: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9972 : clock_control: nrf5_power: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9970 : arm: cmsis: Introduce CMSIS layer
- https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Remove unused code from scb/scs layers
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10222 : net: in newlib, ESHUTDOWN is considered an extension
- https://gerrit.zephyrproject.org/r/10221 : net: buf: Use TCP sent_list variable only if needed
- https://gerrit.zephyrproject.org/r/10217 : samples: net: Enable buffer warning and errors in echo apps on qemu
- https://gerrit.zephyrproject.org/r/10216 : samples: net: Fix a format issues in echo_client
- https://gerrit.zephyrproject.org/r/10195 : samples/zoap_server: Add support for the '/separate' resource
- https://gerrit.zephyrproject.org/r/10196 : samples/zoap_server: Add support for blockwise GET tests
- https://gerrit.zephyrproject.org/r/10197 : iot/zoap: Add response code for Continue status
- https://gerrit.zephyrproject.org/r/10198 : samples/zoap_server: Add resouce for TD_COAP_BLOCK_03
- https://gerrit.zephyrproject.org/r/10199 : iot/zoap: Ignore non-request packets in zoap_handle_request
- https://gerrit.zephyrproject.org/r/10200 : iot/zoap: Fix wrong byte-order when retrieving integer options
- https://gerrit.zephyrproject.org/r/10201 : iot/zoap: Clarify the return value of zoap_register_observer()
- https://gerrit.zephyrproject.org/r/10202 : iot/zoap: Add a helper to find an observer by address
- https://gerrit.zephyrproject.org/r/10203 : samples/zoap_server: Fix responding messages with the wrong type
- https://gerrit.zephyrproject.org/r/10204 : samples/zoap_server: Add support for messages with token
- https://gerrit.zephyrproject.org/r/10205 : samples/zoap_server: Add Content-Format options to GET responses
- https://gerrit.zephyrproject.org/r/10206 : samples/zoap_server: Include a path for the "created" resource
- https://gerrit.zephyrproject.org/r/10207 : samples/zoap-server: Add support for the "location-query" resource
- https://gerrit.zephyrproject.org/r/10208 : samples/zoap_server: Do not error if there's no payload or queries
- https://gerrit.zephyrproject.org/r/10214 : Bluetooth: SPI: Replace Apache boilerplate with SPDX tag
- https://gerrit.zephyrproject.org/r/10174 : arm: nvic: kill _NvicSwInterruptTrigger
- https://gerrit.zephyrproject.org/r/10210 : license: Replace Apache boilerplate with SPDX tag
- https://gerrit.zephyrproject.org/r/10173 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/10209 : drivers: i2c: remove an unnecessary condition check
- https://gerrit.zephyrproject.org/r/10168 : net: shell: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/9964 : Xtensa port: Added board config files for Xtensa simulator paltform
- https://gerrit.zephyrproject.org/r/10154 : net: dhcpv4: Remove dead code
- https://gerrit.zephyrproject.org/r/10153 : net: 6lo: Fix dereferencing null pointer
- https://gerrit.zephyrproject.org/r/10151 : net: nbuf: Check possible null pointer access
- https://gerrit.zephyrproject.org/r/10122 : net: tcp: remove unused semaphore tcp_lock
- https://gerrit.zephyrproject.org/r/10152 : net: 6lo: Handle destination address uncompression properly
- https://gerrit.zephyrproject.org/r/10146 : net: Fix possible null pointer dereference in nbuf
- https://gerrit.zephyrproject.org/r/10147 : net: icmpv6: Removing dead code
- https://gerrit.zephyrproject.org/r/10148 : net: tcp: Allocate space for TCP header
- https://gerrit.zephyrproject.org/r/10149 : net: ipv6: Check neighbor pointer in NS reply timeout
- https://gerrit.zephyrproject.org/r/10150 : net: ipv6: Fix IPv6 prefix comparision
- https://gerrit.zephyrproject.org/r/10120 : sanitycheck: improve terse output
- https://gerrit.zephyrproject.org/r/10125 : build: remove obsolete sections from linker scripts
- https://gerrit.zephyrproject.org/r/10138 : arm: set default vector table address in prep_c when XIP
- https://gerrit.zephyrproject.org/r/10139 : arm/nordic_nrf5: enable SOC_FLASH_NRF5 by default if FLASH is enabled
- https://gerrit.zephyrproject.org/r/10169 : Bluetooth: Don't select TinyCrypt RNG for combined builds
- https://gerrit.zephyrproject.org/r/10111 : Bluetooth: L2CAP: Fix always using RX_BUF_COUNT as initial credits


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 8:57 AM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:

On 19 January 2017 at 14:52, Johan Hedberg <johan.hedberg(a)intel.com> wrote:
Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus
Not having much luck there, but its possible I’m missing something obvious because of lack of sleep:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:24:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:388:33: error: expected ')' before 'PRIu32'
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
^

Here’s what BT_ERR looks like:
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
sizeof(_radio));


- k


Re: uint32_t typedef differences causes issues

Johan Hedberg
 

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

Johan


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 8:52 AM, Johan Hedberg <johan.hedberg(a)intel.com> wrote:

Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
away.

Johan
Thought that myself, but with %u you get:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:23:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]
BT_ERR("Required RAM size: %u, supplied: %u.", err,


- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 19 January 2017 at 14:52, Johan Hedberg <johan.hedberg(a)intel.com> wrote:
Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus


Re: uint32_t typedef differences causes issues

Johan Hedberg
 

Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
away.

Johan


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

[Second attempt at responding, my arm email address seems to have
triggered a moderator approval, sorry about the duplication for those
of you that got a direct reply.]

This is because the code is using the wrong format specifier, see
JIRA-1181 https://jira.zephyrproject.org/browse/ZEP-1181

Cheers
/Marcus

On 19 January 2017 at 14:41, Kumar Gala <kumar.gala(a)linaro.org> wrote:
It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains

- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <Marcus.Shawcroft@...>
 

On 19 Jan 2017, at 14:41, Kumar Gala <kumar.gala(a)linaro.org> wrote:

It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned intuint32_t;

Mini libc:

typedef unsigned intuint32_t;

So wondering if we should change mini-libc to match and fix up all the build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains

- k
Hi, This is because the code is using the wrong format specifier, see JIRA-1181

Cheers
/Marcus
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


uint32_t typedef differences causes issues

Kumar Gala
 

It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains

- k

5641 - 5660 of 7929