On Sat, 4 Jun 2022 15:41:58 +0200, heby wrote:
> On 02/06/2022 14:28, J.F wrote:
>>> A po co te segmenty i w czym są lepsze w porównaiu gdy proces ma
>>> najzwyczajniej pamięc RAM dla siebie, jak chce?
>> Sprawa jest taka, ze program unixowy ma swój kod, powiedzmy ze stały,
>> ma dane w pamieci, ktorych ilosc moze rosnac i ma stos, ktory tez moze
>> rosnąc.
>
> Stosy w typowych systemach operacyjnych są śmiesznie małe. Tak około
> 1000x mniej niż dostepna pamięć i raczej mało kto narzeka.

Cos mi chodzi po glowie, ze na starych Unixach bylo 8kB.
Mozliwe do zmiany jakimis parametrami (ulimit?).
Teraz widze, ze linux ma cos kolo 2MB ... ale co zrobic, jak
zabraknie?

>> I te dwa rosnące obszary stanowią problem, bo trzeba je jakos umiescic
>> w pamieci.
>
> Nie stanowią problemu, choć nie mogę wykluczyć, że bardzo źle napisany
> program może marudzić. Shit happens.

Widziales gdzies wytyczne dla programistow - jak dbac o rozmiar stosu?

>> W dodatku Unix to system wielozadaniowy, wiec mamy wiele procesów,
>> kazdy z apetytem na pamiec. I z pożądaną wzajemną ochroną.
>
> To nie ma związku z segmentacją. Segmentacja to tylko dziadowski system
> przełączania banków pamięci z 8-bit maszyn, zaszyty w procesorze.

pojawila sie np 80286, a to juz 16-bit.


> Tak,
> troche przesadzam, ale prawdę mówiąc niewiele. Jak zerkniesz na to jakie
> machnizmy były popluarne na Z80 i 6502 do ogarniania pamięcu >64k to
> niebezpiecznie blisko koncepcji segmentacji wylądujesz.

Ale to bylo stronnicowanie, a nie segmentacja.
Cos, co dzisiaj chwalisz :-)

> x86 zrobił to
> tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji

Mial byc nastepcą 8080 :-)

> pamięci a potem dodawał w kolejnych wersjach procesorów coraz to nowsze
> "usprawnienia w odpowiedzi na potrzeby rynku" które zakończyły się tym,
> że obecnie z tego nikt nie korzysta, bo to guano, zaprojaktowanie
> skrajnie bezmyślnie i psute iteracyjnie przez dziesięciolecia.

Nie do konca bym tak to nazwal, ale jakos ta wyszlo.
286 byl przestarzaly od poczatku, w 386 segmentacja w zasadzie
niepotrzebna.

> https://en.wikipedia.org/wiki/Memory_segmentation
>
> [...]In a x86-64 architecture it is considered legacy and most
> x86-64-based modern system software don't use memory segmentation.
> Instead they handle programs and their data by utilizing memory-paging
> which also serves as a way of memory protection.[...]
>
> Czyli wyszło jak wykle, u Intela.

No ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
:-)

>> Nowsze programy ładują jeszcze dynamicznie biblioteki, wiec trzeba
>> wiecej nowego miejsca.
>
> Bibliteki shared sa zazwyczaj kompilowane z kodem position independent
> (sprawdzić, czy to nie zabawkowy Windows) i znowu, to nie ma związu z
> segmentacją. Procesory bez segmentacji też ładuja te bibliteki w trybie
> współdzielenia i też je dzielą. x86 się do tego nie nadaje z powodu
> żałosnych problemów z kodem PI, ale już AMD64 tak.
>
> Co zabawne, współdzielenie biblitek jest znacznie łatwiejsze w systemach
> bez ochrony pamieci (Amiga OS). I było powszechne w latach 80 w
> systemach bez MMU, co nie oznacza, że było rozsądne (fragmentacja była
> problemem).

A tu widzisz - segmentacja typu 286 by problem rozwiazala.

