Date   

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


Re: [RFC] MPU support for debugging

Piotr Mienkowski
 


On 14.03.2017 20:08, Boie, Andrew P wrote:
On Tue, 2017-03-14 at 17:29 +0100, Piotr Mienkowski wrote:
I would like to add one more point to the discussion. It is maybe not directly
related to the topic but should likely be considered when designing MPU
support.

Occasionally, mainly in case of device drivers, on MCUs that have cache it is
required to use the so called non-cacheable RAM regions. A memory region for
which caching has been turned off. This task is typically done by MPU/MMU and
Zephyr MPU architecture should also support it. I.e. as a developer I would
like to have a possibility to place a specific variable / set of variables in
a non-cacheable RAM region.
This is a great topic to bring up. In addition to an MPU policy to protect
threads for debugging, we do need to specify a system-level policy that get
applied at boot, even if we are not protecting individual threads.

Are you thinking that this would be something declared at the SOC level? I think
because of the size and alignment constraints of MPU regions, we may want to
configure these reasons in a central area. You may be interested to look at
Vincenzo's patches, which define MPU regions for a few ARM SOCs at boot:

https://gerrit.zephyrproject.org/r/#/q/topic:zephyr_mpu
I was indeed thinking that non-cachable RAM region would be declared at the SoC level. It's simple and efficient. However, probably not compatible with per thread memory protection as a security feature model.

Thanks for the link. That looks interesting indeed, though to support non-cachable RAM region we would also need to modify the linker script. It would probably be best to do it at the same time or after we touch the linker script to add support for all the features we are talking about here.
Looking at this another way, maybe we need to consider different levels of
memory protection support, each building on top of the previous level. What
level any given board target supports will be determined by the available memory
protection hardware and its capabilities, as well as how much extra RAM we can
waste to accommodate the alignment constraints of the MPU hardware:

1) No memory protection

2) System-wide memory protection policy, set at boot by board or SOC code.

3) Per-thread stack overflow protection. We configure the MPU, on a per-thread
basis, to trigger an exception if the thread tries to write past its available
stack space. I think this should only require 1 extra region, just a sentinel
area immediately before the thread's stack to catch writes, with the struct
k_thread stored elsewhere. I think this is something simple we can do which will
make a lot of people happy given how painful stack overflows can be to debug if
you don't know they are happening.

4) Per-thread memory protection. User threads can only write to their own stack
+ additional runtime-configurable memory regions. System calls to interact with
the kernel, whose memory is otherwise untouchable. Basically what we have been
talking about so far.

5) Virtualized memory (MMU). Application and kernel run in different virtualized
memory spaces. Introduce the possibility of different isolated zephyr processes.
That all sounds very reasonable. Every next level of memory protection support builds upon the effort spent and experience gained at the previous one. The only danger with having multiple protection levels is that it may become opaque to the end user.

I have question to the per-thread memory protection model. Maybe the answer is obvious. What about data passed between threads, like data buffers passed through FIFOs? E.g. our networking stack supports zero copy mechanism. A pointer to the data buffer that was filled in by a data link layer driver (working typically in the interrupt context) is passed to the RX thread, user application thread, maybe TX thread. Are such data buffers going to live in a memory region that is accessible to all?

Regards,
Piotr


Re: about multicasting with IPv4

Jukka Rissanen
 

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


Re: Upgrade of RTC api.

Michał Kruszewski <mkru@...>
 

I have just realized that my previous idea with alarm descriptors has one drawback.

Lets suppose the counter value is 4. If rtc needs 2 ticks to start working and catch compare events (for example nordic RTC) then if we set an alarm on value 5 we will miss it.
In above example interrupt has to be triggered in rtc_set_alarm_function(). According to solution with alarm descriptors interrupt would be triggered before alarm_descriptor would be returned.
Instead alarm descriptor I propose to pass a pointer to alarm callback function to rtc_set_alarm function.
Here is git diff:

