search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.19k stars 6.25k forks source link

Support for Teensy 4.0 and 4.1 #30204

Closed ufechner7 closed 3 years ago

ufechner7 commented 3 years ago

Please provide official support for Teensy 4.0 . See: https://www.pjrc.com/store/teensy40.html

This board is sold in large quantities, mainly to hobbyists, but also to small companies. Normally it is used with Arduino Software & Libraries . Making Zephyr available for this board would increase the user base of Zephyr and thus the Zephyr ecosystem. For the user it would allow to run more demanding software on the board, and it would it make it easier to switch to a different board if required.

I ask for support here because while having the time and capabilities to test the Teensy support of Zephyr, I do not have the skills (yet) to implement it. Further more this would be a good place to discuss how to implement the support. A proof-of-concept is already available (see: end of this thread https://forum.pjrc.com/threads/50241-(Question)-zephyr-support-for-teensy-3-x and https://github.com/bdkrae/zephyr/tree/teensy4-branch/boards/arm/teensy4 ).

image

ufechner7 commented 3 years ago

Good progress reported from Bernard Kraemer:

nxp_hal issue solved, see here. That means you can just take the teensy4-folder from my zephyr-clone, place it at the correct place in your local zephyr installation and you should be ready to go.

Ethernet In progress, my hardware to check is on the way.

SD card Working with some drawbacks due to missing card voltage switch ability and detection switch, details will follow.

SPI/CAN/PWM As teensy provides no board specific hardware related to this peripherals I think we can skip testing this.

optional Flash/RAM on 4.1 I am not planning to test this before stating the pull request. Maybe someone is interested to do so.

USB OTG /USB host OTG is working already, host is open. Does zephyr actually provide support for usb host functions?

GPIO issue Controlling internal pullups/pulldowns for gpios seems not to work currently. As a workaround external resistors must be used.

As promised I started an example application located here. Readme will follow. Maybe someone can check it and give some feedback.

ufechner7 commented 3 years ago

I tried: "That means you can just take the teensy4-folder from my zephyr-clone, place it at the correct place in your local zephyr installation and you should be ready to go."

And then I tried: cd ~/zephyrproject/zephyr west build -p auto teensy4 samples/basic/blinky

Output: ERROR: source directory teensy4 does not exist FATAL ERROR: refusing to proceed without --force due to above error

I mean, it does exist:

ufechner@builder:~/zephyrproject/zephyr/boards/arm/teensy4$ ls
CMakeLists.txt     teensy40_defconfig  teensy41.yaml
doc                teensy40.dts        teensy4_flexspi_nor_config.c
Kconfig.board      teensy40.yaml       teensy4_flexspi_nor_config.h
Kconfig.defconfig  teensy41_defconfig  teensy4_sdram_ini_dcd.c
pinmux.c           teensy41.dts        teensy4_sdram_ini_dcd.h

Any idea?

Laczen commented 3 years ago

I tried: "That means you can just take the teensy4-folder from my zephyr-clone, place it at the correct place in your local zephyr installation and you should be ready to go."

And then I tried: cd ~/zephyrproject/zephyr west build -p auto teensy4 samples/basic/blinky

Output: ERROR: source directory teensy4 does not exist FATAL ERROR: refusing to proceed without --force due to above error

I mean, it does exist:

ufechner@builder:~/zephyrproject/zephyr/boards/arm/teensy4$ ls
CMakeLists.txt     teensy40_defconfig  teensy41.yaml
doc                teensy40.dts        teensy4_flexspi_nor_config.c
Kconfig.board      teensy40.yaml       teensy4_flexspi_nor_config.h
Kconfig.defconfig  teensy41_defconfig  teensy4_sdram_ini_dcd.c
pinmux.c           teensy41.dts        teensy4_sdram_ini_dcd.h

Any idea?

-b before teensy4 ?

bdkrae commented 3 years ago

2 Bugs:

But anyway the Blinky sample compiles but seems to be broken. I'll have a look...

bdkrae commented 3 years ago

ok got it. My code cleanup from yesterday was somewhat too fast (and maybe too late in the evening ;-). Yesterday I removed this little part from teensy40.dts:

chosen {
    zephyr,console = &lpuart6;
};

But this defines where the applications standard output goes - e.g. printk() - goes. My example application maps this output to usb and didn't show this bug, so I ran into the trap.

I just pushed a bugfix: https://github.com/bdkrae/zephyr/commit/c958860af6c3f68e627b27c145d85f85755dd1fc

ufechner7 commented 3 years ago

Still not working:

ufechner@builder:~/zephyrproject/zephyr$ west build -p auto -b teensy40 samples/basic/blinky WARNING: This looks like a fresh build and BOARD is unknown; so it probably won't work. To fix, use --board=. Note: to silence the above message, run 'west config build.board_warn false' ninja: error: loading 'build.ninja': No such file or directory FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/ufechner/zephyrproject/zephyr/build

Any idea?

bdkrae commented 3 years ago

Most likely you've not set the environment variables for the required build system. See https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded for more information.

My ones look like this:

ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major
ufechner7 commented 3 years ago

But do I need a 3rd party compiler? I have installed and setup zephyr-sdk-0.11.4 . See: https://docs.zephyrproject.org/latest/getting_started/index.html#install-a-toolchain

ufechner7 commented 3 years ago

Some progress: I had to clean the build directory, then compilation started to work.

cd build
rm -r *
cd ..

The following command works: west build -p -b mimxrt1060_evk samples/basic/blinky

Building for the board teensy40 fails, though:

ufechner@builder:~/zephyrproject/zephyr$ west build -p -b teensy40 samples/basic/blinky
-- west build: generating a build system
Including boilerplate (Zephyr base): /home/ufechner/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: /home/ufechner/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.4.99 (/home/ufechner/zephyrproject/zephyr)
-- Found Python3: /usr/bin/python3.6 (found suitable exact version "3.6.9") found components: Interpreter 
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
-- Board: teensy40
-- Cache files will be written to: /home/ufechner/.cache/zephyr
ZEPHYR_TOOLCHAIN_VARIANT not set, trying to locate Zephyr SDK
-- Found toolchain: zephyr (/home/ufechner/zephyr-sdk-0.11.4)
-- Found dtc: /home/ufechner/zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/ufechner/zephyrproject/zephyr/boards/arm/teensy4/teensy40.dts
-- Generated zephyr.dts: /home/ufechner/zephyrproject/zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ufechner/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h
Parsing /home/ufechner/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/ufechner/zephyrproject/zephyr/boards/arm/teensy4/teensy40_defconfig'
Merged configuration '/home/ufechner/zephyrproject/zephyr/samples/basic/blinky/prj.conf'
Configuration saved to '/home/ufechner/zephyrproject/zephyr/build/zephyr/.config'
Kconfig header saved to '/home/ufechner/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
CMake Deprecation Warning at /home/ufechner/zephyrproject/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

-- Configuring done
-- Generating done
-- Build files have been written to: /home/ufechner/zephyrproject/zephyr/build
-- west build: building application
[83/127] Building C object zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj
/home/ufechner/zephyrproject/zephyr/drivers/serial/uart_mcux_lpuart.c:376:37: warning: 'mcux_lpuart_driver_api' defined but not used [-Wunused-const-variable=]
  376 | static const struct uart_driver_api mcux_lpuart_driver_api = {
      |                                     ^~~~~~~~~~~~~~~~~~~~~~
/home/ufechner/zephyrproject/zephyr/drivers/serial/uart_mcux_lpuart.c:354:12: warning: 'mcux_lpuart_init' defined but not used [-Wunused-function]
  354 | static int mcux_lpuart_init(const struct device *dev)
      |            ^~~~~~~~~~~~~~~~
[122/127] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf 
: && ccache /home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc   zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj -o zephyr/zephyr_prebuilt.elf  -Wl,-T  zephyr/linker.cmd  -Wl,-Map=/home/ufechner/zephyrproject/zephyr/build/zephyr/zephyr_prebuilt.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/mpu/libarch__arm__core__aarch32__cortex_m__mpu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/posix/liblib__posix.a  zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/serial/libdrivers__serial.a  modules/nxp/lib..__modules__hal__nxp.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -L"/home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/thumb/v7e-m/nofp"  -L/home/ufechner/zephyrproject/zephyr/build/zephyr  -lgcc  -Wl,--print-memory-usage  zephyr/arch/common/libisr_tables.a  -mthumb  -mabi=aapcs  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -no-pie  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn && :
Memory region         Used Size  Region Size  %age Used
           OCRAM:          0 GB       768 KB      0.00%
            ITCM:          0 GB       128 KB      0.00%
           FLASH:       22180 B         2 MB      1.06%
            SRAM:        4064 B         0 GB       inf%
        IDT_LIST:         168 B         2 KB      8.20/home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `datas' will not fit in region `SRAM'
/home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: region `SRAM' overflowed by 4064 bytes
collect2: error: ld returned 1 exit status
%
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/ufechner/zephyrproject/zephyr/build
ufechner@builder:~/zephyrproject/zephyr$

Any idea?

ufechner7 commented 3 years ago

When using the target mimxrt1060_evk (which uses the same CPU), I get the following memory usage report:

Memory region         Used Size  Region Size  %age Used
           OCRAM:          0 GB       768 KB      0.00%
            ITCM:          0 GB       128 KB      0.00%
           FLASH:       23492 B         8 MB      0.28%
            DTCM:          0 GB       128 KB      0.00%
            SRAM:          4 KB        32 MB      0.01%
        IDT_LIST:         168 B         2 KB      8.20%

So perhaps the memory resource definition for the board teensy40 is wrong?

I checked the file teensy40.dts, and there is indeed no SRAM defined. Well, the board has no external SRAM, only OCRAM (on chip RAM). That should be good enough. The question is, how to convince the blinky example to use OCRAM or DTCM instead of SRAM...

ufechner7 commented 3 years ago

I tried the example from https://github.com/bdkrae/zephyr_teensy4_test :

west build -p -b teensy40 samples/zephyr_teensy4_test

More or less the same problem:

-- west build: building application
[1/190] Preparing syscall dependency handling

[48/190] Building C object zephyr/CMak...ir/subsys/disk/disk_access_usdhc.c.obj
/home/ufechner/zephyrproject/zephyr/subsys/disk/disk_access_usdhc.c:2796:12: warning: 'disk_usdhc_init' defined but not used [-Wunused-function]
 2796 | static int disk_usdhc_init(const struct device *dev)
      |            ^~~~~~~~~~~~~~~
[74/190] Building C object zephyr/CMak...yr.dir/drivers/ethernet/eth_mcux.c.obj
/home/ufechner/zephyrproject/zephyr/drivers/ethernet/eth_mcux.c:1140:13: warning: 'eth_mcux_common_isr' defined but not used [-Wunused-function]
 1140 | static void eth_mcux_common_isr(const struct device *dev)
      |             ^~~~~~~~~~~~~~~~~~~
/home/ufechner/zephyrproject/zephyr/drivers/ethernet/eth_mcux.c:1120:34: warning: 'api_funcs' defined but not used [-Wunused-const-variable=]
 1120 | static const struct ethernet_api api_funcs = {
      |                                  ^~~~~~~~~
/home/ufechner/zephyrproject/zephyr/drivers/ethernet/eth_mcux.c:981:12: warning: 'eth_init' defined but not used [-Wunused-function]
  981 | static int eth_init(const struct device *dev)
      |            ^~~~~~~~
[185/190] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf 
: && ccache /home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc   zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj -o zephyr/zephyr_prebuilt.elf  -Wl,-T  zephyr/linker.cmd  -Wl,-Map=/home/ufechner/zephyrproject/zephyr/build/zephyr/zephyr_prebuilt.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/mpu/libarch__arm__core__aarch32__cortex_m__mpu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/posix/liblib__posix.a  zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a  zephyr/subsys/fs/libsubsys__fs.a  zephyr/subsys/net/libsubsys__net.a  zephyr/subsys/net/l2/ethernet/libsubsys__net__l2__ethernet.a  zephyr/subsys/net/ip/libsubsys__net__ip.a  zephyr/subsys/random/libsubsys__random.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/entropy/libdrivers__entropy.a  modules/fatfs/lib..__modules__fs__fatfs.a  modules/nxp/lib..__modules__hal__nxp.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -L"/home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/thumb/v7e-m/nofp"  -L/home/ufechner/zephyrproject/zephyr/build/zephyr  -lgcc  -Wl,--print-memory-usage  zephyr/arch/common/libisr_tables.a  -mthumb  -mabi=aapcs  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -no-pie  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn && :
Memory region         Used Size  Region Size  %age Used
           OCRAM:          0 GB       768 KB      0.00%
            ITCM:          0 GB       128 KB      0.00%
           FLASH:       87668 B         2 MB      4.18%
            SRAM:       54576 B         0 GB       inf%
        IDT_LIST:         216 B         2 KB     10.55/home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `nocache' will not fit in region `SRAM'
/home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: region `SRAM' overflowed by 54576 bytes
collect2: error: ld returned 1 exit status
%
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/ufechner/zephyrproject/zephyr/build

See also: https://lists.zephyrproject.org/g/users/message/2034?p=,,,20,0,0,0::Created,,ocram,20,2,0,74673781

bdkrae commented 3 years ago

Hmm, weird. When I compile the blinky sample for teensy40 it looks like this (and works pretty fine):

-- west build: making build dir /Users/bernhardkramer/Projects/testapp_zephyr/app/build pristine
-- west build: generating a build system
Including boilerplate (Zephyr base): /Users/bernhardkramer/Projects/testapp_zephyr/zephyr/cmake/app/boilerplate.cmake
-- Application: /Users/bernhardkramer/Projects/testapp_zephyr/zephyr/samples/basic/blinky
-- Zephyr version: 2.4.99 (/Users/bernhardkramer/Projects/testapp_zephyr/zephyr)
-- Found Python3: /usr/local/bin/python3.8 (found suitable exact version "3.8.6") found components: Interpreter 
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
-- Board: teensy40
-- Cache files will be written to: /Users/bernhardkramer/Library/Caches/zephyr
-- Found toolchain: gnuarmemb (/usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major)
-- Found BOARD.dts: /Users/bernhardkramer/Projects/testapp_zephyr/zephyr/boards/arm/teensy4/teensy40.dts
-- Generated zephyr.dts: /Users/bernhardkramer/Projects/testapp_zephyr/app/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /Users/bernhardkramer/Projects/testapp_zephyr/app/build/zephyr/include/generated/devicetree_unfixed.h
Parsing /Users/bernhardkramer/Projects/testapp_zephyr/zephyr/Kconfig
Loaded configuration '/Users/bernhardkramer/Projects/testapp_zephyr/zephyr/boards/arm/teensy4/teensy40_defconfig'
Merged configuration '/Users/bernhardkramer/Projects/testapp_zephyr/zephyr/samples/basic/blinky/prj.conf'
Configuration saved to '/Users/bernhardkramer/Projects/testapp_zephyr/app/build/zephyr/.config'
Kconfig header saved to '/Users/bernhardkramer/Projects/testapp_zephyr/app/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 7.2.1
-- The CXX compiler identification is GNU 7.2.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/local/gcc_arm/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/bernhardkramer/Projects/testapp_zephyr/app/build
-- west build: building application
[1/126] Preparing syscall dependency handling

[121/126] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           OCRAM:          0 GB       768 KB      0.00%
            ITCM:          0 GB       128 KB      0.00%
           FLASH:       22148 B         2 MB      1.06%
            SRAM:          4 KB       128 KB      3.12%
        IDT_LIST:         168 B         2 KB      8.20%
[126/126] Linking C executable zephyr/zephyr.elf

But yes, it also states SRAM which is actually not present. I think I'll try the sdk toolchain tomorrow since this looks like the common workflow and in addition my compiler version is outdated.

ufechner7 commented 3 years ago

But yes, it also states SRAM which is actually not present.

It looks as if your toolchain is renaming DTCM to SRAM ... How this can be achieved was described here: https://lists.zephyrproject.org/g/users/message/2034?p=,,,20,0,0,0::Created,,ocram,20,2,0,74673781

But the Kconfig option DATA_DTCM does not exist any more in the current version of Zephyr ...

bdkrae commented 3 years ago

Since I'm working on Mac the Zephyr-SDK is not available. I installed GNU 9.2.1 which is nearly the one that Zephyr-SDK uses. Despite some warnings the build succeeds.

So I suggest to focus on the blinky sample to solve this issue. When I look at @ufechner7´s build output for this I'm confused about three things:

This SRAM line in the memory usage result is kind of funny. It seems that either ITCM section is renamed to SRAM (which is the standard behavior), or the OCRAM section is renamed to SRAM if I add CONFIG_DATA_OCRAM=y to file _teensy40defconfig. Both cases work, so I assume that SRAM more generally means "main RAM section" in this case and not "external SDRAM" as used by the mimxrt1060_evk.

ufechner7 commented 3 years ago

If I add CONFIG_DATA_OCRAM=y to file teensy40_defconfig I get the following error message:

Parsing /home/ufechner/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/ufechner/zephyrproject/zephyr/boards/arm/teensy4/teensy40_defconfig'
Merged configuration '/home/ufechner/zephyrproject/zephyr/samples/basic/blinky/prj.conf'

/home/ufechner/zephyrproject/zephyr/boards/arm/teensy4/teensy40_defconfig:19: warning: attempt to assign the value 'y' to the undefined symbol DATA_OCRAM

error: Aborting due to Kconfig warnings

Perhaps you are using a different branch of zephyr than I do?

ufechner@builder:~/zephyrproject/zephyr$ git status On branch master Your branch is up to date with 'origin/master'.

What is your output of the command: ~/zephyrproject/zephyr$ grep -RIs --include="." DATA_OCRAM

I have no hits.

This means I do not have this Kconfig section anywhere: http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.3.2/kconfig/CONFIG_DATA_OCRAM.html

ufechner7 commented 3 years ago

Finally it works :smiley: . I had to switch to the stable branch of zephyr:

cd zephyrproject/zephyr/ git checkout v2.4-branch

ufechner@builder:~/zephyrproject/zephyr$ west build -p -b teensy40 samples/basic/blinky
-- west build: making build dir /home/ufechner/zephyrproject/zephyr/build pristine
-- west build: generating a build system
Including boilerplate (Zephyr base): /home/ufechner/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: /home/ufechner/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.4.0 (/home/ufechner/zephyrproject/zephyr)
-- Found Python3: /usr/bin/python3.6 (found suitable exact version "3.6.9") found components: Interpreter 
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
-- Board: teensy40
-- Cache files will be written to: /home/ufechner/.cache/zephyr
ZEPHYR_TOOLCHAIN_VARIANT not set, trying to locate Zephyr SDK
-- Found toolchain: zephyr (/home/ufechner/zephyr-sdk-0.11.4)
-- Found dtc: /home/ufechner/zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/ufechner/zephyrproject/zephyr/boards/arm/teensy4/teensy40.dts
-- Generated zephyr.dts: /home/ufechner/zephyrproject/zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ufechner/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h
Parsing /home/ufechner/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/ufechner/zephyrproject/zephyr/boards/arm/teensy4/teensy40_defconfig'
Merged configuration '/home/ufechner/zephyrproject/zephyr/samples/basic/blinky/prj.conf'
Configuration saved to '/home/ufechner/zephyrproject/zephyr/build/zephyr/.config'
Kconfig header saved to '/home/ufechner/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/ufechner/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
CMake Deprecation Warning at /home/ufechner/zephyrproject/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

-- Configuring done
-- Generating done
-- Build files have been written to: /home/ufechner/zephyrproject/zephyr/build
-- west build: building application
[1/126] Preparing syscall dependency handling

[121/126] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           OCRAM:          0 GB       768 KB      0.00%
            ITCM:          0 GB       128 KB      0.00%
           FLASH:       21772 B         2 MB      1.04%
            SRAM:        4064 B       128 KB      3.10%
        IDT_LIST:         168 B         2 KB      8.20%
[126/126] Linking C executable zephyr/zephyr.elf
ufechner7 commented 3 years ago

But the next step doesn't work yet:

ufechner@builder:~/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
[0/1] cd /home/ufechner/zephyrproject/zephyr/build/zephyr/cmake/flash && /usr/bin/cmake -E echo

FATAL ERROR: either a pristine build is needed, or board teensy40 doesn't support west flash/debug (no ZEPHYR_RUNNERS_YAML in CMake cache)
ufechner@builder:~/zephyrproject/zephyr$
bdkrae commented 3 years ago

To flash I currently use teensy_loader_cli tool. You can find your hex-file there: .../build/zephyr/zehyr.hex if the build succeeded.

ufechner7 commented 3 years ago

I can confirm that the following steps work for me:

  1. check out and compile teensy_loader_cli from https://github.com/PaulStoffregen/teensy_loader_cli
  2. create a symbolic link to teensy_loader_cli in /usr/local/bin
  3. install 49-teensy.rules in /etc/udev/rules.d (download them from http://www.pjrc.com/teensy/49-teensy.rules ) and reboot
  4. press button on the teensy
  5. execute cd ~/zephyrproject/zephyr/build/zephyr teensy_loader_cli --mcu TEENSY40 zephyr.hex

So I am able to build a project and program the board. :smile:

ufechner7 commented 3 years ago

Next steps:

  1. bisect the Zephyr master branch to find out which commit broke teensy support
  2. I created my own fork of the zephyr clone of Bernard and will start to commit improvements there see: https://github.com/ufechner7/zephyr/tree/teensy4-branch/boards/arm/teensy4

Does this make sense?

ericrabinowitz commented 3 years ago

Hello @ufechner7 and @bdkrae , I am also interested in supporting Zephyr for the Teensy 4.1.
I followed your great work and was able to quickly build a working image under MacOs.

I also used the teensy_loader_cli: It was not stable and frequently error'd that it could not get permission to the usb port which required a minor edit to the source - I'll document that.

I ran a configuration to use the shell via the usb port.

My interest is in enabling the i2c ports. I have an i2c analyzer to test it so I would like to contribute to this project.

After that, I'd like to test SPI, then PWM.

bdkrae commented 3 years ago

Hello @ericrabinowitz, nice to hear, help is welcome.

For the i2c I've already added (but not tested) the pin multiplexing sections to pinmux.c, so you should be able to activate it by stating a section in the teensy41.overlay for your application, as well as CONFIG_I2C=y in prj.conf.

Little update from my side: I´m struggling with the ethernet peripheral for several evenings now, but no luck so far. Since ethernet uses hardware (the PHY-Chip) which is mounted on Teensy4.1, I think we must get this working before opening a pull request. Since lacking analyzing equipment I slowly running out of ideas. So I pushed my current state regarding the enet pinmux and hopefully someone can help us out. If someone could provide me a known-good example (hex-file) accessing the ethernet hardware on Teensy4.1 (e.g. via Paul Stoffregens libs) I would be able to proof my hardware is working correctly.

ufechner7 commented 3 years ago

Created a fairly complete documentation how to build and burn a basic example for Teensy 4.0 on Ubuntu: https://github.com/ufechner7/zephyr_teensy4_test

Tricky: cmake must be neither too new nor too old. And you need the 2.4 branch of Zephyr. Is this still true?

bdkrae commented 3 years ago

I updated my zephyr-fork and rebased the teensy4-branch. This brought up the SRAM problem mentioned above. Proposed solution is pushed to the branch. So the teensy4 board should now run with latest zephyr code.

Some thoughts about RAM placement

It seems that Zephyr always needs a memory region named sram. This line in teensy40.dts defines which physical memory section is mapped as sram:

chosen {
    zephyr,sram = &ocram;
    zephyr,itcm = &itcm;
    zephyr,dtcm = &dtcm;
    ...
};

In the build results this chosen memory (e.g. OCRAM) is then renamed to sram:

-- west build: building application
...
[186/191] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
            ITCM:          0 GB       128 KB      0.00%
           FLASH:       98840 B         8 MB      1.18%
            DTCM:          0 GB       128 KB      0.00%
            SRAM:       64176 B       768 KB      8.16%
        IDT_LIST:         232 B         2 KB     11.33%
...

Without additional code on application level, all stuff will be located in this "default" memory region. Although it may not be the best solution in terms of performance, I propose to set OCRAM section as chosen sram because of its size (768kB) and simplicity in use. Also this provides a good starting point for optional app level code-and-data-relocation which gives detailed control about RAM locations. To be able to use this function dts_fixup.h was added to the board folder. Dts_fixup files seems deprecated and may be removed in future but I haven't found an official solution right now.

Ethernet on Teensy 4.1

Ethernet interface is working now. I tested with various zephyr samples (dhcp, socket echo, html-server, ...), all compile and work without problems. Unfortunately it needs additional code in nxp-hal repository, see here.

ufechner7 commented 3 years ago

Congrats for fixing two difficult issues!

Question: Did you already create a pull request for your nxp-hal patch?

ufechner7 commented 3 years ago

@bdkrae I tested your latest commits and I can confirm that it works fine now with the master branch of Zephyr. I updated my installation instructions: https://github.com/ufechner7/zephyr_teensy4_test

I made a small change to the demo application to improve logging: https://github.com/ufechner7/zephyr_teensy4_test/commit/f6a77180f0d72f7532afe2034401f27b51fcc2f3

I will test more I/O components over Christmas, like serial, I2C, CAN, but I cannot test Ethernet because I do not have a Teensy 4.1 (yet).

ufechner7 commented 3 years ago

Using the example of @bdkrae or my fork, I am not able to toggle pin 2, while toggling the internal LED (pin 13) works fine.

The following code look suspicious to me:

/ {
    aliases {
            toggle = &toggle_gpio;
            sw0 = &button0;
    };

    app-gpios {
      compatible = "gpio-keys";
      toggle_gpio: toggle-gpio {
        gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>;
        label = "Toggle Pin 2";
      };
      button0: button_0 {
        gpios = < &gpio1 25 GPIO_ACTIVE_LOW >;
        label = "Push button switch 0 at Pin 23";
      };
  };
};

And in pin.c:

    LOG_INF("Pin thread started");
    LOG_INF(TOGGLE_GPIO_LABEL);
    LOG_INF("PIN %u", (int)TOGGLE_GPIO_PIN);

    while (true) {
        gpio_pin_set(dev, TOGGLE_GPIO_PIN, (int)pin_is_on);

        LOG_INF("PIN state changed: %u", (int)pin_is_on);

        pin_is_on = !pin_is_on;

        k_msleep(TOGGLE_TIME_MS);
    }

Debug output:

[00:00:00.420,000] <inf> sys: Started zephyr 2.4.99 on board teensy40.
[00:00:00.500,000] <inf> uart: Thread started
[00:00:00.500,000] <inf> but: Set up button at GPIO_1 pin 25
[00:00:00.500,000] <inf> led: Thread started
[00:00:00.500,000] <inf> pin: Pin thread started
[00:00:00.500,000] <inf> pin: GPIO_4
[00:00:00.500,000] <inf> pin: PIN 4
[00:00:00.500,000] <inf> pin: PIN state changed: 1
[00:00:00.993,000] <inf> pin: PIN state changed: 0
[00:00:01.486,000] <inf> pin: PIN state changed: 1
[00:00:01.979,000] <inf> pin: PIN state changed: 0

Why is the pin toggle_gpio in a section "compatible = "gpio-keys";" ? Perhaps thats the problem?

bdkrae commented 3 years ago

@ufechner This seems to be a pin mapping problem. It works fine on T4.1 or if I take another pin on T4.0:

    app-gpios {
      compatible = "gpio-keys";
      toggle_gpio: toggle-gpio {
        gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
        label = "Toggle Pin 14";
      };

But after that I still can see signal on pin 2 but still searching where it comes from.

I fixed up a bug this morning regarding a missing pinmux statement in teensy40_defconfig. Maybe this is important to know before starting with I2c etc.

ufechner7 commented 3 years ago

I tried to create a table of the GPIO and pin names: https://github.com/ufechner7/zephyr_teensy4_test (near the end of the page), but I do not think it is correct. I still do not understand how to do the mapping correctly. Main main source so far was the schematics at https://www.pjrc.com/store/teensy40.html .

I can confirm that toggling pin 14 works. But how do you know that teensy pin 14, on the schematics named AD_B1_02 is named gpio1 pin18 in the device tree? According to my table it should be pin2 in device tree, if I add 16 I get 18. Adding 16 also works for the switch pin. But why do I have to add 16?

bdkrae commented 3 years ago

I have already created this mapping table for zephyr documentation. Look at doc/index.rst in the board folder.

This mapping from teensy-pin-names to imxrt-pad-names to imxrt-port/pin-numbers follows no arithmetic pattern. You have to study the reference manual for imxrt starting from page 293 (Chapter 10 - External Signals and Pin Multiplexing).

ufechner7 commented 3 years ago

@bdkrae My table was based on the schematics, which had one or two wrong pin labels. I could fix them using your table. You can find my current test results at https://github.com/ufechner7/zephyr_teensy4_test . Conclusions:

  1. I understand now the pin numbering, which often - but not always - follows an arithmetic pattern.
  2. Most GPIO pins work, but not those with the label EMC_xx . Possible reason: They are initialized as SDRAM interface.

Any idea which code makes the EMC_xx pins inaccessible as GPIO pins? Edit: Perhaps it is this file: teensy4_sdram_ini_dcd.c But how to disable it?

ufechner7 commented 3 years ago

The issue mentioned above is fixed. I created a pull request, https://github.com/bdkrae/zephyr/pull/4 , all checks passed.

ufechner7 commented 3 years ago

I updated my table of the pins and the test status. Only difference to your table so far is pin 6. You write it is GPIO1_10, my finding is that is is GPIO2_10. Perhaps a typo?

bdkrae commented 3 years ago

I updated my table of the pins and the test status. Only difference to your table so far is pin 6. You write it is GPIO1_10, my finding is that is is GPIO2_10. Perhaps a typo?

Thanks for checking, typo is fixed.

  1. Most GPIO pins work, but not those with the label EMC_xx . Possible reason: They are initialized as SDRAM interface.

Any idea which code makes the EMC_xx pins inaccessible as GPIO pins? Edit: Perhaps it is this file: teensy4_sdram_ini_dcd.c But how to disable it?

This issue seems to be relatively complex. I digged a little deeper:

Confirming your analysis, issue comes back to the file you mentioned. It seems to provide a table containing a boot configuration which is accessed by hardware during boot. Asking the net returns that this file must be generated using NXPs MCUXpresso tools. Since T4.1 has optional external SRAM I see two ways:

The super correct way Get a correctly generated ...sdram_ini_dcd.c file and test with the SRAM option on T.4.1.

The chicken way There exists a Kconfig option DEVICE_CONFIGURATION_DATA which triggers the SRAM boot configuration and is enabled by default. If this is set to =n, both config files are obsolete and can be removed from the board folder. I provide this version in a separate branch.

@ufechner7 if you agree I would prefer the chicken way. This provides a clean solution without support for external RAM. The other way would take about 2 weeks and is probably rarely used. If someone needs in future this could be provided as a supplement.

ufechner7 commented 3 years ago

@bdkrae I can confirm that your branch works. It is a cleaner solution than my commit. Lets go for that!

At some point it would be nice to support additional QSPI memory for Teensy 4.1, but I am not even sure if the two files that you deleted would be required to achieve this goal. And yes, I would postpone that, step one should be to fully support Teensy 4.0, then Teensy 4.1 without extra memory and then QSPI memory.

If you make a new commit, can you also change ram: 128 to ram: 768 in the yaml files for Teensy 4.0 and Teensy 4.1?

Thank you!

ufechner7 commented 3 years ago

I created a second tutorial/ example on how to use the Zephyr shell with Teensy 4.0: https://github.com/ufechner7/teensy4_shell

bdkrae commented 3 years ago

Checked the CAN sample. After adding a can-primary define to teensy40.dts it worked fine with flexcan1 and flexcan2. I defined flexcan1 as chosen default. Find the code here.

With flexcan3 the sample doesn't work. But since this peripheral seems to have some special status acc. to manual, this seems acceptable (maybe a HAL issue).

ufechner7 commented 3 years ago

Any idea where this warning might be coming from: "[00:00:00.297,000] usb_dc_mcux_ehci: endpoint 0x1 already occupied"

Do you also see it when running your example?

ufechner7 commented 3 years ago

I updated https://github.com/ufechner7/teensy4_shell . I added sections about custom commands and inter thread communication.

Other topic: I can confirm that the flag GPIO_PULL_UP doesn't work . This is a missing feature or bug, not in the board definition, but in the driver for the CPU. It should be processed in the file drivers/gpio/gpio_imx.c , but it isn't.

Current code:

    if ((flags & (GPIO_SINGLE_ENDED
              | GPIO_PULL_UP
              | GPIO_PULL_DOWN)) != 0U) {
        return -ENOTSUP;
    }

In the file fpio_stm32.c you find this code:

        if ((flags & GPIO_PULL_UP) != 0) {
            *pincfg |= STM32_PINCFG_PULL_UP;
        } else if ((flags & GPIO_PULL_DOWN) != 0) {
            *pincfg |= STM32_PINCFG_PULL_DOWN;
        } else {
            *pincfg |= STM32_PINCFG_FLOATING;
        }

We need something similar for the imx CPU. 

Page 398 reference manual
IOMUXC_SNVS_SW_PAD_CTL_PAD_PMIC_STBY_REQ

Select one out of next values for pad: PMIC_STBY_REQ
00
01
10
11
13
PUE
PUS_0_100K_Ohm_Pull_Down — 100K Ohm Pull Down
PUS_1_47K_Ohm_Pull_Up — 47K Ohm Pull Up
PUS_2_100K_Ohm_Pull_Up — 100K Ohm Pull Up
PUS_3_22K_Ohm_Pull_Up — 22K Ohm Pull Up
bdkrae commented 3 years ago

Any idea where this warning might be coming from: "[00:00:00.297,000] usb_dc_mcux_ehci: endpoint 0x1 already occupied"

Do you also see it when running your example?

Yes, I also can see it. Most samples regarding usb use CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y in their prj.conf. Especially in combination with log outputs mapped to usb. So I think its ok to do the same and get rid of :-)

dakhouya commented 3 years ago

Hi! I was wondering if one of you two have some work done on the SPI? Btw thank you for all your work on this board, it will be a really nice add-on to the projet!

ufechner7 commented 3 years ago

SPI is next on my ToDo list... No guarantee, of course, but holidays in shutdown give some room for coding and testing...

bdkrae commented 3 years ago

I did some progress on SPI, very simple (and poorly tested) sample is here. I also updated pinmux.c in the teensy4 board defs.

Again there is some side load: In the soc´s Kconfig.soc the line select HAS_MCUX_LPSPI needs to be added:

config SOC_MIMXRT1062
    bool "SOC_MIMXRT1062"
    select HAS_MCUX_LPSPI
       ...

I will ask the nxp experts why this is missing, probably there is a reason. It´s included in most other soc´s declared in the same file.

bdkrae commented 3 years ago

26428 shows the answer for the SPI issue.

ufechner7 commented 3 years ago

Well, is it more complicated to add it here?

github-actions[bot] commented 3 years ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

ufechner7 commented 3 years ago

How can I reopen this issue? I mean, there is a commit that might close it, but that is not merged yet, it is waiting for review.

Stevenlawrencehoriba commented 1 year ago

can somebody confirm if SPI is now supported and what version of Zephyr is required for it. Or is it still being worked on? We are considering using Zephyr but we need SPI support as our custom board has various SPI chips , ADC extensions, thermocouples and DAC?

ottojo commented 1 year ago

can somebody confirm if SPI is now supported and what version of Zephyr is required for it. Or is it still being worked on? We are considering using Zephyr but we need SPI support as our custom board has various SPI chips , ADC extensions, thermocouples and DAC?

@Stevenlawrencehoriba We've been using a Teensy 4.1 with zephyr to interface with sensors via the LPSPI peripheral and have so for almost 2 years, so any recent release should support that :+1: