Date   

Kernel MS Precision

Michael Rosen
 

Zephyr Devs,

 

Weve started moving our project from Zephyr 1.5 to Zephyr 1.7. One big change (aside from the really big ones like unified kernel and all that) is that the APIs for timers and others seems to have changes from taking in values in ticks to taking their arguments in milliseconds. For most applications, this is probably fine but in our case, its really unfortunate. We want to have a tick granularity of 500us (0.5ms) for our system so we can do operations at more precise timings (yes, at the cost of extra timer interrupts), and with the old API, that wasn’t an issue. Youd just change your units to microseconds and do things like:

 

nano_timer_start(&timer, USEC(1500));

 

To get a 1.5ms timer. Now, there seems to be K_MSEC and K_SECONDS to convert from “kernel time measure” as before (replacing just MSEC and SECONDS) but this is just a direct translation and the function itself does the transformation into ticks as the first thing it does. Is there a strong reason why the API was changed to prevent greater than 1ms ticks from being easy to achieve, especially considering users are expected to use K_MSEC and K_SECONDS anyway? I don’t expect any system to have a 1us tick, but just a 0.5ms tick is now impossible (without modifying the kernel code at least).

 

Thanks,

Mike

 

 

 


Re: NXP FRDM-K64F and OpenOCD from 0.9.0 SDK issue

Piotr Król <piotr.krol@...>
 

On 03/21/2017 09:24 PM, Maureen Helm wrote:
Hi Piotr,
Hi Maureen,
thanks for reply.

(...)


The only thing I'm worry about is `error executing cortex_m crc algorithm` any
idea what maybe wrong ?
Not sure.

Is there any way to fix `unable to find CMSIS-DAP device` in SDK OpenOCD ?
We'll need to update the OpenOCD version in the next SDK release. Until then, you can build OpenOCD like you've already done, or use the prebuilt version that ships with Kinetis Design Studio.
Yes and I can flash with that version although I get above errors I'm not sure how important is that. Despite working flashing procedure and correctly running application I can't debug. Breakpoints cause Zephyr crash and initial halt after running debug leave me in kind of idle state.

I will describe this better in next email and probably contact OpenOCD community meanwhile.

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


Re: RFC: Random numbers

Luiz Augusto von Dentz
 

Hi Marcus,

On Wed, Mar 22, 2017 at 2:34 PM, Marcus Shawcroft
<marcus.shawcroft@gmail.com> wrote:
Hi Luiz

On 22 March 2017 at 11:26, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
Hi Marcus,

Lets move the discussion of
https://gerrit.zephyrproject.org/r/#/c/12341 here since it should be
quite important to get it right if we intend Zephyr to be somewhat
secure OS.
My last set of comments in gerrit and this RFC crossed, I'll repost my
comments here in the thread:

> Maybe sys_urand32_get in addition to sys_rand32_get so we mimic
> /dev/urandom and /dev/random. sys_urand32_get might be PRNG based
> and should be considerably faster considering sys_rand32_get can
> block if it doesn't have enough entropy.
This seems reasonable. It would be good to choose names that more
clearly articulate the TRNG / PRNG aspect of their behaviour, its an
important distinction. In my mind the 'u' distinction is not
'obvious' enough. I would also advocate that any new interfaces we
add should drop the uint32_t chunks of entropy and instead adopt a
more flexible interface along the lines of:
From a developer with no much expertise into what does TRNG/PRNG
really means, myself included, Im not sure how using this terms would
improve the situation, in fact I think it would confuse people. Also
after reading a bit more about TRNG there doesn't seem to have a
solution that wouldn't involve a dedicated hardware, perhaps because
of that the Linux /dev/random and /dev/urandom manpage only talks
about CPRNG.

To me it is much more important we define these in terms of behavior,
which should them translate into care or not care about entropy
quality. With that in mind we may decide to add a timeout parameter to
the random number generator and then use that to decide the quality of
the entropy to use, if the user cannot wait then perhaps using
HMAC_PRNG shall be sufficient, otherwise it shall read for the entropy
pool directly.

int some_function_that_gets_entropy(uint8_t *buffer, uint16_t length);
I'd suggest something like this:

int sys_random_get(uint8_t *buffer, uint16_t length, uint32_t timeout);
int sys_random_put(const uint8_t *buffer, uint16_t length, uint32_t timeout);

