17.06.2020 23:59
[#541]
Re: MorphOS na ARM - czemu nie?
@pawelini, post #540
Jak jest jakaś nakładka na RPi to jest DAC po I2S, ma tyle z Rpi wspólnego, że RPi ma i2s. Tyle. Jak wiele innych urządzeń, w tym ESP32. A to cyfrowy standard i jest zupełnie bez znaczenia z czego wychodzi. Doprawdy nie bardzo widzę sensu poruszania tego tematu odnośnie RPI. Jak ktoś myśli, że są cuda tylko dlatego, że to jest podłączone do RPi a nie np. OranePi, NanoPi, czy BananaPi to znaczy tylko tyle, że wierzy w pozłacane wtyki i posrebrzane kable z miedzi beztlenowej podnoszące brzmienie, aaa, najlepiej w hdmi. Powtórzę się, RPI to nie jest żaden zarąbisty sprzęt, to marka która wybiła się w czasach gdy SBC dla mas nie było wcale, a zrobili przyzwoity sprzęt i świetne oprogramowanie dla laika. I tak się zaczęło toczyć. Dokładnie to samo dotyczy arduino. Wzięto dość przeciętny 8 bitowy mikrokontroler i obudowano co prawda ciężkim (dla sprzętu), ale łatwym do ogarnięcia, przystępnym frameworkiem. Rzecz w tym, że Arduino rozwijając się zauważyło jak daleko z tyłu zostaje i aktualnie oferowane są dosyć mocne zestawy na 32bitowych mikrokontrolerach (bo ludzie sami zaczęli po to sięgać z bluepill na STM32F103). A Raspberry goni elitę. Rok przed RPI4 był już RockPi i NanoPi na RK3399 (2x A72, 4x A53), nieco przed Pi4 był Odroid N2 z 4x A73+2xA53. Pi3 weszło z przytupem, ale 64bit system rodził się w bólach a i na 32bit było dużo problemów. Pi4 dzielił te same choroby wieku dziecięcego. Tak wygląda rozwój, tak wygląda opracowanie systemu na nowy sprzęt. Tylko na MOS będzie pracować mniej ludzi i nie na distro linuksa. Więc sprzęt jest potrzebny taki, który na dłuższą chwilę będzie najzaje...fajniejszy w amiświatku i jednocześnie przyniesie konkretne benefity względem poprzedniej generacji na PowerPC. Tego RPI nie zapewnia i zapewniać nie będzie. Ani Odroid. Ani OrangePi. Ale może mógłby np. nv shield
Ostatnia aktualizacja: 18.06.2020 00:00:02 przez abcdef
Ostatnia aktualizacja: 18.06.2020 00:00:02 przez abcdef
18.06.2020 12:03
[#542]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #541
Ale przecież MorphOS wykorzystuje może 10% możliwości Mac-a dajmy na to G5. Jeśli chodzi oto co robiło się na makach w czasie ich świetności a to co teraz robią mosowcy:)
Chyba nie chcesz mi wmówić że użytkownicy Mosa to jakaś elita IT:) I zamiast wziąć jakiegoś Arma i zrobić własne PCB. Bo co stoi na przeszkodzie zrobienia własnego MOSPI.
To wolą przez 19 stron... no właśnie nawet ciężką jest opisać o czym jet tak naprawdę ten wątek:)
Zapewne przy mobo na G5 wymówek było dużo.
A jakie wymówki są przy Armie aby MOS-Team zrobił własne mobo z ARM?
No przecież CPU to parę dolarów
Ostatnia aktualizacja: 18.06.2020 12:04:49 przez tWINpIX
zrobili przyzwoity sprzęt i świetne oprogramowanie dla laika. I tak się zaczęło toczyć.
Chyba nie chcesz mi wmówić że użytkownicy Mosa to jakaś elita IT:) I zamiast wziąć jakiegoś Arma i zrobić własne PCB. Bo co stoi na przeszkodzie zrobienia własnego MOSPI.
To wolą przez 19 stron... no właśnie nawet ciężką jest opisać o czym jet tak naprawdę ten wątek:)
Zapewne przy mobo na G5 wymówek było dużo.
A jakie wymówki są przy Armie aby MOS-Team zrobił własne mobo z ARM?
No przecież CPU to parę dolarów
Ostatnia aktualizacja: 18.06.2020 12:04:49 przez tWINpIX
18.06.2020 12:40
[#543]
Re: MorphOS na ARM - czemu nie?
@tWINpIX, post #542
nie chcesz mi wmówić że użytkownicy Mosa to jakaś elita IT
Nie muszę wmawiać, przeciętny MOSowiec potrafi więcej zrobić przy swojej maszynce niż przeciętny malinkowiec, gdzie duża część z nich nawet karty z systemem nie umie nagrać.
I zamiast wziąć jakiegoś Arma i zrobić własne PCB. Bo co stoi na przeszkodzie zrobienia własnego MOSPI.
Tylko po co. Jak ci pokazałem za długo Pi nie żyje a poszczególne wersje różnią się dramatycznie możliwościami. To niepotrzebny nikomu wysiłek.
Zapewne przy mobo na G5 wymówek było dużo
Po co skoro źródełko układów wyschło, a gotowców (używanych maków) było więcej niż chętnych na mosa?
A jakie wymówki są przy Armie aby MOS-Team zrobił własne mobo z ARM
Powiedz mi PO CO? Druga platforma NG to właśnie takie custom-made solutions i ile to kosztuje?
Nie ma żadnego SoC ARM na rynku, który dorównałby możliwościami x86, a jeśli chodzi o otwartość rozwiązań (sterowniki) też nie jest wcale różowo. Rynek był tak zalany RPi i podobnymi, że doczekaliśmy się wynalazków jak "koprocesor" do BBC Micro, jako stacja dysków do Commodore 64 czy jako stacja dysków do Amigi.
A co do wykorzystania G5 - uważasz, że archiwizator nie wykorzystuje więcej niż 10% ? Odtwarzacz wideo? Gry? Na jakiej podstawie?
18.06.2020 13:03
[#544]
Re: MorphOS na ARM - czemu nie?
@tWINpIX, post #542
A jakie wymówki są przy Armie aby MOS-Team zrobił własne mobo z ARM?
Nie chcę ARM-a. Płyta pod np. AMD Ryzen ma dla mnie większy sens. Pakujesz co chcesz i jak chcesz, a jak po czasie okaże się, że czegoś masz za mało , to wymieniasz.
Dla mnie np. obecnie wspierany mac mini G4 jest niepotrzebny, ponieważ oferuje za małe możliwości rozbudowy, ale np. taki Mac MDD G4 to już prawie idealny sprzęt. HDD dołożę, grafikę w razie czego wymienię, dołożę USB2.0, Soundblastera, kontroler SATA, SSD i mam "Mega" sprzęt.
Oczywiście, zdaję sobie sprawę, że to co dla mnie jest idealne, dla innej osoby będzie całkowicie niepotrzebne, jednak patrząc się na to iż MOSTeam decyduje się na X86 myślę, że takich jak ja jest więcej :) :)
Nie chcę ARM-a. Płyta pod np. AMD Ryzen ma dla mnie większy sens. Pakujesz co chcesz i jak chcesz, a jak po czasie okaże się, że czegoś masz za mało , to wymieniasz.
Dla mnie np. obecnie wspierany mac mini G4 jest niepotrzebny, ponieważ oferuje za małe możliwości rozbudowy, ale np. taki Mac MDD G4 to już prawie idealny sprzęt. HDD dołożę, grafikę w razie czego wymienię, dołożę USB2.0, Soundblastera, kontroler SATA, SSD i mam "Mega" sprzęt.
Oczywiście, zdaję sobie sprawę, że to co dla mnie jest idealne, dla innej osoby będzie całkowicie niepotrzebne, jednak patrząc się na to iż MOSTeam decyduje się na X86 myślę, że takich jak ja jest więcej :) :)
18.06.2020 13:22
[#545]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #543
Ale nie chodzi o użytkownika Rpi.
Tylko wyostrzę bo widzę że klapki na ochach strasznie.
Użytkownik MOS z Mackiem G5 Wykorzystuje go może w 10% w porównaniu z tym co było gdy ten Mak był nowy i miał systemem OSX.
Gie piątki normalnie kiedyś były na topie i ludzie na nich robili Clipy, Filmy i Muzykę zarobkowo.
A nie puszczali LHA aby obciążyć CPU. Wykorzystanie w 100% CPU nie jest równe wykorzystaniu możliwości danej jednostki.
I to co dziś robione jest na G5 spokojnie mogło by być robione na Rpi.
Ale na ślepotę i nepotyzm w IT podobno nie ma leku
Tylko wyostrzę bo widzę że klapki na ochach strasznie.
Użytkownik MOS z Mackiem G5 Wykorzystuje go może w 10% w porównaniu z tym co było gdy ten Mak był nowy i miał systemem OSX.
A co do wykorzystania G5 - uważasz, że archiwizator nie wykorzystuje więcej niż 10% ? Odtwarzacz wideo? Gry? Na jakiej podstawie?
Gie piątki normalnie kiedyś były na topie i ludzie na nich robili Clipy, Filmy i Muzykę zarobkowo.
A nie puszczali LHA aby obciążyć CPU. Wykorzystanie w 100% CPU nie jest równe wykorzystaniu możliwości danej jednostki.
I to co dziś robione jest na G5 spokojnie mogło by być robione na Rpi.
Ale na ślepotę i nepotyzm w IT podobno nie ma leku
18.06.2020 13:28
[#546]
Re: MorphOS na ARM - czemu nie?
@trOLLO, post #544
taki Mac MDD G4 to już prawie idealny sprzęt. HDD dołożę, grafikę w razie czego wymienię, dołożę USB2.0, Soundblastera, kontroler SATA, SSD i mam "Mega" sprzęt.
Tylko twój MDD G4 po tych operacjach dalej nie odbiega za bardzo od Rpi. Czy podobnej konstrukcji na ARM.
Ale rozumie że trzymanie trupa pod biurkiem daje frajdę. Lecz wydaje mi się że już lepszą frajdą jest nieboszczka w szafie:)
18.06.2020 13:35
[#547]
Re: MorphOS na ARM - czemu nie?
@tWINpIX, post #545
Pff, jesteś śmieszny, jeśli Pi potrafi odtwarzać filmy to nie dlatego, że ma taki mocny CPU tylko dlatego że ma wbudowany dekoder. Jak sobie odpalisz distro bez sterowników do tego magicznego dekodera to zobaczysz niezły slideshow, a nikt nawet software dekodera dla ARM nie optymalizuje bo po co jak jest sprzętowy. Dla x86 nie optymalizują bo po co skoro ma dość mocy więc daje radę?
18.06.2020 14:11
[#548]
Re: MorphOS na ARM - czemu nie?
@tWINpIX, post #545
I to co dziś robione jest na G5 spokojnie mogło by być robione na Rpi.
Wreszcie człowiek, który pokaże mi jak Quake III działa na RPi w 1600x1200!
Ale na ślepotę i nepotyzm w IT podobno nie ma leku
Ne-po-tyzm? Znaczy się, że ktoś w IT zatrudnia swoich krewnych w biznesie? Coś jak Jack Tramiel?
nepotyzm 1. «faworyzowanie krewnych i przyjaciół przy obsadzaniu wysokich stanowisk i rozdawaniu godności przez osoby wpływowe»
18.06.2020 15:27
[#549]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #538
Rpi 2012, single core ARM1176 (ARMv6) 700MHzA to akurat nieprawda, ze kazda wersja potrzebuje innych sterownikow:
Rpi2 2015 quad core Cortex A7 / Cortex A53
Rpi3 2016 quad core Cortex A53
RPI4 2019 quad core Cortex A72
Każdy inny, każdy z odmiennymi sterownikami.
Rpi 1 to SoC Broadcom BCM2835 z VideoCore IV
Rpi 2 to SoC Broadcom BCM2836 z VideoCore IV
Rpi 3 to SoC Broadcom BCM2837/BCM2837B0 z VideoCore IV
Rpi 4 to SoC Broadcom Broadcom BCM2711 z VideoCore VI
Roznica miedzy BCM2835 a BCM2836 to tylko ARM core, cala reszta jest identyczna.
Roznica miedzy BCM2836 a BCM2837 to tylko ARM core, cala reszta jest identyczna.
Czyli sterowniki dla BCM2835/2836/2837 sa takie same. Tylko w przypadku najnowszego Rpi 4 sterowniki wymagaja przepisania lub zmian.
18.06.2020 16:02
[#550]
Re: MorphOS na ARM - czemu nie?
@docent, post #549
Zacznijmy od tego, że jeśli jest wykorzystana wirtualizacja jaką wprowadza ARMv7 z BCM2836 to nie może być ten sam sterownik co z ARMv6 ;) I tak samo - jeśli jest 64bitowy system z BCM2837 to nie może być 32bitowy sterownik z poprzednich wersji. Urodzony w bólach raspbian 64bitowy to nie tylko niezgodność samych bibliotek i pakietów (tutaj linux trzyma i aarch32 i aarch64), ale sterownik jądra już musi być 64bit. I z tym problemem też się borykali.
18.06.2020 16:14
[#551]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #550
Zacznijmy od tego, że jeśli jest wykorzystana wirtualizacja jaką wprowadza ARMv7 z BCM2836 to nie może być ten sam sterownik co z ARMv6
Firmware dla VC4 uruchamia procesor ARM w 32-bitowym trybie HYP albo na poziomie EL2 w 64 bitach. Kod systemu operacyjnego moze z tego skorzystać ale nie musi. Moze natychmiast przelaczyc sie do zwykłego supervisora (32bit) albo EL1 (64bit) i "problem" z wirtualizacja znika.
I tak samo - jeśli jest 64bitowy system z BCM2837 to nie może być 32bitowy sterownik z poprzednich wersji.
Kod zrodlowy moze być (i jest) ten sam. Nie trzeba wydziwiać. Jeżeli parsuje sie we właściwy sposób device tree, to nie ma tez problemu ze znalezieniem adresów wszystkich peryferiów. A jedna z najwiekszych zmian w RasPi4 to odejście od dziadowskiego USB na dwc2 do normalnego XHCI na szynie PCIe.
Ostatnia aktualizacja: 18.06.2020 16:15:25 przez mschulz
18.06.2020 22:23
[#552]
Re: MorphOS na ARM - czemu nie?
@tWINpIX, post #546
Tylko twój MDD G4 po tych operacjach dalej nie odbiega za bardzo od Rpi. Czy podobnej konstrukcji na ARM.
Ale rozumie że trzymanie trupa pod biurkiem daje frajdę. Lecz wydaje mi się że już lepszą frajdą jest nieboszczka w szafie:)
Chyba nie zrozumiałeś o co mi chodzi. Obecne płytki ARM-owe ( RP i inne ) w zasadzie nie dają możliwości rozbudowy. Kupujesz raz i tyle, musisz od razu wybrać konfigurację ( ilość ram i procesor na płycie ), dlatego nawet taki stary G4 MDD jest, moim zdaniem, zdecydowanie lepszy od każdego RPi. Obecnie mam w nim SSD 120GB na system i 1 TB HDD na resztę, początkowo był tam zwykły HDD IDE 80GB. Trzymam tam zdjęcia, muzykę, filmy i inne bzdury. Żaden RPi nie da mi takiej swobody, potrzebowałem więcej dysku, to po prostu wstawiłem. I dlatego cieszę się, że MOSTeam postawił na x86 i zwykłe płyty. Będę miał możliwość konfiguracji sprzętu tak jak chcę. A ARM? ... muszę od razu wybrać czy chce mać 2/4 GB RAM, dysk to zazwyczaj karta microSD, a lepsze płytki ARM
, cóż, cenowo robią się nieciekawe, a i tak pod względem możliwości rozbudowy ustępują mojemu G4 MDD.
Ale rozumie że trzymanie trupa pod biurkiem daje frajdę. Lecz wydaje mi się że już lepszą frajdą jest nieboszczka w szafie:)
Chyba nie zrozumiałeś o co mi chodzi. Obecne płytki ARM-owe ( RP i inne ) w zasadzie nie dają możliwości rozbudowy. Kupujesz raz i tyle, musisz od razu wybrać konfigurację ( ilość ram i procesor na płycie ), dlatego nawet taki stary G4 MDD jest, moim zdaniem, zdecydowanie lepszy od każdego RPi. Obecnie mam w nim SSD 120GB na system i 1 TB HDD na resztę, początkowo był tam zwykły HDD IDE 80GB. Trzymam tam zdjęcia, muzykę, filmy i inne bzdury. Żaden RPi nie da mi takiej swobody, potrzebowałem więcej dysku, to po prostu wstawiłem. I dlatego cieszę się, że MOSTeam postawił na x86 i zwykłe płyty. Będę miał możliwość konfiguracji sprzętu tak jak chcę. A ARM? ... muszę od razu wybrać czy chce mać 2/4 GB RAM, dysk to zazwyczaj karta microSD, a lepsze płytki ARM
, cóż, cenowo robią się nieciekawe, a i tak pod względem możliwości rozbudowy ustępują mojemu G4 MDD. 18.06.2020 22:39
[#553]
Re: MorphOS na ARM - czemu nie?
@trOLLO, post #552
Na RPi też można mieć system zainstalowany na SSD. Nie wiem jaki standard SATA MDD G4 wspiera ale na moim RPi4 na USB3 osiągi dysku SSD są całkiem przyzwoite (z tego co pamiętam 160MB/s odczyt 100MB/s zapis i to na najtańszej kieszeni USB3 jaką kiedyś znalazłem na eBay). Są nawet sprzętowe rozwiązania pozwalające na podłączenie do czterech dysków i zbudowanie sobie NAS (ze wsparciem RAID).
18.06.2020 23:05
[#554]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #550
Ja jestem śmieszny ale to Ty twierdzisz że puszczenie LHA i zajęcie 100% wydajności CPU = Wykorzystanie możliwości danej platformy. Idąc tym tokiem myślenia na Amigowych Party oglądało by się w działaniu pakery anie dema
No ale tak nie jest:) Po za tym wystarczy porównać bazę oprogramowanie OSX PPC i porównać ją z MOS. I z tego można już wywnioskować która platforma była bardziej eksplorowana.
Tak samo jest z Amigą 500 też ma od groma prodkucji a LHA, na niej nie działa najszybciej
No ale tak nie jest:) Po za tym wystarczy porównać bazę oprogramowanie OSX PPC i porównać ją z MOS. I z tego można już wywnioskować która platforma była bardziej eksplorowana.
Tak samo jest z Amigą 500 też ma od groma prodkucji a LHA, na niej nie działa
najszybciej 18.06.2020 23:14
[#555]
Re: MorphOS na ARM - czemu nie?
@recedent, post #548
Ne-po-tyzm?
Chodzi o faworyzowanie platformy AMD jest tym dzisiaj czym IntelOUTSIDE kiedyś... Ten tok myślenia doprowadził środowisko NG tu gdzie aktualnie się znajduje czyli w ...
Quake III działa na RPi w 1600x1200!
Przecież działa po za tym nie każdy ma taki duży monitor
1600x1200.
To teraz może pokaż jak przechodzisz tego Quake na tym MOSie.
Bo stwierdzenie jest szybciej, jest słabe bo to szybciej nic nie daje
Oprócz tego że możesz sobie odznaczy "ptaszka" w ToDo liście co rocznych benczmarków
18.06.2020 23:16
[#556]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #550
Zacznijmy od tego, że jeśli jest wykorzystana wirtualizacja jaką wprowadza ARMv7 z BCM2836 to nie może być ten sam sterownik co z ARMv6 ;)
To nieprawda - to, ze ARMv7 ma wirtualizacje nie oznacza, ze jest ona wykorzytywana na Rpi.
I tak samo - jeśli jest 64bitowy system z BCM2837 to nie może być 32bitowy sterownik z poprzednich wersji.
To tez nieprawda - oczywiscie na BCM8237 moze byc wykorzystywany 32bitowy sterownik - nawet jesli core jest 64 bitowy, to moze on pracowac w trybie 32 bitowym.
18.06.2020 23:31
[#557]
Re: MorphOS na ARM - czemu nie?
@trOLLO, post #552
pod względem możliwości rozbudowy ustępują mojemu G4 MDD.
No tak tylko po tej rozbudowie G4 dalej jest tym samym G4 tylko ma większe dyski.
Rpi. Też by się dało rozbudować jak by się uprzeć, np. można wkładać stówki pod monitor.
Po za tym RAM i CPU jest w MOSie ograniczone na poziomie systemu. Tak że. Można powiedzie że Rpi jest stworzone pod ten system:)
19.06.2020 00:05
[#559]
Re: MorphOS na ARM - czemu nie?
@docent, post #556
@docent
Żeby wykorzystać Aarch64 trzeba mieć system 64bitowy więc i sterownik 64bitowy. To nie jest tylko przekompilowanie z przełącznikiem gcc. Tak, sterownik w źródłach nie różni się diametralnie, ale jest innym obiektem dla SYSTEMU 64bitowego niż 32bitowego. Z tego samego powodu były dla wielu urządzeń sterowniki dla XP 32bit, ale zdecydowanie mniej dla XP 64bit (a niektóre gryzły się z PAE w 32bit) - tutaj na przykładzie z x86, ale to akurat "prawda uniwersalna".
No oczywiście, argument mocniejszy niż te 64bit wcześniej (bo nie każdy potrzebuje i używa wirtualizacji, ale te 4GB+ RAM już tak + oczywiście szersze rejestry). Era 32bit się w zasadzie skończyła w desktopach, ale uważasz, że skoro ARM ma też Aarch32 to nic nie stoi na przeszkodzie by go używać. No nic nie szkodzi, tylko po co? Po co się ograniczać. Po co zaciągać hamulec rozwoju? Lepiej jest mieć więcej ficzerów i nie potrzebować niż mieć mniej, a potrzebować. Wirtualizacja jest przykładem czegoś co się niejednokrotnie przydaje. W przypadku portowania amigowych rozwiązań jest to nawet bardzo ciekawe rozwiązanie.
@tWINpIX
To pokaż jak grasz dłużej kiedy zacznie na tych radiatorkach throtlować ;)
Którego nie raczyłeś zdefiniować. Wykorzystanie platformy sprzętowej się wiąże zazwyczaj z jednym - ile z tego co oferuje da się wykorzystać. Czyli dual core G5 - nie, 64bit - nie. Choć oba nie do końca (bo coś tam już grzebali i niby były pewne elementy wprowadzone), ale w normalnym MOSie do typowego usera nie. Reszta - tak. Więc skoro nie zdefiniowałeś o co dokładnie ci chodziło i rzuciłeś figurą 10% to nie dziw się takiej, a nie innej reakcji. To odbiję piłeczkę. Na raspberry z raspbianem zrobisz 10x tyle co na raspberry z MOSem. I czar prysł jak bańka mydlana. Teraz dalej - RPI4 ma 2x USB3.0, ok, podłączysz 2 adaptery na SATA i masz mniej więcej prędkość SATA3 do wykorzystania na 2 urządzenia. W przypadku x86 (a nawet nie, bo rk3399 też) masz pcie nvme coraz częściej w liczbie 2 na płytę OBOK przynajmniej 4(!!) SATA3. Już nie licząc wolnych linii pcie ze slotów na płycie. I tak na B350 (bo kupowałem 2 lata temu i budżetową) mam PCIE 16x 3.0, mam PCIE 4x 2.0, mam nvme (pcie 3.0 4x) i 4SATA, a do tego 2USB 2.0 z tyłu, 4 USB3.0 z tyłu, 1x USB C (3.0) z tyłu, 2 gniazda USB na płycie (dla 4 USB2.0) i gniazdo USB3.0 na płycie (dla 2 USB 3.0 a w zasadzie jak to teraz się nazywa USB 3.1 Gen 1). Ile tego jest łącznie to sobie musisz policzyć. Do tego 4 sloty dla DDR4 gdzie mogę wsadzić czy to 2133 czy 2400, czy 2666, czy 2800, czy 3000, czy 3200 ... 2, 4, 8, 16GB w module. To jest właśnie elastyczność której SBC brakuje i zawsze będzie brakować. Nawet w ITX atom czy celeron zje ARMa nie tylko wydajnością ale też w/w czynnikami, nie jest też tak że na komputer trzeba - jak kiedyś - zbierać 3-4 miesiące, jest zdecydowanie bardziej przystępny. Zatem ekonomia ARMa nie przemawia do mnie zupełnie. Co takiego fajnego ma ARM że lepiej jest się skupić na nim, a nie x86?
Ostatnia aktualizacja: 19.06.2020 00:10:16 przez abcdef
To tez nieprawda - oczywiscie na BCM8237 moze byc wykorzystywany 32bitowy sterownik - nawet jesli core jest 64 bitowy, to moze on pracowac w trybie 32 bitowym
Żeby wykorzystać Aarch64 trzeba mieć system 64bitowy więc i sterownik 64bitowy. To nie jest tylko przekompilowanie z przełącznikiem gcc. Tak, sterownik w źródłach nie różni się diametralnie, ale jest innym obiektem dla SYSTEMU 64bitowego niż 32bitowego. Z tego samego powodu były dla wielu urządzeń sterowniki dla XP 32bit, ale zdecydowanie mniej dla XP 64bit (a niektóre gryzły się z PAE w 32bit) - tutaj na przykładzie z x86, ale to akurat "prawda uniwersalna".
to, ze ARMv7 ma wirtualizacje nie oznacza, ze jest ona wykorzytywana na Rpi
No oczywiście, argument mocniejszy niż te 64bit wcześniej (bo nie każdy potrzebuje i używa wirtualizacji, ale te 4GB+ RAM już tak + oczywiście szersze rejestry). Era 32bit się w zasadzie skończyła w desktopach, ale uważasz, że skoro ARM ma też Aarch32 to nic nie stoi na przeszkodzie by go używać. No nic nie szkodzi, tylko po co? Po co się ograniczać. Po co zaciągać hamulec rozwoju? Lepiej jest mieć więcej ficzerów i nie potrzebować niż mieć mniej, a potrzebować. Wirtualizacja jest przykładem czegoś co się niejednokrotnie przydaje. W przypadku portowania amigowych rozwiązań jest to nawet bardzo ciekawe rozwiązanie.
@tWINpIX
To teraz może pokaż jak przechodzisz tego Quake na tym MOSie
To pokaż jak grasz dłużej kiedy zacznie na tych radiatorkach throtlować ;)
Wykorzystanie możliwości danej platformy
Którego nie raczyłeś zdefiniować. Wykorzystanie platformy sprzętowej się wiąże zazwyczaj z jednym - ile z tego co oferuje da się wykorzystać. Czyli dual core G5 - nie, 64bit - nie. Choć oba nie do końca (bo coś tam już grzebali i niby były pewne elementy wprowadzone), ale w normalnym MOSie do typowego usera nie. Reszta - tak. Więc skoro nie zdefiniowałeś o co dokładnie ci chodziło i rzuciłeś figurą 10% to nie dziw się takiej, a nie innej reakcji. To odbiję piłeczkę. Na raspberry z raspbianem zrobisz 10x tyle co na raspberry z MOSem. I czar prysł jak bańka mydlana. Teraz dalej - RPI4 ma 2x USB3.0, ok, podłączysz 2 adaptery na SATA i masz mniej więcej prędkość SATA3 do wykorzystania na 2 urządzenia. W przypadku x86 (a nawet nie, bo rk3399 też) masz pcie nvme coraz częściej w liczbie 2 na płytę OBOK przynajmniej 4(!!) SATA3. Już nie licząc wolnych linii pcie ze slotów na płycie. I tak na B350 (bo kupowałem 2 lata temu i budżetową) mam PCIE 16x 3.0, mam PCIE 4x 2.0, mam nvme (pcie 3.0 4x) i 4SATA, a do tego 2USB 2.0 z tyłu, 4 USB3.0 z tyłu, 1x USB C (3.0) z tyłu, 2 gniazda USB na płycie (dla 4 USB2.0) i gniazdo USB3.0 na płycie (dla 2 USB 3.0 a w zasadzie jak to teraz się nazywa USB 3.1 Gen 1). Ile tego jest łącznie to sobie musisz policzyć. Do tego 4 sloty dla DDR4 gdzie mogę wsadzić czy to 2133 czy 2400, czy 2666, czy 2800, czy 3000, czy 3200 ... 2, 4, 8, 16GB w module. To jest właśnie elastyczność której SBC brakuje i zawsze będzie brakować. Nawet w ITX atom czy celeron zje ARMa nie tylko wydajnością ale też w/w czynnikami, nie jest też tak że na komputer trzeba - jak kiedyś - zbierać 3-4 miesiące, jest zdecydowanie bardziej przystępny. Zatem ekonomia ARMa nie przemawia do mnie zupełnie. Co takiego fajnego ma ARM że lepiej jest się skupić na nim, a nie x86?
Ostatnia aktualizacja: 19.06.2020 00:10:16 przez abcdef
19.06.2020 03:07
[#561]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #559
Żeby wykorzystać Aarch64 trzeba mieć system 64bitowy więc i sterownik 64bitowy.Swietnie, wskaz mi w takim razie gdzie w downloads na stronie raspberry jest oficjalny 64bitowy system.
To nie jest tylko przekompilowanie z przełącznikiem gcc. Tak, sterownik w źródłach nie różni się diametralnie, ale jest innym obiektem dla SYSTEMU 64bitowego niż 32bitowego.Tak oczywistych rzeczy nie musisz mi tlumaczyc.
No oczywiście, argument mocniejszy niż te 64bit wcześniej (bo nie każdy potrzebuje i używa wirtualizacji, ale te 4GB+ RAM już tak + oczywiście szersze rejestry).4GB+ ram nie ma wiele wspolnego z wirtualizacja.
Era 32bit się w zasadzie skończyła w desktopach, ale uważasz, że skoro ARM ma też Aarch32 to nic nie stoi na przeszkodzie by go używać. No nic nie szkodzi, tylko po co? Po co się ograniczać. Po co zaciągać hamulec rozwoju? Lepiej jest mieć więcej ficzerów i nie potrzebować niż mieć mniej, a potrzebować.No i co z tego wynika dla raspberry pi, bo o tym mowilismy? Twoj oryginalny argument byl taki, ze kazda wersja rpi wymaga napisania nowych sterownikow a ja ci udowodnilem, ze sie mylisz - realnie tylko rpi4 wymaga nowych sterownikow.
Wirtualizacja jest przykładem czegoś co się niejednokrotnie przydaje. W przypadku portowania amigowych rozwiązań jest to nawet bardzo ciekawe rozwiązanie.
Owszem, przydaje sie, ale z punktu widzenia systemu operacyjnego ona nie istnieje - hypervisor (przynajmniej ten typu 1) wirtualizuje np. przerwania na nizszym poziomie niz dziala system operacyjny.
Jak sobie wyobrazasz pomoc wirtualizacji w portowaniu amigowych rozwiazan?
19.06.2020 07:55
[#563]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #559
Masz chociarz jedno Raspberry pi ktorego uzywasz na codzien? Tak sie uczepiles tego przegrzewania. Mam 5 Raspberry pi ktore nie sa nigdy wylaczane. Dwie 4ki, dwie 3ki i jedna 2ka. Na jednej czworce pracuje na codzien. Temperatura nie przekracza 65 stopni C. Gram na niej rowniez w Minecraft (pelna wersja) i uzywam Dosbox. W obudwu przypadkach czasem po kilka godzin i znow temperatura nie przekracza 65 na pasywnym chlodzeniu. Jak widzisz daleko do 85 stopni C przy ktorym CPU zwalnia zeby sie nie spalic...
Tez mam kompa na Ryzenie i Nvme i DDR4 wypasionego. Ne da sie ukryc ze RPi jest wolniejsze. Tylko ze jakbym mial kolejne 3 PC podlaczyc do telewizorow zeby uzywac na nich Kodi, kolejny PC zeby na nim pracowac i jeszcze jeden zeby byl serwerem wydruku dla drukarki 3d to by chyba drozej mnie kosztowalo. A tak male wolne i tanie RPi robi to co chce zeby robilo i nawet nie martwie sie o zuzycie energii. I to wszystko na ARM. Nie wiem jak ciezki jest RaspiOS w porownianiu z MOS ale jestem przekonany ze jesli teoretycznie istnialby port na RPi 4 to predkosc by byla wiecej niz zadowalajaca. Ja RaspiOS uzywam i nie narzekam. Wszystko dziala z zadowalajaca predkoscia (mam bezposrednie porownanie do szybkiego Ryzena). Nawet Q3 (Recedent jak ogarne jak zainstalowac pliki z pelnej wersji to zrobie tego benchmarka).
Tez mam kompa na Ryzenie i Nvme i DDR4 wypasionego. Ne da sie ukryc ze RPi jest wolniejsze. Tylko ze jakbym mial kolejne 3 PC podlaczyc do telewizorow zeby uzywac na nich Kodi, kolejny PC zeby na nim pracowac i jeszcze jeden zeby byl serwerem wydruku dla drukarki 3d to by chyba drozej mnie kosztowalo. A tak male wolne i tanie RPi robi to co chce zeby robilo i nawet nie martwie sie o zuzycie energii. I to wszystko na ARM. Nie wiem jak ciezki jest RaspiOS w porownianiu z MOS ale jestem przekonany ze jesli teoretycznie istnialby port na RPi 4 to predkosc by byla wiecej niz zadowalajaca. Ja RaspiOS uzywam i nie narzekam. Wszystko dziala z zadowalajaca predkoscia (mam bezposrednie porownanie do szybkiego Ryzena). Nawet Q3 (Recedent jak ogarne jak zainstalowac pliki z pelnej wersji to zrobie tego benchmarka).
19.06.2020 08:56
[#564]
Re: MorphOS na ARM - czemu nie?
@BuLa, post #563
RPi4 1GB, 2x RPi3 2GB, Rpi2 1GB. 3 i 4 mieliły nieliczne projekty BOINC dla ARM. I tak, grzały się ładnie. Do tego mam 2x OrangePi Zero (też się grzeją, w pierwszych wersjach armbiana wręcz się gotowały, bo nie był jeszcze dopracowany cpu governor), OrangePi Prime, OrangePi PC2, OrangePi Lite, OrangePi Plus 2E, OrangePi Zero Plus 2 H5, NanoPi M4. Tyle odnośnie tego co posiadam i wykorzystuję, a odnośnie throttlingu kontra firmware
ThermalThrottle
oraz kontra chłodzenie
Cooling
Zatem jak ktoś zaktualizował fw, ma solidny radiator i trzyma Pi na otwartej przestrzeni to luz, ale jak ma premierowego i sobie zamknął w ładnej obudowie to pasywne chłodzenie opierające się na konwekcji już nie wystarczy i siłą rzeczy będzie throttling.
Pytanie główne - co chcesz robić na MOSie @ RPI? Grać w minecrafta? Czemu na MOS konkretnie?
Można bezpiecznie założyć, że nie byłoby dużo gorzej niż na Linuksie (tylko softu mniej i niemal pewne, że scheduler gorszy). A jednak... przerabiałem sprawę i na Prime (Quad Cortex A53, 2GB RAM) i na NanoPi M4 (2x Cortex A72, 4x Cortex A53, 4GB RAM) - to, że da się tego używać jako desktopa, nie jest równoznaczne z tym, że da się tego używać tak jak desktopa (a w sumie nawet nie tyle desktopa co po prostu nowoczesne x86). Miałem w łapkach SBC advantecha. Bardzo często w panelach HMI. Też energooszczędne (no, nie tak jak ARM, ale jednak) ale nawet takie zminiaturyzowane x86 zostawia zdecydowanie lepsze wrażenie z użytkowania. ASRock ma też fajne rozwiązania. Popatrz jakie maleństwo: Jupiter - mocne, stylowe, nie tak drogie jak X5000 (tzn. raczej nie tak drogie bo nadal nigdzie nie widziałem by można było kupić)...
Nie zrozum mnie źle, jeśli prześledzisz uważnie wątek to też miałem takie zdanie jak Ty, że fajnie by było zrobić port na ARM, bo ARM jest wszędzie, bo są dobre SBC itp. Ale jeśli wybór jest "jedna architektura" i między ARM o jednak dużych ograniczeniach i x86 o dużych możliwościach to wspieram autorów w tej decyzji o x86.
nie wiem jak na ARM, ale na x86 do timedemo wystarczy wersja demo. FYI u mnie 973fps, może kiedyś sprawdzę nanopi.
Ostatnia aktualizacja: 19.06.2020 09:03:10 przez abcdef
ThermalThrottle
oraz kontra chłodzenie
Cooling
Zatem jak ktoś zaktualizował fw, ma solidny radiator i trzyma Pi na otwartej przestrzeni to luz, ale jak ma premierowego i sobie zamknął w ładnej obudowie to pasywne chłodzenie opierające się na konwekcji już nie wystarczy i siłą rzeczy będzie throttling.
Tylko ze jakbym mial kolejne 3 PC podlaczyc do telewizorow zeby uzywac na nich Kodi, kolejny PC zeby na nim pracowac i jeszcze jeden zeby byl serwerem wydruku dla drukarki 3d to by chyba drozej mnie kosztowalo.
Pytanie główne - co chcesz robić na MOSie @ RPI? Grać w minecrafta? Czemu na MOS konkretnie?
Nie wiem jak ciezki jest RaspiOS w porownianiu z MOS ale jestem przekonany ze jesli teoretycznie istnialby port na RPi 4 to predkosc by byla wiecej niz zadowalajaca
Można bezpiecznie założyć, że nie byłoby dużo gorzej niż na Linuksie (tylko softu mniej i niemal pewne, że scheduler gorszy). A jednak... przerabiałem sprawę i na Prime (Quad Cortex A53, 2GB RAM) i na NanoPi M4 (2x Cortex A72, 4x Cortex A53, 4GB RAM) - to, że da się tego używać jako desktopa, nie jest równoznaczne z tym, że da się tego używać tak jak desktopa (a w sumie nawet nie tyle desktopa co po prostu nowoczesne x86). Miałem w łapkach SBC advantecha. Bardzo często w panelach HMI. Też energooszczędne (no, nie tak jak ARM, ale jednak) ale nawet takie zminiaturyzowane x86 zostawia zdecydowanie lepsze wrażenie z użytkowania. ASRock ma też fajne rozwiązania. Popatrz jakie maleństwo: Jupiter - mocne, stylowe, nie tak drogie jak X5000 (tzn. raczej nie tak drogie bo nadal nigdzie nie widziałem by można było kupić)...
Nie zrozum mnie źle, jeśli prześledzisz uważnie wątek to też miałem takie zdanie jak Ty, że fajnie by było zrobić port na ARM, bo ARM jest wszędzie, bo są dobre SBC itp. Ale jeśli wybór jest "jedna architektura" i między ARM o jednak dużych ograniczeniach i x86 o dużych możliwościach to wspieram autorów w tej decyzji o x86.
Recedent jak ogarne jak zainstalowac pliki z pelnej wersji to zrobie tego benchmarka
nie wiem jak na ARM, ale na x86 do timedemo wystarczy wersja demo. FYI u mnie 973fps, może kiedyś sprawdzę nanopi.
Ostatnia aktualizacja: 19.06.2020 09:03:10 przez abcdef
19.06.2020 09:18
[#565]
Re: MorphOS na ARM - czemu nie?
@docent, post #561
Swietnie, wskaz mi w takim razie gdzie w downloads na stronie raspberry jest oficjalny 64bitowy system
Czemu mam pokazywać w downloads? Jest oficjalny system 64bitowy? Jest. Jest opracowany przez RPi foundation? Jest. Jest do pobrania z oficjalnego serwisu? Oczywiście, że jest. Co z tego, że beta. A suszenie głowy o 64bit OS się ciągnie od ... RPi2 v1.2
Tak oczywistych rzeczy nie musisz mi tlumaczyc
To mnie do tego nie zmuszaj pisząc
To tez nieprawda - oczywiscie na BCM8237 moze byc wykorzystywany 32bitowy sterownik - nawet jesli core jest 64 bitowy, to moze on pracowac w trybie 32 bitowymskoro odpowiadasz na fragment gdzie WYRAŹNIE napisałem
jeśli jest 64bitowy system
4GB+ ram nie ma wiele wspolnego z wirtualizacja
Primo - nigdzie nie pisałem, że ma, secundo ma z Aarch64 (co akurat pisałem)
bo nie każdy potrzebuje i używa wirtualizacji|wirtualizacja|, |Aarch64|ale te 4GB+ RAM już tak + oczywiście szersze rejestry. Na 32bitowym raspbianie są te same ograniczenia jakie były na windowsach z PAE (np. 2003 server) czyli da się użyć 8GB, ale nie jest to jednolita pamięć i procesy nie mają do niej całej dostępu, a jedynie do kawałków ograniczonych przez 32bitową architekturę systemu.
19.06.2020 09:36
[#566]
Re: MorphOS na ARM - czemu nie?
@tWINpIX, post #557
No tak tylko po tej rozbudowie G4 dalej jest tym samym G4 tylko ma większe dyski.
Czepiłeś się tego G4, a to tylko przykład. Powiem inaczej, jak miałbym wybór między MorphOS na ARM a MorphOS na x86, to wybiorę x86. Dlaczego :
- prostota rozbudowy na płycie x86 ( mnogość gniazd PCIe, SATA, nVMe, RAM )
- duża ilość gniazd ( kilka, kilkanaście USB 2.0/3.0 w zależności od płyty)
- łatwa wymiana np. CPU
Mogę np. kupić sobie płytę na chipsecie B450, 4 GB Ram i np. AMD Ryzen 3 3200G. Jak uznam, że to mało, wywalam CPU, pakuje jakiegoś Ryzen5 , dokładam Ram i jestem zadowolony.
Płyty ARM tego nie oferują. Koniec i kropka. Oglądam sobie różnego rodzaju płytki, łącznie z polecaną przez ciebie RPi 4. I co tam mam, max 8GB Ram , brak SATA, brak PCIe, brak nVMe. Za dysk robi karta microSD, bajer, czyli drogie to, wolne i wątpliwe jeżeli chodzi o trwałość przy tak ciągłym odczycie/zapisie danych. Owszem można podpiąć dysk przez USB3.0, ale ani to ładne, ani eleganckie.
Po za tym RAM i CPU jest w MOSie ograniczone na poziomie systemu. Tak że. Można powiedzie że Rpi jest stworzone pod ten system:)
Obecny MorphOS tak, nie wiesz jakie ograniczenia będzie miał MorphOS w wersji x86.
Czepiłeś się tego G4, a to tylko przykład. Powiem inaczej, jak miałbym wybór między MorphOS na ARM a MorphOS na x86, to wybiorę x86. Dlaczego
:- prostota rozbudowy na płycie x86 ( mnogość gniazd PCIe, SATA, nVMe, RAM )
- duża ilość gniazd ( kilka, kilkanaście USB 2.0/3.0 w zależności od płyty)
- łatwa wymiana np. CPU
Mogę np. kupić sobie płytę na chipsecie B450, 4 GB Ram i np. AMD Ryzen 3 3200G. Jak uznam, że to mało, wywalam CPU, pakuje jakiegoś Ryzen5 , dokładam Ram i jestem zadowolony.
Płyty ARM tego nie oferują. Koniec i kropka. Oglądam sobie różnego rodzaju płytki, łącznie z polecaną przez ciebie RPi 4. I co tam mam, max 8GB Ram , brak SATA, brak PCIe, brak nVMe. Za dysk robi karta microSD, bajer, czyli drogie to, wolne i wątpliwe jeżeli chodzi o trwałość przy tak ciągłym odczycie/zapisie danych. Owszem można podpiąć dysk przez USB3.0, ale ani to ładne, ani eleganckie.
Po za tym RAM i CPU jest w MOSie ograniczone na poziomie systemu. Tak że. Można powiedzie że Rpi jest stworzone pod ten system:)
Obecny MorphOS tak, nie wiesz jakie ograniczenia będzie miał MorphOS w wersji x86.
19.06.2020 09:36
[#567]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #565
Primo - nigdzie nie pisałem, że ma, secundo ma z Aarch64 (co akurat pisałem)
A co to ma wspolnego z tematem dyskusji (MorphOS na ARM)? I co to ma wspolnego z twoim blednym stwierdzeniem ze kazdy kolejny model RasPi potrzebuje innych sterownikow:
Rpi 2012, single core ARM1176 (ARMv6) 700MHz
Rpi2 2015 quad core Cortex A7 / Cortex A53
Rpi3 2016 quad core Cortex A53
RPI4 2019 quad core Cortex A72
Każdy inny, każdy z odmiennymi sterownikami.
19.06.2020 09:45
[#569]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #564
RPi4 1GB, 2x RPi3 2GB
Chyba odwrotnie, nie slyszalem o RPi3 z 2GB RAM.
Zatem jak ktoś zaktualizował fw, ma solidny radiator i trzyma Pi na otwartej przestrzeni to luz, ale jak ma premierowego i sobie zamknął w ładnej obudowie to pasywne chłodzenie opierające się na konwekcji już nie wystarczy i siłą rzeczy będzie throttling.
Nie wiem jakie firmware maja moje RPi4. uzywam takiego chlodzenia: takiego chlodzenia
Jedno RPi 4 jest podlaczone w zamknietej szafce pod telewizorem. Drugie przykrecone z tylu monitora (te na ktorym pracuje). Nie ma problemow z przegrzewaniem. Ponadto te na ktorym pracuje jest podkrecone @2GHz.
Pytanie główne - co chcesz robić na MOSie @ RPI? Grać w minecrafta? Czemu na MOS konkretnie?
Nigdzie nie napisalem ze chcialbym robic cokolwiek na MOSie. Jedynie to ze moim zdaniem jesli teoretycznie bylby port na RPi4 chodzilo by to dobrze. Nic wiecej.
to, że da się tego używać jako desktopa, nie jest równoznaczne z tym, że da się tego używać tak jak desktopa (a w sumie nawet nie tyle desktopa co po prostu nowoczesne x86). Miałem w łapkach SBC advantecha. Bardzo często w panelach HMI. Też energooszczędne (no, nie tak jak ARM, ale jednak) ale nawet takie zminiaturyzowane x86 zostawia zdecydowanie lepsze wrażenie z użytkowania.
Ja uzywam tego jak desktopa na codzien. Moglbym przytargac skrzynie z Ryzenem i na niej pracowac ale nie chce. RPi wystarcza. Moze mam male wymagania ale zdecydowana wiekszosc tego co potrzebuje jest na RaspiOS (fakt trzeba sobie oprogramowania doinstalowac, zreszta podobnie tak jak w Windowsie). Dopiero jak chce pograc w The Division 2 albo wymodelowac cos w Fusion360 to uruchamiam duzego kompa (jak ogarne FreeCAD na RPi to i na tym moze cos uda mi sie wymodelowac).
Niezaprzeczalna jest elastycznosc i stosunkowo niski prog wejscia (finansowy i pod wzgledem umiejetnosci IT) w RPi. Bogactwo systemow ktore mozna na tym uruchomoc i zadan jakie moga wykonywac jest chyba wieksza niz inne SBC, ktore pod wzgledem ilosci sprzedanych egzemplarzy i spolecznosci rozwijajacej oprogramowanie i sprzetowe projekty nie moga sie rownac z malinka. Taka jest moja opinia. A co do portu MOSa to podobno powstaje na x86
. Pozdrawiam. 19.06.2020 10:18
[#570]
Re: MorphOS na ARM - czemu nie?
@BuLa, post #569
Chyba odwrotnie, nie slyszalem o RPi3 z 2GB RAM
Tak, odwrotnie, dzięki za zwrócenie uwagi.
uzywam takiego chlodzenia
To jest zespolony jeden radiator podobny do rozwiązania jakie mam na NanoPi M4, zarówno pojemność cieplna jak i powierzchnia wymiany jest zdecydowanie większa niż wielu doklejek do broadcoma. Zupełnie inna liga. U mnie leciał iirc asteroids@home i jeszcze coś, oba wymagające aarch64 więc zawsze pod górę z Rpi. Armbian 64bit na inne SBC działa całkiem nieźle, np. H5 Allwinnera (SBC na nim konkurowały z Pi3 - ten sam rdzeń, ale iirc lepszy podsystem pamięci) ma wsparcie do akceleracji 3d (lima) i wideo (cedrus). Już na tyle dobre, że jest wersja RetroOrangePi.
Jedynie to ze moim zdaniem jesli teoretycznie bylby port na RPi4 chodzilo by to dobrze
Tak, ale czasem "dobrze" to za mało. Pamiętaj lepsze jest wrogiem dobrego. Tutaj autorzy MOSa są nastawieni na konkretny skok wydajności i możliwości, a nie tylko zapewnienie, że się da odpalić na taniej i przyzwoitej maszynie. RPi nawet w wersji 4 z 8GB ram tego nie zapewni. Prędzej wersje smartfonowe SoC ARM, ale te akurat nie są już takie tanie i nie są tak otwarte.
Bogactwo systemow ktore mozna na tym uruchomoc i zadan jakie moga wykonywac jest chyba wieksza niz inne SBC
Bogactwo systemów sprowadza się do różnych dystrybucji tego samego systemu :) Ale o ile na RPi widziałem rozwiązania "firmware-style" czyli bare-metal OS napisany przez użytkownika w celu realizacji z góry określonej roli, tak na innych SBC tego w zasadzie nie ma. Wygląda na to że jak ktoś chce pisać na Pi jak na mikrokontroler to jest łatwiej na malince niż bananie albo pomarańczy.
A jeśli chodzi o zadania jakie mogą wykonywać... nie, raczej nie. Korzystając z systemowych rozwiązań (spi, i2c, uart, usb) jest raczej bez większej różnicy, bo się odwołujesz przez np. spidev więc bez znaczenia czy to będzie z broadcoma, allwinnera czy mediateka. Z całą pewnością jest łatwiej np. taki display z waveshare zintegrować (dlatego po wielu nie w pełni zadowalających próbach pogodzenia z Opi Zero plus 2 H5 przerzuciłem 3,5'' na RPI4 i ruszył od strzału) czy też i nakładek z softem dedykowanym dla Raspbiana jest więcej (więc nawet jak nakładka pasuje na inny SBC bo ma kompatybilną listwę to od strony supportu programowego jest gorzej). Ale to też ma swój urok, bo RPi też uczy lenistwa. Połącz to z tym, uruchom skrypt i działa. A kombinując pod górę, rozwiązując problemy nabiera się nowych umiejętności i poznaje trochę głębiej sprzęt i system niż tylko powierzchownie.