Date   

Testing random number generators

Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
 

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,

--
Geoffrey


Zephyr 1.7.0 tagged

Nashif, Anas
 

Hi,

 

We are pleased to announce the release of Zephyr kernel version 1.7.0. This

release continues refinement of the unified kernel introduced with the 1.6.0

kernel release, simplifying the overall Zephyr architecture and programming

interfaces. This is the last release that will support the deprecated legacy

nano- and micro-kernel APIs found in the 1.5.0 release and earlier.

 

This release introduces a new native IP stack, replacing the legacy uIP stack,

maintaining the legacy functionality, adding additional capabilities, and allowing

future improvements.

 

We have introduced support for the RISC V and Xtensa architectures and now

support 6 architectures in total.

 

Device tree support for ARM based boards added. The initial

device tree support includes flash/sram base address and UART devices.  Board

support includes NXP Kinetis based SoCs, ARM Beetle, TI CC3200 LaunchXL, and

STML32L476 based SoCs. Plan is to add support for other architectures and

expand device support in upcoming Zephyr releases.

 

More details can be found in the release notes at:

 

https://www.zephyrproject.org/doc/1.7.0/release-notes.html

 

 

Many thanks to all who contributed to this release and continue to make Zephyr

better every day.

 

Master branch is now open for feature development. The Zephyr 1.8 release is

planned for end of May 2017.

 

Regards,

Anas


Reg: GPIO callbacks on galileo Gen 2

Vishal Varun Tipparaju <vlnu1@...>
 

Hello,

I have been working on gpio callbacks for galileo gen2 board. I have referred to zephyr/samples/basic/button/ example and tried the callbacks on DW4 gpio pin. But the callbacks are never fired. Kindly suggest appropriate changes for galileo gen 2 to use the button sample project.

Kindly redirect me to the appropriate mailing list if this is not the list for this issue

Thank you
Vishal T


Re: [RFC] MPU support for debugging

Benjamin Walsh <benjamin.walsh@...>
 

Some random thoughts on this, do with them as you wish. :)

To get more detailed feedback, I think you need to document how exactly
you intend on using the MPU.

Like:

- region 0 to protect the kernel test+rodata (supervisor, ro)
- region 1 to protect the kernel data and kernel thread stacks
(supervisor, rw)
- region 2 for text+rodata for all user threads (user, ro)
- region 3 for data+stacks of threads in group A (user, rw, nx (if
available))
- region 4 for data+stacks of threads in group B (user, rw, nx (if
available))
- region 5 for shared memory between group A and group B (always
accessible) (user, rw, nx (if available))
- regions are fixed
- privileges for region 3 change from user to supervisor when a thread
in group B gets context switched in
- privileges for region 4 change from user to supervisor when a thread
in group A gets context switched in
- privileges for region 3 change from supervisor to user when a thread
in group A gets context switched in
- privileges for region 4 change from supervisor to user when a thread
in group B gets context switched in

or

- region 0 to protect the kernel test+rodata (supervisor, ro)
- region 1 to protect the kernel data and kernel thread stacks
(supervisor, rw)
- region 2 of text+rodata for all user threads (user, ro)
- region 3 for data+stack of currently running user thread (user, rw, nx
(if available)).
- region 4 for shared memory between all threads (always accessible)
(user, rw, nx (if available)).
- region 3 base addr + size get reprogrammed on user threads context
switches to match incoming thread's data+stack section
- kernel can reprogram region 3 base addr + size to match a thread it
wants to pass data to in a user-space buffer

or something else.

On Fri, Mar 10, 2017 at 10:11:20PM +0000, Boie, Andrew P wrote:
This is not a fully-fleshed out specification, but since there is a
lot of interest in memory protection in Zephyr on multiple fronts I
thought this would be a good way to get the conversation going on how
we can use an MPU in Zephyr and what implications it has for the OS
design. Hoping to get a consensus on the scope and capabilities of
this before diving too deep into implementation details.

TL;DR SUMMARY

Memory protection could be used to greatly assist in kernel debugging.
At this time I think it should be positioned as an optional debug
feature and not a security feature. We want to target common MPU
features found on MCUs. Systems without MPU hardware, but have an MMU,
can use MMU with identity page tables instead. We want to be able to
create "user" threads with reduced privileges on what memory they can
write to, so that if they overflow their stack, branch to non-code, or
write to memory that doesn't belong to them, the system will trigger a
fatal error instead of silently wreaking havoc. We want to implement
this in a way that is not invasive to the current Zephyr driver/OS
APIs.

PROBLEM STATEMENTS

As I'm sure we all know, debugging multi-threaded applications is a
complex task, made much more complex if threads can silently corrupt
each other or the OS. Thread stack overflows are also very difficult
to debug, with the usual symptom being strange, unpredictable behavior
until the system eventually crashes.

We'd like to introduce support for memory protection units in Zephyr
to help with these debug issues. To me the following characteristics
would be desirable:

- Introduce the notion of User/Supervisor threads. User threads would
only have write access to their own stack, plus some additional memory
^^^^^^^^^^^^^^^
And whatever other stacks are in the same protection region: stack
overflow will only corrupt the current region, but they can still happen
and wreck havoc within the protection area. Or are you thinking of
rewriting the memory protection area boundaries on every context switch
to with bounds around the current thread's stack ? I don't mean only
changing the permissions, but the boundaries themselves ?