diff --git a/include/rtc.h b/include/rtc.h
index 40c24c5..6b68fca 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -50,6 +50,7 @@ enum clk_rtc_div {


struct rtc_config {
+       clk_rtc_div divider;
        uint32_t init_val;
        /*!< enable/disable alarm  */
        uint8_t alarm_enable;
@@ -60,12 +61,19 @@ struct rtc_config {
        void (*cb_fn)(struct device *dev);
};

+struct rtc_alarm {
+       uint32_t alarm_val;
+       /*!< Pointer to function to call when alarm value
+        * matches current RTC value */
+       void (*cb_fn)(struct device *dev);
+};
+
typedef void (*rtc_api_enable)(struct device *dev);
typedef void (*rtc_api_disable)(struct device *dev);
typedef int (*rtc_api_set_config)(struct device *dev,
                                  struct rtc_config *config);
typedef int (*rtc_api_set_alarm)(struct device *dev,
-                                const uint32_t alarm_val);
+                                const struct rtc_alarm *alarm_val);
typedef uint32_t (*rtc_api_read)(struct device *dev);
typedef uint32_t (*rtc_api_get_pending_int)(struct device *dev);

Michal Kruszewski


about multicasting with IPv4

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

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

 

 

 

 

 


Re: 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
> Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.

Current API already supports multiple instances of a given device
driver, so that's fine.

You are right, there is not need to change that

>> b) different number of compare/alarm registers

That is missing indeed. Or, more precisely, the only current way to
support this is to
have a struct device instance per set of compar/alarm on an rtc, which
is not what we want I guess.

>> 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
> We need to have a standard view of time regardless of how different RTCs encode this.
>
>> 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?
> I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.

You will need to revert the current way rtc is configured I believe.

The device driver would own as many struct rtc_config pointers as it has
of compare/alarm set of registers.

rtc_set_config() would, if a slot is free, install the given
configuration. If not it would get a -EAGAIN

It would require a rtc_remove_config() or rtc_unset_config(), to
un-install the given config pointer.

Just thinking out loud though, maybe there is a better way. The point is
to avoid application to know the number of alarms at built time.
I should be ready to deal with the impossibility to get a slot I think.

About software emulation on top of 1 unique counter/alarm set, sounds a
bit like what we have in kernel as timers.
Code could be generic for that.

Maybe mixing hw and emulation even, if struct rtc_config gets a
sys_dlist node? (bloats a bit the rtc_config struct though).
I mean: being directly installed on an available hw or being emulated,
would be transparent for the app. But it adds up complexity on driver side.

>
>> 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?
> We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.

Agree on that

>
>> 3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
> Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.

add a uint8_t type in struct rtc_config
After rethinking, this feature is also easy to implement in some higher level code. I think drivers should be simple and reproduce what is inside hardware.
There is no register or bit that can be changed in order to change mode to periodic, so do not implement it in driver, implement it higher.
>
>> 4. What about some extra events like TICK, OVERFLOW?
> This would be a counter feature, correct?

We do mix features in 2 distinct APIs for now.
Shall we move stuff into one unique timer.h API for instance?

Are there hw limitations though? isn't there rtc that can be only
counters? (then it would blow up the idea I guess).

You are right, I have come to realize that TICK and OVERFLOW features are not needed in zephyr. If someone needs it then he can embed it in application specific code.

>
>> 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?
> Not sure I follow. Maybe work up a draft API interface with some comments for further discussion

struct rtc_config pointer could be provided to the callback.

Being allocated by the application, it could then with CONTAINER_OF()
retrieve some private data, if the struct rtc_config is part of private
structure holding private data.


