Upcoming Event: Zephyr Project: APIs - Tue, 02/11/2020 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 11 February 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878 Live meeting minutes: https://docs.google.com/
|
|
API meeting: agenda
Carles Cufi
Hi all,
The topics for today: - New API: DAC - https://github.com/zephyrproject-rtos/zephyr/pull/21805 - Overall post-GPIO triage and decision on what to tackle next 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: ARMv7 Cortex-A port for Xilinx Zynq7000
Carlo Caione
On 11/02/2020 15:33, Cufi, Carles wrote:
Hi Immo,Hi everyone, +CC Stephanos Ioannidis (Cortex-R guru) /snip Please comment on the existing Pull Requests and Issues and feel free to open your own Pull Requests to extend the Cortex-A support in Zephyr. I have copied Carlo Caione on this email, since he has been driving this effort so far.This please. Just a quick note that being the ARMv7/Cortex-A still a 32bit arch, that is probably closer to the current ARMv7/Cortex-R work than to my ARMv8/Cortex-A work. /snip The only catch is that one of our target hardware platforms is not yet supported, not only at the board/SoC level, but at the architecture level. We'd very much like to see Zephyr run on the dual core (SMP isn't a requirement, though) Cortex-A9 contained in the Xilinx Zynq7000 SoC, despite the lacking support for ARMv7 Cortex-A CPUs.Cortex-R architecture is supposed to be the arch closer to the ARMv8/Cortex-A if you want a starting point. /snip I'm now at a point at which I'd call the progress I've made up to now a working proof of concept. Here's what I've done so far:/snip It looks like you have done a lot already and you can definitely start pushing things upstream if they are ready for review and are self-contained / self-testable. The problem I encountered when working on the ARMv8 port was that upstream wants to have a fully working port before considering the work ready for merging. This means that you must be able to pass as many tests as possible (in theory all of them). The "push early push often" philosophy seems to not apply very well to the Zephyr project when dealing with new architectures. - The MMU is set up in the simplest possible way, with a page table consisting of nothing but 1 MB page entries. The part of the system's memory map where the RAM is located is configured as cacheable/bufferable, which is a requirement for any unaligned accesses (which can for example be found in the IP stack) to work. If the MMU isn't set up this way, the result is an illegal instruction exception. The rest of the memory map is set up as strongly ordered, covering areas such as the SLCR, the peripherial register space and the OCM.MMU work for ARMv8 is ongoing at https://github.com/zephyrproject-rtos/zephyr/pull/22446 - Added a corresponding QEMU target using the Zynq7000 template.Not a problem. That could be added later. - Caches not activated yet, as my own driver implementations don't contain any barriers yet where they probably should have some.Not a problem. - Only compiled with the GNU ARM Embedded Toolchain so far.Did you try to use the Zephyr SDK? - QEMU only tested to the point where the hello world and philosophers demos are apparently working with a basic IRQ/Timer/UART setup.What's the issue with the remaining tests? - SMP not addressed at all, but this feature isn't that important to me personally. A single 666 MHz core is quite capable by itself...SMP not required for an initial submission. - None of the security features are addressed, it's all secure mode-only for now.Not a problem. - The interrupt controller uses the same workaround as the GIC PL-400 in the Cortex-R port: store a pointer to the driver attached to vector [0] as there is no well-defined interrupt controller such as the Cortex-M's NVIC. Therefore, currently all interrupt vectors are offset by one.Currently worked out at https://github.com/zephyrproject-rtos/zephyr/pull/22718 - No high-level/scripted configuration of the MMU possible for now.Not required. - I'm currently forcing the ARM instruction set, there's currently no Thumb code being generated.Not a problem. - I haven't yet looked into whether any other FP ABIs can be supported or not, and there are currently no configuration options for the FPU such as on how to handle denormals.Not a problem. - Last but not least, the Zynq has some more peripherials generally supported by Zephyr but for which no drivers exist for now. As the processor system in the Zynq usually relies on *some* content in the programmable logic part (e.g. the AXI GPIO IP core), a driver for the Xilinx devcfg interface might be an integral part of the SoC support (although u-boot can handle this just as well), but there's also things like CAN, ADC, SPI, and the Zedboard features an OLED display...Are you able to use QEMU to emulate a working hardware? I'd like to contribute my work to the project, is this of any interest to all of you? Are there any must-have items I should tackle beforehand, probably most likely regaring testing? If so, I'd probably have to start merging my modifications into the current code base, as I'm still working on a code base acquired shortly before the arch/arm path was split up into AARCH32 and AARCH64. What would be the next steps in providing this to the community, considering that this is a bit more than just a stand-alone device driver?IMO the next step is making sure you are able to pass as many tests as possible in a QEMU environment when using the Zephyr SDK. If for some reason some tests are not passable just specify why is that when pushing the PR. This should be enough to convince people to review your code. Cheers and good luck :) -- Carlo Caione
|
|
Re: ARMv7 Cortex-A port for Xilinx Zynq7000
Carles Cufi
Hi Immo,
Thanks for your email and interest in the Zephyr project. Your contributions are certainly welcome!
Basic Armv8, Cortex-A support for Zephyr was merged recently: https://github.com/zephyrproject-rtos/zephyr/pull/20263
MMU support is an ongoing effort: https://github.com/zephyrproject-rtos/zephyr/pull/22446
You can track the progress of Cortex-A support here: https://github.com/zephyrproject-rtos/zephyr/issues/22411
Please comment on the existing Pull Requests and Issues and feel free to open your own Pull Requests to extend the Cortex-A support in Zephyr. I have copied Carlo Caione on this email, since he has been driving this effort so far.
Regards,
Carles
From: devel@... <devel@...>
On Behalf Of Immo Birnbaum via Lists.Zephyrproject.Org
Sent: 11 February 2020 14:54 To: devel@... Cc: devel@... Subject: [Zephyr-devel] ARMv7 Cortex-A port for Xilinx Zynq7000
Hi,
|
|
ARMv7 Cortex-A port for Xilinx Zynq7000
Immo Birnbaum
Hi,
I've been following the development of Zephyr ever since I attended the Embedded World in Nuremberg back in 2016, and I'd like to thank all those who have contributed to the system's current feature set and hardware support. The whole set of what the system now offers has made Zephyr a very attractive RTOS not only to me, but also to my employer, who has become interested in using it for several projects in the IoT field. The only catch is that one of our target hardware platforms is not yet supported, not only at the board/SoC level, but at the architecture level. We'd very much like to see Zephyr run on the dual core (SMP isn't a requirement, though) Cortex-A9 contained in the Xilinx Zynq7000 SoC, despite the lacking support for ARMv7 Cortex-A CPUs. So I've sat down, equipped with a Digilent Zedboard which to my knowledge can still be considered the de-facto standard evaluation board for the Zynq7000 and is readily available and a Lauterbach debugger, and started porting Zephyr to the v7/Cortex-A architecture. I considered this to be an interesting challenge as although I've used ARM-based systems for quite some time now (all the way back to my trusty ol' Apple Newton), my past development experience is on x86- and PowerPC-based systems and RTOSes like QNX or eCos. I'm now at a point at which I'd call the progress I've made up to now a working proof of concept. Here's what I've done so far: - Added cortex_a to arch/arm/core, derived from the cortex_r implementation. - Added Zynq7000 SoC and Zedboard definitions plus device trees. - Implemented a simple driver for the GIC PL-390 interrupt controller. - Re-used the existing Xilinx TTC and UART drivers. - Implemented a driver for the Xilinx GEM GBit Ethernet controller, which includes PHY initialization via MDIO and link monitoring. The PHY part contains some register accesses specific to the Marvell PHY used on the Zedboard, but just the PHY reset and auto-negotiation management is generic. All of the driver's features are configurable via menuconfig. - Implemented an interrupt-capable driver for the Xilinx AXI GPIO IP core, as the Zedboard features switches, pushbuttons and LEDs connected to the processor core via this IP core in the programmable logic part of the system. - A driver for GPIO connected via the EMIO interface shouldn't be too hard either, although the number of available pins might be an issue here. The AXI GPIO driver is limited to single channel operation (the IP core has an optional 2nd channel) as e.g. the pin mask of the GPIO callback struct are limited to 32 bits. - Enabled FPU support and saving of the FPU's registers during a context switch. The register saving is unconditional as Cortex-A doesn't seem to have an equivalent to the Cortex-M's CONTROL register and the flag indicating that the FPU registers are currently in use. With the GNU ARM Embedded Toolchain that I'm currently using, the FPU works using the softfp ABI. - The MMU is set up in the simplest possible way, with a page table consisting of nothing but 1 MB page entries. The part of the system's memory map where the RAM is located is configured as cacheable/bufferable, which is a requirement for any unaligned accesses (which can for example be found in the IP stack) to work. If the MMU isn't set up this way, the result is an illegal instruction exception. The rest of the memory map is set up as strongly ordered, covering areas such as the SLCR, the peripherial register space and the OCM. - Added a corresponding QEMU target using the Zynq7000 template. Still, the to-do-list has a quite a few points on it: - CMSIS for Cortex-A is not yet integrated, e.g. SLCR or FPU register accesses are hand-coded. - Caches not activated yet, as my own driver implementations don't contain any barriers yet where they probably should have some. - Only compiled with the GNU ARM Embedded Toolchain so far. - QEMU only tested to the point where the hello world and philosophers demos are apparently working with a basic IRQ/Timer/UART setup. - No tests from the testsuite have run so far. - SMP not addressed at all, but this feature isn't that important to me personally. A single 666 MHz core is quite capable by itself... - None of the security features are addressed, it's all secure mode-only for now. - The interrupt controller uses the same workaround as the GIC PL-400 in the Cortex-R port: store a pointer to the driver attached to vector [0] as there is no well-defined interrupt controller such as the Cortex-M's NVIC. Therefore, currently all interrupt vectors are offset by one. - No high-level/scripted configuration of the MMU possible for now. - I'm currently forcing the ARM instruction set, there's currently no Thumb code being generated. - I haven't yet looked into whether any other FP ABIs can be supported or not, and there are currently no configuration options for the FPU such as on how to handle denormals. - Last but not least, the Zynq has some more peripherials generally supported by Zephyr but for which no drivers exist for now. As the processor system in the Zynq usually relies on *some* content in the programmable logic part (e.g. the AXI GPIO IP core), a driver for the Xilinx devcfg interface might be an integral part of the SoC support (although u-boot can handle this just as well), but there's also things like CAN, ADC, SPI, and the Zedboard features an OLED display... I'd like to contribute my work to the project, is this of any interest to all of you? Are there any must-have items I should tackle beforehand, probably most likely regaring testing? If so, I'd probably have to start merging my modifications into the current code base, as I'm still working on a code base acquired shortly before the arch/arm path was split up into AARCH32 and AARCH64. What would be the next steps in providing this to the community, considering that this is a bit more than just a stand-alone device driver? Best regards from Germany, Immo
|
|
Zephyr 2.2.0-rc1 has been tagged
Hi Zephyr developers,
The the first Zephyr 2.2 release candidate (v2.2.0-rc1) has been tagged. All required features scheduled for the 2.2 release are now merged into master. As of now we are in the stabilization phase for the 2.2 release; the merge window is closed for new features and enhancements, and will remain closed until the release date. We will also start working on filling in the existing skeleton for the release notes. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the 2.2 release will require approval by TSC. As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers. Testing Zephyr master branch during the stabilisation phase is also requested; please, test the code base and file bug reports so they can be addressed before the release deadline. The full release log can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.2.0-rc1 More details about Zephyr releases is found here: https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management The final release is tentatively scheduled for February 28th. Thank you to everybody who contributed to this release! Johan
|
|
West 0.7.0 released, requires manual intervention on Ubuntu
Bolivar, Marti
Hello,
West 0.7.0 has been released. The main new feature since 0.6.x is the addition of "manifest imports", which let you pull in west.yml files from elsewhere into your own manifest file. You can upgrade in the usual ways: pip3 install west==0.7.0 # Windows and macOS pip3 install --user west==0.7.0 # Linux Please note that there is a problem with the upgrade on the version of pip3 which ships with Ubuntu 18.04. Other Linux distributions, macOS, and Windows are all upgrading successfully. On Ubuntu only, you will need to choose from one of the following workarounds to upgrade west: 1. Remove the old west before upgrading, like this: $ pip3 show west | grep Location: | cut -f 2 -d ' ' /home/foo/.local/lib/python3.6/site-packages $ rm -r /home/foo/.local/lib/python3.6/site-packages/west $ pip3 install --user west==0.7.0 2. Install west in a virtual environment using a more recent version of pip3, e.g. using the venv module: https://docs.python.org/3/library/venv.html Further details in this issue: https://github.com/zephyrproject-rtos/west/issues/373 And in particular, this comment: https://github.com/zephyrproject-rtos/west/issues/373#issuecomment-583489272 Thanks, Marti
|
|
Re: clang toolchain doesn't failing to compile properly
Sigvart Hovland
https://github.com/zephyrproject-rtos/zephyr/blob/e3d39032eb91973c6fc696696d442fa0f61f92c4/arch/arm/core/aarch32/thread.c#L449
toggle quoted messageShow quoted text
Pretty sure it was around here. Could be that I'm wrong(haven't found the code that worked I think I deleted the branch) where start_of_main_stack would disappear when I used Clang in combination with GNU tools. Or it was one of _current = main_thread; since it worked when you turned of multi-threading. My biggest gut feeling is that it is start_of_main_stack since it only has assignments and would be viewed from the compiler as never used if it does not look at the assembly.
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org> Sent: Thursday, February 6, 2020 4:58 PM To: Hovland, Sigvart <Sigvart.Hovland@nordicsemi.no> Cc: akira.kato@biosensics.com; devel@lists.zephyrproject.org Subject: Re: [Zephyr-devel] clang toolchain doesn't failing to compile properly Sigvart, I’d really appreciate if you could try and remember where you might have added that print to deal with the in-line asm getting optimized away. - k On Jan 31, 2020, at 5:54 AM, Sigvart Hovland <sigvart.hovland@nordicsemi.no> wrote:
|
|
Re: clang toolchain doesn't failing to compile properly
Kumar Gala
Sigvart,
toggle quoted messageShow quoted text
I’d really appreciate if you could try and remember where you might have added that print to deal with the in-line asm getting optimized away. - k
On Jan 31, 2020, at 5:54 AM, Sigvart Hovland <sigvart.hovland@nordicsemi.no> wrote:
|
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 02/06/2020 8:00am-9:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 6 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/993312203 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join Zoom Meeting
|
|
Event: Zephyr Toolchain Working Group
#cal-invite
devel@lists.zephyrproject.org Calendar <devel@...>
Zephyr Toolchain Working Group When: Where: Organizer: Maureen Helm Description: Zephyr Working Group is inviting you to a scheduled Zoom meeting. Topic: Zephyr Toolchain Working Group Join Zoom Meeting Meeting ID: 967 549 258 One tap mobile Dial by your location
|
|
add pyocd user scripy cause pylint issue
FrankLi
Hi guys,
Since to flash on mm_swiftio is not supported by pyocd, I want to override the flash algorithm for an external flash by using user script. The user script use pyocd global "target" cause pylint issue in zephyr Check.
Is there any way to solve or bypass this problem? Thanks!You can find the modify https://github.com/zephyrproject-rtos/zephyr/pull/22536 Add refer to https://github.com/mbedmicro/pyOCD/blob/master/docs/user_scripts.md
|
|
Dev-Review Meeting Agenda
Kumar Gala
All,
Meeting Minutes: https://docs.google.com/document/d/1vfgwa1oRVuLA0f4VZW9pMBD2n2kf7ZgI9QCw_4s01gA/edit?usp=sharing Agenda: GitHub PR/Issues: Add support for SiLabs EFR32BG13P SoC [Piotr M] - https://github.com/zephyrproject-rtos/zephyr/pull/22423 Device Tree: Roundup of DT agenda items for the dev review meeting from nordic: - who will work on a zephyr docs PR which includes the conclusions from our last meeting? - doing system initialization in DT dependency ordinal order (I want to discuss this) - issue roundup: - https://github.com/zephyrproject-rtos/zephyr/issues/19285 - https://github.com/zephyrproject-rtos/zephyr/issues/21369 (edited) #19285 devicetree: fixed non-alias reference to specific nodes #21369 devicetree: clearly define constraints on identifier/property name conflicts
|
|
New MCUBoot mailing list
Fabio Utzig <utzig@...>
Hi,
The MCUboot mailing list has been recently moved. We did not re-subscribe previously subscribed users, so for those interested it is now hosted here: https://groups.io/g/mcuboot Cheers, Fabio
|
|
The topic-gpio branch has been merged to master
Carles Cufi
Hi all,
As of this morning the 313 commits in the topic-gpio branch have been merged into Zephyr's master branch. What this means for you if: a) You are a GPIO API user: - Big chunks of the existing API have been deprecated, leading to deprecation build warnings. You should port your application to the new GPIO API as soon as possible, although you have 2 full Zephyr releases until the deprecated API is finally removed. Please refer to Peter Bigot's "porting guide" in this GitHub comment for additional information: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 b) You have outstanding, unmerged Pull Requests: - The Pull Requests may show green CI, but that is misleading. We encourage you to rebase your Pull Request as soon as possible against the current master and push. - If your Pull Request makes use of the GPIO API, it will not pass CI due to deprecation warnings. There is no solution but to port your code to the new GPIO API. If you are on a deadline for 2.2 feature freeze ping us on the #gpio channel on Slack to see if we can help. c) You are a maintainer with merge rights: - You need to make sure that CI has been rerun after the topic-gpio merge happened and *before* you merge any Pull Request to master Additional information about the merge process can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/21789 Finally I want to thank everybody who contributed to this effort, which has spanned many months and several hundred commits. Special mention to Piotr Mienkowski and Peter Bigot, whose dedication to getting this done has made it possible to merge this branch in time for the 2.2 release. Regards, Carles
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 02/04/2020 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 4 February 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878 Live meeting minutes: https://docs.google.com/
|
|
API meeting: Agenda
Carles Cufi
Hi all,
Today we will talk first about GPIO and the merge of the topic-gpio branch to master: - Cleanup the public and private API with typedefs - Testing status - Issues with master CI that might prevent the merge to master - https://github.com/zephyrproject-rtos/zephyr/issues/21789 Additionally I'd like to discuss: - RFC: API Change: clock_control - https://github.com/zephyrproject-rtos/zephyr/issues/22424 - Ability to use an API with device without extending its own API - https://github.com/zephyrproject-rtos/zephyr/issues/22415 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: support for multi instance zephyr in same soc
Carles Cufi
Hi Scott,
Yes, the whole “board” concept needs an overhaul to become instead “instances” or “targets” as you say. In the nRF5340, which is a dual-core asymmetric Cortex-M33, we used “cpuapp” and “cpunet” to distinguish between the application core and the network core: https://github.com/zephyrproject-rtos/zephyr/tree/master/boards/arm/nrf5340_dk_nrf5340
Carles
From: devel@... <devel@...>
On Behalf Of Scott Branden via Lists.Zephyrproject.Org
Sent: 04 February 2020 02:23 To: Kumar Gala <kumar.gala@...> Cc: devel@... Subject: Re: [Zephyr-devel] support for multi instance zephyr in same soc
Thanks Kumar - we will go with this convention for naming the target. ie board_cpu. It will work out as long as there are not multiple cpu's on the same board that need different zephyr builds. At that point you would need board_cpu_n
Really "boards" directory should be renamed "targets"?
On Sun, Feb 2, 2020 at 9:01 AM Kumar Gala <kumar.gala@...> wrote:
|
|
Re: support for multi instance zephyr in same soc
Marc Herbert
Interesting, some parts of the documentation gave me the (wrong?) impression that a BOARD allowed some level of variation and configuration at build time:
toggle quoted messageShow quoted text
https://docs.zephyrproject.org/latest/guides/dts/index.html#input-and-output-files - "Optional DTS format files which override BOARD.dts" - "Extensible with DTS_ROOT" https://docs.zephyrproject.org/latest/guides/porting/board_porting.html#default-board-configuration - "This default board configuration is subordinated to features activation which is application responsibility..." - "... the board’s default Kconfig configuration, which is used in application builds unless explicitly overridden." Marc
On 3 Feb 2020, at 17:22, Scott Branden <sbranden@gmail.com> wrote:
|
|
Re: support for multi instance zephyr in same soc
Scott Branden
Thanks Kumar - we will go with this convention for naming the target. ie board_cpu. It will work out as long as there are not multiple cpu's on the same board that need different zephyr builds. At that point you would need board_cpu_n Really "boards" directory should be renamed "targets"?
On Sun, Feb 2, 2020 at 9:01 AM Kumar Gala <kumar.gala@...> wrote: This has been a long standing issue. Since these are both ARM you can get away with doing something similar to how we handle building different images for SoCs that have 2 different M-class cores.
|
|