Diky za fajn clanek, tanhle serial se mi moc libi.
Mate nekdo zkusenosti s Linuxem (nommu) na Cortex-Mx platforme? U mensich to nedava smysl, ale M4 nebo M7 s externi FLASH a RAM uz muze byt zajimave pro jednodussi aplikace si myslim.
Je tam jeden potencialni problem a to absence radice pameti u nekterych M4. Ale bez problemu tam vali mikroLinux - https://en.wikipedia.org/wiki/UClinux
Btw by se asi hodil nejaky clanek prave na tema UCLinuxu :)
Resp. to pro jistotu jeste doplnim: M4 ma funkcni blok zajistujici vytvareni oblasti pameti chranenych napriklad pred zapisem, to je ok, ale neni tam funkcni blok pro plnohodnotnou virtualni pamet. Proto mikroLinux a mikroLibc:
uCLinux na M3/Mx může běžet, port pro LPC1789 jsem zkoumal. Port obsahuje i možnost použít MPU k chránění procesů mezi sebou a ochraně jádra. Bohužel regionů je celkem málo, ale lze je drobit bitmapou na několik stejně dlouhých úseků a v kombinaci s tím, že se při výjimce určitá část regionů plní ze simulované stránkové tabulky pro každý proces, lze pokrýt kompletní adresní prostor.
Bohužel zatím veškeré Cortex-M mají zásadní chybu pro použití s plnohodnotným OS. Stav procesoru se při přechodu z uživatelského do systémového režimu ukládá vždy na zásobník přerušeného procesu. Z toho vyplývá, že i kdyby byla přidaná MMU, tak není možné zajistit swapování a ani mapování zásobníku přes softwarově obslouženou MMU nebo MPU. Nepřístupný zásobník vede ke ztrátě stavu přerušeného vlákna/procesu a vyhlášení dvojité chyby. Jediné řešení je pak daný proces ukončit. MPU uCLinux to řeší tak, že regiony pro zásobník jsou natvrdo nastavené při každém přepnutí úlohy (procesu,vlákna).
Celkově ale použití MPU jako softwarové TLB vede k nedeterminismu běhu a tím pádem k latence již nevyhoví velkému množství řídicích/real-time aplikací, pro které je Cortex-M určený.
Pro seriózní aplikace, kde je účelné nasadit Linux, je pak rozumné uvažovat BeagleBone a spol (AM335x, AM43xx, AM5728, i.MX6 atd). Na hraní a experimentování pak lze použít RPi2 nebo nějaký Allwinner.
Spojení "plnohodnotný OS" mi působí určité potíže. V embedded světě existují trochu jiná měřítka a např. MMU/MPU tu IMHO rozhodně nepatří mezi must-have.
Jinak mi ovšem poněkud uniká, co vedlo architekty Cortexů M k tomuto řešení, pokud jde o práci se zásobníky. Logika oddělených zásobníků je tím dost silně narušena.
Tak pro mě bylo zvykem RTOS, které se linkují s aplikací do jednoho adresního prostoru, spíš říkat Real-Time Executiva něž klasický (víceuživatelský) operační systém. Holt první systém, když nepočítám osmibitové počítače jen s monitorem/Basicem, se kterým jsem přišel někdy okolo roku 1988 do kontaktu byl víceterminálový vývojový systém na bázi Unixu. Sice jsem pak na svém SAPI86 pak roky pracoval pod DOSem, ale tomuto zavaděči bych také operační systém neříkal.
Ale je to jen věc zvyku a souhlasím s tím, že v mnoha RT aplikcích není MMU potřeba a často ani být ani kvůli zpomalení a zhoršení determinizmu běhu být nemá. I když jakmile je v systému cache, a ta tam pro rychlé zpracování velkých objemů dat být musí, tak klasické metody ověření bezpečnosti také selhávají.
