Jakie materiały edukacyjne polecacie do projektowania płytek PCB pod układy SoC?

Wed Jun 01, 2022 5:17 am   

On 01/06/2022 07:03, J.F wrote:

Masa OSów nie ma forka Zerknij choćby na eCos.


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. Nie naciskałbym, że "musi mieć protekcję".
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...

Wed Jun 01, 2022 5:18 am   

On 01/06/2022 06:58, 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?

Wed Jun 01, 2022 5:29 am   

On Wed, 01 Jun 2022 01:09:51 +0200, Marek wrote:

Aczkolwiek

https://en.wikipedia.org/wiki/Mmap

"The original design of memory mapped files came from the TOPS-20
operating system.
mmap and associated systems calls were designed as part of the
Berkeley Software Distribution (BSD) version of Unix.
Their API was already described in the 4.2BSD System Manual, even
though it was neither implemented in that release, nor in 4.3BSD.[1]

Sun Microsystems had implemented this very API, though, in their SunOS
operating system.
The BSD developers at U.C. Berkeley requested Sun to donate its
implementation, but these talks never led to any transfer of code;

4.3BSD-Reno was shipped instead with an implementation based on the
virtual memory system of Mach.[2]"

To moze da sie bez mmap.
W dodatku ... wczesne implementacje nie mialy jakiegos limitu na
wielkosc pamieci uzywanej?
Np 16KB
Wiec mozna normalnie wczytac do pamieci.

J.

Wed Jun 01, 2022 7:46 am   

On Wed, 1 Jun 2022 07:10:15 +0200, heby <heby@poczta.onet.pl> wrote:

IMHO nazywanie tego OSem tak jak nazywanie świnki morską.

--
Marek

Wed Jun 01, 2022 7:49 am   

On Wed, 1 Jun 2022 07:17:33 +0200, heby <heby@poczta.onet.pl> wrote:

Tak, ale niebo tym jest dyskusja. Atlantis nie pyta o małe
kontrolery.

--
Marek

Wed Jun 01, 2022 7:54 am   

On Wed, 1 Jun 2022 07:18:52 +0200, heby <heby@poczta.onet.pl> wrote:

Właśnie po to by bronić inne zasoby przed tym jego *jak chce*.

--
Marek

Wed Jun 01, 2022 7:54 am   

On 01/06/2022 09:46, Marek wrote:

A jednak to OS. W końcu mówa cały zas o embedded, bywa, że kiepski
filesystem, memtop i put/get na ekran to już OS na dużych komputerach.

Wed Jun 01, 2022 8:04 am   

On 01/06/2022 09:49, Marek wrote:

Raczej pyta o "małe". Współczesne gołe linuxy to gigabaty dysku i
gigabajty ramu i to na SAM9 raczej nie ruszy, ogólnie w grę wchodziły by
tylko jakieś prosto lutowalne SoC jak choćby procesory Hixxxx stosowane
w rejestratorach kamer czy wynalazki z okolic bardziej przyjaznych dla
hobbysty S3C2440, ale one wszystkie są obarczone problemami z żałosną
dokumentacją i zerowym wsparciem w porównaniu z Pi.

Można mieć unix-like experience bez protekcji pamięci. W zasadzie, jesli
to system zabawkowy, to nie ma dużej różnicy dla hobbysty. "Muszę mieć
koniecznie Linuxa z forkiem" może być złym kierunkiem bo zaczną się
problemy które są cięzki i nieistotne jednocześnie.

Wed Jun 01, 2022 8:39 am   

On 01/06/2022 09:54, Marek wrote:

Do tego służy stonicowanie.

Segmentacja to był bardzo, bardzo zły pomysł. Obecnie w poważnych
systemach nie używana (czytaj: olewana) bo generuje tylko kłopoty bez
wyraźnych zysków.

Wed Jun 01, 2022 9:13 am   

On 01/06/2022 10:52, Dawid Rutkowski wrote:

Dlaczego?


W sensie, że protekcja pamieci jest niezbedna aby to był Linux;) ? Mi si
wydawało, że wystarczy mieć kernel Linux-like i już No może być
zgodnym troche z POSIXem.

Unix to płynne pojęcie... 68000 na ten przykład:

http://marc.retronik.fr/motorola/68K/68000/Unix_and_the_MC68000_[BYTE_1986_12p].pdf

[...] The memory management primi-
tives in the UNIX system make no as-
sumptions about the sophistication of
memory management hardware avail-
able to them. UNIX systems have
been implemented with no memory
management and with sophisticated,
paged, segmented systems. Even a
memory protection scheme can be
dispensed with if the system being de-
signed is to be just an applications
engine. [...]

Wed Jun 01, 2022 10:52 am   

