Date   

Re: Passing information from bootloader to Zephyr

Erwan Gouriou
 



On 24 July 2017 at 18:03, Daniel Thompson <daniel.thompson@...> wrote:
On 24/07/17 16:47, Marti Bolivar wrote:
    It's likely future work, but it seems inevitable we'll have to
    define exactly the state of the device that mcuboot provides to the
    chainloaded image. Having a place to put formal definitions will
    simplify this work.


I especially want to highlight this part: ^^

Erwan, I noticed while looking at a recent PR [1] that the STM32 UARTs have a status = "disabled" property in DTS (not introduced in this change, was already there).

But in fact, when Zephyr is chain-loaded by mcuboot, at least one of the UARTs is not disabled, since mcuboot uses it to log and doesn't disable it before jumping to the next image. Further the clocks are reconfigured from their reset defaults, the PLL is on, etc.

It seems like this will inevitably cause problems as the Zephyr DTS continues to get more sophisticated (not just for STM32).

Am I missing something here?

The enabled property doesn't describe whether the peripheral is active or not at bootloader handover. It is more like whether that peripheral is connected to something useful. DT describes the hardware, including the board, so if a UART is not pinned out somewhere in the board design it should not be enabled in the DT.
And if connected to HW, should it be enabled and clocked?
Linux uses mix of Kconfig/dt. Kconfig for compilation/dt for activation. Do we want the same in Zephyr and keep these 2 levels of configuration?
Another option would be to add a property in device tree to declare activation at boot.
Andy.G you may already have thought about this?
Sorry if I have gone off topic.


Also, are you reviewing the SoC DT include file or the board description?

The patch you linked to seems to be mostly SoC include files. It is normal for all peripherals to be disabled in SoC include files. It is only when the pinout for the board is decided that we know what peripherals should actually be enabled (and what pinmux settings to use for them).


Daniel.




Thanks,
Marti

[1] https://github.com/zephyrproject-rtos/zephyr/pull/888



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




incoming build dependency on Python elftools

Boie, Andrew P
 

Some changes are coming in to convert host build tools like gen_idt and gen_offset_header to Python, as well as some new tools to support memory protection which involve parsing DWARF information in the built ELF binaries.

 

To support this change, we will additionally require the Python 3 build of the pyelftools package, version 0.24 or later. You will need to install this on your development workstation. Please note that some Linux distristributions are out-of-date on this package, including the current version of Fedora and Ubuntu 16.04 and earlier. Because of this we recommend installing this via 'pip'. The documentation will be updated when the patches land, but in brief:

 

  pip3 install --user pyelftools

 

You may need to install the Python 3 version of pip, the package name on both Ubuntu and Fedora is 'python3-pip'.

 

Andrew


Re: Passing information from bootloader to Zephyr

Marti Bolivar <marti.bolivar@...>
 



On 24 July 2017 at 12:03, Daniel Thompson <daniel.thompson@...> wrote:
On 24/07/17 16:47, Marti Bolivar wrote:
    It's likely future work, but it seems inevitable we'll have to
    define exactly the state of the device that mcuboot provides to the
    chainloaded image. Having a place to put formal definitions will
    simplify this work.


I especially want to highlight this part: ^^

Erwan, I noticed while looking at a recent PR [1] that the STM32 UARTs have a status = "disabled" property in DTS (not introduced in this change, was already there).

But in fact, when Zephyr is chain-loaded by mcuboot, at least one of the UARTs is not disabled, since mcuboot uses it to log and doesn't disable it before jumping to the next image. Further the clocks are reconfigured from their reset defaults, the PLL is on, etc.

It seems like this will inevitably cause problems as the Zephyr DTS continues to get more sophisticated (not just for STM32).

Am I missing something here?

The enabled property doesn't describe whether the peripheral is active or not at bootloader handover. It is more like whether that peripheral is connected to something useful. DT describes the hardware, including the board, so if a UART is not pinned out somewhere in the board design it should not be enabled in the DT.

