Forum: Mikrocontroller und Digitale Elektronik x86 Memory management


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Hallo liebe Leute,
hoffe alle sind gesund!
Ich wende mich mit einer Frage bezüglich x86 Prozessoren an euch:
In den letzten Wochen habe ich angefangen (zum Spaß) einen Kernel in C 
zu schreiben der startet und einfach Guess a number spielt (also 
Tastatur und Monitor laufen).
Nun würde ich gerne zum experimentieren ein simples Filesystem für eine 
x86 Maschine schreiben. Soweit nichts neues, in C 8-Bit habe ich so 
etwas schon vor langem einmal gemacht. Allerdings haben nun x86 
Prozessoren keinen eigenen Speicher (bzw. nicht viel) sondern sprechen 
eine Festplatte an.
Konkrete Frage:
wie Genaus kann ich eine SATA-Festplatte simpel ansprechen?
Wie erreiche ich dass ich auf die einzelnen Speicher-Seiten der Platte 
zugreifen kann und darin "blättern" kann?
Das ganze ohne virtual Memory sondern einfach physische Adresse :)
Das Programm läuft auf einem ACER bzw ich bin auch über Codebeispiele 
für ARM zB Raspberry sehr dankbar wenn jemand so nett wäre hier eines zu 
posten?
Alles Liebe & bleibt gesund,
Andreas

von John Doe (Gast)


Bewertung
1 lesenswert
nicht lesenswert

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
1 lesenswert
nicht lesenswert
Andreas schrieb:
> Allerdings haben nun x86
> Prozessoren keinen eigenen Speicher (bzw. nicht viel) sondern sprechen
> eine Festplatte an.
Hä?
Auch wenn der RAM nicht auf der CPU sitzt haben die Dinger in der Regel 
auf der Platine wo sie drauf sitzen mehr als genug davon.

> Konkrete Frage:
> wie Genaus kann ich eine SATA-Festplatte simpel ansprechen?
> Wie erreiche ich dass ich auf die einzelnen Speicher-Seiten der Platte
> zugreifen kann und darin "blättern" kann?
Simpel ist hier garnichts, die CPU kann überhaupt nicht direkt auf eine 
Festplatte zugreifen. Dafür sind spezielle Controller zuständig.
Der SATA-Kontroller ist in der Regel einen eigenständigen Chip (ggf. im 
Chipsatz der zur CPU gehört integriert, aber nicht in der CPU) der auch 
entsprechend mit eigenen Steuerbefehlen angesprochen werden will. Der 
übernimmt dann die Kommunikation mit der Festplatte und wenn du alles 
richtig gemacht hast landet irgendwann dann auch mal die Info die du 
haben willst via DMA im RAM. Wenn die Daten mal im RAM sind kannst du 
die dann mit der CPU weiter verarbeiten...

Als Beispiel mal die Kap.14 - 16 reinziehen:

https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/c600-series-chipset-datasheet.pdf

(Du hast ja leider nicht angegeben welchen Chipsatz dein Rechner 
benutzt).

Normale Programmierer nutzen für sowas normalerweise die Funktionen die 
das Betriebssystem mit seinen Hardwaretreibern dafür bereitstellt und 
versuchen das nicht selbst zu Fuß zu bauen. Wenn du hier Beispiele 
benötigst wirst du dir wohl größere Teile des Quellcodes von Linux und 
den zugehörigen Treibern reinziehen müssen. Viel Spass:-)

von Johannes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schon alles gemacht vor vielen vielen Jahren.

Deine Aussage ist ein wenig schwammig - x86 ist ein großes Feld. Real 
Mode? Protected Mode? Long Mode? Das hat einen enormen Einfluss darauf, 
ob bzw. wie du über das BIOS an die Daten kommst. Für die letzten beiden 
solltest du dich ausführlich einlesen, so ein x86er ist ein bisschen 
komplexer als Mikrocontroller.

QEmu kennst du? Eigentlich unverzichtbar zur Entwicklung von solchen 
Sachen. Anders als z.B. VMWare oder VirtualBox kann QEmu ein System sehr 
realistisch simulieren, Geschwindigkeit ist ja egal.


An den Schreiber über mir: Ja es gibt ein BIOS, das mit Hilfe der 
Firmware im Controller generische Funktionen bereitstellt um auf alles 
mögliche zuzugreifen. Teilweise sind die Funktionen Jahrzehnte alt 
(Graphik), teilweise gibt es keine, aber Storage ist vergleichsweise gut 
zugreifbar.

Anders könnte dein Bootloader (egal ob win oder linux) nicht den Kernel 
von der Platte laden.

UEFI klammere ich hier mal aus, das ist schon wieder eine ganz andere 
Geschichte.

von Planloser (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Der Wikipedia-Link oben listet doch schon die nötigen BIOS-Calls auf.

Es ist nicht so, dass so ein (ähnliches) Projekt nicht schon viele 
andere gemacht hätten, hier ein paar Links:

https://github.com/ghaiklor/ghaiklor-os-gcc
https://github.com/cirosantilli/x86-bare-metal-examples
http://mikeos.sourceforge.net/write-your-own-os.html
https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf
https://www.codeproject.com/Articles/664165/Writing-a-boot-loader-in-Assembly-and-C-Part
https://www.alanfoster.me/posts/writing-a-bootloader/

Etliches ist in Assembler, da C für Unbedarfte einige Fallstricke mit 
sich bringt und man in Assembler auch besser sieht, was genau geschieht.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Ich werfe mal noch http://www.lowlevel.eu (deutsch) und 
https://wiki.osdev.org (englisch) in den Raum.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.