J.

do góry

On Wed, 1 Jun 2022 07:17:33 +0200, heby wrote:
> On 01/06/2022 07:03, J.F wrote:
>>> Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
>>> działała bez tego.
>> Chocby dlatego, ze procesy maja te same adresy dla roznych pamieci.
>> forka zrobisz i co?
>
> Masa OSów nie ma forka ;) Zerknij choćby na eCos.

Ale w Unixie to podstawa :-)

>>>> , protekcje
>>> Jeśli ma być "bezpieczny". Ale nie musi.
>> Wielozadaniowy to w zasadzie musi :-)
>
> Mało który *mały* system embedded jest w ogóle preemptive. Za to pełno
> cooperative/event.
>
> Ogólnie to nie tak, że poważne rzeczy da się robić tylko na poważnych
> systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
> skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy formalnej
> weryfikacji/certyfikacji niż Unix-like.
>
> PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
> system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
> przedinternetowych.

Preemptive byl tez wczesny Windows :-)

> Nie naciskałbym, że "musi mieć protekcję".

Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
to musi :-)
A teraz jeszcze wirusy, internet, szpiegowanie :-)

> Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
> nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
> fork, to w zasadzie to już nie jest embedded tylko normalny unix...

Mowa o li/unixie.

J.

do góry

On 06/06/2022 12:17, J.F wrote:
>> Stosy w typowych systemach operacyjnych są śmiesznie małe. Tak około
>> 1000x mniej niż dostepna pamięć i raczej mało kto narzeka.
> Cos mi chodzi po glowie, ze na starych Unixach bylo 8kB.
> Mozliwe do zmiany jakimis parametrami (ulimit?).

Jak masz uprawnienia.

> Teraz widze, ze linux ma cos kolo 2MB ... ale co zrobic, jak
> zabraknie?

Napisać lepszy kod. Przkroczenie 2MB/8MB na stosie jest oznaką bardzo
źle napisanego kodu.

>> Nie stanowią problemu, choć nie mogę wykluczyć, że bardzo źle napisany
>> program może marudzić. Shit happens.
> Widziales gdzies wytyczne dla programistow - jak dbac o rozmiar stosu?

Wytyczne? To się ma we krwi ;)

Jeśli rekurencja, to tylko ogonowa. Zwykłymi wywołaniami bez rekurencji
bardzo trudno przekroczyć stos w normalnym programie.

Naprawdę duże apliakcja, takie DUŻE DUŻE nie maja problemu z działaniem
na stosie kilku MB. Są najzwyczajniej poprawnie napisane.

>>> W dodatku Unix to system wielozadaniowy, wiec mamy wiele procesów,
>>> kazdy z apetytem na pamiec. I z pożądaną wzajemną ochroną.
>> To nie ma związku z segmentacją. Segmentacja to tylko dziadowski system
>> przełączania banków pamięci z 8-bit maszyn, zaszyty w procesorze.
> pojawila sie np 80286, a to juz 16-bit.

Segmentacja miała za zadanie ułatwić widzialnosc większego obszaru RAMu
dla procesora 8086, który tak naprawdę jest lekko odpicowanym 8-bit
8080. Jak że można by to było zrobić lepiej, niż za pomocą śmierdzocego
workaroundu z segmentami? No jak?

>> Tak,
>> troche przesadzam, ale prawdę mówiąc niewiele. Jak zerkniesz na to jakie
>> machnizmy były popluarne na Z80 i 6502 do ogarniania pamięcu >64k to
>> niebezpiecznie blisko koncepcji segmentacji wylądujesz.
> Ale to bylo stronnicowanie, a nie segmentacja.
> Cos, co dzisiaj chwalisz :-)