Also, are you reviewing the SoC DT include file or the board description?

The patch you linked to seems to be mostly SoC include files. It is normal for all peripherals to be disabled in SoC include files. It is only when the pinout for the board is decided that we know what peripherals should actually be enabled (and what pinmux settings to use for them).

OK, so it sounds like these DT changes aren't expressing expectations about the state of the peripheral.

But based on David's response, it does seem like it matters to Zephyr what state the peripherals are in when the bootloader hands over control, and that's not currently managed as it should be.

Should we just let this sit until it causes concrete problems? Any ideas from the Zephyr devs on how they'd like to see this managed (noting that this thread is cross-posted to dev-mcuboot)?

Thanks,
Marti
 



Daniel.




Thanks,
Marti

[1] https://github.com/zephyrproject-rtos/zephyr/pull/888



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




Re: Passing information from bootloader to Zephyr

Daniel Thompson <daniel.thompson@...>
 

On 24/07/17 16:47, Marti Bolivar wrote:
It's likely future work, but it seems inevitable we'll have to
define exactly the state of the device that mcuboot provides to the
chainloaded image. Having a place to put formal definitions will
simplify this work.
I especially want to highlight this part: ^^
Erwan, I noticed while looking at a recent PR [1] that the STM32 UARTs have a status = "disabled" property in DTS (not introduced in this change, was already there).
But in fact, when Zephyr is chain-loaded by mcuboot, at least one of the UARTs is not disabled, since mcuboot uses it to log and doesn't disable it before jumping to the next image. Further the clocks are reconfigured from their reset defaults, the PLL is on, etc.
It seems like this will inevitably cause problems as the Zephyr DTS continues to get more sophisticated (not just for STM32).
Am I missing something here?
The enabled property doesn't describe whether the peripheral is active or not at bootloader handover. It is more like whether that peripheral is connected to something useful. DT describes the hardware, including the board, so if a UART is not pinned out somewhere in the board design it should not be enabled in the DT.

Also, are you reviewing the SoC DT include file or the board description?

The patch you linked to seems to be mostly SoC include files. It is normal for all peripherals to be disabled in SoC include files. It is only when the pinout for the board is decided that we know what peripherals should actually be enabled (and what pinmux settings to use for them).


Daniel.



Thanks,
Marti
[1] https://github.com/zephyrproject-rtos/zephyr/pull/888
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Passing information from bootloader to Zephyr

David Brown
 

On Mon, Jul 24, 2017 at 11:47:47AM -0400, Marti Bolivar wrote:
It's likely future work, but it seems inevitable we'll have to define
exactly the state of the device that mcuboot provides to the chainloaded
image. Having a place to put formal definitions will simplify this work.

I especially want to highlight this part: ^^

Erwan, I noticed while looking at a recent PR [1] that the STM32 UARTs have a 
status = "disabled" property in DTS (not introduced in this change, was already
there).

But in fact, when Zephyr is chain-loaded by mcuboot, at least one of the UARTs
is not disabled, since mcuboot uses it to log and doesn't disable it before
jumping to the next image. Further the clocks are reconfigured from their reset
defaults, the PLL is on, etc.

It seems like this will inevitably cause problems as the Zephyr DTS continues
to get more sophisticated (not just for STM32).

Am I missing something here?
I don't think so. Part of the definition of the bootloader needs to
be to describe what state it leaves things in. For most
compatibility, it would seem best to leave things in as close to reset
state as possible. Ideally, that would shut down any clocks, etc.

Unfortunately, when booting apps that do use the serial port, turning
off the clock like this will usually result in gibberish coming over
the serial port. This probably doesn't hurt much, but can be
annoying.

The Mynewt approach has been to not use the serial port in the
bootloader. We could consider the uart use to be a debugging feature,
and recommend it be turned off for production.

Otherwise, we would want to add code to disable any clocks that were
started. I'm not sure there is an easy way to do this in the mcuboot
code without introducing target-specific code.

David


