1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Immo Birnbaum
 
Edited

Hi Carlo,

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.

To my knowledge, the most significant differences are MMU vs. MPU and the newer interrupt controller in the Cortex-R, which expanded the old controller's basic secure/non-secure model into a multiple-priority model. Other than the FPU stuff, I didn't mess much with the assembly code that implements the context switch.

Did you try to use the Zephyr SDK?

My memory on that is a bit hazy, as I started back in November, but to my best recollection I followed the standard 'getting started' procedure at first, including the SDK setup. Yet, the first Zephyr-compatible board I came across at work was an NXP eval kit based around a Cortex-M33 (the LPCXPRESSO55S69), and compiling the demos with the supplied cross-compiler failed as it did not yet support the M33. That's how I ended up with the alternative ARM toolchain as described in the "3rd party toolchains" section. I can easily set up a fresh development VM and give the Zephyr SDK another try, as the A9 is a proven piece of hardware that has long been supported.

What's the issue with the remaining tests?

Fortunately, there's no technical issue here - it's just an issue of me not yet having had time to read up on how the test framework works.

Are you able to use QEMU to emulate a working hardware?

The QEMU template for the Zynq7000 supports all important components (GIC, TTC, UART) plus the two Ethernet controllers. There's also USB which I'm not looking at right now, plus some SPI/I2C support mostly relevant for flash memory connectivity. While the bitstream programming of the FPGA can be simulated, IP cores such as the GPIO don't seem to be on board, so GPIO won't work while the rest will.

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.
Will do, but prior to that I'll most likely start by updating my codebase and merging my changes into the new AARCH32/AARCH64 structure. I guess with separate assembly code for each architecture's context switch, that part might be a lot more uncluttered compared to what I have right now.

Thanks for the advice!
Regards,
Immo
Xtensa architecture support in LLVM

Ivan Grokhotkov <ivan@...>
 

Hi,

Since Zephyr RTOS includes support for the Xtensa architecture, I'd like to bring attention to the Xtensa LLVM backend, which is currently in review on LLVM Phabircator. This backend was developed by Espressif, with the initial targets being ESP8266 and ESP32 chips.
As some of the Zephyr developers (mainly from Intel) have access to the Xtensa architecture documentation, we would like to ask for reviews on this series of patches.
I think having Xtensa supported in LLVM would also be beneficial for the Zephyr project, as the LLVM backend allows adding new Xtensa core configurations in a much more straightforward way, compared to GCC.

Links to the patch series:

D64826: [Xtensa 1/10] Recognize Xtensa in triple parsing code. https://reviews.llvm.org/D64826
D64827: [Xtensa 2/10] Add Xtensa ELF definitions. https://reviews.llvm.org/D64827
D64829: [Xtensa 3/10] Add initial version of the Xtensa backend. https://reviews.llvm.org/D64829
D64830: [Xtensa 4/10] Add basic *td files with Xtensa architecture description. https://reviews.llvm.org/D64830
D64831: [Xtensa 5/10] Add Xtensa MCTargetDescr initial functionality. https://reviews.llvm.org/D64831
D64832: [Xtensa 6/10] Add Xtensa basic assembler parser. https://reviews.llvm.org/D64832
D64833: [Xtensa 7/10] Add Xtensa instruction printer. https://reviews.llvm.org/D64833
D64834: [Xtensa 8/10] Add support of the Xtensa shift/load/store/move and processor control instructions. https://reviews.llvm.org/D64834
D64835: [Xtensa 9/10] Add basic support of Xtensa disassembler. https://reviews.llvm.org/D64835
D64836: [Xtensa 10/10] Add relaxations and fixups. Add rest part of Xtensa Core Instructions. https://reviews.llvm.org/D64836

The patches are maintained at https://github.com/espressif/llvm-project. This repository can also be used to submit issues.

Thank you,
Ivan Grokhotkov
Espressif Systems
Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Immo Birnbaum
 

Hi Carles,

thanks for those initial pointers! I'll also keep an eye on what's going on regarding the Cortex-R port besides the ARMv8 Cortex-A port, as Carlo mentioned, the ARMv7 Cortex-A and the Cortex-R are quite close relatives.
Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Henrik Brix Andersen
 

Hello Immo,

That is great news! Thank you for working on this.

I started on add Cortex-A9/Zynq7000 support to Zephyr a couple of weeks ago, but stalled it while awaiting the Cortex-R port (which is very similar) to stabilise.
I am very interested in this port and I would be more than happy to help in reviewing and testing a pull request for adding this to mainline Zephyr.

I started out with qemu and the xilinx-zynq-a9 machine defintion, but did not get as far as what you describe below.

Please keep us posted on any progress and let me know if you need help in creating a pull request for this.

Best regards,
Brix
--
Henrik Brix Andersen

On 11 Feb 2020, at 14.53, Immo Birnbaum <immo.birnbaum@freenet.de> wrote:

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
Re: The topic-gpio branch has been merged to master

Piotr Mienkowski
 

Hi all,

I would like to provide a bit more information about the recent change
to the GPIO API.

