Názory k článku
Experimentální jádro s PREEMPT_RT pro Raspberry Pi

Toto jsou věci, které se testují po desetiletí, viz například OSADL QA Farm on Real-time of Mainline Linux, kde si v položce Hardware stačí najít výrobce Broadcom. V seznamu je potřeba hledat jádra s RT PREEMPT a pak se podívat na Display most recent latency plot, například pro .Raspberry Pi 4 Model B Rev 1.1 a 6.6.2-rt15-v7l #3 SMP PREEMPT_RT. Jádra jen s PREEMPT vykazují o řády horší maximální latence při zátěži.

Sami jsme také párkrát testováním přispěli, viz i třeba pro českou komunitu z našich konferenčních přízpěvků sem na Root.cz před lety připravené články GNU/Linux pro řízení a rychlost jeho odezvy a Linux pro řízení: minimalistické řešení řízení stejnosměrného motoru.

Výsledky pro správně napsanou aplikaci zamknutou ve fyzické paměti a časovanou od CLOCK_MONOTONIC přes clock_nanosleep již před lety vycházely tak, že 5 kHz sample time na běžné lokální periferie (GPIO, vlastní znakové ovladače atd.) bez vynechání vzorku pro kvalitní C kód není problém.

Co se týče obecně komunikací, tak tam potíže stále jsou. Viz i moje shrnutí na letošním FOSDEMu především pro automobilovou a průmyslovou komunikaci CAN, kde vlastní linka je sice pomalá ale plně deterministická.

Co je ale tragédie a za co Broadcom a komunitu kolem Raspberry Pi hype nemám rád je to, že neinvestují dostatečně do kvalitního stavu v mainline kernelu. Jejich patch pro aktuální 6.12.y větev proti oficiálnímu Linux 6.12.30, které vydal Greg Kroah-Hartman


1287 files changed, 259638 insertions(+), 4817 deletions(-)


Předpokládám že, v rámci honby za funkcemi propagací Raspberry Pi je mnoho úprav provedeno stylem, který je pro mainline zcela nepřípustný. Do takovéhoto jádra se nedá rozumně pro lidi mimo úzké zaměření na RPi přispívat.

Přitom ty čipy, které mají pro reálné průmyslové nasazení smysl, jako NXP (i.MX6/7/8/9), TI a další mají mnohem lepší podporu v mainline a zároveň jim lze věřit, že poběží i v motorovém prostoru automobilu atd... Mají integrovaná reálná komunikační rozhraní s podporou řízení, alespoň že ta novější RPi již mají reálný Ethernet a ne jen ten na USB, kde tomu v nějakých kritičtějších podmínkách nejde věřit. CAN přes SPI a další podobné katastrofy pro nasazení v reálných řídících aplikacích jsou pak další věc proti. Takže výhoda je jen ta propagace komunitou a možná trochu výkon na video-processing, když je potřeba. Ale i tam bude TI s kombinací ARMů a rychlých DSP asi také lepší. O možnostech AMD/Xilinx Versalu si pak lze u RPi opravdu jen snít, ale souhlasím, že tam je cena jinde.

====
Jejich patch pro aktuální 6.12.y větev proti oficiálnímu Linux 6.12.30, které vydal Greg Kroah-Hartman

1287 files changed, 259638 insertions(+), 4817 deletions(-)

Předpokládám že, v rámci honby za funkcemi propagací Raspberry Pi je mnoho úprav provedeno stylem, který je pro mainline zcela nepřípustný. Do takovéhoto jádra se nedá rozumně pro lidi mimo úzké zaměření na RPi přispívat.
====

Neviděl bych to tak negativně. Kernel RPi obsahuje spoustu ovladačů zařízení určených přímo pro RPi, kterými nemá smysl zaplevelit mainline. Výrobci HATů sami patche posílají. Navíc RPi kernel obsahuje podporu pro HW RPi, např. pro nové RP1 v RPi5 - to v mainlinu snad zatím ani ještě není. 1287 změněných souborů je hodně, ale drtivá většina jsou drivery jen pro RPi.

Tipnul bych si, že patchset PREEMPT_RT převzali bez jakékoliv změny (kromě toho, co by bylo v konfliktu s jejich drivery).

