Threadx on Raspberry pi

[raghu-elastics]

Hello

Is threadX supported on raspberry pi 3 b+ ? I see there is support for cortex A53 which is the core available on the board, but is there any listed steps to try out on the board?

[amgross]

Take a look at #3 maybe it will help you

[raghu-elastics]

Thanks @amgross , the last post in there suggest broadcom internal have running threadx on RPi, but its not available in this repo?

Currently I have raspi with u-boot, tried running threadx_initialize_kernel_setup_test, it doesnt go through.

[lduesing]

Threadx does run on the graphics core of raspberry pi, as far as I read. But not on the normal cpu.

[dan-meyer]

FWIW I spent some time on trying to create an a72 build with aarch64 tools and found a long list of problems. I think that it would be a lot of work and rewrite to get arm64 working. I have a todo to see if I can get a build for aarch32 on bcm2711.

[williamelamie]

Are the problems ThreadX-related or tool related? Just curious...

[fdesbiens]

Hello @raghu-elastics, and my apologies for the very long delay in getting back to you. I'm Frédéric Desbiens, the Eclipse ThreadX project lead at the Eclipse Foundation, and I am going through the older issues in this repository.

The short answer is that the Cortex-A53 CPU is supported, but the Raspberry Pi 3 B+ board is not. The gap between those two things is where all the work is, and it is primarily board-support work rather than a missing ThreadX architecture port.

What the repository ships is ports/cortex_a53/gnu and ports/cortex_a53/ac6 for the single-core case, plus ports_smp/cortex_a53_smp/ for the four-core case. Those are complete AArch64 kernel ports: context save and restore, the scheduler, stack construction, interrupt control primitives, and the system return path. None of that is board-specific, and all of it is applicable to the Cortex-A53 cores in the BCM2837.

What is board-specific is everything around it. The sample build that sits beside the port targets an Arm Fixed Virtual Platform rather than real Raspberry Pi hardware. ports/cortex_a53/gnu/example_build/sample_threadx/ sets up a GICv3 interrupt controller and an SP804 timer at the Base platform addresses. A Raspberry Pi 3 B+ has neither: the BCM2837 uses Broadcom's legacy ARM peripheral interrupt controller together with the per-core local interrupt block, and its periodic tick would normally come from the BCM system timer or the per-core generic timer. So the sample will not run unmodified, which is almost certainly what you encountered with threadx_initialize_kernel_setup_test.

To bring ThreadX up on the board, you would need to supply, in roughly this order: an exception vector table and the EL transition, MMU, and cache setup for the level you choose to run at; a driver for the BCM interrupt controller that dispatches into _tx_thread_context_save and _tx_thread_context_restore; a periodic timer interrupt that calls _tx_timer_interrupt; and a _tx_initialize_low_level implementation that reports the correct first free RAM address for your image layout. If you boot through U-Boot rather than jumping directly from the Raspberry Pi firmware, you also need to be careful about the state U-Boot leaves the core in, particularly the exception level, MMU and cache state, and whether the secondary cores are still parked in the firmware spin table.

On the point @lduesing raised: the ThreadX that famously runs on a Raspberry Pi runs on the VideoCore GPU as part of Broadcom's proprietary boot firmware. That is a closed binary for a completely different instruction set. None of it is in this repository, and it cannot be reused on the Arm cores.

@dan-meyer, @williamelamie, to answer the question that was left hanging in this thread: at least some of the problems were genuinely ours. While working through the backlog, I found and fixed a real defect in the GNU AArch64 low-level initialization, where _tx_initialize_low_level dereferenced __top_of_ram one time too many and left _tx_initialize_unused_memory pointing at whatever happened to be stored at the top of RAM rather than at the top of RAM itself. That is #435, fixed by #726. The AArch64 GNU examples also had no build scripts at all until recently and could only be built through Arm Development Studio project files. There are now build_threadx.sh and build_threadx_sample.sh scripts in every AArch64 example build directory, and they work with both the GNU toolchain and Arm Toolchain for Embedded.

Finally, I have opened [eclipse-threadx/samplex#67](eclipse-threadx/samplex#67) to track implementation of Raspberry Pi 3 B+ support. SampleX is the proper venue for this work: the ThreadX repository provides the architecture-level Cortex-A53 port, while SampleX is where we maintain board- and platform-specific examples, startup code, peripheral initialization, and demonstration applications. I will therefore close this issue in favour of SampleX #67, where the Raspberry Pi bring-up work can be designed and tracked independently of the ThreadX kernel itself.