TO SUM UP:
I would like to RFC in rtc.h api to enable setting multiple alarms on single RTC. Here is git diff on rtc.h
diff --git a/include/rtc.h b/include/rtc.h
index 40c24c5..44beb3d 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -50,6 +50,7 @@ enum clk_rtc_div {


struct rtc_config {
+       enum clk_rtc_div divider;
        uint32_t init_val;
        /*!< enable/disable alarm  */
        uint8_t alarm_enable;
@@ -66,15 +67,17 @@ typedef int (*rtc_api_set_config)(struct device *dev,
                                  struct rtc_config *config);
typedef int (*rtc_api_set_alarm)(struct device *dev,
                                 const uint32_t alarm_val);
+typedef int (*rtc_api_get_alarm_descriptor)(struct device *dev);
typedef uint32_t (*rtc_api_read)(struct device *dev);
typedef uint32_t (*rtc_api_get_pending_int)(struct device *dev);

struct rtc_driver_api {
        rtc_api_enable enable;
        rtc_api_disable disable;
-       rtc_api_read read;
        rtc_api_set_config set_config;
        rtc_api_set_alarm set_alarm;
+       rtc_api_get_alarm_descriptor get_alarm_descriptor;
+       rtc_api_read read;
        rtc_api_get_pending_int get_pending_int;
};

@@ -116,6 +119,13 @@ static inline int rtc_set_alarm(struct device *dev,
        return api->set_alarm(dev, alarm_val);
}

+static inline int rtc_get_alarm_descriptor(struct device *dev)
+{
+       const struct rtc_driver_api *api = dev->driver_api;
+
+       return api->get_alarm_descriptor(dev);
+}

Here is an example on how this api could be used on chips where RTC can handle multiple alarms:
#define ALARM (RTC_ALARM_SECOND)
#define ALARM_2 (5*RTC_ALARM_SECOND)

/* Following variables are used by nrf chips, where single RTC can set multiple
* alarms. */
int ad_1; /* Alarm descriptor 1 */
int ad_2; /* Alarm descriptor 2 */

#if defined(CONFIG_QMSI)
void test_rtc_interrupt_fn(struct device *rtc_dev)
{};
#elif defined(CONFIG_SOC_FAMILY_NRF5)
void alarm_1_handler(struct device *rtc_dev)
{};

void alarm_2_handler(struct device *rtc_dev)
{};

void test_rtc_interrupt_fn(struct device *rtc_dev)
{
        int alarm_descriptor;
        alarm_descriptor = rtc_get_alarm_descriptor(rtc_dev);

        /* Check alarm descritor to determine which alarm hanlder should be
        * called. Valid only for RTC capable of handling multiple alarms */
        if (alarm_descriptor == ad_1) {
                alarm_1_handler(rtc_dev);
        } else if (alarm_descriptor == ad_2) {
                alarm_2_handler(rtc_dev);
        }
}
#endif

void main(void)
{
        struct rtc_config config;
        struct device *rtc_dev;

        printk("Test RTC driver\n");
        rtc_dev = device_get_binding(CONFIG_RTC_0_NAME);

        config.divider = RTC_CLK_DIV_1;
        config.init_val = 0;
        config.alarm_enable = 1;
        config.alarm_val = ALARM;
        config.cb_fn = test_rtc_interrupt_fn;

       rtc_enable(rtc_dev);

#if defined(CONFIG_QMSI)
        rtc_set_config(rtc_dev, &config);
#elif defined(CONFIG_SOC_FAMILY_NRF5)
        ad_1 = rtc_set_config(rtc_dev, &config);
        if (ad_1 == -EAGAIN) {
                printk("Can't configure RTC cause there is at least one alarm set\n");
        } else {
                printk("RTC configured and alarm descriptor returned if you have set alarm_enable field\n");
        }

        ad_2 = rtc_set_alarm(rtc_dev, ALARM_2);
        if (ad_2 == -ENOMEM) {
                printk("Can't set an alarm, no more resources for alarms\n");
        } else {
                printk("Alarm set, alarm descriptor returned\n");
        };
#endif

        while (1) {
        }
}

My change has no impact on devices where only one alarm can be set on RTC.

Michał Kruszewski

Sent with ProtonMail Secure Email.


Re: Upgrade of RTC api.

Tomasz Bursztyka
 

Hi, (quick resend for the thread owner)

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
Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.
Current API already supports multiple instances of a given device driver, so that's fine.

b) different number of compare/alarm registers
That is missing indeed. Or, more precisely, the only current way to support this is to
have a struct device instance per set of compar/alarm on an rtc, which is not what we want I guess.

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
We need to have a standard view of time regardless of how different RTCs encode this.

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?
I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.
You will need to revert the current way rtc is configured I believe.

The device driver would own as many struct rtc_config pointers as it has of compare/alarm set of registers.

rtc_set_config() would, if a slot is free, install the given configuration. If not it would get a -EAGAIN

It would require a rtc_remove_config() or rtc_unset_config(), to un-install the given config pointer.

Just thinking out loud though, maybe there is a better way. The point is to avoid application to know the number of alarms at built time.
I should be ready to deal with the impossibility to get a slot I think.

About software emulation on top of 1 unique counter/alarm set, sounds a bit like what we have in kernel as timers.
Code could be generic for that.

Maybe mixing hw and emulation even, if struct rtc_config gets a sys_dlist node? (bloats a bit the rtc_config struct though).
I mean: being directly installed on an available hw or being emulated, would be transparent for the app. But it adds up complexity on driver side.


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?
We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.
Agree on that


3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.
add a uint8_t type in struct rtc_config


4. What about some extra events like TICK, OVERFLOW?
This would be a counter feature, correct?
We do mix features in 2 distinct APIs for now.
Shall we move stuff into one unique timer.h API for instance?

Are there hw limitations though? isn't there rtc that can be only counters? (then it would blow up the idea I guess).


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?
Not sure I follow. Maybe work up a draft API interface with some comments for further discussion
struct rtc_config pointer could be provided to the callback.

Being allocated by the application, it could then with CONTAINER_OF() retrieve some private data, if the struct rtc_config is part of private structure holding private data.

Tomasz


Daily digests...

Marcus Shawcroft <marcus.shawcroft@...>
 

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


Re: Upgrade of RTC api.

Tomasz Bursztyka
 

Hi,

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
Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.
Current API already supports multiple instances of a given device driver, so that's fine.

b) different number of compare/alarm registers
That is missing indeed. Or, more precisely, the only current way to support this is to
have a struct device instance per set of compar/alarm on an rtc, which is not what we want I guess.

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
We need to have a standard view of time regardless of how different RTCs encode this.

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?
I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.
You will need to revert the current way rtc is configured I believe.