RPi nemá tolik lidí, aby hackovali generické subsystémy, které mohou převzít rovnou z mainline.

2. 6. 2025, 09:42 editováno autorem komentáře

Tak různé device-tree bindings atd. neberu jako tak velký problém, ale následující pravdu mluví o větších problémech správy a komunikace se správci jádra

include/drm/drm_blend.h                            |    5 +
include/drm/drm_color_mgmt.h                       |    3 +
include/drm/drm_connector.h                        |   11 +
include/drm/drm_crtc.h                             |    2 +-
include/drm/drm_gem.h                              |    3 +
include/drm/drm_gem_shmem_helper.h                 |    3 +
include/drm/drm_mipi_dsi.h                         |   38 +-
include/drm/drm_plane.h                            |   40 +-
include/dt-bindings/clock/rp1.h                    |   60 +
include/dt-bindings/gpio/gpio-fsm.h                |   21 +
include/dt-bindings/mfd/rp1.h                      |  235 +
include/linux/backlight.h                          |   15 +
include/linux/brcmphy.h                            |    1 +
include/linux/broadcom/bcm2835_smi.h               |  391 ++
include/linux/broadcom/vc_mem.h                    |   39 +
include/linux/cma.h                                |    6 +
include/linux/fb.h                                 |    2 +
include/linux/gpio/driver.h                        |    1 +
include/linux/irqchip/irq-bcm2836.h                |    2 +
include/linux/leds.h                               |    3 +
include/linux/mempolicy.h                          |   10 +
include/linux/mfd/rpisense/framebuffer.h           |   35 +
include/linux/microchipphy.h                       |    8 +
include/linux/mmc/card.h                           |    5 +
include/linux/mmc/host.h                           |    1 +
include/linux/mmc/sd.h                             |   12 +
include/linux/module.h                             |    2 +-
include/linux/pio_instructions.h                   |  481 ++
include/linux/pio_rp1.h                            | 1019 +++
include/linux/platform_data/dma-bcm2708.h          |  143 +
include/linux/rp1-firmware.h                       |   53 +
include/linux/rp1_platform.h                       |   20 +
include/linux/usb.h                                |    2 +
include/linux/usb/hcd.h                            |    7 +
include/linux/w1.h                                 |    5 +
include/media/media-device.h                       |    9 +
include/media/media-devnode.h                      |    4 +
include/media/media-request.h                      |   38 +-
include/media/videobuf2-core.h                     |   15 +
include/uapi/drm/drm_mode.h                        |    1 +
include/uapi/drm/v3d_drm.h                         |   19 +
include/uapi/linux/bcm2835-isp.h                   |  347 +
include/uapi/linux/fb.h                            |   12 +
include/uapi/linux/media-bus-format.h              |    3 +
.../uapi/linux/media/raspberrypi/pisp_be_config.h  |   42 +-
include/uapi/linux/mempolicy.h                     |    1 +
include/uapi/linux/serial_core.h                   |    3 +
include/uapi/linux/v4l2-controls.h                 |   11 +
include/uapi/linux/videodev2.h                     |   32 +
include/uapi/misc/rp1_pio_if.h                     |  235 +
kernel/cgroup/cgroup.c                             |   33 +
kernel/resource.c                                  |    6 +
lib/earlycpio.c                                    |    1 +
mm/cma.c                                           |   36 +
mm/mempolicy.c                                     |  138 +-
mm/numa_emulation.c                                |    6 +
mm/page_alloc.c                                    |   28 +-
mm/vmscan.c                                        |    2 +-

a to nevypisuji změny v desítkách i obecných a subsystémových ovladačích zařízení. Opravdu to nevypadá to dobře.

Asi souhlas jen bych to s tou stabilitou RPi neviděl tak bledě, oni sami to používají přímo ve výrobě na řízení.
Osobně mám také mnoho RPi nasazených od dob jejich vydání 24/7/365 a za celou dobu jsem neregistroval jediný pád, prostě to běží a běží. Normálně i na SDkartě.

Problém je spíš v bídných implementacích USB, NET apod v jiných zařízeních, že člověk má předsudky.