Zephyr Lfs
Lane Frisch
I just recently downloaded Jira software server. I was watching a tutorial video and the person mentioned Zephyr and I immediately went to the marketplace and and searched for it. But I could not find zephyr for jira test management but only custom report for zephyr. Tried for hours, but to no avail I can't find it
Hi Orfatt,
I just checked. It's likely you downloaded Jira 8.0. The unfortunate news is that Zephyr is not yet compatible with Jira 8. This means that it will not show up in your search results.
You can either look at other test suite alternatives, or consider downloading Jira 7.13 and installing Zephyr there.
Let us know how you go
It seems like you are using the latest 8.0 Jira server and certain apps yet not compatible with the latest version. If you are looking for Test Management app for Jira then you can have a look QMetry for Jira which is supported to latest Jira server 8.0 and I am personally using it.
I really like bare minimum examples as they are the best place to start when learning a new tool. Once one understands the bare minimum configuration, it is easier to pull in more complicated code from other examples. Often the simplest example will show all the structural elements so one can infer how a system works. This makes adding functionality easier to approach and there are just enough breadcrumbs to discover more sophisticated functionality. The example provided here is illustrate just that; A minimal example that will bring up enough to show you that the system is working. In the case of a Zephyr application on the RT685, I want to show that the serial shell is functional. I will be inserting tidbits here and there that are a bit beyond the scope of a board port as they will leave breadcrumbs to some unique Zephyr features and workflow.
For the case of the RT685, there is a nuance with external flash setup that requires the use of a custom board. For most MCUs with internal flash, the built in boards and do 99% of what you need to get started.
When 1st getting started, it is 100% OK to follow the instructions and start hacking on projects in the /samples directory. However, once I know I will be doing some real work on a project, I like to organize my project as a west manifest:
The key take-away once the manifest is created, getting your project development environment setup is just two commands (west init, west update) which makes life much easier over the long term. When you have multiple developers and multiple machines. Feel free to use the rt_super_z repository as starting point. This repo has the west manifest and a simple hello world project structure that I will be using for my board port.
It takes just a few minutes to go through the .yaml, defconfig, etc. to get your custom naming in place. I first focused on remapping text that was MIMXRT685_EVK to RT_SUPER
By default, Zephyr will look in its default boards directory when you kick off a build. To change this behavior, simply edit the CMakeLists.txt in your application folder and add this:
The RT685 represents a bit trickier case with board porting versus a traditional MCU with built in flash memory. There is a little more work to get Zephyr configured for the particular flash on our custom hardware. If your design kept the same memory configuration as the EVK (OctalSPI on FlexSPI Port B), then additional setup is not necessary. Flashless microcontrollers are both a blessing and a curse in this regard. The flexibility allows for better application customization but requires some more work up front to get your system setup for development
After power up or reset, the RT685 first executes a bootloader that is built into ROM. The RT685 ROM bootloader will attempt to access an external device on FlexSPI Port A or B (depending on the state ISP[2:0] pins) using a 1-bit IO mode. A special data structure is expected at a 0x400 offset from base of the of external flash memory. This boot header provides additional configuration details to the bootloader about the attached flash device. The ROM code will the reconfigure the interface per the boot header configuration. If the boot header does not exist or is invalid, the ROM will sit and wait for commands over USB or a UART interface.
During a Zephyr build, the boot header needs to get baked in so the generated binary can run properly after reset. Using the mimxrt685_evk board as a guide, we can modify the boot header for our custom board. Learning how to navigate the Zephyr source tree is an important aspect to being successful in development zephyr boards and drivers.
Here we are defining a new configuration option for the board that selects a different option NXP_IMX_RT6XX_BOOT_HEADER. The boot header is not actually located in the Zephyr source tree, rather in another NXP repository that gets pulled in when you first setup your Zephyr workspace. Note that this happens automatically when setting up Zephyr initially with west init and west update. One reason I really like using a west manifest as described previously is that all these dependencies coming in automagically.
The file flash_config.c contains a data structure with an attribute for the linker to place it in the correct location in flash. For our custom board, we will need to have our own copy of this file with the custom boot header. You can place your own version in the custom board directory.
The SuperMonkey uses a QSPI device for code storage. I had to patch the flexspi node in the board device tree overlay to indicate the new flash driver. As a reference, I actually used the device tree overlay from the i.MXRT1064 EVK board, This board uses the same QSPI flash as the SuperMonkey. Since the RT600 and RT1060 share the same FlexSPI IP, we can reuse the drives and device tree configuration. The device tree approach used by Zephyr starts paying dividends quite quickly when one needs to stitch together complicated system and one can reuse existing functionality.
There is one last config file that needs patched for our particular flash configuration on the SuperMonkey. Kconfig.defconfig inside of the board folder has a bunch of additional Kconfig options added you your project. There is a FLASH_SIZE configuration setting which defaults to a value pulled from the device tree. Using the syntax from the MIMXRT685 EVK, I modified it to pull from our modified device tree with QSPI. The Kconfig and device tree systems are very powerful and allows data to be pulled in at build time to provide configuration information to the build system and application code.
Keep in mind that at the end of the build process, the Kconfig files and device tree overlays turn into header files for your application to use to determine how the system is configured. Kconfig options can be driven from the device tree.
NXP provided board ports add a file pinmux.c to the build system. The purpose of this code is to provide a function that will setup the pin mux on the device to route desired functions to the physical pins on the IC. Before we take a look at the actual function that does the work, I wanted to point out a macro located at the bottom of the file.
In this pin mux implementation, you can see there is logic to conditionally include pin mux setup functions. This provides an example of using both Kconfig macros and device tree access macros. I mentioned before that both KConfig and device tree overlay files ultimately get translated into header files with macros that you can use to control your application code. Feel free to use as much or as little functionality as you want in the pin mux initialization code. It is a good idea to get any UART pins setup in this stage as you will be able to see printk, logging and shell output from the boot process. If you want, you can also do pin mux configuration in your application code but keep in mind you have the option to get pins initialized very early in the boot process.
Some platforms, such as the Nordic NRF families, have a great deal of flexibility in pin assignments where any digital function can be routed to any pin. In this case, NRF based device trees overlays can specify IO pins when peripherals nodes are instantiated. This makes modifying boards very simple with the device tree overlay mechanism. There is work in progress on a new pinctrl API that will allows similar behavior (within the limits of the particular chip) such that pin assignments can be performed in the device tree overlay. Keep a lookout for this feature in future release. For now you will need to perform pin muxing in the board initialization functions or in your application code.
Originating from the vibrant and revolutionary skateboarding scene of the 1970s, the Z-Boys redefined the boundaries of the sport. They shredded the streets of coastal Southern California, like a dancing zephyr, bringing an electrifying energy to their every move. Our caf pays homage to their audacious spirit. Just as the Z-Boys transcended conventions, Zephyr Caf aims to push the boundaries of traditional caf experiences, curating an atmosphere that fosters inspiration, camaraderie, and a sense of adventure. Join us at Zephyr Caf, where we invite you to embark on your own thrilling journey of flavors and experiences.
64591212e2