Date   

Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Yannis Damigos
 

Hi Jun,

On 07/06/2018 06:32 PM, Li, Jun R wrote:
Based on the datasheet <https://www.st.com/resource/en/datasheet/stm32f427vg.pdf> of STM32F429(Page 40), the OTG_HS port supports both full-speed with its integrated transceiver or high-speed with an external Phy. So, the port can still be used as a full-speed USB port without any hardware efforts, which is the way I’m using it on a 429 board I have.

 

To support it, we just need to use the corresponding registers for OTG_HS. This is what I’m expecting. So, I’m wondering where the macro “USB” will be enabled? I think renaming it to something else like CONFIG_HAS_USB_OTG_HS would be more meaningful.
I haven't checked the USB_OTG_HS in STM32Cube and I don't know if it will work out of the box with the usb_dc_stm32 driver. Probably not.
We need to create a second instance of a "USB device" (the driver right now doesn't support this). We also need to add support for this peripheral in the DT.
CONFIG_HAS_USB_OTG_HS (or just CONFIG_USB_OTG_HS) sounds reasonable to me.

Yannis


Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Li, Jun R
 

Hi Aurelien and Yannis,

 

Based on the datasheet of STM32F429(Page 40), the OTG_HS port supports both full-speed with its integrated transceiver or high-speed with an external Phy. So, the port can still be used as a full-speed USB port without any hardware efforts, which is the way I’m using it on a 429 board I have.

 

To support it, we just need to use the corresponding registers for OTG_HS. This is what I’m expecting. So, I’m wondering where the macro “USB” will be enabled? I think renaming it to something else like CONFIG_HAS_USB_OTG_HS would be more meaningful.

 

Regards,

Jun

 

 

On 7/6/18, 07:00, "Yannis Damigos" <giannis.damigos@...> wrote:

 

    > I don't think that's possible. PB14 and PB15 can only be mapped to the

    > full-speed OTG_HS PHY, not the to the full-speed OTG_FS PHY (yes, this

    > is confusing).

   

    I misunderstood the question. I thought that OTG FS was mapped to PB14 / PB15.

    I didn't tested usb_dc_stm32 using OTG_HS PHY.

   

    Yannis

    


Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Yannis Damigos
 

I don't think that's possible. PB14 and PB15 can only be mapped to the
full-speed OTG_HS PHY, not the to the full-speed OTG_FS PHY (yes, this
is confusing).
I misunderstood the question. I thought that OTG FS was mapped to PB14 / PB15.
I didn't tested usb_dc_stm32 using OTG_HS PHY.

Yannis


Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Aurelien Jarno
 

Hi,

On 2018-07-06 12:27, Yannis Damigos wrote:
Hi,

STM32F429 SoCs support OTG FS USB. Check 96b_carbon board as a
reference to enable it.
You should also configure pinmux for PB14 and PB15.
I don't think that's possible. PB14 and PB15 can only be mapped to the
full-speed OTG_HS PHY, not the to the full-speed OTG_FS PHY (yes, this
is confusing).

I don't think there is a way to enable both ports at the same time given
how the USB API is designed (it doesn't take a usb device in argument).
That said it would be nice if we can choose either via Kconfig or via
device tree which of the two OTG ports to use on STM32F4 and STM32F7
families. Any suggestion how to do that?

I am interesting to get the OTG_HS working on the STM32F723 at some
point, as it has an integrated full speed PHY.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net


Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Yannis Damigos
 

Hi,

STM32F429 SoCs support OTG FS USB. Check 96b_carbon board as a
reference to enable it.
You should also configure pinmux for PB14 and PB15.

Regards,
Yannis

On Fri, Jul 6, 2018 at 10:34 AM Erwan Gouriou <erwan.gouriou@linaro.org> wrote:

Hi Jun Li,

About 'USB' flag, you might be interested by the following comment, file sub_dc_stm32.c, line72:
/*
* USB and USB_OTG_FS are defined in STM32Cube HAL and allows to distinguish
* between two kind of USB DC. STM32 F0, F3, and L0 series support USB device
* controller. STM32 F4 and F7 series support USB_OTG_FS device controller.
* STM32 F1 and L4 series support either USB or USB_OTG_FS device controller.
*
* WARNING: Don't mix USB defined in STM32Cube HAL and CONFIG_USB from Zephyr
* Kconfig system.
*/

I agree the name of 'USB' is unfortunate, I've submitted a request to change it.
This might take a while though.

Cheers
Erwan

On Fri, 6 Jul 2018 at 03:21, Li, Jun R <jun.r.li@intel.com> wrote:

Hi,



I have a STM32F429 board on which the USB high speed port (pinned out by PB14 and PB15) is exposed as a USB normal speed port, compared with the USB FS port from PA11 and PA12 usually on other STM32F4’s discovery boards. I’m sure the high speed USB port on PB14 and PB15 can work as a normal speed USB port since we have another working firmware running on the same board and using the same USB port.



Now I’m trying to port Zephyr 1.12 to this board, and enabling this USB port. I’ve checked the USB device driver file: drivers/usb/device/usb_dc_stm32.c and found that it seems the high speed USB port is already supported if the macro “USB” is enabled. However, I can’t find where the macro “USB” can be enabled. So, I’m wondering if anyone has used the USB port on PB14 and PB15 with Zephyr and enabled the macro “USB”?



Also, the macro “USB” is very confusing with zephyr’s macro “CONFIG_USB”. I recommend to rename this one with other proper name. The macro seems to have been introduced by Yannis Damigos. So, I’m cc’ing Yannis Damigos here, trying to get his attention to this.



Thank you!



Jun Li @ Intel




Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Erwan Gouriou
 

Hi Jun Li,

About 'USB' flag, you might be interested by the following comment, file sub_dc_stm32.c, line72:
/*
 * USB and USB_OTG_FS are defined in STM32Cube HAL and allows to distinguish
 * between two kind of USB DC. STM32 F0, F3, and L0 series support USB device
 * controller. STM32 F4 and F7 series support USB_OTG_FS device controller.
 * STM32 F1 and L4 series support either USB or USB_OTG_FS device controller.
 *
 * WARNING: Don't mix USB defined in STM32Cube HAL and CONFIG_USB from Zephyr
 * Kconfig system.
 */

I agree the name of 'USB' is unfortunate, I've submitted a request to change it.
This might take a while though.

Cheers
Erwan


On Fri, 6 Jul 2018 at 03:21, Li, Jun R <jun.r.li@...> wrote:

Hi,

 

I have a STM32F429 board on which the USB high speed port (pinned out by PB14 and PB15) is exposed as a USB normal speed port, compared with the USB FS port from PA11 and PA12 usually on other STM32F4’s discovery boards. I’m sure the high speed USB port on PB14 and PB15 can work as a normal speed USB port since we have another working firmware running on the same board and using the same USB port.

 

Now I’m trying to port Zephyr 1.12 to this board, and enabling this USB port. I’ve checked the USB device driver file: drivers/usb/device/usb_dc_stm32.c and found that it seems the high speed USB port is already supported if the macro “USB” is enabled. However, I can’t find where the macro “USB” can be enabled. So, I’m wondering if anyone has used the USB port on PB14 and PB15 with Zephyr and enabled the macro “USB”?

 

Also, the macro “USB” is very confusing with zephyr’s macro “CONFIG_USB”. I recommend to rename this one with other proper name.  The macro seems to have been introduced by Yannis Damigos. So, I’m cc’ing Yannis Damigos here, trying to get his attention to this.

 

Thank you!

 

Jun Li @ Intel

 


Has anyone used the USB HS port used as a USB FS on STM32F4?

Li, Jun R
 

Hi,

 

I have a STM32F429 board on which the USB high speed port (pinned out by PB14 and PB15) is exposed as a USB normal speed port, compared with the USB FS port from PA11 and PA12 usually on other STM32F4’s discovery boards. I’m sure the high speed USB port on PB14 and PB15 can work as a normal speed USB port since we have another working firmware running on the same board and using the same USB port.

 

Now I’m trying to port Zephyr 1.12 to this board, and enabling this USB port. I’ve checked the USB device driver file: drivers/usb/device/usb_dc_stm32.c and found that it seems the high speed USB port is already supported if the macro “USB” is enabled. However, I can’t find where the macro “USB” can be enabled. So, I’m wondering if anyone has used the USB port on PB14 and PB15 with Zephyr and enabled the macro “USB”?

 

Also, the macro “USB” is very confusing with zephyr’s macro “CONFIG_USB”. I recommend to rename this one with other proper name.  The macro seems to have been introduced by Yannis Damigos. So, I’m cc’ing Yannis Damigos here, trying to get his attention to this.

 

Thank you!

 

Jun Li @ Intel

 


Re: How to recover Atmel SAMV71 Xplained board

Ramakrishna Pallala <ramakrishna.pallala@...>
 

Hi All, Any inputs on this issue?

 

From: devel@... [mailto:devel@...] On Behalf Of Ramakrishna Pallala
Sent: Wednesday, July 4, 2018 2:35 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] How to recover Atmel SAMV71 Xplained board

 

Hi All,

 

I am getting following error while flashing SAMV71(E70) and board does not boot. Tried setting J200 (erase) jumber but no use L

 

warning: --zephyr-base missing and no ZEPHYR_BASE in the environment

Using runner: openocd

Open On-Chip Debugger 0.10.0-g7852ae77-dirty (2018-05-11-23:26)

Licensed under GNU GPL v2

For bug reports, read

        http://openocd.org/doc/doxygen/bugs.html

adapter speed: 1800 kHz

cortex_m reset_config sysresetreq

Info : flash bank command

srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 02.10.017E

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1800 kHz

in procedure 'init'

in procedure 'ocd_bouncer'

 

error: command exited with status 1: /home/rpallala/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /home/rpallala/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/rpallala/ssg-otc/Zephyr/zephyr-pm/21st-June/zephyr/boards/arm/sam_e70_xplained/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/rpallala/ssg-otc/Zephyr/zephyr-pm/21st-June/zephyr/samples/boards/same70/power_mgr/build/zephyr/zephyr.bin 0x400000' -c 'reset halt' -c 'verify_image /home/rpallala/ssg-otc/Zephyr/zephyr-pm/21st-June/zephyr/samples/boards/same70/power_mgr/build/zephyr/zephyr.bin 0x400000' -c 'atsamv gpnvm set 1' -c 'reset run' -c shutdown

run as "west -v ... flash ..." for a stack trace

[100%] Built target flash

 

 

How to recover the board from this?

 

Thanks,

Ram


How to recover Atmel SAMV71 Xplained board

Ramakrishna Pallala <ramakrishna.pallala@...>
 

Hi All,

 

I am getting following error while flashing SAMV71(E70) and board does not boot. Tried setting J200 (erase) jumber but no use L

 

warning: --zephyr-base missing and no ZEPHYR_BASE in the environment

Using runner: openocd

Open On-Chip Debugger 0.10.0-g7852ae77-dirty (2018-05-11-23:26)

Licensed under GNU GPL v2

For bug reports, read

        http://openocd.org/doc/doxygen/bugs.html

adapter speed: 1800 kHz

cortex_m reset_config sysresetreq

Info : flash bank command

srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 02.10.017E

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1800 kHz

in procedure 'init'

in procedure 'ocd_bouncer'

 

error: command exited with status 1: /home/rpallala/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /home/rpallala/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/rpallala/ssg-otc/Zephyr/zephyr-pm/21st-June/zephyr/boards/arm/sam_e70_xplained/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/rpallala/ssg-otc/Zephyr/zephyr-pm/21st-June/zephyr/samples/boards/same70/power_mgr/build/zephyr/zephyr.bin 0x400000' -c 'reset halt' -c 'verify_image /home/rpallala/ssg-otc/Zephyr/zephyr-pm/21st-June/zephyr/samples/boards/same70/power_mgr/build/zephyr/zephyr.bin 0x400000' -c 'atsamv gpnvm set 1' -c 'reset run' -c shutdown

run as "west -v ... flash ..." for a stack trace

[100%] Built target flash

 

 

How to recover the board from this?

 

Thanks,

Ram


Re: [Zephyr-users] Help wanted with Atmel SAM ADC (AFEC) driver

Carles Cufi
 

Hi Justin,

 

Thank you!

 

Andrzej (on copy) is the original author of the new API, and you can also join the weekly API meeting to discuss over the phone: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

 

Regards,

 

Carles

 

From: Justin Watson <jwatson5@...>
Sent: 03 July 2018 23:47
To: Cufi, Carles <carles.cufi@...>
Cc: devel@...; users@...; Głąbek, Andrzej <Andrzej.Glabek@...>; Bursztyka, Tomasz <tomasz.bursztyka@...>; Kumar Gala <kumar.gala@...>; Maureen Helm <maureen.helm@...>; Nashif, Anas <anas.nashif@...>
Subject: Re: [Zephyr-users] Help wanted with Atmel SAM ADC (AFEC) driver

 

I will work on this for the SAM ADC since I've written some of the other SAM drivers.

 

On Tue, Jul 3, 2018 at 10:09 AM Cufi, Carles <carles.cufi@...> wrote:

Hi all,

A rework of the ADC driver API is now ready and existing ADC implementations are being ported to the new API. You can check out the PR [1] with the API and a reference implementation for more details.

However, the Atmel SAM ADC (AFEC) driver [2] is currently orphan of a maintainer and we are asking for help to port this driver to the new API. If you have experience with this SoC family and want to contribute a port, you can do so in a PR or branch that we can later include when the new API and adapted implementations are merged.

Thanks in advance on behalf of the Zephyr TSC.

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7691
[2] https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/adc/adc_sam_afec.c



Re: Adding new DTS binding for SAM0 I2C

Léonard Bise <leonard.bise@...>
 

Hello guys,

Thanks for the help. I fixed my binding problem and also the i2c driver I'm working on seem to be working now.
Thank you also Madani. I took a look at what you did and it's very similar to what I've been writing. The only difference is I used an interrupt based approach.

Best regards,
Léonard.

On 2 July 2018 at 15:43, <m.lainani@...> wrote:
Hi Léonard,

I've been working on adding I2C support for the SAMD21 but I don't feel it is in a state where making a pull request would be relevant: this is my first foray in Zephyr development plus I didn't know much about I2C until a few weeks ago. Still, my driver compiles properly and I was able to validate basic read/write operation. You can check the two commits below. The first is for the driver implementation while the second is for the addition of a new board using the driver in question.

https://github.com/mlainani/zephyr/commit/81919b689cf20b1c51d25ef51171fb1d69750e7f
https://github.com/mlainani/zephyr/commit/b3b0902620deecc14e881627bde471cb19025c9a

Rgds,

Madani.



Re: [Zephyr-users] Help wanted with Atmel SAM ADC (AFEC) driver

Justin
 

I will work on this for the SAM ADC since I've written some of the other SAM drivers.


On Tue, Jul 3, 2018 at 10:09 AM Cufi, Carles <carles.cufi@...> wrote:
Hi all,

A rework of the ADC driver API is now ready and existing ADC implementations are being ported to the new API. You can check out the PR [1] with the API and a reference implementation for more details.

However, the Atmel SAM ADC (AFEC) driver [2] is currently orphan of a maintainer and we are asking for help to port this driver to the new API. If you have experience with this SoC family and want to contribute a port, you can do so in a PR or branch that we can later include when the new API and adapted implementations are merged.

Thanks in advance on behalf of the Zephyr TSC.

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7691
[2] https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/adc/adc_sam_afec.c





Help wanted with Atmel SAM ADC (AFEC) driver

Carles Cufi
 

Hi all,

A rework of the ADC driver API is now ready and existing ADC implementations are being ported to the new API. You can check out the PR [1] with the API and a reference implementation for more details.

However, the Atmel SAM ADC (AFEC) driver [2] is currently orphan of a maintainer and we are asking for help to port this driver to the new API. If you have experience with this SoC family and want to contribute a port, you can do so in a PR or branch that we can later include when the new API and adapted implementations are merged.

Thanks in advance on behalf of the Zephyr TSC.

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7691
[2] https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/adc/adc_sam_afec.c


Re: Bluetooth: Mesh: about avoiding cloud storage

laczenJMS
 

Hi Vikrant,

I think it is a bad idea to have this kind message to put the device
back into unprovisioned state. Anyone who is using this app with your
devices could take over all your devices by using your procedure, and
this person even does not need physical access to the devices.

I would say every device has some kind of hardware mechanism available
to put it into an unprovisioned state. Even if you have no physical
button you could work as follows: to put the device in unprovisioned
state you need to cycle the power to it for at least 10 times. The
power should stay on for 2 seconds but less than 4 seconds. After 2
seconds you increment the counter, after 4 seconds you reset it to 0.
When the counter reaches 10 the device goes into unprovisioned state.
You can change the counter and times to fit your needs.

Hope this helps,

Jehudi


Re: Debug on Eclipse with NXP FRDM-K64F

Carles Cufi
 

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of clemence
Sent: 03 July 2018 12:56
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Debug on Eclipse with NXP FRDM-K64F

Hi,


I am using the board  NXP FRDM-K64F.

I would like to debug my code on eclise. How can I do it ?


Thanks

Clemence



Debug on Eclipse with NXP FRDM-K64F

clemence
 

Hi,


I am using the board  NXP FRDM-K64F.

I would like to debug my code on eclise. How can I do it ?


Thanks

Clemence


Bluetooth: Mesh: about avoiding cloud storage service

vikrant8051 <vikrant8051@...>
 


Hi,
Assume 

1) #BluetoothMesh provisioner App is creating NET & APP key using end-user @username & some unforgettable pass-phrase.