The main drive behind the rework was to support GPIO DTS bindings
https://github.com/torvalds/linux/blob/master/include/dt-bindings/gpio/gpio.h
as known from Linux DTS. That meant introduction of new flags:

- GPIO_ACTIVE_HIGH, GPIO_ACTIVE_LOW
- GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE
- GPIO_PULL_UP, GPIO_PULL_DOWN

All of the above flags are meant to be located in the DTS, typically at
the board level. This allows to decouple application / driver code from
the properties of the hardware they happen to work with.

As an example, if gpio pin is connected to a button it could be
described in the board DTS file as follows:

    button0: button_0 {
        gpios = <&gpio0 17 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
        label = "Push button 0";
    };

It means that the GPIO driver will need to enable a pull up on a pin and
that the pin is active low. All this is transparent to the application
which simply needs to pull in the DTS flags when configuring the pin. To
access the flags generated from the DTS at the application level it is
best to use the so called DT_ALIAS defines. The special DTS aliases node

aliases {
    sw0 = &button0;
};

is a convenient way to give generic application level names to specific
DTS nodes.

The resulting call in the application code could look like this

    gpio_pin_configure(dev_button, DT_ALIAS_SW0_GPIOS_PIN,
DT_ALIAS_SW0_GPIOS_FLAGS | GPIO_INPUT);

To access the flags at the driver level we should ideally be using the
so called DT_INST defines. But here the situation is a little bit more
complicated.

The two new flags that had the biggest impact on the shape of the new
GPIO API are GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW. They define pin
active level known in the new API as logical pin level. From the
documentation

"If pin is configured as Active High, a low physical level will be
interpreted as logical value 0. If pin is configured as Active Low, a
low physical level will be interpreted as logical value 1."

At the application level the two flags encode cause -> effect
relationship. In the above example of a button the GPIO_ACTIVE_LOW flag
means that regardless of the specific design of the hardware button and
the circuitry surrounding it if the button is pressed the pin will see
low physical value. This relationship should be defined in DTS bindings.

This level of abstraction is useful not only when building a generic
application that reacts to the press of a button or has to turn on an
LED but also when building a driver for a well documented external
hardware module. Such module, e.g. a sensor connected over I2C bus, can
provide an active high interrupt pin that should be routed to a GPIO pin
on a SoC. A driver for the hardware module which is using pin logical
rather than pin physical level allows for the possibility that the
interrupt signal from the hardware module is routed to the GPIO pin via
an inverter, e.g. because external module is in a different power
domain. Once again the active level of the interrupt pin will be defined
in DTS and allows the driver code to be decoupled from the specifics of
the PCB design.

An application can get / set pin logical level by calling gpio_pin_get,
gpio_pin_set functions. It is still possible to access pin physical
level, if required, by calling gpio_pin_get_raw, gpio_pin_set_raw functions.

All these concepts are not entirely new. The old GPIO API provided flags
such as GPIO_INT_ACTIVE_LOW and GPIO_POL_INV which aimed to achieve
similar goal. However, they were not very well documented and not
consistently implemented.

Other modifications to the GPIO API include:

- Interrupt configuration was moved to the dedicated
gpio_pin_interrupt_configure() function. Configuring interrupts via
gpio_pin_configure() is still supported but this feature will be removed
in future releases.

- New set of flags allows to define arbitrary interrupt configuration
(if supported by the driver) based on pin physical or logical levels.
The include/drivers/gpio.h contains in fact two sets of interrupt
related flags, one targeted at the driver developers and the other at
the users of the API. Only the latter is documented at
https://docs.zephyrproject.org/latest/reference/peripherals/gpio.html
and should be used by the applications.

- New set of port functions that operate simultaneously on multiple pins
that belong to the same controller.

- New set of flags to configure pin as input, output or in/out as well
as set output initial state.

Majority of the old GPIO API has been deprecated and, to limit impact on
the code size, re-implemented in terms of the new API. While the care
was taken to preserve backward compatibility due to the scope of the
work it was not possible to fully achieve this goal.

We recommend to switch to the new GPIO API as soon as possible.

Areas where the deprecated API may behave differently to the original
old implementation are:

- Configuration of pin interrupts, especially involving
GPIO_INT_ACTIVE_LOW and GPIO_POL_INV flags.

- Behavior of gpio_pin_configure() when invoked without interrupt
related flags. In the new implementation of this deprecated
functionality the interrupts remain unmodified. In the original
implementation some of the GPIO drivers would disable the interrupts.

Regards,
Piotr
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

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY

 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing
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.
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.
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.
- No tests from the testsuite have run so far.
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,

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

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

Johan Hedberg
 

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

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:

What target are you trying to compile for?

From the stack overflow thread I find
Target: x86_64-pc-linux-gnu

Then some references to the Nordic HAL. So I’m just going to assume you are trying to target nrf52xx so what should be noted is that you can’t use the LLVM linker also I think you need to use the arm-none-eabi assembler also if you are targeting an ARM cortex-m platform.

