|
Re: Feedback requested on west manifest imports
Bolivar, Marti
Hello,
I've cut a new west pre-release today (0.6.99.dev5) which is feature complete for manifest imports. The main new feature since 0.6.99.dev4 is you can now use whitelists and blacklists to filter what projects you import, with a slight change of plan from the original proposal which is reflected in the documentation. We'd like to wrap up this west release in the next week or two, so if you have any more feedback, please let us know! This introductory file is still valid: https://github.com/mbolivar/my-zephyr-app/blob/master/README.rst The working documentation build is still here: https://builds.zephyrproject.org/zephyrproject-rtos/zephyr/20433/docs/guides/west/manifest.html#manifest-imports You may need to clear your browser cache and reload to get the latest build. Thanks, Marti
|
||
|
|
||
|
Sample app hello_world fails with z_arm_usage_fault in arm_core_mpu_enable when linked in RAM
robmcgurrin@...
Hi,
I am running on a nxp i.mx RT1064 eval, board mimxrt1064_evk. I created a custom linker file to link the app to SRAM. Here are the mods I made to the default linker file include/arch/arm/aarch32/cortex_m/scripts/linker.ld to force everything into SRAM: #ifdef CONFIG_XIP
#define ROMABLE_REGION SRAM
#define RAMABLE_REGION SRAM
#else
#define ROMABLE_REGION SRAM
#define RAMABLE_REGION SRAM
#endif
And then I added this to prj.confCONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y
CONFIG_CUSTOM_LINKER_SCRIPT="foo_linker.ld" When I run the app I get this fault: z_arm_usage_fault () at arch/arm/core/aarch32/fault_s.S:92 Any suggestions? Is there a better way to link my app to RAM? Thanks in advance, Rob
|
||
|
|
||
|
Re: Windows hosted development
Carles Cufi
Hi Peter,
As you will have noticed in our Getting Started Guide for Windows (https://docs.zephyrproject.org/latest/getting_started/index.html), we only really propose two solutions:
So I really don’t think that the statement “Getting started guide has too many open ended solutions for windows host” is accurate.
Regarding your requirements:
Windows IDE-support of some kind, such as visual studio or eclipse, including both build and debug working out of the box.
Those are easily achieved using the default cmd.exe instructions and then either Eclipse or VS Code. In fact, the section describing Eclipse debugging assumes running on a Windows host: https://docs.zephyrproject.org/latest/application/index.html?highlight=eclipse#eclipse-debugging
If you’d like to contribute instructions on how to use VS Code instead, please do so as a pull request. A starting point for that might be: https://github.com/bus710/zephyr-rtos-development-in-linux Most of the instructions in that GitHub repo should apply to Windows.
Regards,
Carles
From: users@... <users@...>
On Behalf Of PeterFromSwe via Lists.Zephyrproject.Org
Sent: 23 January 2020 15:45 To: users@... Cc: users@... Subject: [Zephyr-users] Windows hosted development
Hi
Are options for windows development documented somewhere. Getting started guide has too many open ended solutions for windows host I think.
There are so many alternatives such as Two separate physical boxes including everything. Turn chair to switch... Windows host with some remote desktop to physical machine. Windows host with some remote desktop to virtualmachine. Windows host with shared folders to virtualmachine and ssh. Windows host with linux subsystem Windows host with CMD (Possibly Linux host combinations as well but that is another topic...)
What is important to achieve is Windows IDE-support of some kind, such as visual studio or eclipse, including both build and debug working out of the box.
Riot has a convenient virtual machine (through vagrant) for builds and windows hosted debugging in eclipse supported through shared folders to vm. Maybe some inspiration from there?
Regards /Peter
|
||
|
|
||
|
SDK 0.11.0 Release
Kumar Gala
Hi,
Latest version of the SDK can be found here: https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.0 Please download and try things out and report any issues. General: • Replaced riscv32 tools with multilib for riscv64 toolchain • Dropped package of MIPS toolchain at this point • Removed x86 IAMCU toolchain • Improved install process / packaging of tools • can get individual arch toolchains • don't need to install as root • prompt for setting up env for you • Replaced multiple x86 toolchains with single x86_64 toolchain for 32 & 64-bit • Improve support for building on Ubuntu 18.04 host • ARM aarch64 support • Added SPARC support [experimental] OpenOCD: • Bump baseline to 20200116 • Removed support for Quark • Various ARC fixes/updates QEMU: • Bump to version 4.2.0 • Pull in Xilinx Cortex-R support • Pull in LEON2 SPARC support GCC: • Bumped to GCC 9.2.0 Host Tools: • Removed sound-open-firmware-tools as it wasnt used NEWLIB: • Added nano-variant builds • Enabled long-long support in full newlib build • Support newlib retargetable locking configuration Thanks to all that contributed fixes and enhancements to this version of the SDK. - k
|
||
|
|
||
|
Windows hosted development
Hi Are options for windows development documented somewhere. Getting started guide has too many open ended solutions for windows host I think. There are so many alternatives such as Two separate physical boxes including everything. Turn chair to switch... Windows host with some remote desktop to physical machine. Windows host with some
remote desktop to virtualmachine.
Windows host with shared folders to virtualmachine and ssh. Windows host with linux subsystem Windows host with CMD (Possibly Linux host combinations as well but that is another topic...) What is important to achieve is Windows IDE-support of some kind, such as visual studio or eclipse, including both build and debug working out of the box. Riot has a convenient virtual machine (through vagrant) for builds and windows hosted debugging in eclipse supported through shared folders to vm. Maybe some inspiration from there? Regards /Peter
|
||
|
|
||
|
UART DFU from nRF9160 to nRF52840
ljaynes87@...
I am looking to DFU an nrf52840 over UART from an nRF9160. The board is set up similar to the Thingy:91. The firmware will be downloaded over LTE on the 9160 and will need to be sent over to the 52840 via UART. Would be best place to start be the smp_svr sample? I know the sample instructions suggest using the mcumgr Command-Line Tool but I need to do this from the 9160. Does the smp_svr provide support for the 9160 to run the DFU commands and start an update on the 52840?
|
||
|
|
||
|
Re: API meeting: agenda
Carles Cufi
Hi all,
toggle quoted messageShow quoted text
I'd like to amend the agenda for today's meeting with the following PRs which have been waiting for resolution for a while: - PR: Validate pin ordinals in wrapper functions - https://github.com/zephyrproject-rtos/zephyr/pull/20115 - PR: Add discussion of terms that define API behavior - https://github.com/zephyrproject-rtos/zephyr/pull/21678 Regards, Carles
-----Original Message-----
|
||
|
|
||
|
Re: Signaling/Messaging Userspace from Kernel
Justin Huang
Thank you Andrew very much for the explanation! Very helpful.
Justin
From: Boie, Andrew P <andrew.p.boie@...>
Sent: Sunday, January 19, 2020 5:49 PM To: Justin Huang <justin.y.huang@...>; users@... <users@...> Subject: RE: [Zephyr-users] Signaling/Messaging Userspace from Kernel
If you look closely you will see that there is no capability for user mode functions to install a callback handler. This type of operation is supervisor mode only.
In the callback handler the application has registered from supervisor mode (typically at application initialization), use an IPC object to wake up a user thread for further processing.
There’s some example code in samples/userspace/prod_consumer
This is something we’d like to iterate on further so if you can come up with some scenarios that you don’t think are well supported please file GH enhancement tickets and assign to me for further discussion.
HTH, Andrew
From: users@... <users@...>
On Behalf Of Justin Huang
Hi,
Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?
I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.
Any thoughts/pointers/suggestions would be greatly appreciated.
Many thanks in advance and with kind regards,
Justin
|
||
|
|
||
|
API meeting: agenda
Carles Cufi
Hi all,
Tomorrow we will discuss an RFC that is ready to be merged, two items that were raised in last week's TSC and we will check on progress with the GPIO porting. - RFC (ready to merge): on-off service request and release - https://github.com/zephyrproject-rtos/zephyr/pull/21090 - Discussion: Stability documentation for APIs. Should it be documented in Doxygen? - Discussion: What exactly is subject to the API lifecycle deprecation policies described in https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html? - Options: - APIs only - APIs, Kconfig options, DeviceTree format - APIs, Kconfig options, DeviceTree format, subsystems, drivers, boards and SoCs - GPIO update (users) - https://github.com/zephyrproject-rtos/zephyr/issues/20017 Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit Regards, Carles
|
||
|
|
||
|
Re: Signaling/Messaging Userspace from Kernel
Boie, Andrew P
If you look closely you will see that there is no capability for user mode functions to install a callback handler. This type of operation is supervisor mode only.
In the callback handler the application has registered from supervisor mode (typically at application initialization), use an IPC object to wake up a user thread for further processing.
There’s some example code in samples/userspace/prod_consumer
This is something we’d like to iterate on further so if you can come up with some scenarios that you don’t think are well supported please file GH enhancement tickets and assign to me for further discussion.
HTH, Andrew
From: users@... <users@...>
On Behalf Of Justin Huang
Sent: Saturday, January 18, 2020 10:38 AM To: users@... Subject: [Zephyr-users] Signaling/Messaging Userspace from Kernel
Hi,
Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?
I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.
Any thoughts/pointers/suggestions would be greatly appreciated.
Many thanks in advance and with kind regards,
Justin
|
||
|
|
||
|
Signaling/Messaging Userspace from Kernel
Justin Huang
Hi,
Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?
I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.
Any thoughts/pointers/suggestions would be greatly appreciated.
Many thanks in advance and
with kind regards,
Justin
|
||
|
|
||
|
Re: Removing an item from the Device tree
Excellent solution. Thank you.
toggle quoted messageShow quoted text
Lawrence King Principal Developer +1(416)627-7302
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org> Sent: Wednesday, January 15, 2020 9:52 AM To: Lawrence King <lawrence.king@irdeto.com> Cc: Zephyr-users@lists.zephyrproject.org Subject: Re: [Zephyr-users] Removing an item from the Device tree You can use /delete-property/, something like: &uart0 { /delete-property/ rts-pin; /delete-property/ cts-pin; }; In your overlay should work. - k On Jan 15, 2020, at 8:49 AM, Lawrence King <lawrence.king@irdeto.com> wrote:
|
||
|
|
||
|
Re: Removing an item from the Device tree
Kumar Gala
You can use /delete-property/, something like:
toggle quoted messageShow quoted text
&uart0 { /delete-property/ rts-pin; /delete-property/ cts-pin; }; In your overlay should work. - k
On Jan 15, 2020, at 8:49 AM, Lawrence King <lawrence.king@irdeto.com> wrote:
|
||
|
|
||
|
Removing an item from the Device tree
I have a little problem with the device tree
In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:
&uart0 { compatible = "nordic,nrf-uart"; current-speed = <115200>; status = "okay"; tx-pin = <20>; rx-pin = <19>; rts-pin = <5>; cts-pin = <7>; };
Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:
&uart0 { compatible = "nordic,nrf-uart"; current-speed = <115200>; status = "okay"; tx-pin = <20>; rx-pin = <19>; /* rts-pin = <5>; */ /* cts-pin = <7>; */ };
And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.
What is the right way to remove RTS and CTS?
Lawrence King Principal Developer Connected Transport Market Unit +1(416)627-7302
CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.
|
||
|
|
||
|
Re: NVS on flash with erase page size 64k or larger
#nvs
Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
NVS on flash with erase page size 64k or larger #nvs
Hi.
64k sector is known limitation – it is not planed by us to support more right now. Although a patch witch configurable extension will be accepted. (a I know the code, it shouldn’t be hard to add such extension). AndrzejR
|
||
|
|
||
|
Re: Feedback requested on west manifest imports
Jørn Villesen Christensen <jvc@...>
On 14/01/2020 19:33, Bolivar, Marti wrote:
Hello Zephyr users and developers,Just had a read through your documentation; it looks nice. Have not tested the code, but judging from the documentation, it looks useful. Thank you :-) ~Jørn
|
||
|
|
||
|
DTS/Binding Issue migrating from 2.0.0 to 2.1.0
#nrf52832
matt@...
Hello Zephyr Users,
I have inherited a Zephyr project using nRF52832 from another developer and am having an issue migrating from 2.0.0 to 2.1.0. Its probably something simple but I'm fairly new to the devicetree system and can't seem to wrap my head around whats wrong here. In my custom board .dts file I have the following i2c configuration (note that the lis3dh is a zephyr-supported sensor driver and I have custom drivers/bindings for tca6507 and mcp47cvb12): Using OS v2.0.0 this built properly. After upgrading the OS to v2.1.0, I get the following error from `zephyr/scripts/dts/extract_dts_includes.py` on build: Exception: /soc/i2c@40003000/lis3dh@19 defines parent /soc/i2c@40003000 as bus master, but /soc/i2c@40003000 is not configured as bus master in bindingBy changing `compatible = "st,lis2dh", "st,lis3dh";` to `compatible = "st,lis2dh-i2c", "st,lis3dh-i2c";` in the .dts file this gets rid of the error for the lis3dh, but i get a similar error for `mcp47cvb12` and `tca6507`. For completeness, here are my .yaml files for these two bindings: mcp,mcp47cvb12.yaml: ti,tca6507.yaml: Alright so onto direct questions:
Matt
|
||
|
|
||
|
Feedback requested on west manifest imports
Bolivar, Marti
Hello Zephyr users and developers,
We've just uploaded a pre-release version of west to PyPI with a new feature: manifest imports. We would like your feedback! For a short README you can follow to try it out, see: https://github.com/mbolivar/my-zephyr-app This new feature lets you import projects from a west.yml file somewhere else (like zephyr/west.yml) into your own "downstream" west.yml file. The import gives you the zephyr repository and all its modules "for free": you do not have to copy/paste projects from zephyr/west.yml into your custom file and manually track changes. You can also add your own repositories or override individual modules if you've got your own forks, etc. See the README for links to more information. Please let us know what you think. We'd like to get feedback before the west 0.7 release, as making big changes after that time will be harder to do. Thanks! Marti
|
||
|
|
||
|
API meeting: Agenda
Carles Cufi
Hi all,
This week we will focus on a new RFC and GPIO. - RFC: New counter_get_value() API call - https://github.com/zephyrproject-rtos/zephyr/issues/21846 - GPIO: Update on progress - Proposal from Peter Bigot: Port remaining users without testing them on hardware (accepted) - Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530) - Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017 - Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!) - Any additional outstanding PRs to topic-gpio Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit Regards, Carles
|
||
|
|
||
|
Re: NXP RT1064 board and JLink Debugging
langrind@...
For what it's worth 8 months later, I was able to use PyOCD and the the built-in debugger on RT1064-EVK board to flash the Zephyr blinky program using MCUXpresso's flash programmer. Thus avoiding (for now) the need to buy a J-link probe. I didn't need to change much of anything.
What I did was use the MCUX option to save the flash command it uses to a file, and then tweaked the file so it's a script I can pass in whatever elf file I want: MCUX_WORKSPACE_LOC=$HOME/Documents/MCUXpresso_11.0.1_2563/workspace MCUX_FLASH_DIR0=/usr/local/mcuxpressoide-11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.bin.linux_11.0.1.201908271452/binaries/Flash MCUX_FLASH_DIR1=$HOME/Documents/MCUXpresso_11.0.1_2563/workspace/.mcuxpressoide_packages_support/MIMXRT1064xxxxA_support/Flash MCUX_IDE_BIN=/usr/local/mcuxpressoide-11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.bin.linux_11.0.1.201908271452/binaries/ $MCUX_IDE_BIN/crt_emu_cm_redlink --flash-load-exec $1 -p MIMXRT1064xxxxA --flash-driver MIMXRT1064.cfx -x $HOME/bin --flash-dir $MCUX_FLASH_DIR0 --flash-dir $MCUX_FLASH_DIR1 (some of that stuff may be unnecessary) I copied MIMXRT1064xxxxA_part.xml and MIMXRT1064xxxxA.xml from an MCUX project directory into ~/bin (hence the -x $HOME/bin in the command above) The script will flash the build/zephyr/zephyr.elf no problem. I didn't have to change any jumpers on the RT1064-EVK other than to set SW7 to boot from internal flash. I didn't have to change anything about how the zephyr sample program is built.
|
||
|
|