I was intending to use a k_msgq to implement the entropy pool, but if
we put and get byte a byte I think I might have to reconsider, or
perhaps handle the chunks internally by calling multiple times
k_msgq_put and k_msgq_get but Im not sure I will be able to honor the
timeout properly so perhaps it would be a better idea to define a
minimal entropy size, if the caller needs more than that then it
should call it multiple times.

> > On systems with copious, low cost HW entropy we could simply wire
> > sys_prng_get() to the hw entropy source and bypass the prng
> > completely.
>
> Btw, isn't depending on one source of entropy alone bad/broken? I
> understand it is currently like this because the did not exist any
> way to collect entropy from other sources, but now we are talking
> about introducing one so we might as well switch from the driver
> given the random number to the driver working as a source of
> entropy which is then collected by random subsystem.
Fair point, if there are multiple sources available then best practice
would be to mix all the sources. I think that this therefore implies
the legacy/existing sys_rand32_get() function should be rewired to
pull entropy from a pool and the pool should be fed by all available
sources. However, I am aware that finding other sources of entropy in
a system is a really hard problem since most if not all can be
externally biased. The interface between a pool and the sources of
entropy is likely to be slightly awkward. On the one hand we have the
"random" drivers that can just be called to produce entropy on demand
(although perhaps with limited bandwidth) in this case a pull
interface works, while on the other hand harvesting entropy from other
parts of the system will likely need to be structured as a push
interface.
I guess we can have both pull and push, for the most part it should be
a push interface feeding the entropy pool, but as soon the pool runs
out or we need a new seed we should attempt to pull, obviously the
pull method shall only be used in case the user have provide a
timeout, that way the driver can go ahead and take that time to
generate more entropy and when it is done wake up the thread waiting
it.

We may also add a k_work to request more entropy from the driver in
case we are sort of entropy in the pool, that should prevent errors
when users need a random number immediately that could otherwise be
provided e.g. HMAC_PRNG but that fails since it needs to be reseeded.


> Btw, regarding the implementation sys_urand32_get, if you agree
> with that, that might use sys_rand32_get to seed.
This structure seems reasonable to me.

Cheers
/Marcus


--
Luiz Augusto von Dentz


Re: RFC: Random numbers

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Luiz

On 22 March 2017 at 11:26, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
Hi Marcus,

Lets move the discussion of
https://gerrit.zephyrproject.org/r/#/c/12341 here since it should be
quite important to get it right if we intend Zephyr to be somewhat
secure OS.
My last set of comments in gerrit and this RFC crossed, I'll repost my
comments here in the thread:

> Maybe sys_urand32_get in addition to sys_rand32_get so we mimic
> /dev/urandom and /dev/random. sys_urand32_get might be PRNG based
> and should be considerably faster considering sys_rand32_get can
> block if it doesn't have enough entropy.
This seems reasonable. It would be good to choose names that more
clearly articulate the TRNG / PRNG aspect of their behaviour, its an
important distinction. In my mind the 'u' distinction is not
'obvious' enough. I would also advocate that any new interfaces we
add should drop the uint32_t chunks of entropy and instead adopt a
more flexible interface along the lines of:

int some_function_that_gets_entropy(uint8_t *buffer, uint16_t length);

> > On systems with copious, low cost HW entropy we could simply wire
> > sys_prng_get() to the hw entropy source and bypass the prng
> > completely.
>
> Btw, isn't depending on one source of entropy alone bad/broken? I
> understand it is currently like this because the did not exist any
> way to collect entropy from other sources, but now we are talking
> about introducing one so we might as well switch from the driver
> given the random number to the driver working as a source of
> entropy which is then collected by random subsystem.
Fair point, if there are multiple sources available then best practice
would be to mix all the sources. I think that this therefore implies
the legacy/existing sys_rand32_get() function should be rewired to
pull entropy from a pool and the pool should be fed by all available
sources. However, I am aware that finding other sources of entropy in
a system is a really hard problem since most if not all can be
externally biased. The interface between a pool and the sources of
entropy is likely to be slightly awkward. On the one hand we have the
"random" drivers that can just be called to produce entropy on demand
(although perhaps with limited bandwidth) in this case a pull
interface works, while on the other hand harvesting entropy from other
parts of the system will likely need to be structured as a push
interface.