Re: Passing information from bootloader to Zephyr

Marti Bolivar <marti.bolivar@...>
 

Hi,

David's threads didn't get much response, but while looking at some STM32 rework in Zephyr, I thought it was worth another try.

On 28 June 2017 at 13:29, Marti Bolivar <marti.bolivar@...> wrote:


In general I also think that we need to start thinking about other issues related to passing control from mcuboot to Zephyr. Beyond just setting up the stack and jumping to the entry point, mcuboot on Zephyr also locks IRQs and disables the system clock. However, those aren't the only hardware resources it uses, and it isn't always "clean" about putting them back into their reset state.

For example, Zephyr mcuboot currently leaves the STM32 clock tree configured to use the PLL, it leaves devices powered on, clocked, and configured (e.g. UART), etc. The story is similar on other targets.

Leaving this vaguely defined is undesirable, especially for power management.

It's likely future work, but it seems inevitable we'll have to define exactly the state of the device that mcuboot provides to the chainloaded image. Having a place to put formal definitions will simplify this work.

I especially want to highlight this part: ^^

Erwan, I noticed while looking at a recent PR [1] that the STM32 UARTs have a status = "disabled" property in DTS (not introduced in this change, was already there).

But in fact, when Zephyr is chain-loaded by mcuboot, at least one of the UARTs is not disabled, since mcuboot uses it to log and doesn't disable it before jumping to the next image. Further the clocks are reconfigured from their reset defaults, the PLL is on, etc.

It seems like this will inevitably cause problems as the Zephyr DTS continues to get more sophisticated (not just for STM32).

Am I missing something here?

Thanks,
Marti


 


Re: STM32F0 nucleo board support.

Neil Armstrong
 

On 07/18/2017 08:48 AM, b0661 wrote:
Hello Maciej,

I'm interested in STM32F091x support and would like to contribute.
Do you have a git repository to clone (and coordinate) the basic work on STM32F0x?

Bobby



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

I'll be happy to follow your work on F0, I'll like to target the F051 from the F0x1 family.

Thanks,
Neil


Regarding 4G(LTE) Networking Support

Sunjie.Wu
 

Dear All,

I am currently working on a 4G(LTE) Networking task, Then I turned to zephyr to try to set it as a beginning. The Internet articles told me it supports 3GPP protocols but I didn't find anything in the source code.

I want to confirm that whether there is some support for 4G Modules in zephyr or is there any plan to support it?

If someone can provide any information, it would be very helpful to me, Thanks

Best Regards,

Sunjie Wu


Regarding 4G(LTE) Networking Support

Sunjie Wu <wusunjie@...>
 

Dear All,

I am currently working on a 4G(LTE) Networking task, Then I turned to zephyr to try to set it as a beginning. The Internet articles told me it supports 3GPP protocols but I didn't find anything in the source code.

I want to confirm that whether there is some support for 4G Modules in zephyr or is there any plan to support it?

If someone can provide any information, it would be very helpful to me, Thanks

Best Regards,

Sunjie Wu


Re: Development Environment Setup on Linux— Zephyr Project Documentation

luobaidunpaigu@sina.com <luobaidunpaigu@...>
 

Dear all,

I installed the SDK on Ubuntu 16.04 64bit system today, it's OK.
So, I guess there is something wrong in the installing script of "zephyr-sdk-0.9.1-setup.run"
Or the tools(x86, arm, arc....) were built for 64 bit systems.


luobaidunpaigu@...

 
Date: 2017-07-22 00:24
Subject: Re: [Zephyr-devel] Development Environment Setup on Linux— Zephyr Project Documentation
 
Hello,
 
On Fri, 21 Jul 2017 08:31:54 -0600
David Brown <david.brown@...> wrote:
 
> The SDK is indeed built for 64 bit systems. It could be built for a
> 32-bit host, although I don't think there has been that much demand
> for it.
 