regions parameterized at runtime.

- Illegal memory access by a user thread, stack overflow, or branching
the PC to memory that is not code should result in a fatal system
error, using SysFatalErrorHandler.

- Kernel and driver APIs should be the same regardless of whether
memory protection is used. For example, during debugging the end user
may enable memory protection to catch issues, but for the final
production build it would be switched off for performance reasons.

- For at least the initial implementation of this feature we should
try to do it changing any existing public kernel or driver APIs as
little as possible, although we will need to introduce some new ones.

MPU LIMITATIONS

It's important to keep in mind the capabilities of a typical MPU unit.
In all the implementations I have seen, the memory regions need to be
aligned to a multiple of their size, and the size must be a power of
two. (ARM lets you further subdivide any given region into 8
sub-regions which can be selectively enabled). Regions may overlap,
but there can only be a fixed number of regions active at any given
time, with 8 or 16 being common.

Some arches like x86 don't have MPU hardware, but if an MMU is present
it can be configured to act like an MPU using an identity page table.

THIS IS NOT A SECURITY FEATURE
This bothers me a bit. If you ever want to turn this into a more
fleshed-out user-space model, would you introduce a third API/model or
modify them again ?

My gut feeling would be to design for the full "user-space" model, and
then have the reduced-capability MPU-model be a special case of it.

Then again, depends on the timeframe and how future-proof you want to
design this.

If you look at all the kernel APIs in kernel.h, they all take pointers
to various data structures owned by the caller. Let's take a Zephyr
timer as an example. If you want to use a timer you need to declare a
struct k_timer and then make kernel API calls passing its pointer
value, which will involve a privilege elevation for the system to do
its work. Some of the members of the k_timer struct are really private
to the kernel and we could cause all kinds of havoc if garbage data is
passed in, or the k_timer struct is corrupted in some way, or someone
was trying to do something malicious.

We have a similar problem with drivers, where pointers to struct
device are passed around and dereferenced in order to get at their API
calls. At a fundamental level, Zephyr in its current state is designed
to be application+kernel all rolled into one address space.

I do not see any good way around this problem unless we completely
redesign all kernel and driver APIs:
Yeah, I think you would need a different API. With pre-zephyr, when we
added user-space and allowed the microkernel APIs from user-space, we
were playing with IDs already (the microkernel API referenced IDs, not
addresses), and we still had to put a bunch of restrictions on what the
APIs could do from user-space, which made the API clunky to use.

You could supplement the API with user-space "wrappers" that allocate
and initialize objects and return and operate on an ID, rather than
playing with addresses.

e.g.

k_sem_id_t k_sem_create(int limit, int count)

or maybe

z_sem_id_t z_sem_create(int limit, int count)

since they are not really kernel APIs when called from users-space, and then

int z_sem_take(z_sem_id_t id, int32_t timeout)

Then you need a pool of object or a real kernel memory allocator.

- Data structures private to the kernel for kernel objects would need
to be completely inaccessible to user threads.

- User threads wanting to work with some kernel object would not
allocate memory for it and pass in a pointer. We'd need an API where
the user thread requests an object (like a timer), the kernel
allocates space for it somehow, and returns to the user thread a
descriptor or handle to use when performing API calls.
Oh well, I wrote the previous comment before getting to this part. :)

- For situations where we only want to use memory protection for
debugging, this layer of abstraction in all the APIs to use
descriptors instead of pointers would impose a lot of unnecessary
overhead for situations where MPU is disabled or not available.

Ideas are very welcome here, but my feeling is that "preventing
threads from crashing the OS in all cases" or "prevent threads from
doing malicious things" is probably not completely feasible in Zephyr
unless we transform it into a remarkably different OS than it is now.
I think this needs more of a "split" between kernel and "user-space"
APIs than a redesign. But then, kernel applications could not be rebuilt
as user-space applications. Applications using the user-space API could
probably be rebuilt as kernel applications, if we provided the
user-space API as a very thin layer around the current kernel APIs in
the kernel. Nothing would prevent removing the user-space layer and run
kernel-only.

Given the limitations of a typical MPU I suspect this would probably
require an MMU to do it right. I feel there are a lot of things we can
do to help with debugging if we assume good intent and are not trying
to protect against malicious behavior, or garbage being passed to
kernel APIs.

In this proposal, threads can switch between supervisor and user
privileges at will. This greatly simplifies the implementation:

- No need for system calls for privilege elevation. Through macro
magic, if memory protection is turned on we can wrap kernel/driver
What do you mean by "macro magic" ? There has to be a mechanism to
trigger the privilege elevation. On ARM, you have to use the SVC
instruction, handle the exception, write the CONTROL register, and come
back to the next instruction after SVC. That's basically one system
call, which purpose is to elevate the privilege of the current thread.

APIs with some code that elevates privileges before calling into the
kernel, check that any supplied pointer values are actually owned by
the calling thread, and drop privileges when returning to the caller.