> Btw, regarding the implementation sys_urand32_get, if you agree
> with that, that might use sys_rand32_get to seed.
This structure seems reasonable to me.

Cheers
/Marcus


RFC: Random numbers

Luiz Augusto von Dentz
 

Hi Marcus,

Lets move the discussion of
https://gerrit.zephyrproject.org/r/#/c/12341 here since it should be
quite important to get it right if we intend Zephyr to be somewhat
secure OS.

Hi,
> >
> > This PRNG implementation has more general utility in zephyr than
> as
> > a pseudo device driver, but I think adding it in this way as a
> > driver is taking us in the wrong direction.
> >
> > Even on systems which have access to HW entropy generators it can
> > be very expensive to harvest that entropy, which means entropy is
> > valuable. There are many places around zephyr where we need some
> > random number, but that number does need to be a high quality
> > random number. For example numerous parts of the network stack
> > need random numbers for transaction ids and timer offsets etc.
> On
> > such systems it would be useful to to distinguish between users
> > that require pure entropy and those that don't, thus reducing
> > pressure to collect quality entropy.
> >
> > I think this PRNG should be recast as subsystem/library rather
> than
> > as a driver for none existant hardware. The reseed interface
> > should be retained, its primary interface should be a new
> interface
> > to sit along side the existing sys_rand32_get(), perhaps
> > sys_prng_get(). We would then move users that don;t require high
> > quality entropy to the sys_prng_get() interface (Im thinking
> > maninly of all the network stack calls). This leaves us with two
> > interfaces, one to get (possibly expensive) high quality entropy,
> > and a second to give PRNG for all uses where that is 'good
> enough'
> >
>
> Maybe sys_urand32_get in addition to sys_rand32_get so we mimic
> /dev/urandom and /dev/random. sys_urand32_get might be PRNG based
> and should be considerably faster considering sys_rand32_get can
> block if it doesn't have enough entropy.
>
> > On systems with copious, low cost HW entropy we could simply wire
> > sys_prng_get() to the hw entropy source and bypass the prng
> > completely.
>
> Btw, isn't depending on one source of entropy alone bad/broken? I
> understand it is currently like this because the did not exist any
> way to collect entropy from other sources, but now we are talking
> about introducing one so we might as well switch from the driver
> given the random number to the driver working as a source of
> entropy which is then collected by random subsystem.
> >
> > On systems with limited/expensive HW entropy we use high quality
> > entropy to seed the prng.
> >
> > On systems with no dedicated source of HW entropy, rather than
> > building a driver like this we should perhaps instead look at
> > adding an entropy pool (as a subsystem or library, not a driver),
> > that has a mechanism to add entropy and can dole out entropy on
> > demand and then adjust various general hw drivers to feed what
> > meagre entropy then have to the pool. As with the previous
> > scenario, the PRNG would be seeded from the entropy pool.
> >
> > What do others think?
>
> I guess I agree, although currently the driver, there can be only
> one Im afraid, work as entropy pool instead of a source of entropy.
>
> Btw, regarding the implementation sys_urand32_get, if you agree
> with that, that might use sys_rand32_get to seed.
--
Luiz Augusto von Dentz


Re: File system in zephyr flashed on Arduino 101

Thomas, Ramesh
 

On Tue, Mar 21, 2017 at 21:28:41, Anila Sri wrote:
Can anyone tell me where the file is stored I mean which part if the
memory

On Mar 21, 2017 4:13 PM, "Anila Sri" <anilasri.y1995@gmail.com
<mailto:anilasri.y1995@gmail.com> > wrote:


I am using zephyr RTOS on Arduino 101. Ihave flashed the file
system code where in the data is written in a file using fs_write as
mentioned in the sample code. The changes I made are :
1. changed FS_SEEK_SET to FS_SEEK_END in fs_seek
2. and not deleting the file after writing
Not clear where you made these changes. Are you referring to the
sample app function test_file_write()?


The problem is that after executing the code the no. of free
blocks reduced from 1700+ to 200 . Now I am not able to retrieve the
blocks again even after deleting. Can anyone help
Not sure what is going on. Assuming the file system got corrupted,
you can try recreating it.