środa, 1 czerwca 2022 o 10:05:23 UTC+2 heby napisał(a):

Bez protekcji pamięci nie będzie unix-like tylko jakiś taki wymysł typu amigaos.
A OP nie chce "systemu zabawkowego", tylko system, na którym zadziała Linux.
Linux, a nie ucLinux czy amigaos.

Na temat tego, co stosować w embedded i czy lepszy Linux - jako "gorszy" OS,
np. bez realtime, ale za to z kupą softu - czy też coś innego, np. lepsze
jako OS (ale i gorsze, bo jednozadaniowe, np. eCos - bardzo fajny, ale to nie ledwo co OS, raczej biblioteka)
ale bez oprogramowania - można długo dyskutować - ale tutaj jest to zdecydowanie nie w temacie.

Wed Jun 01, 2022 10:55 am   

środa, 1 czerwca 2022 o 10:40:15 UTC+2 heby napisał(a):

Segmentacja daje to samo co stronicowanie.
Bo stronicowanie to segmentacja z wieloma segmentami o tej samej wielkości.
Ma zalety, ale też wady - większe zapotrzebowanie na pamięć.
A w takim Linuxie (szczególnie na x86) masz i segmentację i stronicowanie - wykorzystywane
są zalety jednej i drugiej metody.

Wed Jun 01, 2022 11:03 am   

wtorek, 31 maja 2022 o 23:06:56 UTC+2 heby napisał(a):

Masa OSów pozwalała też na uruchomienie tylko jednego procesu na raz
i też "działała bez tego". Tylko kijowo.
Tzn. jak wystarczało to w porządku - ale często "wystarczało"
w takim sensie, jak mówił Henry Ford: "gdybym spytał moich klientów,
czego potrzebują, odpowiedzieliby, że szybszych koni".
Ja też długo puszczałem na 386 z 4MB RAM DOSa i się męczyłem,
żeby było wolnych 620kB pamięci "konwencjonalnej" - a obok megabajty puste leżały.
Były oczywiście protezy w rodzaju TSRów - które trzeba było usuwać,
żeby jakąś lepszą grę uruchomić.
Do dziś zachodzę w głowę, w czym był problem, że potrzeba 620kB, a 600kB nie wystarczy.
Przecież pliki są na dysku...

No i jeszcze OS nie musi się męczyć, żeby program załadować w jakieś inne miejsce pamięci
niż to, na jakie był skompilowany.
Choć hmm, czy DOS tak musiał robić? I tak był jednozadaniowy, a ew. drivery można było ładować
na koniec pamięci, więc programy użytkowe zawsze mogły się ładować od tego samego adresu
(żeby było trudniej, oczywiście nie mogło to być zero).
Oczywiście *.com można było relokować po różnych segmentach ;> (choć to raczej śmiech przez łzy).

Wed Jun 01, 2022 12:01 pm   

środa, 1 czerwca 2022 o 11:14:54 UTC+2 heby napisał(a):

Chyba że rozumiesz "unix-like" jako "prawie jak unix", parafrazując reklamę.

Bez protekcji będzie to raczej dos-like.
Żeby coś nazwać unixem, a tym bardziej Linuxem, musi to przede wszystkim NIE MIEĆ
pewnych problemów, jakie zastosowanie unixa/Linuxa gwarantuje rozwiązać (oczywiście
zapewne pewnym kosztem).
Protekcja kernel space - user space to podstawa.
Protekcja między procesami w user-space - bardzo pożądana (poza wyjątkami
opisanymi w specyfikacji, umożliwiającymi IPC - ale TYLKO wtedy, gdy OBA procesy się na to zgodzą).

Zaczynasz mówić jak mój kolega, który każde nowe zagadnienie omawiał tak:
"No, wszystko jest jasne. Jest tylko jeden bardzo duży problem."

To coś jak:
"Jedna rana stanowczo śmiertelna, ale pozostałe da się wyleczyć."


A co to jest "kernel Linux-like"?
Zaś zgodność z POSIX - zawracanie głowy oczywiście..
Tyle że do czasu, gdy chcesz uruchomić jakieś oprogramowanie napisane pod system POSIXowy.


unix oczywiście jest o wiele bardziej "płynnym" pojęciem od Linuxa.
Linux zawsze miał ochronę pamięci.
Choć oczywiście jest na tyle elastyczny, że można kernel tej ochrony pozbawić.
Tylko że znów bardzo ograniczysz ilość oprogramowania, które na takim okrojonym "Linuxie" uruchomisz.
Tzn. uruchomisz oczywiście, tyle że po fork procesy zaczną się dziwnie zachowywać ;>