2) as app get un-installed, no relevant file will present on local storage. 

3) no hardware mechanism to push NODE into factory reset mode.

In this case, even app get un-installed then fresh one could create same NET-APP key pair.

Can I send encrypted message on ADV-Bearer to unprovisioned all NODEs in vicinity to their configuration Server (by selecting destination addr. as 0xFFFF) using freshly installed App?

Is there any chance so that we could avoid cloud storage with "ANY" Bluetooth Mesh implementation without going against SIG specification for above mentioned assumptions ?

Thank You !!


Bluetooth: Mesh: about avoiding cloud storage

vikrant8051 <vikrant8051@...>
 

Hi,
Assume 

1) #BluetoothMesh provisioner App is creating NET & APP key using end-user @username & some unforgettable pass-phrase.

2) as app get un-installed, no relevant file will present on local storage. 

3) no hardware mechanism to push NODE into factory reset mode.

In this case, even app get un-installed then fresh one could create same NET-APP key pair.

Can I send encrypted message on ADV-Bearer to unprovisioned all NODEs in vicinity to their configuration Server (by selecting destination addr. as 0xFFFF) using freshly installed App?

Is there any chance so that we could avoid cloud storage with "ANY" Bluetooth Mesh implementation without going against SIG specification for above mentioned assumptions ?