We currently do not have an external API/tool like "format" to recreate
the file system. There is a Jira story for that
https://jira.zephyrproject.org/browse/ZEP-903

For now you can make a temporary change in code to force recreation
of the file system.

In subsys/fs/fat_fs.c, in fs_init() function, comment out

res = f_mount(&fat_fs, "", 1);

and add a line
res = FR_NO_FILESYSTEM

This will force entry into the if condition block that calls f_mkfs() which
will recreate the file system at the next boot. After one reboot, you
can undo the above changes.



Thanks and Regards,
Anila


Re: File system in zephyr flashed on Arduino 101

Ani
 

Can anyone tell me where the file is stored I mean which part if the memory

On Mar 21, 2017 4:13 PM, "Anila Sri" <anilasri.y1995@...> wrote:

I am using zephyr RTOS on Arduino 101. Ihave flashed the file system code where in the data is written in a file using fs_write as mentioned in the sample code. The changes I made are :
1. changed FS_SEEK_SET to FS_SEEK_END in fs_seek
2. and not deleting the file after writing

The problem is that after executing the code the no. of free blocks reduced from 1700+ to 200 . Now I am not able to retrieve the blocks again even after deleting. Can anyone help


Thanks and Regards, 
Anila


Re: LWM2M: Call for proposals

Ricardo Salveti de Araujo <ricardo.salveti@...>
 

On Tue, Mar 21, 2017 at 5:22 PM, Joakim Eriksson <joakim.eriksson@ri.se> wrote:
Hello Anas,

I would like to try our LWM2M client only implementation in Zephyr and as recently have been working hard
to get it more portable and independent of Contiki it should be fairly easy I hope.
Is your implementation available anywhere public already?

Are you planning a client and server implementation or a client only?
Don't think we should restrict Zephyr to have only client support, but
I would imagine that is the most important piece to start with.

One option would be that we add some work on getting it adapted to the Zephyr stack so it kind of is “native”
in Zephyr. It would be a good way of getting a bit of hand-on experience of the Zephyr OS and stack.
Looks like option 3, which would probably be a good start if you
already have an implementation based on Contiki.

Cheers,
--
Ricardo Salveti


Re: NXP FRDM-K64F and OpenOCD from 0.9.0 SDK issue

Maureen Helm
 

Hi Piotr,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Piotr Król
Sent: Saturday, March 18, 2017 11:04 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] NXP FRDM-K64F and OpenOCD from 0.9.0 SDK issue

Hi all,
I'm not sure why, but OpenOCD from SDK can't flash and debug my K64F:

```
[16:51:40] pietrushnic:hello_world git:(master*) $ make BOARD=frdm_k64f
flash
make[1]: Entering directory
'/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
make[2]: Entering directory
'/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hel
lo_world/outdir/frdm_k64f'
Using /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr as
source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
CHK include/generated/generated_dts_board.h
CHK include/generated/offsets.h

make[3]: 'isr_tables.o' is up to date.

Flashing frdm_k64f
Flashing Target Device
Open On-Chip Debugger 0.9.0-dirty (2017-01-08-19:49) Licensed under GNU
GPL v2 For bug reports, read

https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopeno
cd.org%2Fdoc%2Fdoxygen%2Fbugs.html&data=01%7C01%7Cmaureen.helm%4
0nxp.com%7Caff7356f9e58452ba98508d46e18decc%7C686ea1d3bc2b4c6fa92cd
99c5c301635%7C0&sdata=flUQF%2B3omRsnwN08L4o%2FvwT2ttdE8JbeCDhuo5
z%2FT9k%3D&reserved=0
Info : only one transport option; autoselect 'swd'
Info : add flash_bank kinetis k60.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Error: unable to find CMSIS-DAP device

Done flashing
```

I compiled OpenOCD from master and with that version flashing and debugging
works:
OpenOCD support for K64 didn't make it upstream until 0.10.


