Memoriacimzessel kapcsolatos alapkerdes

Merevlemezek, vezérlők

Hello.

Az operativtarral kapcsolatos dolgokrol tanultam, de nem minden volt szamomra tiszta. Tudnatok segiteni rendberakni?

Szoval ahogy tudom a regebbi Intel processzorok hagyomanyait tartva a mai processzoroknak is 16bites cimbusza van. Ezzel ugyebar 64k-t lehet kozvetlenul megcimezni. Regebben amig ez eleg volt, erre a cimtartomanyra osztottak ki a RAM es ROM-okat is. Viszont ez a tar eleg hamar kevesnek bizonyult.

Azzal nem vagyok tisztaban, hogy hogyan mukodik a felhasznalo altal is bovitheto RAM-ok (es az alap ROM-ok) cimzese a mai szamitogepekben. Valaki ossze tudna foglalni? Vagy valami hasznos link esetleg?

koszonom

  • 1340 megtekintés

( crossbone | 2008. 01. 25., p – 17:41 )

"...a regebbi Intel processzorok hagyomanyait tartva a mai processzoroknak is 16bites cimbusza van"
Mondjuk az i386-nak már assszem 24bites cím- és 16bites adatbusza volt. A Pentium Pro és a PII vonal 36 bites címbuszt tudott (és ők már a PAE-t is támogatják).
P4: 36bit cím, 64bit adatbusz...

Itt egy P4 adatlap - ebben benne lehet, amit keresel.

_m.

( kamm | 2008. 01. 25., p – 20:24 )

mar a 8086/8088 is 20 bittel cimzett, ket 16 bites regiszter kombinaciojaval (szegmens+offszet) lehet(ett) cimezni ebben a cpu modban (valos/real). akkor regen ugy mukodtek pl. a memoria bovitok (1 MB felett), hogy egy a 640kb-1024kb tartomanyon belul eso reszen, ahova a romok, periferiak dolgai vannak mappelve, egy 64kbyte-os reszre tudott mappelni az 1 MB feletti reszrol, es igy mar meg lehetett cimezni es hasznalni. persze elotte mindig meg kellett neki mondani, hogy epp melyik reszt mappelje oda. emlekeim szerint az EMS igy mukodott.

Csak egy kicsit igazítanám ki, az EMS az "Expanded Memory Specification"-t jelenti, az EM kezelését az "Expanded Memory Manager" végzi, pl. EMM386, QEMM386.
Ráadásul a 640kB és 1MB közti terület kezelése sem egyszerű, továbbá az A20vonallal elérhető legmagasabb címen, azaz a 0xFFFFH-n levő 64kB-os szegmens is az extended memoriához tartozik. Ennek szabványszerű definíciója az "Expanded Memory Specification". Managerek pl. a VCPI, a Himem.sys, de a DPMi is, és az EMM386 az expanded memoriát az extendedre képezi le, emulálja, valós módban.
A 386-ostól kezdve a címbusz 32 bites, ez a fizikai cím határát jelüli ki. A virtuális cím egy szegmensszelektorból és egy offsetből áll, és a virtuális címtartomány így 46 bit, 64 terabyte. Asszem az ufs-nél a file méret éppen ennyi.
A 36 bit széles címsin egy ideig vmi titok volt, ha jól emlékszem, a felső 4 bit kicsit el van rejtve, hirtelen meg nem mondom, melyik vezérlő bittel állítható.
A szegmensek mérete kétféle lehet, vagy egy byte-tól 1 MB-ig, vagy 4kB-tól 4GB-ig. A lapméret is változtatható, alapértelmezett érték a 4kB, átállítható 2MB-ra.(ebben az értékben nem vagyok biztos, fix me.)
Még annyit, hogy a Unix csak a lapozást engedi, a szegmentálást nem, a Linux viszont mindkettőt.
Az Intel honlapján lehet találni leírásokat (vagy AMD...), de érdekes az Intelsecrets-re rákeresni.

(A "felső memória " így nem egyértelmű, az Upper Memory a 640 és 1024 kB közti terület, a High Memory Area pedig az 1024 és 1088kB közti 64 kB-os tartomány.)

"A virtuális cím egy szegmensszelektorból és egy offsetből áll, és a virtuális címtartomány így 46 bit, 64 terabyte. Asszem az ufs-nél a file méret éppen ennyi."

A virtuális cím az 32 bites. A szelektor egy index a GDTben vagy a LDTben, onnan olvassa ki az adott szegmens alapcímét, ehhez adja hozzá az ofszetet, mindkettő 32 bites. Az x86_64nél vannak 48 bites virtuális címek.

