Date   

Re: 回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

Johan Hedberg
 

Earlier you said it was 4.1.15. Which one was a typo? :)

Johan

On Tue, Aug 28, 2018, sxzxchen@163.com wrote:
imx6ull,with linux kernel version 4.15

发自我的华为手机


-------- 原始邮件 --------
主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Maureen Helm
收件人:sxzxchen@163.com,Johan Hedberg
抄送:devel@lists.zephyrproject.org




Which NXP device are you running embedded Linux? I can check to see if we
have plans to update the kernel version.



From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of sxzxchen@163.com
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running
zephyr



Thanks for your explanation.since the embedded linux version is bound with
the chip, I cannot update it easily.So is there any ways to solve this
problem without updating linux version ?







At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@intel.com> wrote:

>Hi,

>

>On Thu, Aug 23, 2018, sxzxchen@163.com wrote:

>> I bought a official nrf52832 development kits and ported zephyr

>> project successfully. It runs fine with my ubuntu host,via btattach

>> and btmgmt tools.But it didn't work with my nxp embedded linux,the

>> linux version is 4.1.15 and supports hciattach hciconfig tools

>> only.When I tried to bring the bluetooth module up with hciconfig hci0

>> up,an error comes up:

>

>The 4.1 kernel is too old to support controllers without a public

>address. IIRC you need at least a 4.4 kernel, but ideally something much

>newer than that.

>

>Johan







回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

icephyr
 

imx6ull,with linux kernel version 4.15

发自我的华为手机


-------- 原始邮件 --------
主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Maureen Helm
收件人:sxzxchen@...,Johan Hedberg
抄送:devel@...


Which NXP device are you running embedded Linux? I can check to see if we have plans to update the kernel version.

 

From: devel@... <devel@...> On Behalf Of sxzxchen@...
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  




 


At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote:
>Hi,
>On Thu, Aug 23, 2018, sxzxchen@... wrote:
>> I bought a official nrf52832 development kits and ported zephyr
>> project successfully. It runs fine with my ubuntu host,via btattach
>> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>> linux version is 4.1.15 and supports hciattach hciconfig tools
>> only.When I tried to bring the bluetooth module up with hciconfig hci0
>> up,an error comes up:
>The 4.1 kernel is too old to support controllers without a public
>address. IIRC you need at least a 4.4 kernel, but ideally something much
>newer than that.
>Johan

 

 


Re: hciconfig tools error with nrf52832 running zephyr

Maureen Helm
 

Which NXP device are you running embedded Linux? I can check to see if we have plans to update the kernel version.

 

From: devel@... <devel@...> On Behalf Of sxzxchen@...
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  




 


At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote:
>Hi,
>On Thu, Aug 23, 2018, sxzxchen@... wrote:
>> I bought a official nrf52832 development kits and ported zephyr
>> project successfully. It runs fine with my ubuntu host,via btattach
>> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>> linux version is 4.1.15 and supports hciattach hciconfig tools
>> only.When I tried to bring the bluetooth module up with hciconfig hci0
>> up,an error comes up:
>The 4.1 kernel is too old to support controllers without a public
>address. IIRC you need at least a 4.4 kernel, but ideally something much
>newer than that.
>Johan

 

 


Re: hciconfig tools error with nrf52832 running zephyr

icephyr
 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  






At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote: >Hi, > >On Thu, Aug 23, 2018, sxzxchen@... wrote: >> I bought a official nrf52832 development kits and ported zephyr >> project successfully. It runs fine with my ubuntu host,via btattach >> and btmgmt tools.But it didn't work with my nxp embedded linux,the >> linux version is 4.1.15 and supports hciattach hciconfig tools >> only.When I tried to bring the bluetooth module up with hciconfig hci0 >> up,an error comes up: > >The 4.1 kernel is too old to support controllers without a public >address. IIRC you need at least a 4.4 kernel, but ideally something much >newer than that. > >Johan


 


Re: nrf52840_pca10059 startup

Chettimada, Vinayak Kariappa
 

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@...> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@... on behalf of Henrik Brix Andersen" <devel@... on behalf of henrik@...> wrote:

  Hi,

  I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

  When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
  But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

  If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
  I am not using mcuboot or any other bootloader; just the bare-bone sample application.

  What am I missing here?

  Best regards,
  Brix
  --
  Henrik Brix Andersen













NRF52 : use of NFFS file system

Laurence Pasteau
 

Hi everybody,


I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.


I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.


I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.


I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.


Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.



Here is my configuration (I don't use MCU_BOOT) :


In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };


In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y


In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)


Thanks in advance for any help.


Regards,

Laurence






Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen









Re: nrf52840_pca10059 startup

Carles Cufi
 

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen


nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen


Trying to add support for FRDM-KL28Z (nxp)

Lars Knudsen
 

Hi,

I'm trying to add support for the FRDM-KL28Z board but realize, there seem to be missing support under /ext (where I see support for e.g. MKL25Z4).

Would this need to be pulled from an NXP repo?

br
Lars