```
[16:51:46] pietrushnic:hello_world git:(master*) $
OPENOCD=/usr/local/bin/openocd make BOARD=frdm_k64f flash
make[1]: Entering directory
'/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
make[2]: Entering directory
'/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hel
lo_world/outdir/frdm_k64f'
Using /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr as
source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
CHK include/generated/generated_dts_board.h
CHK include/generated/offsets.h
make[3]: 'isr_tables.o' is up to date.
Flashing frdm_k64f
Flashing Target Device
Open On-Chip Debugger 0.10.0+dev-00093-g6b2acc0243f6 (2017-03-18-15:52)
Licensed under GNU GPL v2 For bug reports, read

https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopeno
cd.org%2Fdoc%2Fdoxygen%2Fbugs.html&data=01%7C01%7Cmaureen.helm%4
0nxp.com%7Caff7356f9e58452ba98508d46e18decc%7C686ea1d3bc2b4c6fa92cd
99c5c301635%7C0&sdata=flUQF%2B3omRsnwN08L4o%2FvwT2ttdE8JbeCDhuo5
z%2FT9k%3D&reserved=0
Info : auto-selecting first available session transport "swd". To override use
'transport select <transport>'.
Info : add flash_bank kinetis k60.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD) Info : CMSIS-DAP: FW Version =
1.0 Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : SWD DPIDR
0x2ba01477 Info : k60.cpu: hardware has 6 breakpoints, 4 watchpoints Info :
MDM: Chip is unsecured. Continuing.
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* k60.cpu cortex_m little k60.cpu running
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001a28 msp: 0x20000640 auto erase enabled Info :
Probing flash info for bank 0 Warn : Flash Configuration Field written.
Warn : Reset or power off the device to make settings effective.
wrote 12288 bytes from file
/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hell
o_world/outdir/frdm_k64f/zephyr.bin
in 0.995954s (12.049 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001a28 msp: 0x20000640
Error: timed out while waiting for target halted target halted due to debug-
request, current mode: Thread
xPSR: 0x41000000 pc: 0x000018f8 psp: 0x20000730
Error: error executing cortex_m crc algorithm verified 10520 bytes in 20.876684s
(0.492 KiB/s) Info : MDM: Chip is unsecured. Continuing.
shutdown command invoked
Done flashing
make[2]: Leaving directory
'/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hel
lo_world/outdir/frdm_k64f'
make[1]: Leaving directory
'/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
```

The only thing I'm worry about is `error executing cortex_m crc algorithm` any
idea what maybe wrong ?
Not sure.

Is there any way to fix `unable to find CMSIS-DAP device` in SDK OpenOCD ?
We'll need to update the OpenOCD version in the next SDK release. Until then, you can build OpenOCD like you've already done, or use the prebuilt version that ships with Kinetis Design Studio.


Best Regards,
--
Piotr Król
Embedded Systems Consultant
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F3mde
b.com&data=01%7C01%7Cmaureen.helm%40nxp.com%7Caff7356f9e58452ba9
8508d46e18decc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=v7usAG
UB5yWTjT8KfbBJA2JPkh0QHdcoD0C5UXw2k%2FI%3D&reserved=0 |
@3mdeb_com _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.z
ephyrproject.org%2Fmailman%2Flistinfo%2Fzephyr-
devel&data=01%7C01%7Cmaureen.helm%40nxp.com%7Caff7356f9e58452ba98
508d46e18decc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=VbI%2BA
5KOEOWe5x7DgdGqgrKYEr%2F9xxzS60LLSuNmO%2FY%3D&reserved=0


Re: LWM2M: Call for proposals

Joakim Eriksson <joakim.eriksson@...>
 

Hello Anas,

I would like to try our LWM2M client only implementation in Zephyr and as recently have been working hard
to get it more portable and independent of Contiki it should be fairly easy I hope.

Are you planning a client and server implementation or a client only?

One option would be that we add some work on getting it adapted to the Zephyr stack so it kind of is “native”
in Zephyr. It would be a good way of getting a bit of hand-on experience of the Zephyr OS and stack.

Best regards,
— Joakim Eriksson, RISE SICS

On 21 Mar 2017, at 19:32, Nashif, Anas <anas.nashif@intel.com> wrote:

Hi,

In different forums and discussions around Zephyr features and the roadmap some interest was shown for getting LWM2M support in Zephyr.

Talking with different people and organizations we realized that there a few teams working on porting or have intentions to port existing LWM2M implementation to Zephyr. All is good news, however it would make sense to start talking about this on the mailing list and show intentions and progress and submit proposals so we can join forces and work on something common if possible.