The device driver would own as many struct rtc_config pointers as it has of compare/alarm set of registers.

rtc_set_config() would, if a slot is free, install the given configuration. If not it would get a -EAGAIN

It would require a rtc_remove_config() or rtc_unset_config(), to un-install the given config pointer.

Just thinking out loud though, maybe there is a better way. The point is to avoid application to know the number of alarms at built time.
I should be ready to deal with the impossibility to get a slot I think.

About software emulation on top of 1 unique counter/alarm set, sounds a bit like what we have in kernel as timers.
Code could be generic for that.

Maybe mixing hw and emulation even, if struct rtc_config gets a sys_dlist node? (bloats a bit the rtc_config struct though).
I mean: being directly installed on an available hw or being emulated, would be transparent for the app. But it adds up complexity on driver side.


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?
We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.
Agree on that


3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.
add a uint8_t type in struct rtc_config


4. What about some extra events like TICK, OVERFLOW?
This would be a counter feature, correct?
We do mix features in 2 distinct APIs for now.
Shall we move stuff into one unique timer.h API for instance?

Are there hw limitations though? isn't there rtc that can be only counters? (then it would blow up the idea I guess).


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?
Not sure I follow. Maybe work up a draft API interface with some comments for further discussion
struct rtc_config pointer could be provided to the callback.

Being allocated by the application, it could then with CONTAINER_OF() retrieve some private data, if the struct rtc_config is part of private structure holding private data.

Tomasz


Re: Testing random number generators

Daniel Thompson <daniel.thompson@...>
 

On 15/03/17 13:37, Kumar Gala wrote:
On Mar 13, 2017, at 11:10 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@smile.fr> wrote:

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,
Seems like a pretty worth while thing to work on. We have some
support for a few random number generators in the tree already
(drivers/random). So I think a test app as you described shouldn’t
be too difficult to work up and writeup how to connect with ENT.
Would be a great idea. Especially useful to bring to the surface RNGs that have been interfaced to the system without a whitening filter...


Daniel.


Re: Testing random number generators

Kumar Gala
 

On Mar 13, 2017, at 11:10 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@smile.fr> wrote:

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,
Seems like a pretty worth while thing to work on. We have some support for a few random number generators in the tree already (drivers/random). So I think a test app as you described shouldn’t be too difficult to work up and writeup how to connect with ENT.

- k


Re: Upgrade of RTC api.

Kumar Gala
 

On Mar 9, 2017, at 2:35 PM, Michał Kruszewski via Zephyr-devel <zephyr-devel@lists.zephyrproject.org> wrote:

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
Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.

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
We need to have a standard view of time regardless of how different RTCs encode this.

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?
I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.

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?
We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.

3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.

4. What about some extra events like TICK, OVERFLOW?
This would be a counter feature, correct?

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?
Not sure I follow. Maybe work up a draft API interface with some comments for further discussion

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
Sorry for delay in response, a lot of developers where at Linaro Connect last week and some at Embedded World this week.

- k


Re: Reg: Command handling Via USB driver

Marti Bolivar <marti.bolivar@...>
 

On 15 March 2017 at 04:52, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
Hi,

On Tue, Mar 14, 2017 at 09:02:55AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

Thanks for the reply But as of now with the available zephyr, the USB
can work either as DFU flashing or as UART over USB (CDC) and not both
functionalities together.

We have a requirement at End of Line, we need to pass commands from a
PC to test each interfaces. And finally we need to flash the
functional software to the device via DFU flashing.

So only I have a doubt that can we use USB DFU class and expand the
driver to handle some more custom commands other than DFU commands to
satisfy my requirement.