I got it to compile with LLVM and GCC/GNU assembler/linker. You will have to add an config in the /home/zephyrproject/modules/hal/nordic/nrfx/mdk/compiler_abstraction.h:66 that you are using Clang (ARMCC > 6 is an ARM version of Clang) I think it’s something like __CLANG or it could be __llvm__ or __clang__.

Some discussion on it here:

https://github.com/zephyrproject-rtos/zephyr/pull/19120

Some of the changes are added here
https://github.com/zephyrproject-rtos/zephyr/pull/19218

Based on https://github.com/galak/zephyr/tree/llvm I believe.

I don’t have my old branch where I got it to build unfortunately so I don’t have anything direct to link too but was able to build and run hello world with clang + arm-none-eabi linker and assembler. Also I don’t remember the exact point in the code where I had to add a print for it to work. There was some in-line assembly which was optimized out by clang if it was not used so I added a print and it would work. Sorry for not being very helpful thought I would just give you some information.


From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Akira Kato via Lists.Zephyrproject.Org
Sent: Thursday, January 30, 2020 7:13 PM
To: devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] clang toolchain doesn't failing to compile
properly

Hi,
I don't know if this is the proper place to ask technical question
about zephyr but I have tried stackoverflow and started github issue
with no help. I am new to zephyr so I followed the getting started
guide. Here's the post I made:
https://stackoverflow.com/questions/59976179/zephyr-error-using-llvm-w
orks-fine-with-default-toolchain The problem is described there with
the error logs.
Thanks,
Akira
Re: clang toolchain doesn't failing to compile properly

Kumar Gala
 

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:

What target are you trying to compile for?

From the stack overflow thread I find
Target: x86_64-pc-linux-gnu

Then some references to the Nordic HAL. So I’m just going to assume you are trying to target nrf52xx so what should be noted is that you can’t use the LLVM linker also I think you need to use the arm-none-eabi assembler also if you are targeting an ARM cortex-m platform.

I got it to compile with LLVM and GCC/GNU assembler/linker. You will have to add an config in the /home/zephyrproject/modules/hal/nordic/nrfx/mdk/compiler_abstraction.h:66 that you are using Clang (ARMCC > 6 is an ARM version of Clang) I think it’s something like __CLANG or it could be __llvm__ or __clang__.

Some discussion on it here:

https://github.com/zephyrproject-rtos/zephyr/pull/19120

Some of the changes are added here
https://github.com/zephyrproject-rtos/zephyr/pull/19218

Based on https://github.com/galak/zephyr/tree/llvm I believe.

I don’t have my old branch where I got it to build unfortunately so I don’t have anything direct to link too but was able to build and run hello world with clang + arm-none-eabi linker and assembler. Also I don’t remember the exact point in the code where I had to add a print for it to work. There was some in-line assembly which was optimized out by clang if it was not used so I added a print and it would work. Sorry for not being very helpful thought I would just give you some information.


From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Akira Kato via Lists.Zephyrproject.Org
Sent: Thursday, January 30, 2020 7:13 PM
To: devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] clang toolchain doesn't failing to compile properly

Hi,
I don't know if this is the proper place to ask technical question about zephyr but I have tried stackoverflow and started github issue with no help. I am new to zephyr so I followed the getting started guide. Here's the post I made: https://stackoverflow.com/questions/59976179/zephyr-error-using-llvm-works-fine-with-default-toolchain
The problem is described there with the error logs.
Thanks,
Akira
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
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf
Event: Zephyr Toolchain Working Group #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr Toolchain Working Group

When:
Thursday, 20 February 2020
9:00am to 10:00am
(UTC-06:00) America/Chicago
Repeats: Every 2 weeks on Thursday, through Thursday, 23 July 2020

Where:
https://zoom.us/j/967549258

Organizer: Maureen Helm

Description:

Zephyr Working Group is inviting you to a scheduled Zoom meeting.

Topic:  Zephyr Toolchain Working Group
Time: Feb 20, 2020 09:00 AM Central Time (US and Canada)
        Every 2 weeks on Thu, until Jul 23, 2020, 12 occurrence(s)
        Feb 20, 2020 09:00 AM
        Mar 5, 2020 09:00 AM
        Mar 19, 2020 09:00 AM
        Apr 2, 2020 09:00 AM
        Apr 16, 2020 09:00 AM
        Apr 30, 2020 09:00 AM
        May 14, 2020 09:00 AM
        May 28, 2020 09:00 AM
        Jun 11, 2020 09:00 AM
        Jun 25, 2020 09:00 AM
        Jul 9, 2020 09:00 AM
        Jul 23, 2020 09:00 AM
Please download and import the following iCalendar (.ics) files to your calendar system.
Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

Join Zoom Meeting
https://zoom.us/j/967549258

Meeting ID: 967 549 258

One tap mobile
+16699006833,,967549258# US (San Jose)
+16465588656,,967549258# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        855 880 1246 US Toll-free
        877 369 0926 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 967 549 258
Find your local number: https://zoom.us/u/abfRKTHWtN

Calendar
Calendar

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. 
 
************* Module pyocd_user
boards/arm/mm_swiftio/burner/pyocd_user.py:9:15: E0602: Undefined variable 'target' (undefined-variable)
    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
1301 - 1320 of 8033