I recently hit a case when I needed to run Zephyr SDK on 32-bit system
and of course, it was a rather unpleasant surprise to remember that I
can't. I ended up installing 64-bit kernel and corresponding multilib
support, to be able to run existing 32-bit userspace, but also the SDK.
I googled up how to do that, I believe it was some Stack Exchange site,
likely https://askubuntu.com/ .
 
So, it was good luck that such opportunity exists at all and I could
use it. But for all other cases, I'd personally vote to turn SDK back
to 32 bit, as the most compatible one.
 
 
>
> David
>
> On Fri, Jul 21, 2017 at 6:09 AM, luobaidunpaigu@... <
> luobaidunpaigu@...> wrote: 
>
> > Dear All
> >
> > I got a trouble when installing zephyr SDK on Ubuntu 16.04.2
> > desktop i386 (32 bit)
> > I followed the instructions exactly on page https://www.
> > zephyrproject.org/doc/getting_started/installation_linux.html
> > The Requirements and Dependencies are installed correctly.
> > The message is:
> > ------------------------------------------------------------
> > -----------------------------------------------
> > peng@ubuntu:~/work$ sudo ./zephyr-sdk-0.9.1-setup.run
> > Verifying archive integrity... All good.
> > Uncompressing SDK for Zephyr  100%
> > Enter target directory for SDK (default: /opt/zephyr-sdk/):
> > Installing SDK to /opt/zephyr-sdk
> >  [*] Installing x86 tools...
> >  [*] Installing arm tools...
> >  [*] Installing arc tools...
> >  [*] Installing iamcu tools...
> >  [*] Installing nios2 tools...
> >  [*] Installing xtensa tools...
> >  [*] Installing riscv32 tools...
> >  [*] Installing additional host tools...
> > rm: cannot remove 'environment-setup*': No such file or directory
> > mv: cannot stat 'version-*': No such file or directory
> > Success installing SDK. SDK is ready to be used.
> > ------------------------------------------------------------
> > --------------------------------------------
> > I checked the default folder.  Only
> >
> > info-zephyr-sdk-0.9.1(empty folder)
> > sdk_version
> >
> > existed there.
> >
> > Is there anyone can help me. Is this SDK only for 64bit system?
> >
> > ------------------------------
> > luobaidunpaigu@...
> >
> > _______________________________________________
> > Zephyr-devel mailing list
> > Zephyr-devel@...
> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
> >
> > 
 
 
 
--
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
 
 


RFC: LwM2M subsystem + sample client for Zephyr

Michael Scott <michael.scott@...>
 

Hi all,

I'm currently working on a pull request to introduce a Lightweight Machine-to-Machine (LwM2M) library to Zephyr. If you are interested, please see:
https://github.com/zephyrproject-rtos/zephyr/pull/712

You can pull the Zephyr branch that this PR is based on from:
https://github.com/mike-scott/zephyr/tree/lwm2m-new
(NOTE: this branch will get force pushed as further revisions happen to the PR)

Brief instructions for testing:

The sample for LWM2M can be run via QEMU by following the instructions here:
https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/networking/qemu_setup.rst