Thank You !!


Re: Adding new DTS binding for SAM0 I2C

Madani Lainani
 

Hi Léonard,

I've been working on adding I2C support for the SAMD21 but I don't feel it is in a state where making a pull request would be relevant: this is my first foray in Zephyr development plus I didn't know much about I2C until a few weeks ago. Still, my driver compiles properly and I was able to validate basic read/write operation. You can check the two commits below. The first is for the driver implementation while the second is for the addition of a new board using the driver in question.

https://github.com/mlainani/zephyr/commit/81919b689cf20b1c51d25ef51171fb1d69750e7f
https://github.com/mlainani/zephyr/commit/b3b0902620deecc14e881627bde471cb19025c9a

Rgds,

Madani.


Re: Adding new DTS binding for SAM0 I2C

Erwan Gouriou
 

Thanks for the additional info. It would be nice to see what at line 164 in file sodaq_one_v3.dts.pre.tmp.
Anyway, my first guess would be that you miss i2c.h binding file inclusion in your dtsi file.
#include <dt-bindings/i2c/i2c.h>

Erwan


On Mon, 2 Jul 2018 at 10:10, Léonard Bise <leonard.bise@...> wrote:
Hello Erwan,

Thanks for your help.
Well the thing is that is one of my problem, I don't have much to go by.
All I get is a syntax error message from dtc when running cmake:

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.5", minimum required is "3.4") 
-- Selected BOARD sodaq_one_v3
Zephyr version: 1.12.99
Parsing Kconfig tree in /home/leonard/gitrepo/zephyr_fork/Kconfig
Using /home/leonard/gitrepo/TravailBachelor/src/Zephyr_sodaq_one_v3/boards/arm/sodaq_one_v3/sodaq_one_v3_defconfig as base
Merging /home/leonard/gitrepo/TravailBachelor/src/Zephyr_sodaq_one_v3/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
Error: sodaq_one_v3.dts.pre.tmp:164.21-22 syntax error
FATAL ERROR: Unable to parse input tree
CMake Error at /home/leonard/gitrepo/zephyr_fork/cmake/dts.cmake:83 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  /home/leonard/gitrepo/zephyr_fork/cmake/app/boilerplate.cmake:275 (include)
  CMakeLists.txt:9 (include)