Please suggest !!
You can combine those descriptors together to have multifunction device.
http://www.beyondlogic.org/usbnutshell/usb5.shtml
(I have not tried it myself)
IIRC, last time I tried this (5 or so years ago), composite devices
required custom drivers on Windows. That may not work for a factory
line test environment; these tend to involve very locked down PCs that
don't even allow custom unprivileged executables, much less device
drivers. The situation may have gotten better since then.

Marti


Best regards
Andrei Emeltchenko


Thanks
Mahendra

-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: Thursday, March 09, 2017 1:47 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Reg: Command handling Via USB driver

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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Odp.: Graphics and Zephyr

Daniel Thompson <daniel.thompson@...>
 

On 15/03/17 09:53, Bober, Wojciech wrote:
Hi Bill,


I'm not sure if ugfx has been ported to Zephyr but you can check it
anyway. I've heard good things about it.

https://ugfx.io/
Interesting product indeed but beware of the "100% open" on the front page. ugfx is not open source... merely "open".


Daniel.



------------------------------------------------------------------------
*Od:* zephyr-devel-bounces@lists.zephyrproject.org
<zephyr-devel-bounces@lists.zephyrproject.org> w imieniu użytkownika
Bill Rees <bill@zglue.com>
*Wysłane:* 14 marca 2017 00:15:35
*Do:* zephyr-devel@lists.zephyrproject.org
*Temat:* [Zephyr-devel] Graphics and Zephyr


I'm looking around for RTOSs that support graphics and while I don't
see any references to graphics support in Jira or schedules I'm hoping
someone knows of a 3rd party library that would work?

Thanks,
Bill Rees

--
___________________________________________
: +1 (650) 533-4054 <tel:(650)%20533-4054>
: zGlue Inc., Mountain View, CA
___________________________________________


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


Odp.: Graphics and Zephyr

Bober, Wojciech <Wojciech.Bober@...>
 

Hi Bill,


I'm not sure if ugfx has been ported to Zephyr but you can check it anyway. I've heard good things about it.


https://ugfx.io/


Od: zephyr-devel-bounces@... <zephyr-devel-bounces@...> w imieniu użytkownika Bill Rees <bill@...>
Wysłane: 14 marca 2017 00:15:35
Do: zephyr-devel@...
Temat: [Zephyr-devel] Graphics and Zephyr
 

    I'm looking around for RTOSs that support graphics and while I don't see any references to graphics support in Jira or schedules I'm hoping someone knows of a 3rd party library that would work?

Thanks,
Bill Rees

--

___________________________________________
 : zGlue Inc., Mountain View, CA
___________________________________________



Re: Reg: Command handling Via USB driver

Andrei
 

Hi,

On Tue, Mar 14, 2017 at 09:02:55AM +0000, Mahendravarman Rajarao (RBEI/EAA10) wrote:
Hi

Thanks for the reply But as of now with the available zephyr, the USB
can work either as DFU flashing or as UART over USB (CDC) and not both
functionalities together.

We have a requirement at End of Line, we need to pass commands from a
PC to test each interfaces. And finally we need to flash the
functional software to the device via DFU flashing.

So only I have a doubt that can we use USB DFU class and expand the
driver to handle some more custom commands other than DFU commands to
satisfy my requirement.

Please suggest !!
You can combine those descriptors together to have multifunction device.
http://www.beyondlogic.org/usbnutshell/usb5.shtml
(I have not tried it myself)

Best regards
Andrei Emeltchenko


Thanks
Mahendra

-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: Thursday, March 09, 2017 1:47 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@in.bosch.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Reg: Command handling Via USB driver

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


Re: [RFC] MPU support for debugging

Boie, Andrew P
 

On Tue, 2017-03-14 at 17:29 +0100, Piotr Mienkowski wrote:
I would like to add one more point to the discussion. It is maybe not directly
related to the topic but should likely be considered when designing MPU
support.

Occasionally, mainly in case of device drivers, on MCUs that have cache it is
required to use the so called non-cacheable RAM regions. A memory region for
which caching has been turned off. This task is typically done by MPU/MMU and
Zephyr MPU architecture should also support it. I.e. as a developer I would
like to have a possibility to place a specific variable / set of variables in
a non-cacheable RAM region.
This is a great topic to bring up. In addition to an MPU policy to protect
threads for debugging, we do need to specify a system-level policy that get
applied at boot, even if we are not protecting individual threads.

Are you thinking that this would be something declared at the SOC level? I think
because of the size and alignment constraints of MPU regions, we may want to
configure these reasons in a central area. You may be interested to look at
Vincenzo's patches, which define MPU regions for a few ARM SOCs at boot:

