Płytki Milkv-Duo

Ja nie patrzyłem, ale zerknę.

Od tego masz kompilatory skrośne na PC. Taka płytka raczej nie może się równać z byle jakim współczesnym pecetem i używanie na niej kompilatora natywnego byłoby męczarnią.

Hę? A czemu ma nie działać? Starsze wersje na pewno. Sam odpalałem OpenWRT na ruterku z MIPS32 i 4 MiB RAM. A na strychu stoi i nabiera wartości kolekcjonerskiej pecet z jakimś 486 i zdaje się 8MiB RAM i Slackware 3.3 :-)

No właśnie do tego, zwłaszcza, że mnie np. bardziej interesuje bare metal niż Linux. W każdym razie RISC-V to bardzo gorący temat ostatnimi czasy. W repo gcc najwięcej commitów dotyczy chyba właśnie tej architektury.

Jak pisałem w wyciętym kawałku gcc czy clang prawdopodobnie wymaga zbyt wiele zasobów. Ale to nie znaczy że na takiej płytce nie da się rozsądnie użyc natywnego kompilatora. Procek ma koło 1800 DMIPS, to jest porównywalne z najtańszymi prockami do PC sprzed kilku lat (nie wiem który pecetowy procek jest w tej chwili najszybszy, ale to najszybsze są co najmniej 15 razy szybsze). Z trochę innego punktu widzenia procek jest koło 1800 razy szybszy niż popularny VAX na którym chodziło całkiem sporo kompilatorów. Pamięci też mamy więcj niż w typowych wczesnych VAX-ach.

Trochę kombinacji i Tiny C zaczął mi chodzić natywnie (OK, na razie działa Hello World, pewnie będę musiał jeszcze dograć parę detali).

Nie ja byłem wątpiącym. Ale też chodzi o to że to jest w miarę współczesny Linux, jądro 5.10.4, programy użytkowe też w miarę nowe. Stary Linux podziała na 386 SX z 2MB RAM, wiem bo próbowałem, ale raczej nie zadziała na współczesnym sprzęcie, a na pewno nie zadziała na Risc-V.

Chip w Milkv-Duo tak naprawdę ma kilka rdzeni w środku. Na rdzeniu Risc-V 1GHz chodzi Linux, ale jest jeszcze rdzeń Risc-V 700 MHz na którym defaultowo chodzi FreeRTOS z jakimś minimalnym demo. Jest wsparcie dla Arduino, choć to mnie mniej interesuje. Raczej, wolałbym własny program "od zera". Na razie nie znalazłem żadnej dukumentacji jak ładować programy do tego rdzenia, ale jest kod bootloadera który na starcie ładuje FreeRTOS-a. Popatrzyłem na ten kod i chyba wiem jak załadować własny program.

Kilka rdzeni tj. 2 czy więcej? Jaką taki "drugi OS" ma mieć przydatność? Oczywiście są skrajne przypadki, gdy RT os będzie responsywniejszy niż nieRT na innym rdzeniu ale właściwie po co? Ten FreeRT ile widzi RAM? Jak oba systemy dzielą zasoby na płytce?

Zależy.. często działa. Paradygmat "najstarszy soft najnowszy sprzęt" to gwarancja działania najszybciej przy najmniejszych zasobach.

Milkv-Duo 64MB ma zasadzie 4: Risc-V 1GHz, Risc-V 700 Mhz, 8051 300 MHz i "TPU". Milkv-Duo 256MB i Milkv-Duo S mają jeszcze 1 GHz ARM.

Jak nie potrzebujesz RT i chcesz wszyskto robić pod Linuxem to pewnie Ci niepotrzebne. Jak masz dedukowany procek to znacznie łatwiej spełnić zależności czasowe. W prostych przypadkach możesz puścić pętlę w stylu Arduino i wiesz że nic tej pętli nie przerwie i że nie przeszkadza ona Linuxowi.

Ten drugi Risc-V chyba ma dostęp do prawie wszystkiego. Tzn. pierwszy ma koło setki linii przerwań, drugi koło 60 czyli drugi nie dostanie części przerwań. Ale reszta chyba jest dostępna dla obu. Oczywiście protrzebna jest jakaś konwencja żeby oba procki sobie nawzajem nie przeszkadzały. Jest specjalne urządzenie ("mailbox") do komunikacji między procesorami, nie znalazłem dokumentacji tego, ale jest kod (drivery). Linux przy starcie dostaje listę dostępnych urządzeń i jak rozumiem reszty nie rusza. FreeRTOS też używa tylko urządzenia o których mu się powie. Cześć pamięci z punktu widzenia Linuxa jest zarezerwowana, normalnie Linux jej nie rusza (można się do niej dostać przez /dev/mem). Jeden zarezewowany kawałek jest dla FreeRTOS, większość dla interfejsu kamery i TPU.

W granicach rozsądku. Ten Linux nie obsługiwał USB, AHCI ani APIC. Nowe PC często obsługują tylko start EFI, więc starego Linuxa nie da się wystartować. Jak wystartuje potrzebna by była emulacja

Jak jest mniej niż 2GB RAM (i nie ma swapu), to ma sens kompilacja w trybie 32-bitowym. Ale na PC-towych prockach stary tryb 32-bitowy ogranicza szybkość. Lepszą szybkość daje tryb x86_32, ale wtedy kompilator nie może być zbyt stary. Podobnie z jądrem.

Stare programy często działają bardzo dobrze i szybko, ale trzeba być selektywnym, czasami nowe jest mniejsze/szybsze. A czasami są potrzebne ficzery których nie było w starym sofcie.