Nie, segmentacja. Dodanie dodatkowego "offsetu adresu" do normalnych
adresów. Potem dorobiono do tego ideologię i workaroundy (że niby
pozwala na pracę wielu maszyn wirtualnych, ochrania dostep, itp
śmiesznosci). Pierwotnie jedyne co chcieli osiągnąc to przekroczyć 64kB
bez zrywania z 8-bit. Co im się udało w prześmieszny sposób (A20).
Reszta to paniczne szukanie jak to jeszcze bardziej popsuć.

>> x86 zrobił to
>> tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji
> Mial byc nastepcą 8080 :-)

To był 8080 z doszytymi segmentami, z punktu widzenia programisty.
Róznica taka, zę mój Atari 65XE przełączenie banków miał w hardware na
płycie, a 8086 w procesorze. Ot, postęp i profesjonalizm.

> No ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
> :-)

MC68000 nie potrzebuje segmentacji. Pojawił się na rynku chwile po 8086.

Z jakiejś przyczyny ludzie do dzisiaj dorabiają idiotyczne ideologie
jaka ta segmentacja jest super i potrzebna do czegoś.

Niewiarygodne. Czasami wcinam popkorn oglądając takie dysputy, to lepsze
niż kabaret.

>> Co zabawne, współdzielenie biblitek jest znacznie łatwiejsze w systemach
>> bez ochrony pamieci (Amiga OS). I było powszechne w latach 80 w
>> systemach bez MMU, co nie oznacza, że było rozsądne (fragmentacja była
>> problemem).
> A tu widzisz - segmentacja typu 286 by problem rozwiazala.

Nie. Do prawidłowej pracy biblotek współdzielonych przy separacji
procesów wymagana jest translacja adresów i to dość swobodnie, w różnych
miejscach pamieci wirtualnej w różne miejsca pamieci fizycznej.
Segmentacja nic to nie pomoże, a tylko przeszkadza.

do góry

On 06/06/2022 12:22, J.F wrote:
>> Masa OSów nie ma forka ;) Zerknij choćby na eCos.
> Ale w Unixie to podstawa :-)

Można ją zrealizować bez MMU, tylko mało wydajnie.

>> PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
>> system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
>> przedinternetowych.
> Preemptive byl tez wczesny Windows :-)

Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
Dokładnie 10 lat po Amidzie i Sinclair Ql.

>> Nie naciskałbym, że "musi mieć protekcję".
> Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
> programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
> to musi :-)

Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
użyteczny system.

> A teraz jeszcze wirusy, internet, szpiegowanie :-)

*TERAZ* tak. Wtedy nie.

>> Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
>> nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
>> fork, to w zasadzie to już nie jest embedded tylko normalny unix...
> Mowa o li/unixie.

uCLinux to nie Linux ;)? Wystarczy że zgodny z POSIX. To czy masz w nim
paging czy nie, w sumie nie musi być wiadome dla aplikacji. Nie ma to
znaczenia.

do góry

On Mon, 6 Jun 2022 12:55:31 +0200, heby wrote:
> On 06/06/2022 12:22, J.F wrote:
>>> Masa OSów nie ma forka ;) Zerknij choćby na eCos.
>> Ale w Unixie to podstawa :-)
>
> Można ją zrealizować bez MMU, tylko mało wydajnie.

Nie bardzo czuje jak.
Jest program, ma kod, ma dane, ma gdzies zapamietane adresy tych
danych, i nagle to trzeba zduplikowac.

Kod moglby zostac ten sam, ale co z adresami w pamieci?


>>> PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
>>> system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
>>> przedinternetowych.
>> Preemptive byl tez wczesny Windows :-)
>
> Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
> Dokładnie 10 lat po Amidzie i Sinclair Ql.

A, ok, pomylilo mi sie.
Ale preemptive byly tez chyba widowsy 3.x, o ile uruchamiane na 386.

>>> Nie naciskałbym, że "musi mieć protekcję".
>> Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
>> programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
>> to musi :-)
> Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
> użyteczny system.

A co to za uzyteczny system, ktory nie wiadomo kiedy wyleci, z winy
jednego programu :-)

>> A teraz jeszcze wirusy, internet, szpiegowanie :-)
> *TERAZ* tak. Wtedy nie.

