Płytki Milkv-Duo

[Waldek Hebisch]

Od jakieś czasu są dostępne bardzo tanie płytki z procesorami Risc-V.
Ciekaw jest czy ktoś z Was na nie patrzył. Ja sobie kupiłem
3 rodzaje: podstawowy Milkv-Duo z 64MB RAM, wersje 256MB i
Milkv-Duo S (tam ma 512M). W sieci są zestawienia ficzerów, może
napiszę tylko że każda z wesji ma trochę inny chipset. W wersji
64MB i 256MB chipset ma wyjście Ethernet, ale na płytce nie ma
gniazdka (ani transformatora) do Ethernetu, czyli bez zewnętrzynych
dodatków nie ma Ethernetu. Milkv-Duo S ma złącze Ethernetu na płytce.
Z Githuba można sobie sciągnąć obraz Linux-a. Defaultowo koło 30MB
jest zarezerwowane (głównie na "media"), więc Linux ma koło 34MB.
Ten Linux jest przykrojny, ale jak widzę chodzi OK. Tzn. obraz
jest budowany przez 'buildroot', jak chce się mieć coś więcej niż
w obrazie to trzeba sobie dokompilować. Wygląda że nie ma żadnych
narzędzi do zarządzania pakietami binarnymi. Jako bibliotekę C używa
'musl' tak że binarki łączone dynamicznie z innych dystrybucji raczej
nie będą działać. W obazie nie ma żadnego kompilatora (ani gcc ani
clang raczej nie zadziała w dostępnej pamięci), jest python
i oczywiście shell i awk. W sumie powiedziałbym że jest skromnie,
ale są podstawowe narzędzia. Jest sieć przez USB: jak się
podepnie kabelkiem USB do peceta to na pececie jest widoczny
interfejs sieciowy USB który daje połączenie do płytki.

Tu jakiś czas temu była dyskusja czy przy małej pamięci komputera
Linux podziała. Jak widać wyżej jest skromnie ale działa.

Trochę się zastanawiam do czego taką płytkę można użyć. Dla mnie
na razie to jest okazja żeby tanio potestować różne rzeczy na
Risc-V. Te mniejsze płytki pewnie można by użyć do robotów które
optycznie badają otoczenie (płytki mają złącze do kamery, ale
jak kupowałem to kamer nie było na stanie, więc nie mam kamery).
Nie widzę prostej możliwości podłącznia normalnego monitora.
To i brak sieci eliminuje sporo zastosowań. Powiedziałbym
że wersja Duo-S, choć nieco droższa od tych mniejszych jest
bardziej interesująca: mając Ethernet i 512MB RAM można robić
różne małe serwery.

Wygląda że te płytki mają bardzo mały pobór prądu. Ta mniejsza
normalnie (tzn. z chodzącym Linuxem ale bez czegokolwiek
obciążającego) daje 0 na moim mierniku USB co pewnie oznacza
poniżej 20mA. Dla Duo-S wychodzi mi koło 130mA. Dla porównania
Orange Pi Zero 3 bierze mi koło 260mA. Dla jasności: ta mała
(64MB) chyba miała wyłączony Ethernet (linie wisiały w powietrzu),
Duo-S miała działający Ethernet 100Mb, Orange Pi Zero miał
działający Ethernet 1G.

Jeszcze jedno: w tej chwili na Duo-S nie działa poweroff, tzn.
zamiast wyłączyć płytkie robi reboot.

[JDX]

Post by Waldek Hebisch
Od jakieś czasu są dostępne bardzo tanie płytki z procesorami Risc-V.
Ciekaw jest czy ktoś z Was na nie patrzył. Ja sobie kupiłem

Ja nie patrzyłem, ale zerknę.

Post by Waldek Hebisch
nie będą działać. W obazie nie ma żadnego kompilatora (ani gcc ani
clang raczej nie zadziała w dostępnej pamięci), jest python

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ą.

Post by Waldek Hebisch
Tu jakiś czas temu była dyskusja czy przy małej pamięci komputera
Linux podziała. Jak widać wyżej jest skromnie ale działa.

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 :-)

Post by Waldek Hebisch
Trochę się zastanawiam do czego taką płytkę można użyć. Dla mnie
na razie to jest okazja żeby tanio potestować różne rzeczy na
Risc-V.

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.

[Waldek Hebisch]

Post by JDX

Post by Waldek Hebisch
Od jakieś czasu są dostępne bardzo tanie płytki z procesorami Risc-V.
Ciekaw jest czy ktoś z Was na nie patrzył. Ja sobie kupiłem

Ja nie patrzyłem, ale zerknę.

Post by Waldek Hebisch
nie będą działać. W obazie nie ma żadnego kompilatora (ani gcc ani
clang raczej nie zadziała w dostępnej pamięci), jest python

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ą.

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).

Post by JDX

Post by Waldek Hebisch
Tu jakiś czas temu była dyskusja czy przy małej pamięci komputera
Linux podziała. Jak widać wyżej jest skromnie ale działa.

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 :-)

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.

Post by JDX

Post by Waldek Hebisch
Trochę się zastanawiam do czego taką płytkę można użyć. Dla mnie
na razie to jest okazja żeby tanio potestować różne rzeczy na
Risc-V.

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.

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.

[Marek]

Post by Waldek Hebisch
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.

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?

[Waldek Hebisch]

Post by Marek

Post by Waldek Hebisch
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.

Kilka rdzeni tj. 2 czy więcej?

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.

Post by Marek
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?

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.

Post by Marek
Ten FreeRT ile widzi RAM? Jak oba systemy dzielą zasoby na płytce?

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.

[Marek]

Post by Waldek Hebisch
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,

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

[Waldek Hebisch]

Post by Marek

Post by Waldek Hebisch
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,

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

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
8259, IDE, karty sieciowej, karty graficznej. Przez wiele lat
BIOS/chipset miał taką emulacje ale wygląda że producenci to
usuwają z nowych PC. Nawet jak jest emulacja to nie bedzie działać
tak szybko jak dedykowane sterowniki. A jak dodasz sterowniki dla
współczesnego sprzętu to raczej się nie zmieścisz w 2MB.

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.