As soon as I comment the following block in my dts file it works again. So I assume that it is related to the new atmel,sam0-i2c binding I added.
I added the atmel,sam0-i2c.yaml file in dts/bindings/i2c but I'm not sure if I missed something elsewhere?

&sercom3 {
status = "ok";
compatible = "atmel,sam0-i2c";
clock-frequency = <I2C_BITRATE_FAST>;
#address-cells = <1>;
#size-cells = <0>;
};

Thank you,
Léonard.

On 2 July 2018 at 09:13, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Léonard,

Some additional information on build error would help to provide you support.

Cheers
Erwan

On Sun, 1 Jul 2018 at 13:37, Léonard Bise <leonard.bise@...> wrote:
I'm trying to add support for SAM0 I2C. Currently my code is compiling as I see warnings in my i2c_sam0.c file. 
However I'm trying to add a new binding for that in zephyr/dts/bindings/i2c/atmel,sam0-i2c.yaml and hitting a wall.

---
title: Atmel SAM0 SERCOM I2C driver
id: atmel,sam0-i2c
version: 0.1
 
description: >
    This binding gives a base representation of the Atmel SAM0 SERCOM I2C driver
 
inherits:
    !include i2c.yaml
 
properties:
    compatible:
      type: string
      category: required
      description: compatible strings
      constraint: "atmel,sam0-i2c"
 
    reg:
      type: array
      description: mmio register space
      generation: define
      category: required
 
...

Then in my board dts I added the following:

&sercom3 {
status = "ok";
compatible = "atmel,sam0-i2c";
clock-frequency = <I2C_BITRATE_FAST>;
#address-cells = <1>;
#size-cells = <0>;
};

But something is missing because I keep getting an error when building that it cannot parse the device tree.
I looked around how the other SAM0 device are setup but I didn't find what I'm missing.

Any pointer on how I should go about setting up this binding ?

Best regards,
Léonard.



3201 - 3220 of 8048