[Assembly]biosgegevens uitlezen

[Verwijderd]

Ik ben bezig aan een klein besturingssysteempje (dat ondertussen al iets op het scherm kan printen en iets afdrukken op papier) maar ik was nog van plan om bepaalde settings uit te lezen. Nu gaat dit wel met de api's van C/C++ maar in Assembly ben je daar niet veel mee.
Ik zoek meer naar de adressen waar ik de cijfers kan uitlezen van de cpu-temperatuur, de verscheidene clockfrequenties etc... ook de tijd zou handig zijn. Dat moet toch ergens allemaal gestockeerd zijn veronderstel ik. Dus dat zou met bepaalde assembler instructies uitleesbaar moeten zijn denk ik. Ik weet nog niet welke instructies, maybe gaat een mov van de waarde op het biosadres van bvb de cpu-temp naar een werkregister of er zullen wel in/output commando's voor bestaan.
Wie iets meer weet mag dit altijd posten.

Ik heb al op verschillende sites gekeken waaronder ook die van amd en mijn mobo-fabrikant, evenals als programmersheaven maar ik kon niet echt nuttigs vinden. Ik zoek enkel een adres om het uit te lezen en eventueel de benodigde extra instructies als die speciaal zijn voor de bios uit te lezen tenminste. Want iets uitlezen en in een register zetten en dan printen op het scherm kan ik zelf ook wel.

Ik gebruik nasm om de asm-files te compileren, nuja al die compilers verschillen toch niet zoveel qua syntax, toch niet degene die ik al in mijn handen had.

[ Voor 29% gewijzigd door Verwijderd op 26-03-2003 20:25 ]

[Verwijderd]

temp sensors zitten aangesloten op de smbus kan je dus niet dmv een simpele geheugen locatie uitlezen voor specs zie hier en hier

[Verwijderd]

ik denk dat je bios interrupts moet aanroepen.. In de tijd van dos waren er in ieder geval al bios interrupts voordat dos werd opgestart.. ik neem aan dat dat niet veranderd is..

[Verwijderd]

>Yarvieh dat zijn interessante pages die je me gaf, net wat ik nodig heb, thx

[Verwijderd]

Ik heb eens navraag gedaan en naar het schijnt staan ook bios-gegevens op een bepaalde geheugenplaats zodat je die wel simpelweg kan uitlezen. Alleen moet je wel het geheugenadres weten.

[Verwijderd]

Ok... een van de bekendste temp proggies MBM moet specifiek support hebben voor je chipset en gebruikt een of ander drivertje om direct je hardware io porten te benaderen, hoe groot is de kans dat je je temps gewoon uit 'n geheugen locatie zou kunnen lezen?

[madwizard]

Misschien heb je hier wat aan:
http://www.programmersheaven.com/2/Art_C_1

[Verwijderd]

Verwijderd schreef op 27 March 2003 @ 09:37:
Ok... een van de bekendste temp proggies MBM moet specifiek support hebben voor je chipset en gebruikt een of ander drivertje om direct je hardware io porten te benaderen, hoe groot is de kans dat je je temps gewoon uit 'n geheugen locatie zou kunnen lezen?

Ja maar die progjes werken vanuit windows, het progje van mij niet, die is bootable, maakt dat dan geen verschil.
Via windows kan je aan zoveel dingen niet, zo kan je ook niet printen naar de lpt1 poort terwijl (want dat is gereserveerd voor de printerdriver) maar via een bootable progje gaat dit wel. Dus het lijkt dan niet zo onrealistisch dat dat dan gaat.

[Creepy]

Verwijderd schreef op 27 March 2003 @ 11:16:
[...]

Ja maar die progjes werken vanuit windows, het progje van mij niet, die is bootable, maakt dat dan geen verschil.
Via windows kan je aan zoveel dingen niet, zo kan je ook niet printen naar de lpt1 poort terwijl (want dat is gereserveerd voor de printerdriver) maar via een bootable progje gaat dit wel. Dus het lijkt dan niet zo onrealistisch dat dat dan gaat.

Daar zijn dus drivers voor. Je kan dan zonder problemen printen, en zelfs rechtstreeks de printer of de lpt poort aansturen.

