Hi Carles,

Thanks for your suggestion.

Now, I can download code and build it successfully.

Kernel: 2.2.0

SDK: 0.11.1

When I burn zephyr.hex into our chip (NRF51824) , and I encounter an issue.

In my previous version (kernel: 1.13   SDK: 0.9.5) , the issue is absence .

Could you give us some suggestions.

Thank You

Tommy

Hi there,

Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.

Please update your Python installation. If you are on Ubuntu something like this should work:

sudo apt install python3.7

sudo update-alternatives --config python3

Carles

Hi Zephyr,

I following Getting Started Guide .

https://docs.zephyrproject.org/latest/getting_started/index.html

In ‘west update’ , I encounter an error:

My PC is Ubuntu 16.04 LTS

Could you give us some suggestions

Thank You,

Tommy

Hi there,

Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.

Please update your Python installation. If you are on Ubuntu something like this should work:

sudo apt install python3.7

sudo update-alternatives --config python3

Carles

Hi Zephyr,

I following Getting Started Guide .

https://docs.zephyrproject.org/latest/getting_started/index.html

In ‘west update’ , I encounter an error:

My PC is Ubuntu 16.04 LTS

Could you give us some suggestions

Thank You,

Tommy

Hi Zephyr,

I following Getting Started Guide .

https://docs.zephyrproject.org/latest/getting_started/index.html

In ‘west update’ , I encounter an error:

My PC is Ubuntu 16.04 LTS

Could you give us some suggestions

Thank You,

Tommy

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

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

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