To start with you will want to use Leshan LWM2M demo server:
[terminal window #1]
$ wget https://hudson.eclipse.org/leshan/job/leshan/lastSuccessfulBuild/artifact/leshan-server-demo.jar
$ java -jar ./leshan-server-demo.jar
(You can now open a web browser to http://localhost:8080/ to watch connections)

Next, checkout https://github.com/zephyrproject-rtos/net-tools and follow the build instructions referenced above. After they are built, start up the slip tools:
[terminal window #2]
$ ./loop-socat.sh

[terminal window #3]
$ sudo ./loop-slip-tap.sh

Now you can cd to your checkout of Zephyr (with LwM2M) and build the sample for QEMU target:
[terminal window #4]
$ export ZEPHYR_SDK_INSTALL_DIR=<path to Zephyr SDK>
$ export ZEPHYR_GCC_VARIANT=zephyr
$ . zephyr-env.sh
$ make -C samples/net/lwm2m_client qemu

You should see the sample app connect to Leshan and register twice (IPv4 connection and IPv6 connection). Feel free to navigate around Leshan and play with the QEMU LWM2M client.

I look forward to your comments and if you get a chance please take a look at the PR: https://github.com/zephyrproject-rtos/zephyr/pull/712

- Mike


Re: Development Environment Setup on Linux — Zephyr Project Documentation

Paul Sokolovsky
 

Hello,

On Fri, 21 Jul 2017 08:31:54 -0600
David Brown <david.brown@...> wrote:

The SDK is indeed built for 64 bit systems. It could be built for a
32-bit host, although I don't think there has been that much demand
for it.
I recently hit a case when I needed to run Zephyr SDK on 32-bit system
and of course, it was a rather unpleasant surprise to remember that I
can't. I ended up installing 64-bit kernel and corresponding multilib
support, to be able to run existing 32-bit userspace, but also the SDK.
I googled up how to do that, I believe it was some Stack Exchange site,
likely https://askubuntu.com/ .

So, it was good luck that such opportunity exists at all and I could
use it. But for all other cases, I'd personally vote to turn SDK back
to 32 bit, as the most compatible one.



David

On Fri, Jul 21, 2017 at 6:09 AM, luobaidunpaigu@... <
luobaidunpaigu@...> wrote:

Dear All

I got a trouble when installing zephyr SDK on Ubuntu 16.04.2
desktop i386 (32 bit)
I followed the instructions exactly on page https://www.
zephyrproject.org/doc/getting_started/installation_linux.html
The Requirements and Dependencies are installed correctly.
The message is:
------------------------------------------------------------
-----------------------------------------------
peng@ubuntu:~/work$ sudo ./zephyr-sdk-0.9.1-setup.run
Verifying archive integrity... All good.
Uncompressing SDK for Zephyr 100%
Enter target directory for SDK (default: /opt/zephyr-sdk/):
Installing SDK to /opt/zephyr-sdk
[*] Installing x86 tools...
[*] Installing arm tools...
[*] Installing arc tools...
[*] Installing iamcu tools...
[*] Installing nios2 tools...
[*] Installing xtensa tools...
[*] Installing riscv32 tools...
[*] Installing additional host tools...
rm: cannot remove 'environment-setup*': No such file or directory
mv: cannot stat 'version-*': No such file or directory
Success installing SDK. SDK is ready to be used.
------------------------------------------------------------
--------------------------------------------
I checked the default folder. Only

info-zephyr-sdk-0.9.1(empty folder)
sdk_version

existed there.

Is there anyone can help me. Is this SDK only for 64bit system?

------------------------------
luobaidunpaigu@...

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



--
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: Development Environment Setup on Linux — Zephyr Project Documentation

David Brown
 

The SDK is indeed built for 64 bit systems. It could be built for a 32-bit host, although I don't think there has been that much demand for it.

David

On Fri, Jul 21, 2017 at 6:09 AM, luobaidunpaigu@... <luobaidunpaigu@...> wrote:
Dear All

I got a trouble when installing zephyr SDK on Ubuntu 16.04.2 desktop i386  (32 bit)
The Requirements and Dependencies are installed correctly.
The message is:
----------------------------------------------------------------------------------------------------------- 
peng@ubuntu:~/work$ sudo ./zephyr-sdk-0.9.1-setup.run 
Verifying archive integrity... All good.
Uncompressing SDK for Zephyr  100%  
Enter target directory for SDK (default: /opt/zephyr-sdk/): 
Installing SDK to /opt/zephyr-sdk
 [*] Installing x86 tools... 
 [*] Installing arm tools... 
 [*] Installing arc tools... 
 [*] Installing iamcu tools... 
 [*] Installing nios2 tools... 
 [*] Installing xtensa tools..
 [*] Installing riscv32 tools... 
 [*] Installing additional host tools... 
rm: cannot remove 'environment-setup*': No such file or directory
mv: cannot stat 'version-*': No such file or directory
Success installing SDK. SDK is ready to be used.
--------------------------------------------------------------------------------------------------------
I checked the default folder.  Only 

info-zephyr-sdk-0.9.1(empty folder)
sdk_version

existed there.

Is there anyone can help me. Is this SDK only for 64bit system?



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



Development Environment Setup on Linux — Zephyr Project Documentation

luobaidunpaigu@sina.com <luobaidunpaigu@...>
 

Dear All

I got a trouble when installing zephyr SDK on Ubuntu 16.04.2 desktop i386  (32 bit)
The Requirements and Dependencies are installed correctly.
The message is:
----------------------------------------------------------------------------------------------------------- 
peng@ubuntu:~/work$ sudo ./zephyr-sdk-0.9.1-setup.run 
Verifying archive integrity... All good.
Uncompressing SDK for Zephyr  100%  
Enter target directory for SDK (default: /opt/zephyr-sdk/): 
Installing SDK to /opt/zephyr-sdk
 [*] Installing x86 tools... 
 [*] Installing arm tools... 
 [*] Installing arc tools... 
 [*] Installing iamcu tools... 
 [*] Installing nios2 tools... 
 [*] Installing xtensa tools... 
 [*] Installing riscv32 tools... 
 [*] Installing additional host tools... 
rm: cannot remove 'environment-setup*': No such file or directory
mv: cannot stat 'version-*': No such file or directory
Success installing SDK. SDK is ready to be used.
--------------------------------------------------------------------------------------------------------
I checked the default folder.  Only 

info-zephyr-sdk-0.9.1(empty folder)
sdk_version

existed there.

Is there anyone can help me. Is this SDK only for 64bit system?


luobaidunpaigu@...


Re: CAN drivers

Erwin Rol
 

On Wed, 2017-07-19 at 16:55 +0300, Jukka Rissanen wrote:
Hi Erwin,

On Wed, 2017-07-19 at 14:39 +0200, Erwin Rol wrote:
Hallo all,

I am working on a CAN driver for STM32F4 and am having a few
conceptual
problems. How to generalize the interface to hardware that can be
very
different. For example the hardware-msg-filtering, two selectable
receive FIFO's, the second CAN port shares hardware with the first
port,
etc. are rather unique to the STM32 hardware. Other CAN controllers
have other features.

This is not just a CAN-driver problem, a same problem is setting the
multicast-filters of Ethernet hardware, they also come in a lot of
different flavors.

So how do I offer a Zephyr application a generic CAN interface (or
device interface for that matter)? If I make is
lowest-common-denominator generic (for CAN just sending and receiving
CAN frames) a lot of advanced feature will be lost that might really
make a difference between a working and non-working application (for
example hardware filtering that prevents CPU/IRQ overload).
We could follow the same idea as IEEE 802.15.4 radio API is doing. So
each CAN hw driver would need to provide a set of function pointers to
do various CAN operations. See include/net/ieee802154_radio.h for
details.

For doing various management operations, we have the net_mgmt interface
that should be used. See include/net/net_mgmt.h for details.
OK I'll look into that to see how it fits my needs (and if it isn't to
much more work how it would fit other ppl's needs).

For application that wants to send/receive actual CAN data, do we need
to create a new API for that, or could we extend the current
net_context API to support CAN interfaces? So similar way as what Linux
is doing things with SocketCAN.
I am not sure if that is the right way to go for resource constraint
systems like Zephyr.

First CAN frames are really small, they have maximum 8 data bytes, 4 len
bits, 29 ID bits and some flag bits. So a CAN frame struct would be
something like;

struct can_frame {
u32 id;
u8 data[8];
u8 len_flags;
}

And even CAN-FD has only 64 data bytes, so still smaller than a useful
net_pkt buffer size (default 128 bytes I believe). So all stuff to chain
packets/frames is useless for CAN, and just causes memory overhead.

Secondly there can be a lot of frames per second, CAN is a broadcast
bus, and everybody receives everything (unless they have hardware to
filter out certain frames). And with 1Mbit/s you could have almost 10k
frames per second.

Keeping those two things in mind I would want to keep the handling
overhead as small as possible.

But the low level CAN driver is just one part, mostly there will be
something like CANopen (which isn't as open as the name suggests :/)
running on top of it. Maybe CANsockets can also be a layer on top of the
low level CAN driver? I have not yet looked at the net_pkt buffers in
detail, but maybe the CAN-frame buffer could just be the data part, and
so one could do a zero-copy transformation from a CAN-frame into a
network packet ?

- Erwin


Re: CAN drivers

Jukka Rissanen
 

Hi Erwin,

On Wed, 2017-07-19 at 14:39 +0200, Erwin Rol wrote:
Hallo all,

I am working on a CAN driver for STM32F4 and am having a few
conceptual
problems. How to generalize the interface to hardware that can be
very
different. For example the hardware-msg-filtering, two selectable
receive FIFO's, the second CAN port shares hardware with the first
port,
etc.  are rather unique to the STM32 hardware. Other CAN controllers
have other features. 

This is not just a CAN-driver problem, a same problem is setting the
multicast-filters of Ethernet hardware, they also come in a lot of
different flavors. 

So how do I offer a Zephyr application a generic CAN interface (or
device interface for that matter)? If I make is
lowest-common-denominator generic (for CAN just sending and receiving
CAN frames) a lot of advanced feature will be lost that might really
make a difference between a working and non-working application (for
example hardware filtering that prevents CPU/IRQ overload).
We could follow the same idea as IEEE 802.15.4 radio API is doing. So
each CAN hw driver would need to provide a set of function pointers to
do various CAN operations. See include/net/ieee802154_radio.h for
details.

For doing various management operations, we have the net_mgmt interface
that should be used. See include/net/net_mgmt.h for details.

For application that wants to send/receive actual CAN data, do we need
to create a new API for that, or could we extend the current
net_context API to support CAN interfaces? So similar way as what Linux
is doing things with SocketCAN.


If I make a load of stm32_can_set_filter functions every CAN
application
will be different and only run on just that stm32 hardware. 

If I make something like the linux-ioctl we will need some "registry"
to
manage those.

I am sure others have had these "problems" also, but I can't really
recognize a pattern in the Zephyr code to use as an example.

Guidance, hints, and comments are highly appreciated.  

- Erwin
 
Cheers,
Jukka


CAN drivers

Erwin Rol
 

Hallo all,

I am working on a CAN driver for STM32F4 and am having a few conceptual
problems. How to generalize the interface to hardware that can be very
different. For example the hardware-msg-filtering, two selectable
receive FIFO's, the second CAN port shares hardware with the first port,
etc. are rather unique to the STM32 hardware. Other CAN controllers
have other features.

This is not just a CAN-driver problem, a same problem is setting the
multicast-filters of Ethernet hardware, they also come in a lot of
different flavors.

So how do I offer a Zephyr application a generic CAN interface (or
device interface for that matter)? If I make is
lowest-common-denominator generic (for CAN just sending and receiving
CAN frames) a lot of advanced feature will be lost that might really
make a difference between a working and non-working application (for
example hardware filtering that prevents CPU/IRQ overload).

If I make a load of stm32_can_set_filter functions every CAN application
will be different and only run on just that stm32 hardware.

If I make something like the linux-ioctl we will need some "registry" to
manage those.

I am sure others have had these "problems" also, but I can't really
recognize a pattern in the Zephyr code to use as an example.

Guidance, hints, and comments are highly appreciated.

- Erwin


Disabling of the GitHub Issues Feature

Linkmeyer, Mark J <mark.j.linkmeyer@...>
 

The Zephyr Technical Steering Committee (TSC) has not yet made a decision on whether GitHub Issues will be eventually used for issue tracking instead of Jira.  Because of that the Issues feature of GitHub has been disabled for the Zephyr Project.  The TSC has stated, in a recent TSC meeting,  that Jira will continue to be used for issue tracking through the release of Zephyr 1.9.  No potential issue tracking tool change will impact the 1.9 release.  A TSC decision on whether to switch to GitHub Issues is pending.  Until then, please continue to use Jira for all issue tracking on the Zephyr project.
 
The following issues, which were recently found to have been created in GitHub Issues, have been moved to Jira:
 
GitHub Issue # 779
 
GitHub Issue # 758 --->
 
GitHub Issue # 752 --->
 
GitHub Issue # 729 --->
 
GitHub Issue # 652 --->
 
Please continue any discussions on these issues and all tracking of them to completion using Jira.  I did my best to copy-and-paste all content and comments into Jira.  If anything is missing or incorrect, please fix it.
 
If you have issues/concerns with the use of Jira, please submit your specific issues to the Zephyr Process Working Group using the Process WG’s mailing list (process@...).  Or, even better yet, use Jira to submit bugs against the process.  The Process WG actively monitors Jira for any bugs submitted against Zephyr processes (and this includes tools used to facilitate the process, like Jira).  Simply create a bug in Jira, describe the issue you encounter, and be sure to set the Component/s field to ‘Process’.  It will then be driven to closure by the Process WG members.
 
Thanks,
Mark
 
Mark Linkmeyer
Intel Corporation
Open Source Technology Centerà Zephyr™ Software Project Manager
 
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or attorney-client privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message.
 
 
 


Re: What happened to github issue tracker?

Paul Sokolovsky
 

Hello Andrew,

On Tue, 18 Jul 2017 16:04:01 +0000
"Boie, Andrew P" <andrew.p.boie@...> wrote:

Why were bugs being filed on Github instead of JIRA?
It would be interesting to ask someone who posted a first bug on Github
why they did that. But I'd imagine the answer would be "The project is
on github, bug tracker is on github, where else should I post bugs???"

I can explain why I gave up and started to submit bugs on Github too,
like other people did - because it's awfully practical, can be
done quickly, allows to xref other bugs/pullreqs/commits, etc.

Having two simultaneous bug tracking systems in use seems insane to
me.
I guess we can always switch to github tracker ahead of schedule.


But the question is why Github tracker, containing important
information (down-to-earth, daily bugs vs mostly "something for
[distant] future" in Jira) was disabled without a prior notice.



Andrew


-----Original Message-----
From: zephyr-devel-bounces@...
[mailto:zephyr-devel-bounces@...] On Behalf Of
Paul Sokolovsky Sent: Tuesday, July 18, 2017 3:07 AM To:
devel@...; Nashif, Anas <anas.nashif@...>
Subject: [Zephyr-devel] What happened to github issue tracker?

Hello,

Some people started to use Github's project issue tracker at
https://github.com/zephyrproject-rtos/zephyr to file routine issues
(*not* epics or user stories) - for example, regression reports after
recently merged patches.

Today, suddenly, access to Github issue tracker is blocked,
corresponding tab is removed from the page above. And nothing here on
the mailing list.

Please re-enable the issue tracker, as it already contains important
information required to work on the quality 1.9 release.

Thanks.

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


--
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: What happened to github issue tracker?

Boie, Andrew P
 

Why were bugs being filed on Github instead of JIRA?
Having two simultaneous bug tracking systems in use seems insane to me.

Andrew

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky
Sent: Tuesday, July 18, 2017 3:07 AM
To: devel@...; Nashif, Anas <anas.nashif@...>
Subject: [Zephyr-devel] What happened to github issue tracker?

Hello,

Some people started to use Github's project issue tracker at https://github.com/zephyrproject-rtos/zephyr to file routine issues
(*not* epics or user stories) - for example, regression reports after recently merged patches.

Today, suddenly, access to Github issue tracker is blocked, corresponding tab is removed from the page above. And nothing here on the mailing list.

Please re-enable the issue tracker, as it already contains important information required to work on the quality 1.9 release.

Thanks.

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

5661 - 5680 of 8790