Het is gewoon niet zo simpel als jij wilt. Je zult echt de SMbus moeten gaan uitlezen (want dat doet de BIOS stiekum ook) en dat verschilt ook nog eens per motherboard.

[PiepPiep]

kijk eens op http://www-2.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html
Interrupt lijst van ralf brown, zitten erg veel erg leuke dingetjes in.
Als het goed is zit er in een van die zip's een proggie dat intsum heet, die vind ik erg
makkelijk om te zoeken in al die files.

[Verwijderd]

Creepy schreef op 27 March 2003 @ 11:33:
[...]
Daar zijn dus drivers voor. Je kan dan zonder problemen printen, en zelfs rechtstreeks de printer of de lpt poort aansturen.

Precies alleen werk ik wel rechtstreeks waardoor ik niet via de SMbus moet gaan, het printen is wel gelukt dus. Het printen gaat hier ook niet als ik met een simulator (bochs) onder windows werk want dan kan je daar niet aan, alleen drivers hebben daarvoor permissie. Echter als je zoals ik deed een bootable programma maakt en met rawrite op een floppy zet dan gaat dit wel.
Vandaar besturingssysteem (in't klein dan). Dus hierin heb je ongelijk.

Het is gewoon niet zo simpel als jij wilt. Je zult echt de SMbus moeten gaan uitlezen (want dat doet de BIOS stiekum ook) en dat verschilt ook nog eens per motherboard.

Wat de bios zelf doet weet ik niet, leest die echt via SMbus, volgens mij zou dit vrij omslachtig maar ik weet het dus niet. Volgens anderen kan de bios wel die gegevens rechtstreeks uitlezen, dus als de bios dat kan kan ik dat ook. Maar als de bios wel via SMbus werkt heb je natuurlijk volledig gelijk.
Echter over dat verschillen per mobo, dat geloof ik niet echt, neem nu een willekeurig besturingssysteem, die leest ook gegevens uit over het moederbord, op zijn minst wordt de tijd al uitgelezen, moest dit verschillend zijn voor ieder mobo was dit voor de programmeurs onmogelijk om dat te programmeren, er komen immers bij wijze van spreken iedere dag nieuwe moederborden bij. Er moet daar een standaard in zijn net zoals het startadres van de cpu 000ffff0h is en het adres waarop sector 0 geladen wordt 7C00h is.

Maar ik ga nu eens kijken wat ik op Ralf Brown's Files vind.

Meer info is nog welkom natuurlijk.

[ Voor 18% gewijzigd door Verwijderd op 27-03-2003 14:23 ]

[Verwijderd]

Int 80h wordt iig tijdens de POST gebruikt

[Creepy]

Verwijderd schreef op 27 maart 2003 @ 14:17:
[...]

MBM is 1 van de weinige progjes die CPU temps. e.d. kan weergeven van verschillende mobo's van verschillende fabrikanten. MBM doet dat via de SMBus

In Linux is er 1 standaard om cpu temps. e.d. uit te lezen.. Dit word gedaan via de SMBus waarvoor ook verschillende drivers bestaan voor verschillende soorten mobo's. Dus ik denk echt dat je via de SM Bus zal moeten gaan.

Ben je zelf een OS aan het schrijven ofzo? Dan moet het uitlezen van de SMBus toch ook wel gaan.

CPU info (naam, snelheid e.d. maar temp's dus niet) gaat NIET via de SMBus maar is inderdaad via de BIOS te benaderen.. ik heb alleen geen idee hoe

[Verwijderd]

Creepy schreef op 27 maart 2003 @ 14:59:
In Linux is er 1 standaard om cpu temps. e.d. uit te lezen.. Dit word gedaan via de SMBus waarvoor ook verschillende drivers bestaan voor verschillende soorten mobo's. Dus ik denk echt dat je via de SM Bus zal moeten gaan.

Oké dat wist ik niet dat dat zo gebeurde voor de temperatuur.

Ben je zelf een OS aan het schrijven ofzo? Dan moet het uitlezen van de SMBus toch ook wel gaan.

Ik ben idd bezig met een klein OSje aan het schrijven (allé het kan toch al booten, printen op scherm en printen op een blad via lpt1-poort) maar ik wou het dus meer functionaliteit geven => gegevens over de pc zelf enz...

CPU info (naam, snelheid e.d. maar temp's dus niet) gaat NIET via de SMBus maar is inderdaad via de BIOS te benaderen.. ik heb alleen geen idee hoe

Oké het zullen dus die dingen zijn die die andere persoon dacht dat ik bedoelde, en ik wil ook die dingen weten.
Concreet was ik geïntresseert in:
cpu info (FSB, naam, cpu-clock, enz...)
cpu temperatuur
tijd
Da's alles. Weet jij soms toevallig of de tijd ook via de SMBus is? Ik denk het niet? Dus dat moet ook uitleesbaar zijn.
Mocht iemand anders of jij soms weten hoe ik daaraan geraak => het is altijd welkom.
Die cpu-temperatuur zal ik dan maar via de omsalchtige manier doen.

thx

[Verwijderd]

Ik vraag me trouwens ook nog af hoe je de PC kunt laten uitschakelen m.b.h.v. assembly instructie. Bij ATX dan.

[Verwijderd]

hint: zoek de specs op van de Advanced Configuration Power Interface

[Verwijderd]

Hmmm die ACPI ziet er voorlopig nog vrij ingewikkeld uit, das voor later. Maar toch bedankt want nu weet ik tenminste op wat ik moet zoeken. Das dan goed voor in de grote vakantie.

[ Voor 13% gewijzigd door Verwijderd op 27-03-2003 18:51 ]

[PiepPiep]

cpu info (FSB, naam, cpu-clock, enz...) :
Weet ik niet meer helemaal meer 100% precies zeker
maar ik dacht dat je een waarde moest pushen en dan kijken of die
op [sp] staat, dat is het verschil tussen >=386 en <386
Als je weet dat het een 386 is, is die dus 32 bits.
Dan moet je iets doen van

code:

pushf
pop ax
or/and ax ; deze weet ik dus niet
push ax
popf
pushf
pop ax

en dan kijken of die flags wel of niet aan of uit of verandert zijn.
Welke flags dat zijn kan je dacht ik wel vinden in 1 van die files
van ralf brown. (bedenk me dat het ook wel eens pushdf ofzo kan zijn, dus 32 bits
versie van de flags register)
Als je zeker weet dat het minimaal een pentium of een van de latere 486's is,
dan kan je in assembler CPUID uitvoeren.
Je moet dat in eax een waarde hebben staan, ik dacht dat de pentium 1 de waarde
0 en 1 ondersteund, de ene krijg je GenuineIntel in de registers als ascii en bij
de andere krijg je dingen als cache grootte en type en nog paar kleine dingen.
Staat volgens mij ook ergens op die ralf brown lijst

cpu temperatuur
Deze wil ik ook wel weten

tijd :

code:

mov ah,2
int 1Ah

AH = 0
AL = hours, in BCD
CH = hours, in BCD
CL = minutes, in BCD
DH = seconds, in BCD
DL 00h = no Daylight Savings Time option
01h = Daylight Savings Time option
CF NC (0) clock operating
CY (1) clock not operating or busy being updated

Ik denk dat je wel weet wat BCD is, maar zo niet, als je bv 23 in bcd
wilt schrijven is dat gewoon 23h
Dus van decimaal -> hexadecimaal gewoon een h erachter zetten
(in C een 0x ervoor )

[Verwijderd]

Over CPUID heb ik interessante site nog gevonden: http://www.paradicesoftware.com/specs/cpuid/index.htm

[Verwijderd]

Hier ben ik weer eens terug, ik heb de instructie cpuid eens gebruikt met als input eax = 0 en dan krijg je als output de "Vendor"-string in hexadecimale vorm.
ebx:edx:ecx zou dan AuthenticAMD moeten zijn in mijn geval.

Nu krijg ik het volgende als output:
ebx = 756E6574
edx = 49656E69
ecx = 6C65746E
en dit zou moeten gelijk zijn aan:
ebx = Auth
edx = enti
ecx = cAMD
Echter als je hetgeen wat ik krijg omzet krijg je een andere string die op niets slaat. Maar nu kan dit zijn omdat de pc een andere notatie gebruikt, maar ik weet niet welke en dat is natuurlijk essentieel om de gegeven output te kunnen vertalen.
Weet soms iemand of mijn output nu juist is, of welke notatie de pc gebruikt.

[PiepPiep]

Verwijderd schreef op 29 March 2003 @ 16:34:
ebx = 756E6574
edx = 49656E69
ecx = 6C65746E
en dit zou moeten gelijk zijn aan:
ebx = Auth
edx = enti
ecx = cAMD

Als ebx een tik fout bevat, en het 756E6547 moet zijn, dan staat er
ebx = uneG => Genu
edx = Ieni => ineI
ecx = letn => ntel
En dat geeft dus GenuineIntel en dus heb je geen AMD maar Intel in je comp
Je moet de letters trouwens omdraaien omdat als die ebx bv in het geheugen geschreven wordt, dan komt het least significant byte als eerste.

[Verwijderd]

Ge hebt alleszinds al gelijk PiepPiep, ik zie nu ook in little Endian "GenuineIntel" staan. Dat vind ik persoonlijk wel erg raar want er zit een AMD cpu in mijn pc, ik heb hem er immers zelf ingestoken op een ECS K7S5A bordje. De CPU zelf is een AMD Athlon XP 1800+ dus...
Maar die cpuid geeft idd (want ik had me inderdaad mistypt) GenuineIntel. Dat kan toch niet, of is dat toeval (wat ik ten zeerste betwijfel) of werkt die instructie cpuid niet goed???

De gebruikte code:

code:

    mov eax,0
    cpuid
    push    0
    push    0
    push    ebx
    call    printhex
    mov eax,0
    cpuid
    push    0
    push    9
    push    edx
    call    printhex
    mov eax,0
    cpuid
    push    0
    push    18
    push    ecx
    call    printhex

ter verduidelijking:
printhex is iets dat ik zelf bricoleerde, dat heeft drie argumenten nodig, een rij, een kolom en dan het hexadecimale getal (in mijn geval wat in het register zit).
ik roep 3 keer cpuid op en telkens de registers dan want dat is nodig want printhex gebruikt mijn registers ook en anders zouden deze al gewijzigd zijn.

edit:
Ik heb het mijn vriend ook es laten testen die heeft een AMD Duron cpu en die krijgt:
68747541 69746E65 444D4163
en dat staat dus wel voor AuthenticAMD, das wel erg vaag, of geven alle Athlon Xp's GenuineIntel, zou mij erg verwonderen maar is best wel vaag eigenlijk.
Of CPUID geeft foute informatie als het gaat over Athlon XP cpu's, maar dat zou ik moeten kunnen testen op meerdere athlon's dan. Want dat is toch erg vaag, vooral ik heb hier wat systeemtestprogjes staan en die geven allemaal aan dat ik een Athlon XP heb dus het zou mij erg verwonderen. Het kan ook gewoon niet want ik heb zelf dees pc ineengestoken en ik heb een athlon xp gekocht als cpu met een Arctic SuperSilent pro (voor XP 2800+) koeler erop die best nog goed presteerd want cpu wordt maar 34°C (maar dat doet er allemaal niet toe eigenlijk).

[ Voor 31% gewijzigd door Verwijderd op 29-03-2003 20:58 ]

[PiepPiep]

Hoe run je je programma?
Is het een dosbox proggie wat je in een box onder windows draait die de cpuid doet?
Zoja, probeer het eens onder echte dos?
Als ie onder dos wel AuthenticAMD zegt heb ik een theory, hoewel ik zelf die theory erg onwaarschijnlijk vind.
Wat zegt windows dat je voor cpu hebt trouwens?

[Verwijderd]

PiepPiep ge zijt mijne engel (want ge hebt mij op het goede spoor gebracht), ge weet mijn progsel is een mini-besturingssysteem, dus normaal zou ik dat altijd op floppy moeten zetten met rawrite en dan pc opstarten. Maar dat doe ik uiteraard niet altijd, want als ik altijd moet herstarten om te controleren dan wordt dat nogal lastig, dus ik gebruikte "bochs" als simulator. Maar blijkbaar werkt dat daarmee dus niet optimaal.
Want als ik het programma op een diskette zet en pc ermee boot gaat het wel en geeft hij AuthenticAMD. Net zoals mijn vriend dat wel op een diskette gezet had, want van bochs enal heeft hij niet veel kaas gegeten.
Nu ben ik wel erg benieuwd naar je theorie, 't is wel niet helemaal hetgeen wat jij zegt maar 't is wel ongeveer hetzelfste niet?
thx anyway

[ Voor 15% gewijzigd door Verwijderd op 29-03-2003 21:52 ]

[PiepPiep]

Logisch dat bochs GenuineIntel geeft bedenk ik me nu ;-)
Bochs emuleert namelijk een computer, hij gebruikt niet direct de cpu om alles uit te voeren.
Bochs doet gewoon een intel cpu na, had ik nog niet aangedacht maar das het.

Mijn theory was dat cpuid privileged was ofzo, ik was namelijk een tijdje terug bezig met rdtsc, read timestamp counter, die een 64 bits waarde geeft van het aantal clockpulsen sinds dat de cpu aanstaat.
Als ik deze instructie onder windows in een dosbox deed kreeg ik een foutmelding van windows, in dos werkte het prima, dit was op een pentium 1.
Later op mijn pentium 2 of gewoon een andere windows versie kan ook weet ik ff niet meer, werkte het wel onder windows.
Blijkt dus dat er een flag in een configuratie register is die bepaalt of iedereen of alleen ring0 (os kernel) deze instructie mag gebruiken.
Onder dos draait alles op hetzelfde niveau en dus mag elk programma gewoon rdtsc doen.
Wat het nut is om deze instructie te verbieden snap ik nog niet, mja, intel zal wel een reden hebben.
Wat ik nu dus dacht is dat cpuid misschien ook niet echt mocht maar dat windows het zou afvangen en gewoon dus GenuineIntel zou invullen.
Dit is echter niet waar, mijn theory dus, want je draaide onder bochs :-)
Voor zover ik weet mag dus elk programma gewoon cpuid uitvoeren.

[madwizard]

PiepPiep schreef op 29 March 2003 @ 22:41:
Mijn theory was dat cpuid privileged was ofzo, ik was namelijk een tijdje terug bezig met rdtsc, read timestamp counter, die een 64 bits waarde geeft van het aantal clockpulsen sinds dat de cpu aanstaat.
Als ik deze instructie onder windows in een dosbox deed kreeg ik een foutmelding van windows, in dos werkte het prima, dit was op een pentium 1.
Later op mijn pentium 2 of gewoon een andere windows versie kan ook weet ik ff niet meer, werkte het wel onder windows.
Blijkt dus dat er een flag in een configuratie register is die bepaalt of iedereen of alleen ring0 (os kernel) deze instructie mag gebruiken.
Onder dos draait alles op hetzelfde niveau en dus mag elk programma gewoon rdtsc doen.

CPUID is niet privileged, mag je overal gebruiken. RDTSC is inderdaad privileged als de TSD flag (time stamp disable) is geset in cr4, behalve in real mode dan mag je em altijd gebruiken. In windows hoort deze gewoon uit te staan en windows programma's mogen/kunnen de instructie gewoon gebruiken.
Het probleem was waarschijnlijk dat door een bug in de (dacht alleen de vroegere) pentiums RDTSC in virtual86 mode (dos box) toch niet was toegestaan.
Sommige programma's die programma's in virtual86 mode draaien (zoals een dos box) vangen de fout op en corrigeren de resultaten van de instructie waardoor het toch allemaal weer werkt.
In real & protected mode zou het allemaal moeten werken, CPUID al helemaal want die heeft geen restricties.

Wat het nut is om deze instructie te verbieden snap ik nog niet, mja, intel zal wel een reden hebben.

Ze verbieden het niet, ze geven er de mogelijkheid toe. Als 1 of ander OS niet wil dat z'n programma's die instructie gebruiken kan deze het dus uitzetten.