Generally, we would like to adopt or support implementations that fit the architecture of Zephyr and that re-use existing components provided by Zephyr (CoAP, DTLS, ..). There are different approaches and ways this could be implemented, for example:

1. Native LWM2M support in Zephyr (native)
2. Import existing implementation into Zephyr and adapt it (fork)
3. Add support for Zephyr in existing implementation and support building for Zephyr (external)
4. Pull external code supporting zephyr as a module during build time (module)
5. Provide an LWM2M API in zephyr and allow external modules to implement those APIs (api)

I personally would have preferred native, but this would be a duplication given the number of implementations already out there, forking is not a favorite, so the remaining 3 options remain.

If you are working on LWM2M for Zephyr, please provide some information about your intentions or better provide a proposal by sending an RFC providing implementation details and how you want to integrate with rest of Zephyr.

Thanks,
Anas

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


LWM2M: Call for proposals

Nashif, Anas
 

Hi,

In different forums and discussions around Zephyr features and the roadmap some interest was shown for getting LWM2M support in Zephyr.

Talking with different people and organizations we realized that there a few teams working on porting or have intentions to port existing LWM2M implementation to Zephyr. All is good news, however it would make sense to start talking about this on the mailing list and show intentions and progress and submit proposals so we can join forces and work on something common if possible.

Generally, we would like to adopt or support implementations that fit the architecture of Zephyr and that re-use existing components provided by Zephyr (CoAP, DTLS, ..). There are different approaches and ways this could be implemented, for example:

1. Native LWM2M support in Zephyr (native)
2. Import existing implementation into Zephyr and adapt it (fork)
3. Add support for Zephyr in existing implementation and support building for Zephyr (external)
4. Pull external code supporting zephyr as a module during build time (module)
5. Provide an LWM2M API in zephyr and allow external modules to implement those APIs (api)

I personally would have preferred native, but this would be a duplication given the number of implementations already out there, forking is not a favorite, so the remaining 3 options remain.

If you are working on LWM2M for Zephyr, please provide some information about your intentions or better provide a proposal by sending an RFC providing implementation details and how you want to integrate with rest of Zephyr.

Thanks,
Anas


Re: Daily digests...

Marti Bolivar <marti.bolivar@...>
 

+1, I miss these and it would be good to have them back.

On 16 March 2017 at 07:46, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
Folks, We don't appear to have had any daily gerrit digests since
7/3/2017. Does anyone know what this issue is?

Cheers
/Marcus
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: File volume stats

Thomas, Ramesh
 

On Mon, Mar 20, 2017 at 23:19:02, phani karthik cs wrote:
Allocation unit size = 1024
This is 1024 bytes right?

Free space in f_frsize units = 1795
So free space would be (1795*1024)bytes.
Am I correct here?
That is correct.


On 21 Mar 2017 06:22, "Thomas, Ramesh" <ramesh.thomas@intel.com
<mailto:ramesh.thomas@intel.com> > wrote:


On Sun, Mar 19, 2017 at 22:22:05, phani karthik cs wrote:
> Hello all,
> Iam having trouble interpreting the fs_statvfs function. How
to
> interpret the below results that i ran on arduino 101
> -------------------------------------------------
> Optimal transfer block size = 512

This is the sector size. Data transfer size of the physical
storage media.

> Allocation unit size = 1024

Minimum size of storage the file system will allocate when
writing new
data. Will be multiples of block size.

> Volume size in f_frsize units = 2028
> Free space in f_frsize units = 1795

f_frsize is allocation unit size

> ------------------------------------------------ given the
above
> output, how much free memory do I have in bytes???
>
> Thank You
> Phani Karthik C S



Re: about multicasting with IPv4

Jukka Rissanen
 

Hi,

it is not enough to just add an API for adding the multicast address to
the interface. In order to routers send multicast traffic to the
device, it needs to also join IPv4 multicast group.
For IPv6 there is MLDv2 (Multicast Listener Discovery) support that was
added recently, so something similar should be done for IPv4.

Cheers,
Jukka

On Tue, 2017-03-21 at 08:13 +0000, 황윤희 wrote:
Dear Jukka,
 
