1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Bios-Bugs: Linux-Kernel schnappt…

Unter 640 KiB?

  1. Thema

Neues Thema Ansicht wechseln


  1. Unter 640 KiB?

    Autor: /mecki78 10.06.21 - 14:28

    Auf einem x86 System, auf dem Firmware den Speicher unter 640 KiB nutzt, könnte nicht einmal MS-DOS fehlerfrei laufen. IMHO ist hier das System bzw. diese Firmware kaputt. Was für Systeme sollen das bitte sein?

    Und ein bisschen Geschichte für interessierte:
    https://www.xtof.info/the-640k-memory-limit-of-ms-dos.html

    /Mecki

  2. Re: Unter 640 KiB?

    Autor: wolf.duttlinger 10.06.21 - 15:07

    The times, they are achanging.. Es gab mal die Aussage einer Firma mit drei Buchstaben, dass es ein OS/2 geben würde, das mit nur 2MB RAM auskommen würde. Heutzutage wird einfach mal so 1 MB ausgeblendet...

  3. Re: Unter 640 KiB?

    Autor: Johannes321 10.06.21 - 16:29

    In dem Link fehlt noch der Unreal Mode, bei dem man (ab 386) die GDT mit linearen 4GB Segmenten lädt, die CPU-internen Segmentregister lädt (nach außen hat z.B. DS nur 16bit, nach innen ab 286/386 viel mehr), und dann wieder in den Real Mode zurück wechselt.

    Von dem Punkt an funktionieren Zugriffe mit 32bit Registern auch aus dem Real Mode heraus.

    Aber zum eigentlichen Thema: Es gibt teilweise Firmware die leider wirklich wirklich schlecht geschrieben ist. Fast jede Firma die meint was für Computer herstellen zu müssen muss am Ende auch Firmware machen, manche wären da lieber bei der Hardware geblieben.

    Eine Blacklist würde mich da aber auch mal brennend interessieren. In gewissen Kreisen wird ja bekannt sein, für welche Gerätschaften der 1MiB Schreibschutz eingeführt wurde.



    1 mal bearbeitet, zuletzt am 10.06.21 16:29 durch Johannes321.

  4. Re: Unter 640 KiB?

    Autor: abufrejoval 10.06.21 - 22:15

    Johannes321 schrieb:
    --------------------------------------------------------------------------------
    > In dem Link fehlt noch der Unreal Mode, bei dem man (ab 386) die GDT mit
    > linearen 4GB Segmenten lädt, die CPU-internen Segmentregister lädt (nach
    > außen hat z.B. DS nur 16bit, nach innen ab 286/386 viel mehr), und dann
    > wieder in den Real Mode zurück wechselt.
    Den gab es wohl wirklich nur mit 80386er CPUs, schon beim i486er ging das nicht mehr und beim 80286 funktionierte das prinzipiell nicht, weil alle Register, auch die Segmentregister, ja noch 16-Bit waren.

    Um von den 20 physischen Adreßbits des 8086 bzw. Real-Mode auf die physischen 24 Bit im 80286er Protected Mode zu kommen, war der Shift für die physische Basisaddresse gegenüber dem Real-Mode noch mal um vier Bit nach links verschoben. Außerdem wurden die niederwertigsten Bits der Segmentaddressen tatsächlich nicht als Offset, sondern als Segmentattribute ausgewertet. Im Real Mode überlappten sich nachfolgende Segmentadressen im physischen Speicher fast vollständig, nur die ersten/letzten 16 Byte nicht. Der Protected Mode verwandelte den physischen Speicher in 64k Kacheln.

    >
    > Aber zum eigentlichen Thema: Es gibt teilweise Firmware die leider wirklich
    > wirklich schlecht geschrieben ist. Fast jede Firma die meint was für
    > Computer herstellen zu müssen muss am Ende auch Firmware machen, manche
    > wären da lieber bei der Hardware geblieben.
    Nach den Comments im Source-Code scheint das Problem hier eher zu sein, daß es gelegentlich noch Firmware gibt, welche tatsächlich im Real-Mode laufen muß und auf das Extended Bios Data Area zugreift. Und die hat nun mal gar keine Wahl, als den Bereich zwischen 0 und 640K zu verwenden, denn etwas anderes läßt sich da (außer mit dem Unreal-Mode) nicht adressieren.

    Ich denke mit etwas Nostalgie daran zurück, wie ich meinen eigenen DOS Protected Mode Extender für meinen 80286 geschrieben habe, um den zusätzlichen Speicher, den ich sonst vor allem für Microport Unix (für den 80286!) einsetzte, auch unter DOS bzw. GEM nutzbar zu machen.

    Eine Rückkehr vom Protected Mode war für den 80286 nämlich nicht vorgesehen. Weil aber IBM beim IBM PC-AT beim Booten den gesamten physischen Speicher prüfen wollten, mußte ein Mechanismums her, mit dem man nach dem Speichertest im Protected-Mode wieder in den Real-Mode zurückschalten konnte.

    Dazu wurde ein Port des Tastaturkontrollers mit der Reset-Leitung des Prozessors verbunden und der dann aufgefordert, kurz Reset zu aktivieren. Damit der Rechner aber unterscheiden konnte, ob er gerade eingeschaltet worden war (Speichertest noch durchführen) oder nur aus dem PM zurückkehren sollte (mit einer Rückspungaddresse aus der Interrupttabelle), wurde dies in einem freien Byte im CMOS Speicher der Uhr vermerkt. Klar, daß so ein PM/RM Wechsel schon ein paar Taktzyklen verschliß..

    Später fanden ein paar findige Leute heraus, daß man über einen Tripple-Fault einen Reset weit schneller auslösen konnte, als über den Tastaturkontroller. Und in späteren CPUs wurde das ggf. noch besser gelöst.

    Ach ja, mein 80286 (auf 8MHz übertaktet) mit einer EGA-Graphikkarte kostete nur so schlappe 20.000,- DM und fühlte sich unglaublich cool und schnell an. Meine Kommilitonen mußten sich i.d.R. mit 8088 und grün/orange auf schwarz begnügen.

    Ich habe nie wieder so viel Geld für Computer ausgegeben. Keine Ehefrau würde das heute ohne eine Gegenleistung in vergleichbarer Größe durchgehen lassen.

    Und da sollen sich heute ja Leute darüber beschweren, daß eine RTX 3090 ¤3000 kostet. Eine EGA mit 16 aus 64 Farben bei 640x350 Pixeln völlig beschleunigungsfrei kostete 1986 eher mehr.

  5. Re: Unter 640 KiB?

    Autor: Johannes321 11.06.21 - 14:04

    Doch das geht schon auch auf späteren CPUs, möglicherweise wurde das Verhalten dort aber extra emuliert. Sogar Emulatoren ala QEmu können es.

    Wenn ich mich richtig erinnere war das Vorgehen bei Linux bzgl. Real Mode Firmware, dass diese in einem Emulator laufen soll. (8086 RM Emulator ist ja recht einfach.)
    Vielleicht wurde das aber nicht vollständig umgesetzt... hat AMD64 noch den Virtual 86 Mode? Ohne den wäre es grob fahrlässig Firmware im Real Mode laufen zu lassen, man könnte ja dann beliebiges mit der Hardware anstellen.
    Mir war so als wäre der damals entfernt worden weil von solchen Firmware-Geschichten abgesehen inzwischen wirklich völlig unnötig.

    EDIT:

    Hier noch ein paar kurze Infos dazu: https://wiki.osdev.org/Unreal_Mode



    1 mal bearbeitet, zuletzt am 11.06.21 14:05 durch Johannes321.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT Expert Consultant (m/w/d) PLM/PDM
    Dürr Systems AG, Bietigheim-Bissingen
  2. Automatisierer/SPS-Programmi- erer SPS-Technik / Leittechnik (m/w/d)
    ZIPPE Industrieanlagen GmbH, Wertheim
  3. Product Owner Digital Sales für die Abteilung Kundenprozesse, -anwendungen & -daten (m/w/d)
    Allianz Deutschland AG, München, Unterföhring
  4. Controller*in (m/w/d)
    Medion AG, Essen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Chivalry 2 für 32,99€, Dovetail Deals (u. a. Train Sim World 2 für 9,99€, Fishing Sim...
  2. 69,99€
  3. (u. a. HP Wired Desktop 320MK Desktop-Set Tastatur & Maus für 29,99€, HP Business Headset v2...
  4. (u. a. The Hateful 8 Steelbook Limited Edition (Blu-ray) für 12,97€, Stephen Kings - Manchmal...


Haben wir etwas übersehen?

E-Mail an news@golem.de