nah. a 8086 -nak 20 bites cimbusza volt. az mas kerdes, hogy ezt a 20 bitet hogyan rakta ossze. ( Seg * 16 + offset ) a 80286 -nak mar 24 bites cimbusza volt. a 'highmem' az egy bug a 80286 -os intel processzorban :D) ugyanis az a lenyeg, hogy ami a 8086 cimbuszan az alabbi cimzessel FFFF:0011 = 00001 lett, az a 80286 -nal 10001 azaz a legfelso 4 bitet real modban nem nullazta ki a proci...
ami az ems -t illeti, az arrol szolt, hogy az akkortajt ritkan lakott 640K - 960K kozotti tartomanyba lehet belapozni az 1MB feletti cimeket, ami (pedig elvileg a 640K-ba minden belefer az urban legend szerint) mar akkoriban is igen jol jott bizonyos alkalmazasoknak.
A lapmeretet most nem feszegetem, asszem 16K lehetett, de ennek mar nagyon utana kellene neznem. Es lon i386 es lon 32 bites cimbusz. Kesobb a DR dos feltalalta, hogy a 386-os mar tud mindenfele kunsztot, es feltalalta az umb-t, hogy az os es segedei azt hasznalhatjak, igy az 'also 640K-ba' beferjenek a programok. No ezt az ms is gyorsan atvette, mert lata, hogy jo. Es lon emm386 , ami az i386 cpu kepessegeit kihasznalva szepen tudott ems -t emulalni, de ha arra kertuk, csinalt emm-et, es lon umb, meg telleg DPMI mer aztis, es szerencses esetben es jo konstrukcioju alaplapon akar eccere mindet, es ettol ritkan fagyott a gep. de inkabb surun, mert kulonben is DOOM es Tajvanon akkoriban lestek el a nagyok alaplapgyarto tudomanyat...
Mar a 286-ban (hogy egy korabeli szakkonyvet idezzek : "az IBM -tol az Intel fele aramlo szaktudas eredmenyekeppen" // ha valakit erdekel, nezzen utana, hogy a regebbi IBM mainframe-k cimzese mennyire hasonlit az i286/i386 -hoz ! //) megjelent a vedett mod, es levenek descriptorok meg miegymas. Es ez a 386-ban csak tovabb bonyolodott, mert ott mar 32 bites cimbusz stb. De ehhez ki kell jozanodnom, mert egyreszt elo kell asni a regi konyveket a temaban, masreszt meg kib* hosszu lenne, es meg bele is zavarodnek igy az x.-ik so:r utan....

( turul16 v | 2008. 01. 25., p – 21:51 )

I/O portok(címek) vannak limitálva 64k-ra.

( turul16 v | 2008. 01. 25., p – 22:09 )


$ cat /proc/iomem 
00000000-0009fbff : System RAM
00000000-00000000 : Crash kernel
0009fc00-0009ffff : reserved
000f0000-000fffff : reserved
00100000-3ffeffff : System RAM
00200000-007367d1 : Kernel code
007367d2-009279cf : Kernel data
3fff0000-3fff7fff : ACPI Tables
3fff8000-3fffffff : ACPI Non-volatile Storage
add00000-cdcfffff : PCI Bus #01
b0000000-bfffffff : 0000:01:00.0
cddfe000-cddfefff : 0000:00:0a.0
cddfe000-cddfefff : bttv0
cddff000-cddfffff : 0000:00:0a.1
cde00000-cfefffff : PCI Bus #01
ce000000-ceffffff : 0000:01:00.0
ce000000-ceffffff : nvidia
cfee0000-cfefffff : 0000:01:00.0
cffc0000-cffdffff : 0000:00:0b.0
cfff0000-cfff7fff : 0000:00:08.0
cfff0000-cfff7fff : 0000:00:08.0
cfffbd00-cfffbdff : 0000:00:10.4
cfffbd00-cfffbdff : ehci_hcd
cfffbf00-cfffbfff : 0000:00:0b.0
cfffbf00-cfffbfff : r8169
d0000000-d7ffffff : GART
d0000000-d7ffffff : aperture
fec00000-fec00fff : IOAPIC 0
fec00000-fec00fff : reserved
fee00000-fee00fff : Local APIC
fff80000-ffffffff : reserved

regen

Mint látod fizikai memoria cim tartomanyba van a tenyleges RAM mellett egy smás. ROM -ok, biz. harware eszközök memóriái.

(Védet modban 0 selectorral a fizkia memóriát cimzed,az Offset címmel x86 -on)

namostan ezen majd nemsokara ossze fogsz zavarodni, mert ugye valamikor aztat hivtuk virtualis memorianak, ami nem kezzelfoghato rammodul volt (swapfile / swap particio) de nemreg jol osszebalheztam egy szakival, aki ertette is, amit mond, azota tudom, hogy a programok szempontjabol minden memoria virtualis. inkabb igyunk.

Bocs, nem jártam erre. Egyetértünk, a fenti címekbe se a lapozás, se a GDT nem szól bele. A szelektor nemigen lehet nulla, mert abból semmi nem lesz. A GDT-ben viszont kell lennie egy null-deszkriptornak, ami nemcsak hogy használaton kívül van, de nem is használható semmire. Az Intel mérnökeit kéne megkérdezni, hogy ezt - többek között - minek csinálták. Mindenesetre a GDT csak 8191 bejegyzést tartalmazhat, a LDT viszont 8192-t, mert ott nincs null-deszkriptor.

Viszont a fenti címekhez hasonlóan nálam is vannak 512MB felettiek, pedig a gépben csak annyi van, szóval ezek erősen logikaiak. Az LGDT, SGDT és tsai utasítások privilegizáltak (ring0), úgyhogy a táblázatok tartalma, így a fizikai címek sem érhetők el konzolból sehogy, root-ként sem.

"Viszont a fenti címekhez hasonlóan nálam is vannak 512MB felettiek, pedig a gépben csak annyi van, szóval ezek erősen logikaiak."
Még a fizkai címzés alatt is vannak dolgok. A System RAM-ot (valódi ram), perifiriák RAM -ját,..stb-t, be kell mappolni a fizikai cím tartományba.

"úgyhogy a táblázatok tartalma, így a fizikai címek sem érhetők el konzolból sehogy, root-ként sem."
mmap /dev/mem és minden elerhető.

"Konzolból" remek kernel modulokat lehet írni, ha valamit még se találnál.