- Many drivers and subsystems allow for the registration of callbacks
upon events. Some of these run in ISR context and should be left
as-is. However for example in the network stack you can supply
callbacks invoked by supervisor network stack worker threads to
perform protocol parsing on the application side, and it would be
great if these callbacks could run in a reduced set of privileges. The
worker threads in the subsystem that make the callbacks could lower
their privileges (granting access to buffer memory regions if
necessary) when making the callback, restoring them when it returns.

THREAD PERMISSIONS

By default all threads start their life in supervisor mode. I think
what Vincenzo recently uploaded is a good policy for supervisor
threads: https://gerrit.zephyrproject.org/r/#/q/topic:zephyr_mpu.

Threads may drop down to user mode with an API call. This would grant
the thread write access to only its stack memory, plus additional
memory regions parameterized at runtime. Threads may go back to
supervisor mode with another API call, there's no restrictions on
moving back and forth between these states.

Even though we allow threads to move between user and supervisor mode
at will, we are trying to catch mistakes. So some kernel/driver APIs
that are intended to be called from user mode will have an implicit
privilege elevation, but others which are intended to be
supervisor-only will not.

For globals (data/bss) I think we should separate the data used by the
OS (libzephyr.a) and globals declared by the application, put them in
different memory regions. We should make it easy to grant any given
thread write access to globals defined within the application. I'm
thinking of a programming model similar to pthreads:

each pthread's stack is private
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's not really true: within a process, threads can stomp on each
other's stacks (that said, I haven't done a lot of pthread programming,
and I don't know if e.g. the Linux kernel allows protecting a thread's
stack from the other threads within a process).

and you can't touch OS data structures, but all the
pthreads can access/modify globals within the process they run in. In
Zephyr we more or less have many threads running in exactly one
process.

Additionally, application globals that are never intended to be
touched by user threads could be tagged with a __supervisor variable
attribute which will roll them in with the other OS globals.

ZEPHYR IMPLICATIONS

Rough to-do list to make this happen:

- Fully specify the relevant API calls for this feature

- Move the struct k_thread out of the thread stack where it currently
lives. We don't want the thread clobbering this if too much stack is
used, which is currently what happens since it's at the lowest memory
addresses of the stack. May need to reserve some additional memory on
the kernel side for this data to live in.
Normally, you need a kernel stack in addition to the user-space stack to
do this right. In pre-zephyr user-space, we tried doing everything on
the user-space stack to save space, but finally abandoned that approach
when facing too many issues.

- Some APIs which assume use of the system heap for all allocations may
need to be extended for user-supplied memory pools

- Separate out kernel globals (bss/data) from application globals. A
typical user thread may need to have access to application globals,
but should never need to write to kernel data structures in a
non-supervisor state. Application globals tagged with __supervisor
would be put with the OS data structures.

- Implement magic for implicit privilege elevation in kernel/driver
APIs when calling them from user mode

- Define a memory protection API specification between the core kernel
and arch/ code which actually talks to the MPU (or MMU)

- Possible adjustments to how the network stack does callbacks

- Test cases to prove that this all works


Re: Eddystone on nrf51 / nrf52

Marcus Shawcroft <marcus.shawcroft@...>
 

On 11 March 2017 at 08:17, Johan Hedberg <johan.hedberg@intel.com> wrote:

