The ThreadX repository ships complete AArch64 kernel ports for the Cortex-A53, both single core ( ports/cortex_a53/gnu and ports/cortex_a53/ac6 ) and SMP ( ports_smp/cortex_a53_smp/ ). What it does not ship, and deliberately will not ship, is board support. The only example build that sits beside those ports targets an Arm fixed virtual platform with a GICv3 interrupt controller and an SP804 timer at the Base platform addresses.
That leaves a gap that people keep walking into. eclipse-threadx/threadx#282 asked whether ThreadX runs on a Raspberry Pi 3 B+ in 2023 and the honest answer is "the CPU port does, the board does not, and nobody has written the missing piece." This repository is the right place for that missing piece.
What to build
A RaspberryPi/RaspberryPi3ModelBPlus directory following the structure the existing samples use, with CMakeLists.txt , README.md , NOTICE.md , and app , cmake , lib and scripts subdirectories, producing a kernel8.img that can be copied onto the boot partition of an SD card.
The board is a BCM2837B0 with four Cortex-A53 cores. The interesting part is that essentially none of the peripherals the ThreadX AArch64 example assumes are present, so the demo has to supply all of them.
Scope
Boot and entry. With arm_64bit=1 in config.txt the VideoCore firmware loads kernel8.img at 0x80000 and the default armstub enters the primary core at EL2 with the secondary cores parked in a spin table. The sample needs to decide which exception level to run at, drop to EL1 if that is the choice, and set up its own vector table, stack and MMU and cache configuration.
Interrupt controller. The BCM2837 has no GIC. It uses the legacy Broadcom ARM interrupt controller in the peripheral block together with a per-core local interrupt controller that owns the generic timer interrupts and the core mailboxes. The demo needs a small driver for both that dispatches into _tx_thread_context_save and _tx_thread_context_restore .
Timer tick. Either the BCM system timer or the per-core generic timer, driving _tx_timer_interrupt at the configured tick rate. The generic timer is probably the better choice because it is per core and therefore extends naturally to SMP.
Console. A UART driver so the demo can print. On the 3 B+ the PL011 is routed to the Bluetooth module by default and the mini UART is the one on the GPIO header, so the sample should either use the mini UART or document the config.txt change needed to swap them.
Low-level initialization. A _tx_initialize_low_level that reports a correct first free RAM address for the image layout, and a linker script to match.
Application. Start with the single core port and the standard ThreadX demo threads, so the result is easy to verify. SMP on all four cores is a natural follow-up but should not block the first version.
Why it is worth doing
The Raspberry Pi 3 B+ is cheap, available everywhere and needs no debug probe to get started, which makes it an unusually good on-ramp for people who want to try ThreadX on a Cortex-A class part. It would also give us a real hardware target for the AArch64 ports, which are currently only ever exercised against a model.
Notes
One thing worth clearing up, because it comes up every time this is discussed: the ThreadX that is known to run on a Raspberry Pi runs on the VideoCore GPU as part of Broadcom's proprietary boot firmware. That is a closed binary for a different instruction set. It is unrelated to this work and gives us nothing to start from.
The ThreadX repository ships complete AArch64 kernel ports for the Cortex-A53, both single core ( ports/cortex_a53/gnu and ports/cortex_a53/ac6 ) and SMP ( ports_smp/cortex_a53_smp/ ). What it does not ship, and deliberately will not ship, is board support. The only example build that sits beside those ports targets an Arm fixed virtual platform with a GICv3 interrupt controller and an SP804 timer at the Base platform addresses.
That leaves a gap that people keep walking into. eclipse-threadx/threadx#282 asked whether ThreadX runs on a Raspberry Pi 3 B+ in 2023 and the honest answer is "the CPU port does, the board does not, and nobody has written the missing piece." This repository is the right place for that missing piece.
What to build
A RaspberryPi/RaspberryPi3ModelBPlus directory following the structure the existing samples use, with CMakeLists.txt , README.md , NOTICE.md , and app , cmake , lib and scripts subdirectories, producing a kernel8.img that can be copied onto the boot partition of an SD card.
The board is a BCM2837B0 with four Cortex-A53 cores. The interesting part is that essentially none of the peripherals the ThreadX AArch64 example assumes are present, so the demo has to supply all of them.
Scope
Boot and entry. With arm_64bit=1 in config.txt the VideoCore firmware loads kernel8.img at 0x80000 and the default armstub enters the primary core at EL2 with the secondary cores parked in a spin table. The sample needs to decide which exception level to run at, drop to EL1 if that is the choice, and set up its own vector table, stack and MMU and cache configuration.
Interrupt controller. The BCM2837 has no GIC. It uses the legacy Broadcom ARM interrupt controller in the peripheral block together with a per-core local interrupt controller that owns the generic timer interrupts and the core mailboxes. The demo needs a small driver for both that dispatches into _tx_thread_context_save and _tx_thread_context_restore .
Timer tick. Either the BCM system timer or the per-core generic timer, driving _tx_timer_interrupt at the configured tick rate. The generic timer is probably the better choice because it is per core and therefore extends naturally to SMP.
Console. A UART driver so the demo can print. On the 3 B+ the PL011 is routed to the Bluetooth module by default and the mini UART is the one on the GPIO header, so the sample should either use the mini UART or document the config.txt change needed to swap them.
Low-level initialization. A _tx_initialize_low_level that reports a correct first free RAM address for the image layout, and a linker script to match.
Application. Start with the single core port and the standard ThreadX demo threads, so the result is easy to verify. SMP on all four cores is a natural follow-up but should not block the first version.
Why it is worth doing
The Raspberry Pi 3 B+ is cheap, available everywhere and needs no debug probe to get started, which makes it an unusually good on-ramp for people who want to try ThreadX on a Cortex-A class part. It would also give us a real hardware target for the AArch64 ports, which are currently only ever exercised against a model.
Notes
One thing worth clearing up, because it comes up every time this is discussed: the ThreadX that is known to run on a Raspberry Pi runs on the VideoCore GPU as part of Broadcom's proprietary boot firmware. That is a closed binary for a different instruction set. It is unrelated to this work and gives us nothing to start from.