Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boards: Add support for the iMX6SX Udoo Neo board #7123

Merged
merged 3 commits into from Jun 19, 2018

Conversation

Projects
None yet
6 participants
@MaureenHelm
Copy link
Member

MaureenHelm commented Apr 19, 2018

Adds support for the iMX6SX M4 subsystem on the Udoo Neo board. This initial port includes uart and gpio drivers to enable the hello_world and basic/blinky samples.

cc: @diegosueiro

@codecov-io

This comment has been minimized.

Copy link

codecov-io commented Apr 19, 2018

Codecov Report

Merging #7123 into master will increase coverage by <.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7123      +/-   ##
==========================================
+ Coverage   64.53%   64.53%   +<.01%     
==========================================
  Files         420      420              
  Lines       40101    40101              
  Branches     6762     6762              
==========================================
+ Hits        25879    25880       +1     
  Misses      11104    11104              
+ Partials     3118     3117       -1
Impacted Files Coverage Δ
boards/posix/native_posix/timer_model.c 100% <0%> (+1.78%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d04a7ef...4c65925. Read the comment docs.


UDOO Neo Full is an open source Arduino Uno compatible single board computer.
It is equipped with an NXP |reg| i.MX 6SoloX hybrid multicore processor
composed by one ARM |reg| Cortex-A9 core running up to 1 GHz and one Cortex-M4

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

change to composed of

It is equipped with an NXP |reg| i.MX 6SoloX hybrid multicore processor
composed by one ARM |reg| Cortex-A9 core running up to 1 GHz and one Cortex-M4
core running up to 227 MHz for high CPU performance and real-time response.
Zephyr was ported to run on the Cortex-M4 core. In a later release, it will

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

for clarity add only to:

ported to run on the Cortex-M4 core only.

Zephyr was ported to run on the Cortex-M4 core. In a later release, it will
also communicate with the Cortex-A9 core (running Linux) via RPMsg.

.. image:: udoo_neo_full.jpg

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

The image directive doesn't allow a caption (hence the error about content not being allowed. Change this to use the figure directive (everything else is the same), which does allow content (for the caption).


The MCIMX6X SoC is configured to use the 24 MHz external oscillator
on the board with the on-chip PLL to generate core clock.
PLL settings for M4 core are set via code running on A9 core.

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

change to: on the A9 core

Serial Port
===========

The MCIMX6X SoC has six UARTs. UART5 is configured for M4 console and the

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

change to for the M4 core and by the A9 core on the next line

at power-on-reset. Therefore it needs to be started by the A9 core.
The A9 core is responsible to load the M4 binary application into the RAM,
put the M4 in reset, set the M4 Program Counter and Stack Pointer, and get
the M4 out of reset. The A9 can perform these steps at bootloader level

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

change to at the bootloader

Debugging
=========

The UDOO Neo Full board includes the pads for soldering of the 14-pin JTAG

This comment has been minimized.

@dbkinder

dbkinder Apr 19, 2018

Collaborator

change to:

The UDOO Neo Full board includes pads for soldering the 14-pin JTAG
connector. Zephyr applications running on the M4 core have only been
tested by observing UART console output.
@galak
Copy link
Contributor

galak left a comment

From the perspective of Zephyr & the m4, does the the fact that the board is udoo_neo_full vs the other cfg mater?

Programming and Debugging
*************************

The M4 core does not have flash memory and is not provided a clock

This comment has been minimized.

@galak

galak Apr 19, 2018

Contributor

Can we add details like in colibri_imx7d_m4 doc's have for loading via u-boot?

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

Agreed

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Apr 25, 2018

Collaborator

I haven't used u-boot. Only loaded it from Linux user space application which is part of the particular Linux distribution used (UDOObuntu). Anyway, I will add some instructions for this distribution at least (and the link to program, which is distribution independent).

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Jun 6, 2018

Collaborator

Added details about the loading of second core image.

The A9 core is responsible to load the M4 binary application into the RAM,
put the M4 in reset, set the M4 Program Counter and Stack Pointer, and get
the M4 out of reset. The A9 can perform these steps at bootloader level
after the Linux system has booted.

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

Need to add an "or".
at the bootloader level or after the Linux system has booted.

#include <init.h>
#include "device_imx.h"

static int udoo_neo_full_m4_init(struct device *dev)

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

What about the GPIO pinmux config?

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Jun 6, 2018

Collaborator

Added LED GPIO pin config into pinmux.c + RDC access in soc.c

@@ -7,6 +7,7 @@ zephyr_sources_ifdef(CONFIG_GPIO_DW gpio_dw.c)
zephyr_sources_ifdef(CONFIG_GPIO_ESP32 gpio_esp32.c)
zephyr_sources_ifdef(CONFIG_GPIO_FE310 gpio_fe310.c)
zephyr_sources_ifdef(CONFIG_GPIO_GECKO gpio_gecko.c)
zephyr_sources_ifdef(CONFIG_GPIO_IMX gpio_imx_gpio.c)

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

Do you think is possible to use the same GPIO driver from PR #7113?

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Apr 20, 2018

Collaborator

Yes, should be possible. We should select one or the other.

This comment has been minimized.

@diegosueiro

diegosueiro May 1, 2018

Contributor

Instead of gpio_imx_gpio.c can we use gpio_imx.c?
This way the filename is more clear.

This comment has been minimized.

@stanislav-poboril

stanislav-poboril May 2, 2018

Collaborator

Ok. Note that the FreeRTOS BSP driver is also gpio_imx.c, hopefully it won't cause problems in any toolchains.

This comment has been minimized.

@stanislav-poboril

stanislav-poboril May 2, 2018

Collaborator

Extracted this part into a separated PR #7306 so #7113 can rebase to it.

This comment has been minimized.

@diegosueiro

diegosueiro May 2, 2018

Contributor

@stanislav-poboril,

I had this name in my PR and no issues with the compilation.

CONFIG_SERIAL=y
CONFIG_SERIAL_HAS_DRIVER=y
CONFIG_CORTEX_M_SYSTICK=y
CONFIG_GPIO=n

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

In the board dts you set the gpio ports 4, 5 and 6 to status "ok" but in this config the GPIO is set to "n".

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Jun 6, 2018

Collaborator

Changed.

*
* @return 0
*/
static int mcimx6x_m4_init(struct device *arg)

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

Should we have a similar soc initialization for nxp_mcimx7_init, like SOC_CacheInit()?

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Apr 20, 2018

Collaborator

I think this is optional. The FreeRTOS BSP initializes it when in startup, see:
FreeRTOS_BSP_1.0.1_iMX7D/platform/devices/MCIMX7D/startup/system_MCIMX7D_M4.c, function SystemInit(). Or we could have a config item at the SoC level to enable/disable this.
We could also utilize LMEM_EnableSystemCache() in ext/hal/nxp/imx/drivers/lmem.c.
Or let the cache initialization be done (or not done) by user application.

identifier: udoo_neo_full_m4
name: UDOO Neo Full
type: mcu
arch: arm

This comment has been minimized.

@diegosueiro

diegosueiro Apr 20, 2018

Contributor

Add the entry:
ram: 32

@stanislav-poboril stanislav-poboril force-pushed the NXPmicro:imx6sx_support branch 2 times, most recently from ed8c9ca to 89a6aef Apr 20, 2018


References
==========

This comment has been minimized.

@dbkinder

dbkinder Apr 20, 2018

Collaborator

If you're intention was for the references listed here to show up in the generated HTML page under this heading, add a directive to do that here:

.. target-notes::

followed by a blank line.

@stanislav-poboril

This comment has been minimized.

Copy link
Collaborator

stanislav-poboril commented Apr 25, 2018

From the perspective of Zephyr & the m4, does the the fact that the board is udoo_neo_full vs the other cfg mater?

The basic, extended and full versions differ in the availability of:

  • Wi-Fi
  • Bluetooth
  • Fast Ethernet
  • 9-Axis sensor
  • amount of external RAM (this depends on size of area reserved for M4 anyway)

So it makes sense to have separate dts files at least. Question is if Zephyr will support all those peripherals. If not, we don't have to distinguish versions. Or we could only separate the configuration once something from the above list is implemented.

@stanislav-poboril stanislav-poboril force-pushed the NXPmicro:imx6sx_support branch from 89a6aef to e5323e5 Apr 25, 2018


#define CONFIG_UART_IMX_UART_1_BASE_ADDRESS NXP_IMX_UART_42020000_BASE_ADDRESS_0
#define CONFIG_UART_IMX_UART_1_NAME NXP_IMX_UART_42020000_LABEL
#define CONFIG_UART_IMX_UART_1_IRQ NXP_IMX_UART_42020000_IRQ_0

This comment has been minimized.

@diegosueiro

diegosueiro May 2, 2018

Contributor

Use CONFIG_UART_IMX_UART_[X]_IRQ_NUM instead of CONFIG_UART_IMX_UART_[X]_IRQ

This comment has been minimized.

@stanislav-poboril

stanislav-poboril Jun 6, 2018

Collaborator

Changed.

@dbkinder
Copy link
Collaborator

dbkinder left a comment

Thanks.

@galak

This comment has been minimized.

Copy link
Contributor

galak commented May 8, 2018

Can we update this to resolve the conflict?

@stanislav-poboril

This comment has been minimized.

Copy link
Collaborator

stanislav-poboril commented May 9, 2018

Can we update this to resolve the conflict?
Yes, I am planning to update my open pull requests, but I will get into this tomorrow or in the week of May 21st.

@stanislav-poboril stanislav-poboril force-pushed the NXPmicro:imx6sx_support branch from e5323e5 to 884ba4d May 10, 2018

@MaureenHelm MaureenHelm force-pushed the NXPmicro:imx6sx_support branch from 884ba4d to a4967ea May 14, 2018

@MaureenHelm

This comment has been minimized.

Copy link
Member Author

MaureenHelm commented May 14, 2018

  • Rebased to latest master
  • Fixed CI UART failures
  • Updated dts base addresses to drop trailing _0 (consequence of commit 081c9c3)

I don't have this board on hand so I could not test these changes on hardware.

@galak: Are these the conflicts you were referring to, or is there something else? There weren't any git merge conflicts when I rebased.

@stanislav-poboril

This comment has been minimized.

Copy link
Collaborator

stanislav-poboril commented May 14, 2018

@MaureenHelm, the conflict was due to #7306 being merged and its changes were left in this PR too. I have removed what was part of #7306 from here, which has removed the conflict.

@stanislav-poboril stanislav-poboril force-pushed the NXPmicro:imx6sx_support branch from a4967ea to edf7333 May 29, 2018

stanislav-poboril added some commits Apr 18, 2018

ext/hal/nxp/imx: Import the nxp imx6 freertos bsp
This code component is used to add Zephyr support on iMX6SX
processors, exclusively on Cortex M4 core, and to speed up the
development process it was decided to have it based on NXP FreeRTOS BSP
implementation.

The i.MX FreeRTOS BSP is split into separate downloadable packages,
based on SoC. The packages share most of the peripheral driver files
and here they are combined together.

The source code was imported from the following folders:
FreeRTOS_BSP_1.0.1_iMX6SX/platform/drivers
FreeRTOS_BSP_1.0.1_iMX6SX/platform/devices

This source code depends on headers and sources from zephyr:
    ext/hal/cmsis

Origin: i.MX 6SoloX FreeRTOS BSP 1.0.1 for Cortex-M4 Peripheral Driver
License: BSD 3-Clause
URL: https://www.nxp.com/webapp/Download?colCode=FreeRTOS_MX6SX_1.0.1_LINUX&appType=license
commit: no commit hash
Purpose: The peripheral driver wraps the H/W for i.MX6SX M4 core
Maintained-by: External

Signed-off-by: Stanislav Poboril <stanislav.poboril@nxp.com>
arch: Add imx6sx m4 soc support
The i.MX 6SoloX SoC is a hybrid multi-core processor composed by one
Cortex A9 core and one Cortex M4 core.

Zephyr was ported to run on the M4 core. In a later release, it will
also communicate with the A9 core (running Linux) via RPMsg.

The low level drivers come from NXP FreeRTOS BSP and are located at
ext/hal/nxp/imx. More details can be found at ext/hal/nxp/imx/README

The A9 core is responsible to load the M4 binary application into the
RAM, put the M4 in reset, set the M4 Program Counter and Stack Pointer,
and get the M4 out of reset.
The A9 can perform these steps at bootloader level after the Linux
system has booted.

Signed-off-by: Stanislav Poboril <stanislav.poboril@nxp.com>
boards/arm: add support for udoo_neo_full_m4 board
The UDOO Neo Full single board computer configuration supports
the following hardware features on the Cortex M4 Core:

+-----------+------------+-------------------------------------+
| Interface | Controller | Driver/Component                    |
+===========+============+=====================================+
| NVIC      | on-chip    | nested vector interrupt controller  |
+-----------+------------+-------------------------------------+
| SYSTICK   | on-chip    | systick                             |
+-----------+------------+-------------------------------------+
| UART      | on-chip    | serial port-polling;                |
|           |            | serial port-interrupt               |
+-----------+------------+-------------------------------------+
| GPIO      | on-chip    | general purpose input/output        |
+-----------+------------+-------------------------------------+

The default configuration can be found in the defconfig file:
boards/arm/udoo_neo_full_m4/udoo_neo_full_m4_defconfig

Other hardware features are not currently supported by the port.

Connections and IOs:

The UDOO Neo Full board was tested with the following pinmux
controller configuration.

+---------------+-----------------+---------------------------+
| Board Name    | SoC Name        | Usage                     |
+===============+=================+===========================+
| J4 RX         | UART5_RX_DATA   | UART Console              |
+---------------+-----------------+---------------------------+
| J4 TX         | UART5_TX_DATA   | UART Console              |
+---------------+-----------------+---------------------------+

The board has been tested with the following samples.
 - samples/hello_world
 - samples/basic/blinky

Signed-off-by: Stanislav Poboril <stanislav.poboril@nxp.com>

@stanislav-poboril stanislav-poboril force-pushed the NXPmicro:imx6sx_support branch from edf7333 to 4c65925 Jun 6, 2018

@stanislav-poboril

This comment has been minimized.

Copy link
Collaborator

stanislav-poboril commented Jun 19, 2018

Hello, since the Zephyr release has been done, could this be merged into the master now? Thanks, S.

@MaureenHelm MaureenHelm merged commit 52e120e into zephyrproject-rtos:master Jun 19, 2018

1 check passed

Shippable Run 16647 status is SUCCESS.
Details

@MaureenHelm MaureenHelm deleted the NXPmicro:imx6sx_support branch Jun 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.