Wirusy sa stare :-)

>>> Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
>>> nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
>>> fork, to w zasadzie to już nie jest embedded tylko normalny unix...
>> Mowa o li/unixie.
>
> uCLinux to nie Linux ;)? Wystarczy że zgodny z POSIX. To czy masz w nim
> paging czy nie, w sumie nie musi być wiadome dla aplikacji. Nie ma to
> znaczenia.

J.

do góry

On Mon, 6 Jun 2022 12:52:07 +0200, heby wrote:
> On 06/06/2022 12:17, J.F wrote:
>>> Stosy w typowych systemach operacyjnych są śmiesznie małe. Tak około
>>> 1000x mniej niż dostepna pamięć i raczej mało kto narzeka.
>> Cos mi chodzi po glowie, ze na starych Unixach bylo 8kB.
>> Mozliwe do zmiany jakimis parametrami (ulimit?).
>
> Jak masz uprawnienia.
>
>> Teraz widze, ze linux ma cos kolo 2MB ... ale co zrobic, jak
>> zabraknie?
>
> Napisać lepszy kod. Przkroczenie 2MB/8MB na stosie jest oznaką bardzo
> źle napisanego kodu.
>
>>> Nie stanowią problemu, choć nie mogę wykluczyć, że bardzo źle napisany
>>> program może marudzić. Shit happens.
>> Widziales gdzies wytyczne dla programistow - jak dbac o rozmiar stosu?
>
> Wytyczne? To się ma we krwi ;)
>
> Jeśli rekurencja, to tylko ogonowa. Zwykłymi wywołaniami bez rekurencji
> bardzo trudno przekroczyć stos w normalnym programie.
>
> Naprawdę duże apliakcja, takie DUŻE DUŻE nie maja problemu z działaniem
> na stosie kilku MB. Są najzwyczajniej poprawnie napisane.
>
>>>> W dodatku Unix to system wielozadaniowy, wiec mamy wiele procesów,
>>>> kazdy z apetytem na pamiec. I z pożądaną wzajemną ochroną.
>>> To nie ma związku z segmentacją. Segmentacja to tylko dziadowski system
>>> przełączania banków pamięci z 8-bit maszyn, zaszyty w procesorze.
>> pojawila sie np 80286, a to juz 16-bit.
>
> Segmentacja miała za zadanie ułatwić widzialnosc większego obszaru RAMu
> dla procesora 8086, który tak naprawdę jest lekko odpicowanym 8-bit
> 8080. Jak że można by to było zrobić lepiej, niż za pomocą śmierdzocego
> workaroundu z segmentami? No jak?

Ale nie mowie o 8086, tylko o 80286. Tryb "protected".
Rozwineli skrzydla w segmentacji, i to juz byla konstrukcja 16-bit.
Ktore zreszta przestalo wystarczac, wiec na smietnik :-)

>>> Tak,
>>> troche przesadzam, ale prawdę mówiąc niewiele. Jak zerkniesz na to jakie
>>> machnizmy były popluarne na Z80 i 6502 do ogarniania pamięcu >64k to
>>> niebezpiecznie blisko koncepcji segmentacji wylądujesz.
>> Ale to bylo stronnicowanie, a nie segmentacja.
>> Cos, co dzisiaj chwalisz :-)
>
> Nie, segmentacja. Dodanie dodatkowego "offsetu adresu" do normalnych
> adresów.

Ale tam nie miales "offsetu adresu", tylko przełączanie stron pamieci.

Z uwagi na niedorozwoj MMU tylko zgrubne, np jedna wymiena strona
16KB, ale ciagle przelaczanie stron.

Jakiegos "offsetu adresu" mozna by sie dopatrzec w Keil C na 8051.

I moze cos bylo w 80251 - tego nie znam.