I used the latest bluetooth branch which was rebased against master just
a few hours ago. There's only a one commit difference between the two
branches which is not related (it's for an IPSP static analyzer warning)
so master should behave the same. I didn't do any changes to the
eddystone sample but just built it with its default configuration.

Ok, I have it running now, I swapped microbits. It appears I have 3
microbits on which it works and 1 microbit on which it doesn't work.

Thank you both for your help.

Cheers
/Marcus


Re: Eddystone on nrf51 / nrf52

Vinayak Kariappa <vinayak.kariappa@...>
 

Can you check if the gcc library being linked is from arm6v-m? This is when if you use CROSS_COMPILE.



On 11 Mar 2017, at 08:48, Marcus Shawcroft <marcus.shawcroft@...> wrote:


On Sat, 11 Mar 2017 at 06:40, Johan Hedberg <johan.hedberg@...> wrote:
Hi Marcus,

On Fri, Mar 10, 2017, Marcus Shawcroft wrote:
> I've just tried samples/bluetooth/eddystone on nrf51 (bbc_microbit)
> and so far as I can tell it doesn't boot as far as main().
>
> Same experiment on nrf52 (pca10040) runs just fine.
>
> Is edddystone expected run on nrf51, has anyone ever tried it?

It is expected to run. I've been mainly using nRF51 USB dongles, but I
just tried the eddystone sample on my micro:bit and it's working fine.
How do you flash yours? I remember I had some strange issues with the
original debug IC firmware, and switching to a JLink one made it better.

Interesting.  I can still build various other samples and flash them to the microbit and they run just fine. I used a microbit fairly extensively a while back when putting together drivers for its I2C, magnetometer, accelerometer, TRNG etc and recall on one or two occasions getting it in a state where it would not flash using the vanilla daplink firmware. Iirc that cleared by power cycling both host and microbit. I also recall that switching to newlib instead of minimal Libc with BT enabled on the microbit results in a similar failure to reach main(). 

Johan would you mind sending me your microbit Eddystone configure file and the git hash of the dev tree that you just tested as working?

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


Re: Eddystone on nrf51 / nrf52

Johan Hedberg
 

Hi Marcus,

On Sat, Mar 11, 2017, Marcus Shawcroft wrote:
It is expected to run. I've been mainly using nRF51 USB dongles, but I
just tried the eddystone sample on my micro:bit and it's working fine.
How do you flash yours? I remember I had some strange issues with the
original debug IC firmware, and switching to a JLink one made it better.
Interesting. I can still build various other samples and flash them to the
microbit and they run just fine. I used a microbit fairly extensively a
while back when putting together drivers for its I2C, magnetometer,
accelerometer, TRNG etc and recall on one or two occasions getting it in a
state where it would not flash using the vanilla daplink firmware. Iirc
that cleared by power cycling both host and microbit. I also recall that
switching to newlib instead of minimal Libc with BT enabled on the microbit
results in a similar failure to reach main().

Johan would you mind sending me your microbit Eddystone configure file and
the git hash of the dev tree that you just tested as working?
I used the latest bluetooth branch which was rebased against master just
a few hours ago. There's only a one commit difference between the two
branches which is not related (it's for an IPSP static analyzer warning)
so master should behave the same. I didn't do any changes to the
eddystone sample but just built it with its default configuration.

Johan


Re: Eddystone on nrf51 / nrf52

Marcus Shawcroft <marcus.shawcroft@...>
 


On Sat, 11 Mar 2017 at 06:40, Johan Hedberg <johan.hedberg@...> wrote:
Hi Marcus,

On Fri, Mar 10, 2017, Marcus Shawcroft wrote:
> I've just tried samples/bluetooth/eddystone on nrf51 (bbc_microbit)
> and so far as I can tell it doesn't boot as far as main().
>
> Same experiment on nrf52 (pca10040) runs just fine.
>
> Is edddystone expected run on nrf51, has anyone ever tried it?

It is expected to run. I've been mainly using nRF51 USB dongles, but I
just tried the eddystone sample on my micro:bit and it's working fine.
How do you flash yours? I remember I had some strange issues with the
original debug IC firmware, and switching to a JLink one made it better.

Interesting.  I can still build various other samples and flash them to the microbit and they run just fine. I used a microbit fairly extensively a while back when putting together drivers for its I2C, magnetometer, accelerometer, TRNG etc and recall on one or two occasions getting it in a state where it would not flash using the vanilla daplink firmware. Iirc that cleared by power cycling both host and microbit. I also recall that switching to newlib instead of minimal Libc with BT enabled on the microbit results in a similar failure to reach main(). 

Johan would you mind sending me your microbit Eddystone configure file and the git hash of the dev tree that you just tested as working?

Cheers
/Marcus


Re: Eddystone on nrf51 / nrf52

Johan Hedberg
 

Hi Marcus,

On Fri, Mar 10, 2017, Marcus Shawcroft wrote:
I've just tried samples/bluetooth/eddystone on nrf51 (bbc_microbit)
and so far as I can tell it doesn't boot as far as main().

Same experiment on nrf52 (pca10040) runs just fine.

Is edddystone expected run on nrf51, has anyone ever tried it?
It is expected to run. I've been mainly using nRF51 USB dongles, but I
just tried the eddystone sample on my micro:bit and it's working fine.
How do you flash yours? I remember I had some strange issues with the
original debug IC firmware, and switching to a JLink one made it better.
You can download a new debug IC firmware here (look for "micro:bit"):

https://www.segger.com/downloads/jlink

You flash it by plugging in the board while keeping the reset button
pressed. It'll show up as a "MAINTENANCE" drive rather than "MICROBIT".

Johan


[RFC] MPU support for debugging

Boie, Andrew P
 

This is not a fully-fleshed out specification, but since there is a lot of interest in memory protection in Zephyr on multiple fronts I thought this would be a good way to get the conversation going on how we can use an MPU in Zephyr and what implications it has for the OS design. Hoping to get a consensus on the scope and capabilities of this before diving too deep into implementation details.

TL;DR SUMMARY

Memory protection could be used to greatly assist in kernel debugging. At this time I think it should be positioned as an optional debug feature and not a security feature. We want to target common MPU features found on MCUs. Systems without MPU hardware, but have an MMU, can use MMU with identity page tables instead. We want to be able to create "user" threads with reduced privileges on what memory they can write to, so that if they overflow their stack, branch to non-code, or write to memory that doesn't belong to them, the system will trigger a fatal error instead of silently wreaking havoc. We want to implement this in a way that is not invasive to the current Zephyr driver/OS APIs.

PROBLEM STATEMENTS

As I'm sure we all know, debugging multi-threaded applications is a complex task, made much more complex if threads can silently corrupt each other or the OS. Thread stack overflows are also very difficult to debug, with the usual symptom being strange, unpredictable behavior until the system eventually crashes.

We'd like to introduce support for memory protection units in Zephyr to help with these debug issues. To me the following characteristics would be desirable:

- Introduce the notion of User/Supervisor threads. User threads would only have write access to their own stack, plus some additional memory regions parameterized at runtime.
- Illegal memory access by a user thread, stack overflow, or branching the PC to memory that is not code should result in a fatal system error, using SysFatalErrorHandler.
- Kernel and driver APIs should be the same regardless of whether memory protection is used. For example, during debugging the end user may enable memory protection to catch issues, but for the final production build it would be switched off for performance reasons.
- For at least the initial implementation of this feature we should try to do it changing any existing public kernel or driver APIs as little as possible, although we will need to introduce some new ones.

MPU LIMITATIONS

It's important to keep in mind the capabilities of a typical MPU unit. In all the implementations I have seen, the memory regions need to be aligned to a multiple of their size, and the size must be a power of two. (ARM lets you further subdivide any given region into 8 sub-regions which can be selectively enabled). Regions may overlap, but there can only be a fixed number of regions active at any given time, with 8 or 16 being common.

Some arches like x86 don't have MPU hardware, but if an MMU is present it can be configured to act like an MPU using an identity page table.

THIS IS NOT A SECURITY FEATURE

If you look at all the kernel APIs in kernel.h, they all take pointers to various data structures owned by the caller. Let's take a Zephyr timer as an example. If you want to use a timer you need to declare a struct k_timer and then make kernel API calls passing its pointer value, which will involve a privilege elevation for the system to do its work. Some of the members of the k_timer struct are really private to the kernel and we could cause all kinds of havoc if garbage data is passed in, or the k_timer struct is corrupted in some way, or someone was trying to do something malicious.

We have a similar problem with drivers, where pointers to struct device are passed around and dereferenced in order to get at their API calls. At a fundamental level, Zephyr in its current state is designed to be application+kernel all rolled into one address space.

I do not see any good way around this problem unless we completely redesign all kernel and driver APIs:
- Data structures private to the kernel for kernel objects would need to be completely inaccessible to user threads.
- User threads wanting to work with some kernel object would not allocate memory for it and pass in a pointer. We'd need an API where the user thread requests an object (like a timer), the kernel allocates space for it somehow, and returns to the user thread a descriptor or handle to use when performing API calls.
- For situations where we only want to use memory protection for debugging, this layer of abstraction in all the APIs to use descriptors instead of pointers would impose a lot of unnecessary overhead for situations where MPU is disabled or not available.

Ideas are very welcome here, but my feeling is that "preventing threads from crashing the OS in all cases" or "prevent threads from doing malicious things" is probably not completely feasible in Zephyr unless we transform it into a remarkably different OS than it is now. Given the limitations of a typical MPU I suspect this would probably require an MMU to do it right. I feel there are a lot of things we can do to help with debugging if we assume good intent and are not trying to protect against malicious behavior, or garbage being passed to kernel APIs.

In this proposal, threads can switch between supervisor and user privileges at will. This greatly simplifies the implementation:

- No need for system calls for privilege elevation. Through macro magic, if memory protection is turned on we can wrap kernel/driver APIs with some code that elevates privileges before calling into the kernel, check that any supplied pointer values are actually owned by the calling thread, and drop privileges when returning to the caller.
- Many drivers and subsystems allow for the registration of callbacks upon events. Some of these run in ISR context and should be left as-is. However for example in the network stack you can supply callbacks invoked by supervisor network stack worker threads to perform protocol parsing on the application side, and it would be great if these callbacks could run in a reduced set of privileges. The worker threads in the subsystem that make the callbacks could lower their privileges (granting access to buffer memory regions if necessary) when making the callback, restoring them when it returns.

THREAD PERMISSIONS

By default all threads start their life in supervisor mode. I think what Vincenzo recently uploaded is a good policy for supervisor threads: https://gerrit.zephyrproject.org/r/#/q/topic:zephyr_mpu.

Threads may drop down to user mode with an API call. This would grant the thread write access to only its stack memory, plus additional memory regions parameterized at runtime. Threads may go back to supervisor mode with another API call, there's no restrictions on moving back and forth between these states.

Even though we allow threads to move between user and supervisor mode at will, we are trying to catch mistakes. So some kernel/driver APIs that are intended to be called from user mode will have an implicit privilege elevation, but others which are intended to be supervisor-only will not.

For globals (data/bss) I think we should separate the data used by the OS (libzephyr.a) and globals declared by the application, put them in different memory regions. We should make it easy to grant any given thread write access to globals defined within the application. I'm thinking of a programming model similar to pthreads: each pthread's stack is private, and you can't touch OS data structures, but all the pthreads can access/modify globals within the process they run in. In Zephyr we more or less have many threads running in exactly one process.

Additionally, application globals that are never intended to be touched by user threads could be tagged with a __supervisor variable attribute which will roll them in with the other OS globals.

ZEPHYR IMPLICATIONS

Rough to-do list to make this happen:
- Fully specify the relevant API calls for this feature
- Move the struct k_thread out of the thread stack where it currently lives. We don't want the thread clobbering this if too much stack is used, which is currently what happens since it's at the lowest memory addresses of the stack. May need to reserve some additional memory on the kernel side for this data to live in.
- Some APIs which assume use of the system heap for all allocations may need to be extended for user-supplied memory pools
- Separate out kernel globals (bss/data) from application globals. A typical user thread may need to have access to application globals, but should never need to write to kernel data structures in a non-supervisor state. Application globals tagged with __supervisor would be put with the OS data structures.
- Implement magic for implicit privilege elevation in kernel/driver APIs when calling them from user mode
- Define a memory protection API specification between the core kernel and arch/ code which actually talks to the MPU (or MMU)
- Possible adjustments to how the network stack does callbacks
- Test cases to prove that this all works


Eddystone on nrf51 / nrf52

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,


I've just tried samples/bluetooth/eddystone on nrf51 (bbc_microbit)
and so far as I can tell it doesn't boot as far as main().

Same experiment on nrf52 (pca10040) runs just fine.

Is edddystone expected run on nrf51, has anyone ever tried it?

Cheers
/Marcus


Upgrade of RTC api.

Michał Kruszewski <mkru@...>
 

I wanted to implement rtc driver for nrf chips and I think that rtc.h api is too loosely defined.
Chips from IC vendors are very  different in terms of RTC peripheral, for example:
a) different number of RTC instances
b) different number of compare/alarm registers
c) some can generate additional events like TICK for tick-less RTOS
d) some have registers for current time and format of that time can also differ
e) different size of COUNTER register (that's actually not a big issue cause you can   always implement 32 bit counter in software).

I would like to implement more advanced rtc api and I would like you to help me define how it should look like. For example:
1. How many alarms can be set on single RTC, should it be configured via Kconfig (even with single alarm register it is possible to implement it in software) or the number of alarms should equal to number of available compare registers?
2. Should we keep track of current time inside rtc driver or should there be some higher module that would only use rtc driver, if yes then what format of time should we use, should it be configurable?
3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
4. What about some extra events like TICK, OVERFLOW?
5. Should there be only one callback function? rtc_api_set_alarm could then return descriptor to alarm and inside callback function we could check what exact alarm was triggered. Or maybe we should pass pointer to callback function  as an argument to rtc_api_set_alarm function?

I want to implement that api and some drivers but I need more details from people who have impact on how the project looks like, people who can make decisions.

Michał Kruszewski

Sent with ProtonMail Secure Email.


Re: Reg: Command handling Via USB driver

Andrei
 

Hi Mahendra,

On Thu, Mar 09, 2017 at 04:54:23AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

We are using Quark_C1000 controller in our project along with zephyr 1.6.
I could see zephyr 1.6 has support for USB.

I have a query.

We are currently having a requirement of send some commands via USB (from
a PC)  and based on the commands received (in the device ) we will execute
certain applications.

For this requirement I need clarifications regarding the USB driver.

I could see that the USB DFU handles command which is sent from a PC.

Do I need to expand this driver itself for my requirement or Should I use
the USB UART driver for my requirement ?
It is easier to use cdc_acm sample in samples/usb/cdc_acm, then your PC
already has the driver for it and it appears on your PC as ttyACM or
ttyUSB, then you can communicate over serial.

If you want to implement certain USB class like Bluetooth in hci_usb
sample you should look here: samples/bluetooth/hci_usb/

For other samples you need AFAIK to have certain driver, like btusb for
hci_usb, etc.

Best regards
Andrei Emeltchenko


Reg: Command handling Via USB driver

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi

 

We are using Quark_C1000 controller in our project along with zephyr 1.6.

I could see zephyr 1.6 has support for USB.

 

I have a query.

 

We are currently having a requirement of send some commands via USB (from a PC)  and based on the commands received (in the device ) we will execute certain applications.

 

For this requirement I need clarifications regarding the USB driver.

 

I could see that the USB DFU handles command which is sent from a PC.

Do I need to expand this driver itself for my requirement or Should I use the USB UART driver for my requirement ?

 

Thanks

Mahendra


Re: Checking if code is compiled for Zephyr

Paul Sokolovsky
 

On Tue, 7 Mar 2017 17:01:04 +0100
Paul Sokolovsky <Paul.Sokolovsky@linaro.org> wrote:

On Tue, 7 Mar 2017 14:38:16 +0000
Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:

On 7 March 2017 at 14:35, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello,

I'm trying to #ifdef a part of cross-platform code for Zephyr,
and I didn't find a clear, self-describing way to do so. Am I
missing something? Can we have something like __ZEPHYR__, _ZEPHYR
of whatever preprocessor macro to check for?
The toplevel Makefile hardwires:

-D__ZEPHYR__=1
Cool, thanks for replies! I grepped include/* for anything like that,
I checked predefined macros in gcc. Who'd new I should grep Makefiles
too ;-).
Well, too early. I do build against Zephyr, I use its configuration and
includes, but my 3rd party project doesn't use Zephyr *Makefiles*.
So, __ZEPHYR__ isn't available.

I'll prepare a patch.


--
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: Checking if code is compiled for Zephyr

Paul Sokolovsky
 

On Tue, 7 Mar 2017 14:38:16 +0000
Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:

On 7 March 2017 at 14:35, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello,

I'm trying to #ifdef a part of cross-platform code for Zephyr, and I
didn't find a clear, self-describing way to do so. Am I missing
something? Can we have something like __ZEPHYR__, _ZEPHYR of
whatever preprocessor macro to check for?
The toplevel Makefile hardwires:

-D__ZEPHYR__=1
Cool, thanks for replies! I grepped include/* for anything like that, I
checked predefined macros in gcc. Who'd new I should grep Makefiles
too ;-).


I don't know if that symbol is documented somewhere, but it would be
nice if it was.
+1. doc/* doesn't mention it, I'll see where it fits and drop a patch
on occasion.


--
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: Checking if code is compiled for Zephyr

flaviosantes@...
 

Hello,

__ZEPHYR__ ?

https://gerrit.zephyrproject.org/r/#/c/7470/2

Regards,
Flavio

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

On Tue, 3/7/17, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:

Subject: Re: [Zephyr-devel] Checking if code is compiled for Zephyr
To: "Paul Sokolovsky" <paul.sokolovsky@linaro.org>
Cc: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Date: Tuesday, March 7, 2017, 8:38 AM

On 7 March 2017 at 14:35,
Paul Sokolovsky <paul.sokolovsky@linaro.org>
wrote:
> Hello,
>
> I'm trying to #ifdef a part of
cross-platform code for Zephyr, and I
>
didn't find a clear, self-describing way to do so. Am I
missing
> something? Can we have
something like __ZEPHYR__, _ZEPHYR of whatever
> preprocessor macro to check for?

The toplevel Makefile
hardwires:

-D__ZEPHYR__=1

I don't know if that symbol is documented
somewhere, but it would be
nice if it
was.


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


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/11998 : Bluetooth: Controller: Kconfig option to set public address
- https://gerrit.zephyrproject.org/r/12008 : build: Fix qemugdb target
- https://gerrit.zephyrproject.org/r/12005 : net: core: Use K_NO_WAIT when spawning RX and TX threads
- https://gerrit.zephyrproject.org/r/12007 : boards/arm/nrf52840: Disable default build of Bluetooth stack
- https://gerrit.zephyrproject.org/r/12004 : net: core: Mark RX and TX threads essential
- https://gerrit.zephyrproject.org/r/11997 : samples: net: dtlsclient RX buf count too low
- https://gerrit.zephyrproject.org/r/11992 : samples/net: Add the HTTP API to the HTTP server sample application
- https://gerrit.zephyrproject.org/r/11988 : samples: net/nats: Fix parsing of MSG messages
- https://gerrit.zephyrproject.org/r/11985 : mem_pool: Fix pool allocation, make portable
- https://gerrit.zephyrproject.org/r/11986 : samples: dtls client: DTLS client sample configuration file

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11395 : Bluetooth: AT: Reset the state during error
- https://gerrit.zephyrproject.org/r/11272 : Bluetooth: HFP HF: SCO: Handle SCO Disconnect
- https://gerrit.zephyrproject.org/r/11669 : Bluetooth: HFP HF: Support to send hf AT command
- https://gerrit.zephyrproject.org/r/11269 : Bluetooth: HFP HF: SCO: Accept eSCO conn request
- https://gerrit.zephyrproject.org/r/11271 : Bluetooth: HFP HF: SCO: Handle synchronous_conn_complete
- https://gerrit.zephyrproject.org/r/11972 : Bluetooth: HFP HF: SCO Initiate Audio connection
- https://gerrit.zephyrproject.org/r/10645 : Bluetooth: HFP HF: Handling AG Network error
- https://gerrit.zephyrproject.org/r/11396 : Bluetooth: HFP HF: Add support for RING indication cb
- https://gerrit.zephyrproject.org/r/11268 : Bluetooth: HFP HF: SCO: Add esco supported pkt type
- https://gerrit.zephyrproject.org/r/11229 : net: ipv6: Respond to MLD query
- https://gerrit.zephyrproject.org/r/11227 : net: ipv6: Add router alert option to MLD msg
- https://gerrit.zephyrproject.org/r/11228 : tests: net: Add unit tests for mld
- https://gerrit.zephyrproject.org/r/11224 : net: if: Leave all joined IPv6 multicast groups at net_if_down
- https://gerrit.zephyrproject.org/r/11866 : tests: net: Add MLD query tests
- https://gerrit.zephyrproject.org/r/11226 : net: if: Create support to flush the TX queue
- https://gerrit.zephyrproject.org/r/11222 : net: if: Join/leave pre-defined IPv6 multicast groups
- https://gerrit.zephyrproject.org/r/11221 : net: ipv6: Add support to join/leave multicast group
- https://gerrit.zephyrproject.org/r/11970 : tests: net: Check allnodes and solicit node addresses.
- https://gerrit.zephyrproject.org/r/11843 : net: todo: Mark multicast join/leave support done
- https://gerrit.zephyrproject.org/r/11915 : net: icmpv6: Add function to unregister ICMPv6 handler
- https://gerrit.zephyrproject.org/r/10806 : Bluetooth: AVDTP: Handling Discover response
- https://gerrit.zephyrproject.org/r/11223 : net: ipv6: Notify others if we join/leave IPv6 mcast group
- https://gerrit.zephyrproject.org/r/11225 : net: ipv6: Allow joining to existing multicast address
- https://gerrit.zephyrproject.org/r/11971 : net: iface: Print error if we cannot join mcast groups
- https://gerrit.zephyrproject.org/r/11842 : net: ipv6: Collect MLD statistics
- https://gerrit.zephyrproject.org/r/11732 : Bluetooth: SDP: Server: Send service search response
- https://gerrit.zephyrproject.org/r/11458 : Bluetooth: AVDTP: Add AVDTP GetCapabilities Function Definition
- https://gerrit.zephyrproject.org/r/11627 : WIP: Security guideline
- https://gerrit.zephyrproject.org/r/11172 : soc: defconfig: Enable WDT for ATMEL SAM MCUs
- https://gerrit.zephyrproject.org/r/10886 : errno.h: Changed errno.h to make it safe to be included in assembly files.
- https://gerrit.zephyrproject.org/r/10879 : sensor/mag3110: Add mag3110 three axis magnetometer driver.
- https://gerrit.zephyrproject.org/r/11029 : watchdog: Add WDT driver for Atmel SAM SoCs
- https://gerrit.zephyrproject.org/r/11478 : net/http: Add the HTTP/1.1 API
- https://gerrit.zephyrproject.org/r/11968 : xtensa: add xtensa-hal recipe
- https://gerrit.zephyrproject.org/r/11969 : tests: Improve readabilty of ztest output
- https://gerrit.zephyrproject.org/r/11946 : WIP: Bluetooth: Controller: Fix assert on role stop/abort
- https://gerrit.zephyrproject.org/r/11787 : timer: tickless: hpet: Add tickless kernel support
- https://gerrit.zephyrproject.org/r/11479 : samples: pwm: change hard-coded device name
- https://gerrit.zephyrproject.org/r/11332 : boards: arduino_101: enable GPIO by default
- https://gerrit.zephyrproject.org/r/11947 : sanitycheck: run legacy tests only on daily basis
- https://gerrit.zephyrproject.org/r/11263 : tests: add zephyr SPI driver api test case

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11995 : meta-zephyr-sdk:first yamllint pass
- https://gerrit.zephyrproject.org/r/11994 : zephyr: first yamllint pass
- https://gerrit.zephyrproject.org/r/11993 : ci-management: first yamllint pass
- https://gerrit.zephyrproject.org/r/11996 : Bluetooth: L2CAP: Add TX queueing for LE CoC
- https://gerrit.zephyrproject.org/r/11984 : samples/logger-hook: fix usage of ring buffer
- https://gerrit.zephyrproject.org/r/12006 : net/trickle: Include net_core.h in order to define NET_ASSERT
- https://gerrit.zephyrproject.org/r/12003 : Bluetooth: Controller: Run all enqueued mayfly before disable
- https://gerrit.zephyrproject.org/r/11999 : nrf_rtc_timer: clear events and counter when disabling sys_clock
- https://gerrit.zephyrproject.org/r/11987 : riscv32: fixed build warnings for obj_tracing
- https://gerrit.zephyrproject.org/r/11980 : drivers/ieee802154: Added RAW device to nRF5 radio driver
- https://gerrit.zephyrproject.org/r/11983 : samples: net: echo-server: Fix conditional around net_if_ipv4_addr_add()
- https://gerrit.zephyrproject.org/r/11982 : net: shell: Fix missing return when IPv6 disabled
- https://gerrit.zephyrproject.org/r/11981 : Update minion baseline to latest cross-project
- https://gerrit.zephyrproject.org/r/11941 : global: first yamllint pass
- https://gerrit.zephyrproject.org/r/11769 : build: Fix qemugdb target
- https://gerrit.zephyrproject.org/r/11977 : hci_usb: Add project configuration for tinyTile board.
- https://gerrit.zephyrproject.org/r/11976 : hci_usb: Fix incorrect length log
- https://gerrit.zephyrproject.org/r/11897 : quark_se: Fix Bluetooth settings for NBLE
- https://gerrit.zephyrproject.org/r/11805 : Bluetooth: L2CAP: Move functions in preparation for queuing
- https://gerrit.zephyrproject.org/r/11756 : nrf_rtc_timer: clear events and counter when disabling sys_clock
- https://gerrit.zephyrproject.org/r/11864 : arduino_101: fix default ROM size
- https://gerrit.zephyrproject.org/r/11852 : samples: grove: add missing testcase.ini
- https://gerrit.zephyrproject.org/r/11772 : xt-sim: set default stack size for IPM console receiver
- https://gerrit.zephyrproject.org/r/11771 : ipm_console: add Kconfig for receiver stack size


Re: Checking if code is compiled for Zephyr

Marcus Shawcroft <marcus.shawcroft@...>
 

On 7 March 2017 at 14:35, Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote:
Hello,

I'm trying to #ifdef a part of cross-platform code for Zephyr, and I
didn't find a clear, self-describing way to do so. Am I missing
something? Can we have something like __ZEPHYR__, _ZEPHYR of whatever
preprocessor macro to check for?
The toplevel Makefile hardwires:

-D__ZEPHYR__=1

I don't know if that symbol is documented somewhere, but it would be
nice if it was.


Cheers
/Marcus


Checking if code is compiled for Zephyr

Paul Sokolovsky
 

Hello,

I'm trying to #ifdef a part of cross-platform code for Zephyr, and I
didn't find a clear, self-describing way to do so. Am I missing
something? Can we have something like __ZEPHYR__, _ZEPHYR of whatever
preprocessor macro to check for?


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

5621 - 5640 of 8196