Názory k článku
Linux běží na ESP32-S3 bez potřeby emulace

Jestli nekdo znate podrobnosti, je tam implementace takova, ze to kopiruje vzdy datovou oblast procesu u kazdeho taskswitche, nebo to vyuziva nejak to "MMU"-cko co je v ESP32S3 na mapovani prostrednictvim dcache?

Uplne nechapu jaky je duvod neudelat nove ABI pro NOMMU userland a nechat jeden registr jako relativni offset do dat (podobne jako se treba pristupuje do tls pres %gs na Intelu). Sice to neni uplne Unix-sbrk kompatibilni, nicmene slo by udelat globalni heap ve stylu Windows 1-2-3.x-95-98-ME a malloc&pratele by pouzivali jednoduse tohle.

14. 9. 2026, 13:48 editováno autorem komentáře

myslim ze nommu nema fork ktery by delal kopie dat, ale jenom vfork ktery ceka v parentovi az child udela exec takze to s tim registrem asi neresi zadny realny problem, nebo tam bude moznost kdy oba sdileji stejna data jako thready v mmu verzi

ale kdyby to tam bylo a ten problem existoval tak to myslim registr neresi protoze to je fragmentovane v ramci stranek, nestaci zmenit offset v jednom registru. Na fragmentaci by pomohlo neco jako dvojite pointery ve starem macos + zamykani pred pristupem ale to uz je taky neco jineho nez linux.

Nechapu pointu, podle mne by to fungovalo dobre, akorat by to vyzadovalo par zmen, treba ze by byly dopredu v ELFu zadratovane max velikosti stacku a bss.

Ve starych Unixech (SysV apod.) naprosta vetsina veci jede tak,ze zespoda se zvetsuje pres sbrk heap. Kdyz do toho streli mmap, tak se tenhle pristup dost komplikuje - ale pro bezne tooly "ze stareho sveta" to neni potrebne.

Ad (v)fork, pochopil jsem to prave tak, ze oni kopiruji u taskswitche ty datove stranky procesu (zjednodusuji). Videl bych teda jeste optimalizaci pomoci MPU pri taskswitchi dat cely region "PROT_NONE" a odkopirovavat a zpristupnit "rw-" jen to kam si proces sahne (nez dojde pocet MPU slotu).

clanecek rika "Jádro je přímo zkompilované pro architekturu Xtensa, kterou ESP32-S3 skutečně používá. Kvůli absenci MMU však Linux běží v režimu NOMMU. " takze jen pro jistotu, bavime se teda o nommu verzi, ano?

nevim co presne myslite jak "taskswitch', ale i nommu verze je plne multitaskova takze pri prepinani mezi bezicimi procesy se nic nekopiruje, vsechny procesy bezi naraz a kazdy ma nejakou trvale obsazenou pamet, vsechny ale sdili stejny adresovy prostor, takze pamet je fragmentovana, kazda cast muze patrit jinemu procesu. v nommu verzi tedy nema kazdy proces cely adresovy prostor pro sebe a myslim ze ani neni souvisly - to by bylo velmi limitujici. docela dobre to tak funguje co se tyce vykonu i sdileni pameti (az na jeji ochranu), jediny velky problem je fork - v unixu s MMU to zduplikuje proces a oba pak typicky bezi v kopii kdy ze zacatku sdileji stejne data a adresy ale pri zapisu pomoci copy on write se stranky postupne zdvojuji. to v nommu verzi samorejme nefunguje takze vfork necha bezet child proces az zavola exec cimz se teprv novy proces prepne na novy exe + nove alokovanou pamet a parent proces pak muze pokracovat se svou pameti dal. v pripade ze se spousti jenom novy thread se sdilenou pameti tak tam zas tak velky problem/rozdil oproti mmu verzi neni. ty veci co popisujete kdyz zminujete "taskswitch" ohedne "odkopirovani dat" tam myslim vubec nejsou a ani by to moc dobre nefungovalo

Myslím si, že toto nemá moc cenu. Na inovované verzi ESP32S31 běží jádro Linux s plnou podporou fork a MMU. Espressif Xtensu opouští, ESP32S31 je založená na RISC-V RV32 a obsahuje standardní Sv32 MMU

https://github.com/espressif/esp-linux-bsp

Jedná se o oficiální Linux BSP experiment od Espressif, existuje i několik dalších.