> Potem dorobiono do tego ideologię i workaroundy (że niby
> pozwala na pracę wielu maszyn wirtualnych, ochrania dostep, itp
> śmiesznosci). Pierwotnie jedyne co chcieli osiągnąc to przekroczyć 64kB
> bez zrywania z 8-bit.

Tak.
Ale tryb protected 286 dzialal inaczej - zawartosc rejestru
segmentowego nie byla sumowana do adresu jak 86, tylko stanowila
indeks po tablicy (deskryptorow) segmentow. Kazdy segment mial swoj
poczatek w pamieci, dlugosc, flagi protekcji.
Nie wiem, czy nawet jakiejs namiastki pamieci wirtualnej nie dalo sie
na tym zrobic.

> Co im się udało w prześmieszny sposób (A20).
> Reszta to paniczne szukanie jak to jeszcze bardziej popsuć.

Ale to chyba cos piszesz o trybie rzeczywistym.
Bo tryb protected nie byl stososowany z uwagi na niekompatybilnosc
z programami na MS-DOS.

A tryb protected 286 ... niby fajny, niby ma mozliwosci, ale segmenty
tylko 64KB, i setki problemow z tym zwiazane, jak danych jest wiecej
niz te 64KB.

>>> x86 zrobił to
>>> tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji
>> Mial byc nastepcą 8080 :-)
>
> To był 8080 z doszytymi segmentami, z punktu widzenia programisty.
> Róznica taka, zę mój Atari 65XE przełączenie banków miał w hardware na
> płycie, a 8086 w procesorze. Ot, postęp i profesjonalizm.

No wlasnie - atari mialo ubogie stronnicowanie na plycie, wraz ze
zwiazanymi z tym klopotami, 86 mialo w miare wygodne ofsety w adresie.

286 to byla nowa jakosc ... tylko o 10 lat spozniona :-)

>> No ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
>> :-)
> MC68000 nie potrzebuje segmentacji. Pojawił się na rynku chwile po 8086.

68k, podobnie jak 386 nie potrzebowal segmentacji w czasach, gdy
pamieci RAM mialy np 4MB. Czy nawet 128GB.
Czy nawet 3GB
Segmentacja mogla jednak pomoc na fragmentacje przestrzeni adresowej.

A potem pamieci bylo w komputerze pojawilo sie 4GB pamieci,
zaczal sie problem dla procesorow :-)

Zrobilismy procesory 64 bit i znow nie trzeba segmentacji :-)
I to raczej na długo :-)

> Z jakiejś przyczyny ludzie do dzisiaj dorabiają idiotyczne ideologie
> jaka ta segmentacja jest super i potrzebna do czegoś.
>
> Niewiarygodne. Czasami wcinam popkorn oglądając takie dysputy, to lepsze
> niż kabaret.

Jesli mowimy o 286/386, to miala pewne zalety.
Tylko 286 - za pozno, 386 - prawie niepotrzebne, a tez w praktyce - zc
czasem ograniczajace.

>>> Co zabawne, współdzielenie biblitek jest znacznie łatwiejsze w systemach
>>> bez ochrony pamieci (Amiga OS). I było powszechne w latach 80 w
>>> systemach bez MMU, co nie oznacza, że było rozsądne (fragmentacja była
>>> problemem).
>> A tu widzisz - segmentacja typu 286 by problem rozwiazala.
>
> Nie. Do prawidłowej pracy biblotek współdzielonych przy separacji
> procesów wymagana jest translacja adresów i to dość swobodnie, w różnych
> miejscach pamieci wirtualnej w różne miejsca pamieci fizycznej.
> Segmentacja nic to nie pomoże, a tylko przeszkadza.

Ale taka segmentacja
https://en.wikipedia.org/wiki/X86_memory_segmentatio
n#Protected_mode
https://en.wikipedia.org/wiki/Protected_mode#286

J.

do góry

On 06/06/2022 13:08, J.F wrote:
>> Można ją zrealizować bez MMU, tylko mało wydajnie.
> Nie bardzo czuje jak.
> Jest program, ma kod, ma dane, ma gdzies zapamietane adresy tych
> danych, i nagle to trzeba zduplikowac.
> Kod moglby zostac ten sam, ale co z adresami w pamieci?