Re: [Zephyr-users] [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

Chettimada, Vinayak Kariappa
 

Why don’t you use tests/bluetooth/mesh_shell ? and add your commands?

Johan may be of assistance.

On 24 Aug 2018, at 13:08, Vikrant More <vikrant8051@...> wrote:

Hi Vinayak,
My sim is to create commands & send it to PDK where PDK process them & help onboard #BluetoothMesh clients to create data packets.

Currently using thread triggered by button interrupt to send Bluetooth Mesh Client mesaages like
Gen_OnOff_Set/ Gen_OnOff_Set_Unack/Gen_Level_Set/Gen_Level_Set_Unack

Thank You !!

On Fri, Aug 24, 2018 at 4:32 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!





Re: Applying TDD to an IP stack issue

Oleg Zhurakivskyy
 

Hello Paul,

On 08/23/2018 01:29 PM, Paul Sokolovsky wrote:

The simplest test would be as follows: it should be an active close,
i.e. connection close should happen on Zephyr side. Then test would
expect to receive a FIN pkt, but should ignore it and not send an ACK.
Then the test should verify that a FIN retransmission is received
within reasonable time.
Thanks for the input.

Currenly the TCP suite is very simple and doesn't have a capability to initiate events on a peer's side of TCP connection.

I am planning to add such capability and will try to implement such a test.

Regards,
Oleg


Re: [Zephyr-users] [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

vikrant8051 <vikrant8051@...>
 

Hi Vinayak,
My sim is to create commands & send it to PDK where PDK process them & help onboard #BluetoothMesh clients to create data packets.

Currently using thread triggered by button interrupt to send Bluetooth Mesh Client mesaages like
Gen_OnOff_Set/ Gen_OnOff_Set_Unack/Gen_Level_Set/Gen_Level_Set_Unack

Thank You !!

On Fri, Aug 24, 2018 at 4:32 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!




Re: [Zephyr-users] [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

Chettimada, Vinayak Kariappa
 

if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!




Re: nRF52: USART: sending data from Serial terminal to DK

vikrant8051 <vikrant8051@...>
 

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!


DS-5 ARM compiler support

miem@...
 

Hi,

Does Zephyr have (or plan to add) support for DS-5 ARM compiler? 

Regards,
Mina


Re: Code cleanup for dts.fixup #defines

@ibisz
 

>What do you think? Do you see any caveats about this?

A similar or the same idea drived the #9526 PR.
I think  a prefix like dtconfig_ is  usefull in aliases definition.

Best regards,
István
 


Re: hciconfig tools error with nrf52832 running zephyr

Johan Hedberg
 

Hi,

On Thu, Aug 23, 2018, sxzxchen@163.com wrote:
I bought a official nrf52832 development kits and ported zephyr
project successfully. It runs fine with my ubuntu host,via btattach
and btmgmt tools.But it didn't work with my nxp embedded linux,the
linux version is 4.1.15 and supports hciattach hciconfig tools
only.When I tried to bring the bluetooth module up with hciconfig hci0
up,an error comes up:
The 4.1 kernel is too old to support controllers without a public
address. IIRC you need at least a 4.4 kernel, but ideally something much
newer than that.

Johan


hciconfig tools error with nrf52832 running zephyr

icephyr
 

hi guys,
    I got a problem here and hope anyone can give me some advice,thanks.

    I bought a official nrf52832 development kits and ported zephyr project successfully. It runs fine with my ubuntu host,via btattach and btmgmt tools.But it didn't work with my nxp embedded linux,the linux version is 4.1.15 and supports hciattach hciconfig tools only.When I tried to bring the bluetooth module up with hciconfig hci0 up,an error comes up:

#hciconfig hci0 up
#Can't init device hci1: Cannot assign requested address (99)

has anyone met this problem before ? I don't know how to deal with it now,the hci0 can not be up status.


Re: Code cleanup for dts.fixup #defines

Andy Gross
 


On 23 August 2018 at 14:12, Diego Sueiro <diego.sueiro@...> wrote:
Andy,

This is an excellent idea.  The only downside (upside?) is having to standardize on all of the subsystem driver labels.  And it still doesn't solve the device specific properties unless we were to extend this idea to automatically generate generic labels for all device specific properties by adding a #define to point the generic label + property to the device compatible + address value.  Then you'd have to build up the platform data structures to contain this stuff.

Actually, the dts extraction already deals with the driver properties listed in the yaml file.

For example, the nxp,imx-uart.yaml, has the following #defines automatically generated for the uart-2 alias:
<build>/zephyr/include/generated/generated_dts_board.h:
#define CONFIG_UART_CONSOLE_ON_DEV_NAME         "UART_2"
#define NXP_IMX_UART_30890000_BASE_ADDRESS      0x30890000
#define NXP_IMX_UART_30890000_CURRENT_SPEED     115200
#define NXP_IMX_UART_30890000_IRQ_0             27
#define NXP_IMX_UART_30890000_IRQ_0_PRIORITY    3
#define NXP_IMX_UART_30890000_LABEL             "UART_2"
#define NXP_IMX_UART_30890000_MODEM_MODE        64
#define NXP_IMX_UART_30890000_RDC               15
#define NXP_IMX_UART_30890000_SIZE              65536
#define UART_2_BASE_ADDRESS                     NXP_IMX_UART_30890000_BASE_ADDRESS
#define UART_2_CURRENT_SPEED                    NXP_IMX_UART_30890000_CURRENT_SPEED
#define UART_2_IRQ                              NXP_IMX_UART_30890000_IRQ_0
#define UART_2_IRQ_PRIORITY                     NXP_IMX_UART_30890000_IRQ_0_PRIORITY
#define UART_2_LABEL                            NXP_IMX_UART_30890000_LABEL
#define UART_2_MODEM_MODE                       NXP_IMX_UART_30890000_MODEM_MODE
#define UART_2_RDC                              NXP_IMX_UART_30890000_RDC
#define UART_2_SIZE                             NXP_IMX_UART_30890000_SIZE

Note that RDC and MODEM_MODE are custom properties for the imx uart driver.

Ah, right.  Yeah this looks quite nice then.

3181 - 3200 of 8194