Z unixów też mogłeś wyciąć ochronę i uruchamiać je na 68k - zresztą inaczej się nie dało,
do pamięci wirtualnej trzeba było wziąć 68010.
Jak taki komputer miał 128kB pamięci to i tak wiele poza kernelem i jednym procesem nie uruchomiłeś.
A to przecież i tak było dużo, ludzie liczyli na komputerach z 16kB - a nawet liczyli na mniejszych
pamięciach, w 16kB to nawet miejsce na OS było ;>

Więc mogły być wersje "unixa" bez ochrony - ale to był "unix" w taki sam sposób jak S/360 model 20
"należał" do S/360 (IBM zresztą ostro się w takich głupotach powtarzał, PS/2 model 30 to ta sama
historia - "prawie jak PS/2", tyle że nie miał ani VGA, ani MCA - oraz na 8086 nie można było uruchomić OS/2).
Bo nawet PDP-11 miały ochronę.

Zadziwiającą maszyną był pierwszy macintosh, ze 128kB RAM, z czego 24kB zajmowała pamięć obrazu
(nie mówiąc już o zajmowaniu przez wyświetlanie 1/4 czasu magistrali, procesor był w HALT, bo nie miał cache).
Przecież tyle miał Spectrum 128kB (ech, czemu Sir Clive nie pomyślał, i nie dał w spectrusiu prostego
bankowania + nie umożliwił wykorzystania drugiej połowy tych chipów, które kupował z uszkodzonym jednym bankiem,
można by z każdego zrobić 80kB - albo mieć 64kB RAM działających z jedną szybkością) czy komoda 128
(ten miał też Z80
Oczywiście szybko wszedł model 512kB - ale ta kula u nogi 128kB pozostała.
Tak jak było z S/370 - dwa pierwsze modele nie miały MMU - "bo tak" - ale następne wszystkie już miały.
I mamy piękną "kompatybilność".

Wed Jun 01, 2022 1:27 pm   

On 01/06/2022 12:01, Dawid Rutkowski wrote:

Rozumiem jako system oparty o POSIX i kilka innych dupereli na około. W
zasadzie, jeśli tak się naprawdę dobrze zastanowić, to protekcja pamieci
nikomu nie jest niezbędna, aby mieć Unixa.


Nie, DOS-like to tylko gówniany filesystem, memtop i kilka funkcji do
printowania na ekran.

Główna róznica to wielozadaniowość i IPC.


Zaryzykuje, że to Twoja definicja, subiektywna.

Wiele osób używa pojęcia "Unix" choćby tylko dlatego, że jest POSIX. W/g
tej definicji Windows jest troche POSIX bo sporo rzeczy pasuje, też ma
rury, a APi da się nagiąć co pokazuje cygwin i WSL. No i ma protekcję :P


E tam. Mało ważne, w prostym embedded praktycznie wcale.


To dalej jest problem natury jakościowej/bezpieczeństwa a nie bycia lub
nie Unixem.


Niezupełnie. Pamietaj, że mowa o embedded. To nie system ktory ma
przejmować się bezpieczeństwem bo wszystkie apliakcje sa zaufane. Jedyne
co protekcja pamieci ułatwia, to że pad jednego programu nie zabija
innych. Ale to słabe rozróżnienie: jak Ci coś padnie w powaznym systemie
to i tak często jesteś w d... czy protekcja czy nie.


Taki np. uCLinux. Cholera wie czy to Linux czy nie. Ale w sumie, gdybyś
nie wiedział nic o kernelu, to nie poznałbyś.


Te małe linux-like bez MMU są jako-tako POSIX.


Nie powinno być problemu z *kompilacją*.


Chyba nie zawsze. O ile pamiętam, pierwsze wersje, ekperymentalne, nie
miały, lub nie działała poprawnie. Z reszt on chyba jest bazowany na
Minixie (tzn to taki żart) wiec puryści Unixowi nie nazywaj go Unixem.

A Minix to najczęsciej używany system operacyjny na świecie.


I czy wtedy dalej jest Linuxem? Czym w zasadzie jest Linux że odkrojenie
MMU powoduje że już nie jest?


Raczej wątpię.


A niby czemu? fork bez MMU jest możliwy, tylko cieżki i nierozsądny.


No ale po co chcesz ją chronić? Masa systemów, nawet takich od których
zalezy Twoje życie, nie ma chronionej pamięci. To nie jest wyznacznik
Unixa ani Linuxa.


Ale on miał ochorną z innych przyczyn. Na przykłąd ktoś to projektował
jako wielodostęp.

Unix nie musi być wielodostepowy.

Ba, wiele linuxów embedded składa się z 1 apliakcji typu "kamera
sportowa" i nikogo nie obchodzi jakaś protekcja pamięci.



Raczej dowiedzenie faktu, że MMU to tylko element dajacy ficzery a nie
identyfikujący, zy komputer jest czy nie popędzany Unixem.