Dwie rzeczy:
1) tak, for jest trudny w systemach bez pamięci wirtualnej i wymaga masy
roboty (i w wielu sytuacjach może sie nie powieść). Na pewno jest to
skrajnie kosztowne i bez sensu.

ale

2) for prawie nigdy nie jest uzywany w małych systemach w taki sposób
jak "watki". Na 99% fork zakończy się execv, co oznacza, że cała ta
ciężka robota z potencjalnym forkowaniem zazwyczaj to tylko wymówka aby
odpalic inny proces. O, to już można mieć protezę forka. Gdzieś taką
implementację widziałem nawet, nie wiem czy nie w jednym z tych małych
Linuxów bez mmu - robiło "forka" i czekało na execv i to wystarczyło aby
ogarnąć 99% programów Linuxowych.

>> Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
>> Dokładnie 10 lat po Amidzie i Sinclair Ql.
> A, ok, pomylilo mi sie.
> Ale preemptive byly tez chyba widowsy 3.x, o ile uruchamiane na 386.

Win3.11 jest cooperative, co nie było niczym specjalnie dziwnym, jabłka
też były, jakoś przeoczyli rewolucje siedząc dalej w nakładce na DOSa.

Być może były jakies protezy pod spodem, któe pozwalały odpalać kilka
Win na raz (gdzieś to widziałem) i byc może były preemptive, ale nie
natywnie w Win.

>> Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
>> użyteczny system.
> A co to za uzyteczny system, ktory nie wiadomo kiedy wyleci, z winy
> jednego programu :-)

To nie ma znaczenia. To czy Ci wyleci sterowanik silnika respiratora w
procesorze z MMU czy bez MMU jest mało istotne bo w obu wypadkach jesteś
w d... To tylko może nieco zmniejszych poziom katastrofy, ale nie
zapobiega jej. Zaryzykuje, że ważniejsza jest jakośc kodu niż to, czy
jest chroniony w systemie *zamkniętym*.

Tak naprawdę ochrona ma sens dopiero w czasach malware. Wczesniej była
fajnym ficzerem, ale niekoniecznie krytycznym, a przez dziesięciolecia
olewanym na wszelkie sposoby przez twórców OSów.

>>> A teraz jeszcze wirusy, internet, szpiegowanie :-)
>> *TERAZ* tak. Wtedy nie.
> Wirusy sa stare :-)

Wirusy które robią coś uzytecznego, online, są w miarę nowe.

A w dawnych czasach, posiadanie "protected MMU win95" oznaczało tylko,
że trzeba było zawołać ze 3 wywołania WinAPI więcej, żeby uzyskac
admina. To żałosny system był, protekcja pamieci to pic na wodę w
tamtych czasach. W zasadzie jako taką uwagę przyłożono dopiero w lini
NT, a linia 9x była robiona na odpiernicz się.

Dalej, są miejsca (embedded) gdzie protekcja/stronicowanie pamieci nie
ma wielkiego znaczenia i gdzie można stosować systemy które wyglądają
jak Unix, jesli ktoś potrzebuje. Wymaga to poświęcenia kilku detali, ale
one nie są krytyczne.

do góry

On 31.05.2022 21:12, Cezar wrote:

> uClinux z kernelem 2.0
>
> https://www.youtube.com/watch?v=SRdLlaUmmpM

Uświadomiłem sobie, że gdybym jednak miał się bawić z uCLinux, to jest
jeszcze jedna opcja sprzętowa, stojąca gdzieś na pograniczu retro i
współczesności. Procesory DragonBall, stosowane m.in. w Palmach (zanim
ten producent przeszedł na ARMy od TI i Intela). Z jednej strony
klasyczny rdzeń 68k, z drugiej obudowa TQFP oraz trochę zintegrowanych
peryferiów.

do góry