Thanks for kind response.
I have a quesiton.
Is it possible to support IPv4 if only we make the api to add
multicast address?
Is that the only thing to do for enabling multicasting with IPv4 ?
I'm not sure if it's meaningful job that I make that api.
If then, I think I can try to do it.
But if not, it's impossible to me.
That's why I ask you about it.
 
Thanks and regards,
Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center
SAMSUNG ELECTRONICS CO.,LTD

TEL: +82-2-6147-7654
Moblie: +82-10-3421-1574
E-mail: yunhee.hwang@samsung.com
 
 
 
 
 
--------- Original Message ---------
Sender : Jukka Rissanen <jukka.rissanen@linux.intel.com>
Date : 2017-03-16 23:54 (GMT+9)
Title : Re: [Zephyr-devel] about multicasting with IPv4
 
Hi,

IPv4 multicast support is not really there yet. We have space in
net_if
struct (see net_if.h) for storing the IPv4 multicast addresses but
currently there is no API to set and/or use them.

Feel free to send patches to fix this if you can.

Cheers,
Jukka


On Thu, 2017-03-16 at 13:13 +0000, 황윤희 wrote:
Hello all,
 
I have a question about IPV4 dev status.
I check some networking funtions with IPv4. 
It seems to me that Zephyr doesn't have the api to set IPv4
multicast
address .
Doesn't Zephyr support IPv4 multicasting?
If it does, could anybody let me know how to enable it?
 
Thanks and regards,
Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center
SAMSUNG ELECTRONICS CO.,LTD
 
TEL: +82-2-6147-7654
Moblie: +82-10-3421-1574
E-mail: yunhee.hwang@samsung.com
 
 
 
  
  
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


File system in zephyr flashed on Arduino 101

Ani
 

I am using zephyr RTOS on Arduino 101. Ihave flashed the file system code where in the data is written in a file using fs_write as mentioned in the sample code. The changes I made are :
1. changed FS_SEEK_SET to FS_SEEK_END in fs_seek
2. and not deleting the file after writing

The problem is that after executing the code the no. of free blocks reduced from 1700+ to 200 . Now I am not able to retrieve the blocks again even after deleting. Can anyone help


Thanks and Regards, 
Anila


Re: about multicasting with IPv4

황윤희 <yunhee.hwang@...>
 

Dear Jukka,

 

Thanks for kind response.

I have a quesiton.

Is it possible to support IPv4 if only we make the api to add multicast address?

Is that the only thing to do for enabling multicasting with IPv4 ?

I'm not sure if it's meaningful job that I make that api.

If then, I think I can try to do it.

But if not, it's impossible to me.

That's why I ask you about it.

 

Thanks and regards,

Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center

SAMSUNG ELECTRONICS CO.,LTD

TEL: +82-2-6147-7654

Moblie: +82-10-3421-1574

E-mail: yunhee.hwang@...

 

 

 

 

 

--------- Original Message ---------

Sender : Jukka Rissanen <jukka.rissanen@...>

Date : 2017-03-16 23:54 (GMT+9)

Title : Re: [Zephyr-devel] about multicasting with IPv4

 

Hi,

IPv4 multicast support is not really there yet. We have space in net_if
struct (see net_if.h) for storing the IPv4 multicast addresses but
currently there is no API to set and/or use them.

Feel free to send patches to fix this if you can.

Cheers,
Jukka


On Thu, 2017-03-16 at 13:13 +0000, 황윤희 wrote:
> Hello all,
>  
> I have a question about IPV4 dev status.
> I check some networking funtions with IPv4. 
> It seems to me that Zephyr doesn't have the api to set IPv4 multicast
> address .
> Doesn't Zephyr support IPv4 multicasting?
> If it does, could anybody let me know how to enable it?
>  
> Thanks and regards,
> Hwang, Yunhee (Eunice)  
> IoT Lab ,Software R&D Center
> SAMSUNG ELECTRONICS CO.,LTD
> 
> TEL: +82-2-6147-7654
> Moblie: +82-10-3421-1574
> E-mail: yunhee.hwang@...
>  
>  
>  
>   
>   
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 


Re: File volume stats

phani karthik cs <phanikartcs@...>
 

> Allocation unit size          = 1024
This is 1024 bytes right?

> Free space in f_frsize units  = 1795
So free space would be (1795*1024)bytes.
Am I correct here?