https://gerrit.zephyrproject.org/r/#/q/topic:zephyr_mpu

This brings up another thing we need to consider: for thread-level debugging,
what is the minimum number of free MPU regions necessary to make it work?

For example, on an ARM Cortex-M, AFAIK you can only configure 8 MPU regions
total, each of which must be aligned to a multiple of their size. If 5 or 6 of
them are already used for system-wide MPU policy, it may be not be feasible to
introduce all the thread-level protection ideas that have been discussed so far.

Looking at this another way, maybe we need to consider different levels of
memory protection support, each building on top of the previous level. What
level any given board target supports will be determined by the available memory
protection hardware and its capabilities, as well as how much extra RAM we can
waste to accommodate the alignment constraints of the MPU hardware:

1) No memory protection

2) System-wide memory protection policy, set at boot by board or SOC code.

3) Per-thread stack overflow protection. We configure the MPU, on a per-thread
basis, to trigger an exception if the thread tries to write past its available
stack space. I think this should only require 1 extra region, just a sentinel
area immediately before the thread's stack to catch writes, with the struct
k_thread stored elsewhere. I think this is something simple we can do which will
make a lot of people happy given how painful stack overflows can be to debug if
you don't know they are happening.

4) Per-thread memory protection. User threads can only write to their own stack
+ additional runtime-configurable memory regions. System calls to interact with
the kernel, whose memory is otherwise untouchable. Basically what we have been
talking about so far.

5) Virtualized memory (MMU). Application and kernel run in different virtualized
memory spaces. Introduce the possibility of different isolated zephyr processes.

We may never need or want to get as far as #5, although I think whatever design
we come up with ought to leave the door open for it.

Andrew


Re: [RFC] MPU support for debugging

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Mar 14, 2017 at 05:29:57PM +0100, Piotr Mienkowski wrote:
I would like to add one more point to the discussion. It is maybe not
directly related to the topic but should likely be considered when
designing MPU support.

Occasionally, mainly in case of device drivers, on MCUs that have cache
it is required to use the so called non-cacheable RAM regions. A memory
region for which caching has been turned off. This task is typically
done by MPU/MMU and Zephyr MPU architecture should also support it. I.e.
as a developer I would like to have a possibility to place a specific
variable / set of variables in a non-cacheable RAM region.

Following is one real life example when using non-cacheable RAM region
is necessary (for the interested):
Atmel SAM Ethernet module, like most other Ethernet modules, is using
scatter-gather technique to exchange data with the Ethernet driver. To
communicate the location of the data buffers the driver sets-up a so
called descriptor list. This is effectively a place in RAM containing a
sequence of 32-bit words representing buffer location and its status. If
cache is enabled every time the device driver updates data in the
descriptor list it should theoretically also call cache clean operation.
This would ensure that the data is written to RAM where it can be read
by the hardware module. Unfortunately, at the same time the device
driver is modifying one location in the descriptor list the hardware
module can be modifying one next to it. Since cache clean operation
works on a full cache line - 8 bytes in case of Atmel device - it would
overwrite any such modifications done by the hardware module. As such,
ensuring cache coherency using standard techniques is not possible here.
One workaround would be to force write-through cache policy but this is
really just a workaround.
Yet another example that shows the importance of laying out early what
the different MPU regions will be used for, as stated in the top comment
in my original reply to the RFC.


Re: [RFC] MPU support for debugging

Boie, Andrew P
 

On Tue, Mar 14, 2017 at 09:01:53AM +0000, Jon Medhurst (Tixy) wrote:
On Mon, 2017-03-13 at 23:08 +0000, Boie, Andrew P wrote:
Thanks for your feedback, I'm going to spend some more time thinking
about this, but now I'm leaning towards a full userspace solution
(with MPU as a special case with physical=virtual addresses) with a
supplemental API for userspace applications that handles descriptor
management and kernel object allocation.
And validation of all the arguments passed into each function call. No
point going to all this trouble if userspace code can pass in dodgy
pointers or lengths etc. to the kernel.
Agreed, but I think this can be made optional if the application is trusted and
user-space is used more as a debugging aid. Although, that's Yet Another
Kconfig configuration to verify.
I had planned on checking user pointers unconditionally, I think it's a common programming mistake. When running in supervisor mode on behalf of a user thread, we should make sure any buffers passed in are actually owned and writable by the caller.

Andrew

5441 - 5460 of 8046