Hallo Leute, ich habe da mal eine eher theoretische Frage: Welche Bedingungen muessen erfuellt sein, damit man auf einem PC (also x86) ein Programm ausfuehren kann, ohne das ein OS vorhanden sein muss? Wuerde es reichen den Programmcode auf einem Datentraeger (HDD, DOM, USB-Stick, CD/DVD, was auch immer) so zu platzieren, das der Code an einer bestimmten Adresse anfaengt? Was muss beachtet/erfuellt werden damit sowas funktioniert? Gruesse
Kaj G. schrieb: > Wuerde es reichen den Programmcode auf einem Datentraeger (HDD, DOM, > USB-Stick, CD/DVD, was auch immer) so zu platzieren, das der Code an > einer bestimmten Adresse anfaengt? Ja, natürlich. Nichts anderes machen doch Bootloader. Kaj G. schrieb: > Was muss beachtet/erfuellt werden damit sowas funktioniert? Der Code muss an der richtigen Stelle sein, und drumherum das richtige Format vorhanden (MBR bei Festplatten, USB-Sticks, El Torito bei CD's etc) sein. Der Code darf natürlich keine Betriebssystem-Funktionen ausführen. Er muss (zumindest zum Starten) auf BIOS-Funktionen zurückgreifen, und könnte dann "richtige" Treiber für zB die Festplatte laden, um mehr Code laden und ausführen zu können. Typischerweise ist dieser Teil in Assembler geschrieben. Gibts sogar Tutorials für, musst du nur ein bisschen Googlen.
Vielen Dank fuer die Antworten, das Hilft mir schon mal. :) Werde mir die Links gleich mal anschauen. Gruesse
Kaj G. schrieb: > Welche Bedingungen muessen erfuellt sein, damit man auf einem PC (also > x86) ein Programm ausfuehren kann, ohne das ein OS vorhanden sein muss? Verallgemeinert muss das Programm alles selbst mitbringen, was es braucht... > Wuerde es reichen den Programmcode auf einem Datentraeger (HDD, DOM, > USB-Stick, CD/DVD, was auch immer) so zu platzieren, das der Code an > einer bestimmten Adresse anfaengt? Nein, weil der PC ohne OS gaaanz trivial gesagt nicht mal weiß, dass er USB hat. > Was muss beachtet/erfuellt werden damit sowas funktioniert? Dem BIOS muss nach dem Initialisieren ein Einsprungpunkt gegeben werden, an dem das Programm übernehmen kann - sprich, der Startdatenträger (HDD / DVD und bei modernem BIOS auch USB-Datenträger) muss die entsprechenden Dateien zur Verfügung stellen (zu DOS-Zeiten nannte man das Startdiskette). Soweit ich weiß ist aber nur ein minimalistischer BIOS-Treiber für USB implementiert (je nachdem hat man da evtl sogar Zugriff auf den Treiber), d.h. wahrscheinlich wird dein Programm die restliche USB-Funktionalität selbst mitbringen müssen. Dann wäre da noch das Konfigurieren (oder allgemein eben Treiber) der jeweiligen Hardwarekomponenten, also z.B. RTC für die Uhrzeit, MemoryManagementUnit(s), Grafikkarte, Soundkarte, Netzwerkkarte, etc, je nachdem, welche Funktionen du denn brauchst... Das alles ist gelinde gesagt an der Oberfläche(*) gekratzt (und vielleicht die eine oder andere Aussage nicht ganz richtig), aber PC ohne OS ist wie ein Auto ohne Motor, du kannst zwar einsteigen und den Blinker oder das Radio laufen lassen, aber sonst nicht viel damit machen... Wenn du allerdings ältere Rechner (286/386/ggf. noch 486) verwendest, da kannst du wahrscheinlich mit ein bisschen Assembler relativ viel erreichen, was für das Verständnis so eines Rechners bestimmt etwas bringt. My 50ct... Ralf * -> Selbst wenn du beispielsweise einen Treiber geschrieben hast, um mit der Festplatte zu kommunizieren, dann fehlt dir immer noch der Treiber für das vorhandene Dateisystem...
Sieh dir doch den Quelltext eines Bootloaders und/oder der den entsprechenden Teil eines älteren Linux-Kerns an (ein 2.4x liess sich IIRC noch "blank" von einer Diskette starten)...
Dr. Sommer schrieb: > Er muss (zumindest zum Starten) auf BIOS-Funktionen > zurückgreifen Nö, muss er nicht.
Ralf schrieb: > Verallgemeinert muss das Programm alles selbst mitbringen, was es > braucht... Fast. Das BIOS gibts schon noch. > Nein, weil der PC ohne OS gaaanz trivial gesagt nicht mal weiß, dass er > USB hat. Muss er auch nicht, booten kann er trotzdem. USB Massenspeicher werden also offenbar vom BIOS in den INT 13h reingehängt. > Dem BIOS muss nach dem Initialisieren ein Einsprungpunkt gegeben werden, > an dem das Programm übernehmen kann Das BIOS läd den Code im Bootsektor der Disk an eine feste Adresse im RAM und springt dort hin. Den Rest muss dieser Code erledigen. > Dann wäre da noch das Konfigurieren (oder allgemein eben Treiber) der > jeweiligen Hardwarekomponenten, also z.B. RTC für die Uhrzeit, > MemoryManagementUnit(s), Grafikkarte, Soundkarte, Netzwerkkarte, etc, je > nachdem, welche Funktionen du denn brauchst... So lange man bei jenen Komponenten bleibt, die anno 80er in den PC/AT Vorbildern schon existierten, gibts nicht viel zu konfigurieren. Das löppt auch so. Also ein CPU-Core, grundlegende Speicherkonfiguration, VGA-Grafik. > Wenn du allerdings ältere Rechner (286/386/ggf. noch 486) verwendest, da > kannst du wahrscheinlich mit ein bisschen Assembler relativ viel > erreichen, was für das Verständnis so eines Rechners bestimmt etwas > bringt. Wenn er sich beim neuen Rechner darauf beschränkt, was bei diesen älteren Rechnern schon ging, ändert sich nicht viel. Nur die Geschwindigkeit des zunächst einzig verwendbaren Cores.
Ralf schrieb: > Nein, weil der PC ohne OS gaaanz trivial gesagt nicht mal weiß, dass er > USB hat. Doch: wenn er vom USB-Stick booten kann, muss sein BIOS schon wissen, wie es mit dem USB und einem dort befindlichen mass storage device umgeht.
Jörg Wunsch schrieb: > Doch: wenn er vom USB-Stick booten kann, muss sein BIOS schon wissen, > wie es mit dem USB und einem dort befindlichen mass storage device > umgeht. Ebenso Tastatur und Maus. BIOS: legacy device emulation, oder so ähnlich.
Wie diese "Legacy Device Emulation" funktioniert ist eh interessant (Stichwort http://en.wikipedia.org/wiki/System_Management_Mode) ... da läuft BIOS-Code und simuliert Hardware ohne dass Du es mitbekommst....
Der heutige BIOS ist wie ein Eisberg. Das, was man davon sieht, ist klein gegenüber dem, was sich unterhalb der Oberfläche befindet. Wenn man mal die Gesamtheit der Firmwares unter "BIOS" zusammenfasst.
:
Bearbeitet durch User
Naja man muß zumindest vom Real-mode in den Protected-mode schalten. Nach dem anschalten ist der PC halt ne richtig schnelle 16-Bit CPU. http://www.lowlevel.eu/wiki/Real_Mode und die GDT (Global Descriptor Table) sollte initialisiert werden. http://www.lowlevel.eu/wiki/Global_Descriptor_Table http://www.lowlevel.eu/wiki/Hauptseite
uwe schrieb: > Naja man muß zumindest vom Real-mode in den Protected-mode schalten. Vielleicht will man es, aber man muss es nicht. 640kB reichen doch ewig. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Vielleicht will man es, aber man muss es nicht. > 640kB reichen doch ewig. ;-) dafür brauch man dann nicht mal ram, das läuft dann im Cache vom Prozessor.
Wenn man richtig "Spaß" haben will nimmt man ein modernes UEFI mit Secure Boot. So richtig versteht da keiner mehr wie das Booten abläuft. Besonders nicht den Unterschied zwischen der feinen Theorie und der mehr als dreckigen Praxis.
A. K. schrieb: > Der heutige BIOS ist wie ein Eisberg Das was der TO will, geht auch ohne BIOS - man schreibt Software, die an der Resetadresse beginnt und ALLES macht, was man erreichen will, und die brennt man in ein ROM, das man anstelle des BIOS einsetzt. Nachteil: die Abstraktion bzw. Anpassung, die das BIOS bereits leistet, muss man selbst erbringen, allerdings kann man dafür Hardware verwenden, mit der ein BIOS nichts anfangen kann, z.B. Matrixtastaturen oder exotische LCDs. Wahrscheinlich funktioniert sowas nur genau auf einem einzigen PC, oder es wird zur Lebensaufgabe. Ist wohl eher was für Verrückte. Georg
Georg schrieb: > Ist wohl eher was für Verrückte. Und die anderen machen das mit einem Boot-Medium (z.B. USB-Stick).
A. K. schrieb: > 640kB reichen doch ewig. ;-) Genau genommen reichen sie doch für jeden völlig aus. :-)
ein kernel muss idr geladen werden, weil ein programm nur z.b. speicher anfordert, sich aber nicht um das speicherlayout kümmert. wenn es multithreaded ist braucht es noch den scheduler vom kernel, wenn es dateien lesen/schreiben will api zugriffe aufs vfs, wenn es was auf dem bildschirm ausgeben soll einen grafikkarten treiber… usw usf. neben dem treiber braucht das programm noch alle dynamisch zu ladenden libs - oder es ist halt statisch gelinkt. "ein programm" "alleine auf x86" laufen zu lassen ist idr nicht möglich.
c.m. schrieb: > ein kernel muss idr geladen werden, weil ein programm nur z.b. speicher > anfordert, sich aber nicht um das speicherlayout kümmert. > wenn es multithreaded ist braucht es noch den scheduler vom kernel, wenn > es dateien lesen/schreiben will api zugriffe aufs vfs, wenn es was auf > dem bildschirm ausgeben soll einen grafikkarten treiber… usw usf. > neben dem treiber braucht das programm noch alle dynamisch zu ladenden > libs - oder es ist halt statisch gelinkt. > > "ein programm" "alleine auf x86" laufen zu lassen ist idr nicht möglich. doch, sonst könnte man auch keine µC Programmieren. Der Kernel ist auch nur ein Programm. memtest ist doch ein schönen Beispiel, ist ein Programm was direkt ausgeführt wird, er kann sogar den kompletten Speicher nutzen und braucht auch keinen Kernel.
c.m. schrieb: > "ein programm" "alleine auf x86" laufen zu lassen ist idr nicht möglich. Warum denn nicht. Logisch kann man dann keine API-Zugriffe und ähnliches machen. Weil es keine API gibt. Aber wenn das Programm alles selbst macht, was es braucht, warum soll das nicht funktionieren? Das BIOS für die grundlegenden Sachen kann man ja auf jeden Fall nutzen. Aber eben alles, was Betriebssystemfunktionen sind, nicht.
x86 muß ja nicht zwangsläufig ein PC sein, da ist so ein Vorhaben vermutlich ein Projekt ohne Ende, aber es gibt auch Dev-Boards mit x86 Prozessoren, und da sollte das machbar sein. http://www.amazon.com/Development-Boards-Kits-INTEL-GALILEO1/dp/B00HKI9PXI http://www.gizmosphere.org/ Mit freundlichen Grüßen - Martin
Georg schrieb: > Das was der TO will, geht auch ohne BIOS - man schreibt Software, die an > der Resetadresse beginnt und ALLES macht, was man erreichen will, und > die brennt man in ein ROM, das man anstelle des BIOS einsetzt. Das allerdings wird problematisch, denn dazu benötigt man recht wahrscheinlich allerhand Informationen die nicht öffentlich verfügbar sind. Sondern die man beim nur auf Anfrage beim jeweiligen Hersteller erhält, gegen Unterschrift der Nichtweitergabe. Wenn überhaupt.
A. K. schrieb: > Das allerdings wird problematisch, denn dazu benötigt man recht > wahrscheinlich allerhand Informationen die nicht öffentlich verfügbar > sind. Sondern die man beim nur auf Anfrage beim jeweiligen Hersteller > erhält, gegen Unterschrift der Nichtweitergabe. Wenn überhaupt. Naja, ganz so schlimm ist es im PC-Bereich zum Glück noch nicht, das ist ja nicht diese hochproprietäre ARM-Seuche. Grundsätzlich ist alles möglich, was auch ein Linux-Kernel ohne proprietäre Treiber auf dem entsprechenden System kann. Und bei PCs ist das halt in aller Regel immer noch sehr viel mehr als bei den meisten ARM-Systemen. Die zielen wirklich fast alle auf maximale Entrechtung des Users ab, um die Geldmachmaschinen auf den höheren Software-Ebenen maximal abzusichern. Allerdings befindet sich leider auch im PC-Bereich die Entwicklung auf genau diesem Weg, insofern gebe ich dir Recht.
c-hater schrieb: > Naja, ganz so schlimm ist es im PC-Bereich zum Glück noch nicht, Zum BIOS gehören bei Intel-Prozessoren seit langer Zeit Microcode-Patches für die CPU. Ich hatte bisher nicht den Eindruck, dass die leicht zu kriegen seien. Nur als Beispiel. > Grundsätzlich ist alles > möglich, was auch ein Linux-Kernel ohne proprietäre Treiber auf dem > entsprechenden System kann. Weil der Rechner ein BIOS vorneweg hat, das den Kram initialisiert und Basisfunktionen zur Verfügung stellt, geht mindesten VGA. Nackt und bloss, ohne BIOS, also auch ohne BIOS der Graka, das wird schon interessanter.
Woah, so viele Antworten :O Martin Schlüter schrieb: > aber es gibt auch Dev-Boards mit x86 > Prozessoren, und da sollte das machbar sein. Danke fuer den Hinweis, werd ich mir mal anschauen :) Georg schrieb: > Das was der TO will, geht auch ohne BIOS Man muss ja nicht gleich uebertreiben, ich wollte die Geschichte der Menschheit nicht neu schreiben^^ Georg schrieb: > Ist wohl eher was für Verrückte. Oder fuer die, die einer theoretischen Ueberlegung nachgehen :) uwe schrieb: > Naja man muß zumindest vom Real-mode in den Protected-mode schalten. > Nach dem anschalten ist der PC halt ne richtig schnelle 16-Bit CPU. > http://www.lowlevel.eu/wiki/Real_Mode > und die GDT (Global Descriptor Table) sollte initialisiert werden. > http://www.lowlevel.eu/wiki/Global_Descriptor_Table > http://www.lowlevel.eu/wiki/Hauptseite > http://www.lowlevel.eu/wiki/Teil_4_-_Hello_World Danke, das sieht gut aus :) c.m. schrieb: > ein kernel Den ich ja gar nicht haben will... Kaj G. schrieb: > ohne das ein OS vorhanden sein muss Bevor sich hier wieder Leute die Koeppe einschlagen, was sein muss oder nicht, ob mit oder ohne BIOS usw: Das ist nach wie vor eher eine theoretische Frage :) Vielleicht ist es hilfreich wenn man ab hier annimmt, das ein BIOS vorhanden ist, ob das originale BIOS oder Coreboot sei einmal dahin gestellt. Alle Eure Antworten helfen mir auf jeden Fall bei meinen Gedankengaengen. Vielen Vielen Dank! :) Gruesse
A. K. schrieb: > Zum BIOS gehören bei Intel-Prozessoren seit langer Zeit > Microcode-Patches für die CPU Aber der Prozessor funktioniert auch ohne, sonst könnte man sie ja nicht laden. Georg
Kommt drauf an was du unter einem 'Programm' verstehst... Hab mich mal mit der gleichen Frage beschäftigt und glaube nun an einem Punkt zu sein wo ich dir sagen kann dass es 'relativ' aufwendig ist. Solltest Du Dich intensiever damit beschäftigen wollen so rate ich dir auf jeden Fall dich mit x86 und IBM-kompatiblen PCs vertraut zu machen; es ist auch nützlich die BIOS Reference Manuals (gibts über google) anzuschauen da dort die ganzen BIOS-Funktionen dokumentiert sind. Solltest Du vorhaben das Programm in c zu realisieren so sollte man sicher auch mit der gnu tool chain vertraut sein... und vieles mehr... Wie bereits angesprochen ist es auch sehr hilfreich den Linux-Kernel unter die Lupe zu nehmen. Man kann sich dort ein Bild machen wie Linux auf x86 startet. Ist ein bisschen zeitaufwendig aber sicher interessant. ... soviel dazu wenn du wirklich etwas machen möchtest das du dann verkaufen möchtest. Ansonsten hätte ich noch als heißen Tip MenuetOS -> http://www.menuetos.de/downloads/ ... Ein kleines Betriebssystem das in Assembler programmiert ist. Du kannst dir dort den Quelltext runterladen. Ich habe ausgehend von dem ein kleines 'Programm' geschrieben das selbständig 'booten' konnte und 'hello world' auf dem Bildschirm anzeigen konnte; das war dann aber schon alles...
schau dir mal http://www.coreboot.org/ an, die ersetzen das BIOS mit eigenem code (hier nen bootloader + optional ein bios)
Das wäre natürlich auch eine Möglichkeit herumzuprobieren: ein älteres Mainboard nehmen und die BIOS-ROMs mit solchen (oder einem Emulator) ersetzen die deinen Code enthalten. Logischerweise musst Du Dich dann um jede Hardware die Du ansprechen willst selbst kümmern...
Andy D. schrieb: > Logischerweise musst Du Dich dann um jede Hardware die Du ansprechen > willst selbst kümmern... Macht sich deutlich entspannter, wenn man noch ein altes Board mit ISA benutzen kann. Das ist ein vergleichsweise simpler Bus, bei dem alles geradlinig benutzt werden kann. Wenn der ISA-Bus jedoch hinter einer PCI-to-ISA-Bridge sitzt, dann muss man sich dennoch erstmal um die komplette PCI-Konfiguration kümmern. Also: je älter das Board, um so einfacher geht das alles.
Beim IBM PC, XT und AT wurde neben den vollständigen Schaltplänen auch der Assemblerquelltext des BIOS veröffentlicht ... die jeweiligen "Technical Reference Manuals" lassen sich im Internet finden.
Ausserdem könnte man als Konsole erstmal eine serielle verwenden wie bei einem uc solange diese auf dem Board noch vorhanden ist. Bei einer VGA-Karte wäre die Frage ob diese in einen brauchbaren Modus initialisiert wird wenn der Code im EPROM nicht ausgeführt wird (wahrscheinlich ja - das BIOS nutzt die Karte ja recht früh für Ausgaben), dann reicht eigentlich schon http://en.wikipedia.org/wiki/VGA-compatible_text_mode#Access_methods als Anleitung...
Andy D. schrieb: > Bei einer VGA-Karte wäre die Frage ob diese in einen brauchbaren Modus > initialisiert wird wenn der Code im EPROM nicht ausgeführt wird > (wahrscheinlich ja - das BIOS nutzt die Karte ja recht früh für > Ausgaben), Nein. Bevor das BIOS etwas auf der VGA-Karte ausgeben kann, muss es die initialisieren, und dazu ruft es entsprechende Funktionen im BIOS-Erweiterungs-ROM der VGA-Karte auf. Das wiederum biegt den Softwareinterrupvektor für die Bildschirmausgabe auf sich um. Das PC-BIOS selbst enthält nur den Code zur Ansteuerung von MDA bzw. CGA, alles weitere (EGA oder VGA) läuft nur mit BIOS-Erweiterungs-ROMs. Bei heutigen PCs mit im Chipsatz bzw. der CPU integrierter Graphikhardware ist dieses BIOS-Erweiterungs-ROM natürlich Bestandteil des Konglomerats, aus dem sich das BIOS mittlerweile zusammensetzt, in Form solcher Erweiterungs-ROMs enthält das auch den Code für die "Legacy-Unterstützung" von USB-Devices (Tastatur, Maus und Massenspeicher zum Booten) und auch das Netzwerkkarten-ROM zum Booten über das Netzwerk. s
Rufus Τ. Firefly schrieb: > in > Form solcher Erweiterungs-ROMs enthält das auch den Code für die > "Legacy-Unterstützung" von USB-Devices Wozu - bei so einem Mainboard ist die Grafik bekannt, Netzwerkchip usw. auch, da kann man sich die ganze Mimik mit Roms an bestimmten Adressen und Prüfsummen, die das BIOS erst suchen muss, von vornherein sparen und einfach nur die Initialisierung an geeigneter Stelle im Power On Ablauf aufrufen. Georg
Dann müsste man ja anfangen, spezielle Roms zu schnitzen. Natürlich ist die Summe aller Erweiterungs-ROMs und des eigentlichen BIOS in einem großen Klumpen zusammen in einem Flash-Baustein untergebracht, aber das grundlegende Konzept bleibt das gleiche. Warum auch nicht, so lassen sich verschiedene Varianten durch einfaches Zusammenfügen der Komponenten herstellen, und die Unterstützung für das Suchen nach Erweiterungs-ROMs muss eh' vorhanden sein, um mit realen Erweiterungskarten zurechtzukommen. (Der Vereinfachung halber habe ich die Behandlung von ROMs auf PCI-/PCIe-Karten ohne die PCI-/PCIe-Initialisierung beschrieben)
@rufus der 80x25 16-Farb-Modus funktioniert bei CGA/EGA/VGA gleich (bei MDA/HGC ist die Basisaddresse für den Wiederholspeicher anders), und es scheint dass die ROMs auf den ursprünglichen Karten lediglich Zeichengeneratoren sind?
Andy D. schrieb: > der 80x25 16-Farb-Modus funktioniert bei CGA/EGA/VGA gleich Bei EGA und VGA aber erst nach Initialisierung der Hardware durch die Funktionen im BIOS-Erweiterungs-ROM. > und es scheint dass die ROMs auf den ursprünglichen Karten lediglich > Zeichengeneratoren sind? Die auf CGA und MDA. Die auf EGA und VGA nicht. Schaltpläne von CGA und MDA findest Du im "Technical Reference Manual" für IBM 5150 und 5160. (PC und XT). Die der EGA-Karte sind leider nicht im Manual für IBM 5170 (AT) enthalten.
Wer sich für so lowlevel Dinge wie ohne OS starten interessiert, der sollte hier http://rayer.g6.cz/romos/romose.htm weiterlesen. Hatte so um 2004 rum damit mal experimentiert und hatte es sogar geschafft, das mein Rechner eigenen Code auageführt hat, welchen ich im ROM der Netzwerkkarte platziert hatte. Bei ELV gab es einen EPROM-Simulator, damit war das recht einfach machbar. Den Bootrom selbst musste man über DOS-Tools von Intel erst einschalten.
Sven L. schrieb: > Den Bootrom selbst musste man über DOS-Tools von Intel erst einschalten Gut dass es das so nicht mehr gibt, das wäre ein schönes Einfallstor für Trojaner, die selbst einen Festplattentausch überleben. Georg
Gibt genug andere Hardware die Option-Roms hat die sich überflashen lassen, wenn nicht sogar mehr als vor zehn Jahren...
A. K. schrieb: > Zum BIOS gehören bei Intel-Prozessoren seit langer Zeit > Microcode-Patches für die CPU. Ich hatte bisher nicht den Eindruck, dass > die leicht zu kriegen seien. Nur als Beispiel. Wie macht das Coreboot?
Habe ein wenig recherchiert. Die Patches sind nicht im geringsten schwer zu bekommen: goo . gl/ffLdyq Nicht nur das BIOS laed sie in den Prozessor, auch der Linux Kernel kann das tun. Manche CPU Modelle kommen auch ohne aus, bzw stuerzen dann halt alle 2 Wochen mal ab. Andere Modelle brauchen die Patches allein schon um beim Taktfrequenzwechsel nicht zu crashen. An sich aber kein Problem, bekommen kann man sie ja... Ueberhaupt ist es "kein Problem" das BIOS zu tauschen. Coreboot tut genau das. Sie implementieren (natuerlich) auch einen SMI Vektor und co. Alles Open Source. Dass das Programm dann auf einem anderen PC nicht laeuft ist klar, jedes Mainboard ist anders, daher kannst du ja auch nicht einfach auf dein Mainboard das BIOS eines anderen flashen. Coreboot hat recht viel Support, ich habe gelesen man muesse nur die richtigen Treiber zusammen compilen und dann sollte es auch schon auf einem neuen Board laufen. Falls die Treiber existieren natuerlich. Aus einem Security Standpunkt sind die Microcode Patches uebrigens schon irgendwie fragwuerdig... Wenigstens den SMM bekommt man mit Coreboot weg.
Was mich immer wieder fasziniert sind PCs diverser Hersteller die die interne Grafik einer i5 oder i7 CPU nutzen und es dann irgendwie fertig bringen dass die Referenztreiber, bei Intel heruntergeladen oder in der WHQL-Variante via Windows Update bekommen, nicht mehr funktionieren. Was man nicht vergessen sollte: Manche Hardware wird thermisch ganz schön belastet wenn man Code darauf laufen lässt der seinen Ruhezustand über busy loops statt über HALT oder Runtertakten implementiert (zB auch einige BIOSe solange man im Setup abhängt)...
In der guten alten Zeit soll es sogar Leute gegeben haben die Ihre Software ins Eprom geschossen haben und an der Stelle des BIOSes aufs Board gesteckt haben. Das scheidet ja heute wegen der aufwendigen Hardware etwas aus. Aber zu 286/386er-Zeiten wart die Welt noch eine andere.
Georg schrieb: > Gut dass es das so nicht mehr gibt, das wäre ein schönes Einfallstor für > Trojaner, die selbst einen Festplattentausch überleben. Im Zuge des technischen Fortschritts hat man es sich wieder eingefangen: http://www.heise.de/newsticker/meldung/US-Cert-warnt-vor-weiteren-UEFI-BIOS-Luecken-2512913.html
Fragezeichen schrieb: > In der guten alten Zeit soll es sogar Leute gegeben haben die Ihre > Software ins Eprom geschossen haben und an der Stelle des BIOSes aufs > Board gesteckt haben. Man konnte dafür gut die freie Fassung auf der Netzwerkkarte nehmen. Das EPROM musste mit 55AA anfangen, und im vierten Byte einen Offsetwert enthalten. Das BIOS ist dann auf EPROM-Adresse plus Offsetwert gesprungen und hat den dort vorhandenen Code ausgeführt. Hatte den Vorteil, dass die Mainboard-Register dann schon initialisiert sind und man INT-13, INT-25 und wie sie alle heissen nutzen kann.
Koennte man fuer experiemte in diese Richtung vielleicht das Minnowboard (http://www.minnowboard.org/meet-minnowboard-max/) verwenden? Ich kann mit vorstellen, dass es bei diesem Board einfacher ist, eigenen Code in den Flash zu schieben, als bei einem echten Mainboard. Was meint Ihr dazu?
Kaj G. schrieb: > Ich kann mit vorstellen, dass es bei diesem Board einfacher ist, eigenen > Code in den Flash zu schieben, als bei einem echten Mainboard. Warum sollte es das sein? Weil das Ding kleiner ist? Oder weil es dafür noch 'nen Stecker gibt? Das Übertragen des Codes ins Flash ist bei der ganzen Aktion das geringste Problem.
Rufus Τ. Firefly schrieb: > Warum sollte es das sein? Weil (soweit mein Verstaendnis) solche "Embedded"-Boards eher dafuer gedacht sind eigenen Code laufen zu lassen, als ein "normales" Mainboard der ueblichen Herstellen, wie z.B Gigabyte, Asus, usw. Ich lass mich gerne eines besseren belehren. Wenn ihr sagt, dass das voellig Stulle ist, ist auch gut.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.