On 21 Mar 2017 06:22, "Thomas, Ramesh" <ramesh.thomas@...> wrote:
On Sun, Mar 19, 2017 at 22:22:05, phani karthik cs wrote:
> Hello all,
> Iam having trouble interpreting  the fs_statvfs function. How to
> interpret the below results that i ran on arduino 101
> -------------------------------------------------
> Optimal transfer block size   = 512

This is the sector size.  Data transfer size of the physical storage media.

> Allocation unit size          = 1024

Minimum size of storage the file system will allocate when writing new
data. Will be multiples of block size.

> Volume size in f_frsize units = 2028
> Free space in f_frsize units  = 1795

f_frsize is allocation unit size

> ------------------------------------------------ given the above
> output, how much free memory do I have in bytes???
>
> Thank You
> Phani Karthik C S



Re: File volume stats

Thomas, Ramesh
 

On Sun, Mar 19, 2017 at 22:22:05, phani karthik cs wrote:
Hello all,
Iam having trouble interpreting the fs_statvfs function. How to
interpret the below results that i ran on arduino 101
-------------------------------------------------
Optimal transfer block size = 512
This is the sector size. Data transfer size of the physical storage media.

Allocation unit size = 1024
Minimum size of storage the file system will allocate when writing new
data. Will be multiples of block size.

Volume size in f_frsize units = 2028
Free space in f_frsize units = 1795
f_frsize is allocation unit size

------------------------------------------------ given the above
output, how much free memory do I have in bytes???

Thank You
Phani Karthik C S


File volume stats

phani karthik cs <phanikartcs@...>
 

Hello all,
Iam having trouble interpreting  the fs_statvfs function. How to interpret the below results that i ran on arduino 101
-------------------------------------------------
Optimal transfer block size   = 512
Allocation unit size          = 1024
Volume size in f_frsize units = 2028
Free space in f_frsize units  = 1795
------------------------------------------------ given the above output, how much free memory do I have in bytes???

Thank You
Phani Karthik C S


NXP FRDM-K64F and OpenOCD from 0.9.0 SDK issue

Piotr Król <piotr.krol@...>
 

Hi all,
I'm not sure why, but OpenOCD from SDK can't flash and debug my K64F:

```
[16:51:40] pietrushnic:hello_world git:(master*) $ make BOARD=frdm_k64f flash
make[1]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
make[2]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f'
Using /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
CHK include/generated/generated_dts_board.h
CHK include/generated/offsets.h

make[3]: 'isr_tables.o' is up to date.

Flashing frdm_k64f
Flashing Target Device
Open On-Chip Debugger 0.9.0-dirty (2017-01-08-19:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Info : add flash_bank kinetis k60.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Error: unable to find CMSIS-DAP device

Done flashing
```

I compiled OpenOCD from master and with that version flashing and debugging works:

```
[16:51:46] pietrushnic:hello_world git:(master*) $ OPENOCD=/usr/local/bin/openocd make BOARD=frdm_k64f flash
make[1]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
make[2]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f'
Using /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
CHK include/generated/generated_dts_board.h
CHK include/generated/offsets.h
make[3]: 'isr_tables.o' is up to date.
Flashing frdm_k64f
Flashing Target Device
Open On-Chip Debugger 0.10.0+dev-00093-g6b2acc0243f6 (2017-03-18-15:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : add flash_bank kinetis k60.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : k60.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : MDM: Chip is unsecured. Continuing.
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* k60.cpu cortex_m little k60.cpu running
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001a28 msp: 0x20000640
auto erase enabled
Info : Probing flash info for bank 0
Warn : Flash Configuration Field written.
Warn : Reset or power off the device to make settings effective.
wrote 12288 bytes from file /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f/zephyr.bin in 0.995954s (12.049 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001a28 msp: 0x20000640
Error: timed out while waiting for target halted
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x000018f8 psp: 0x20000730
Error: error executing cortex_m crc algorithm
verified 10520 bytes in 20.876684s (0.492 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
shutdown command invoked
Done flashing
make[2]: Leaving directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f'
make[1]: Leaving directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
```

The only thing I'm worry about is `error executing cortex_m crc algorithm` any idea what maybe wrong ?

Is there any way to fix `unable to find CMSIS-DAP device` in SDK OpenOCD ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com

5141 - 5160 of 7764