Jinak i tak si myslím, že 16 MB RAM je v dnešní době na aktuální jádro Linux celkem málo. Jádro Linux je již algoritmy optimalizované ne větší systémy. Pro malé čipy má smysl měnší POSIXový RTOS, jako je třeba NuttX (https://nuttx.apache.org/), který dokáže vytvořit pro rozumně velké aplikace známé prostředí a přenositelnost lze pro ně s GNU/Linuxem udržet. V rámci nami vedeného GSoC byla nyní přidaná i možnost psaní aplikací proti X11 API a Win API

https://github.com/apache/nuttx/issues/18566

https://github.com/apache/nuttx/issues/18566#issuecomment-5130479878

Přitom NuttX kromě podpory MCU bez MMU nabízí na těch s MMU i oddělené paměťové prostory a tedy fork a plnohodnotné procesy. Experimentální vývojová větev pro ESP32S31 s MMU zde

https://github.com/78/nuttx-esp32s31

Pokud se pak chcete dozvědět, jak MMU obecně a na RISC-V v 32 a 64-bit režimu pracuje, tak přijďte na naší přednášku na LinuxDays

https://pretalx.linuxdays.cz/linuxdays-2026/talk/WSVKET/

Vše již dokážeme demonstrovat na aktuální vývojové větvi QtRvSim

https://github.com/cvut/qtrvsim

a do LinuxDays plánujeme připravit i nový release s podporou MMU a dalších novinek.

Jinak někdy okolo roku 2000 jsme měli standardní Linuxové jádro v MMU-less módu puštěné na MC68376, kdy flat model umožňoval i spuštění jedné aplikace vícekrát a i sdílené knihovny

https://www.pikron.com/pages/products/cpu_boards/mo_cpu1.html

Ale také to byl jen experiment, který moc smysl neměl, desky běží od té doby v jednotkách na řízení robotů, které přežily práci generací studentů. Ukázka/video na stránce

https://www.pikron.com/pages/products/motion_control.html

Jinak přiměřený k HW byl RTEMS https://www.rtems.org/, který jsme tam i měli roběhaný.

Měl jsem puštěný Linux i na Cortex-M4, boot přes U-boot

https://www.pikron.com/pages/products/cpu_boards/lx_cpu.html

ale to bylo opravdu jen jako ta lodička v láhvi, protože to někdo udělal a nyní již z mainline jádra podpora MMU-less ARM a Cortex čipů mizí. Přitom na Cortex-M se využívalo MPU a možnost dělění jeho regionů tak, aby se vlastně emulovalo něco jako soft TLB, ale dobře to chodit nemůže, Cortex-M ukládá stav faultujícího user space na user space zásobník, takže přítomnost zásobníku musí být vždy zaručená. Tedy přímo tato varianta architektury na rozdíl od staršího 32 bit ARMv4 a nových Cortex-A není na opravdový režim stránkování ani po hypotetickém doplnění MMU plně použitelná.

tesat do kamen, Linux je overkill a myslim si, ze to maji jen jako marketing, bwt ja NUTTX pouzivam na esp32c3 a naprosta spokojenost.

Ja používam klasiku EspHome, Arduino, MicroPython. Čo na tom bežíte? Seriózne, nemám predstavu na čo by som tam chcel komplet os.

Jak propaguji NuttX, tak zase plně uznávám, že na větší věci, kde je tlak na výkonnější nebo do světa otevřené WWW služby nebo databáze, se nehodí. Předpokládám, že pro Espressif je ESP32S31 ve směru GNU/Linuxu jen milník na cestě a časem přijdou i s čipy plně na Linuxové jádro vybavenými. Sice tam je dnes konkurence velká, ale jak díky technologiím v čase klesá rozměr a cena pro danou složitost, tak se postupně i budou do jejich cenové kategorie dostávat čipy třeba s 64 MB RAM a větší cache a Linux na to půjde provozovat dobře. Na druhou stranu pro drobnou automatizaci (spínač světel, RGB osvětlení, řízení motoru přes CAN, Ethernet T1S) i tak ta jednodušší řešení mají smysl.

taky hlavne co se tyce power managementu a boot time. ty zdroje navic (RAM) neco zerou a nez ten kernel nastartuje tak to taky trva, nektere ty zminovane veci se hodi i vypinat uplne a po zapnuti se ceka reakce v radu milisekund

Na EPS32S3 jsem měl Linux o Vánocích 2024, konkrétně na hodinkách T-Watch S3 - LILYGO.

Běhalo mi tam WiFi, SSHčko a pár uživatelských programů. Kvůli úspoře paměti bylo cca 60 GNU aplikací zkondenzováno do jednoho souboru a akce se spouštěly podle toho, přes jaký link byl ten soubor zavolán.

Pak už jsem ale nenašel čas pořešit všechny periferie, které bych tam potřeboval (a že jich v těch hodinkách je.)

Dotaz na zkušenější:
V případě, že k tomu EPSčku jsou připojeny mnohé další periferie jako: dotykový display, mikrofon, repráčky, Lora, Bluetooth, IR vysílač, ... co za OS byste zvolili, abyste to všechno mohli pokrýt ovladači a dobře je ovládat?