[hydrixOS] : Re: Verbesserungsvorschlaege
- From: kempf_stefan@xxxxxxxx
- To: hydrixos@xxxxxxxxxxxxx
- Date: Sun, 26 May 2002 17:14:41 +0200 (CEST)
On Sun, 26 May 2002, Friedrich Gr=E4ter wrote:
> kempf_stefan@xxxxxxxx wrote:
> >
> > ich war erstaunt als ich sah, dass die Groesse des
> > RAMs ueber Schreiben und Auslesen des Speichers ermittelt
> > wird. Das ist nicht ganz ungefaehrlich. Wird ein Geraet in
> > diesen Speicherbereich gemappt und du schreibst in diesen
> > Bereich kann das zu undefiniertem Verhalten fuehren.
> > IIRc wurde dieses Verfahren deswegen aus dem Linux Kernel genommen.
> > Ich habe angefangen, die RAM Groesse ueber das BIOS zu ermitteln.
> > Den Code wuerde ich dir dann zuschicken.
>
> Es ist allerdings gef=E4hrlich, da muss ich dir Recht geben. Andererseits
> hat das BIOS den Nachteil, dass es nur maximal 64 MB zur=FCckgeben kann,
> so zumindest mein Handbuch =FCber den BIOS Interrupt 12:
[Zitat]
Nein. Ich benutze die Funktion 0xE820 des Interrupts 0x15.
Die sollte bis zu 2^64 Byte zurueckliefern koennen, da die
Adressen in der Memory Map als 64 Bit Zahl zurueckgeliefert werden.
Ueber die Memory Map werden Adresse, Laenge und Typ eines Speicherbereichs
zurueckgeliefert. Der Typ gibt an, ob der Speicher frei oder reserviert
ist usw. Allerdings muss man den Interrupt ein paar mal aurufen, um die
komplette Map zu bekommen.
Sollte dieser Interrupt fehlschlagen nimmt man aeltere BIOS Ints
und im Notfall liest man die RAM Groesse bis 64 MB ueber das CMOS
aus.
Die Funktion ist ein Ralf Browns Interrupt List erlaeutert und steht
auch in der os-faq.
> Die Methode aus 'setup.S' vom Linux-Kernel versteh ich noch nicht ganz.
> Irgendwie wird irgendwo eine Memory map zur Verf=FCgung gestellt. Aber ic=
h
> wei=DF noch nicht ganz wie, und wie diese Map aussieht :).
Siehe os-faq (die URL weiss ich nicht mehr, irgendwas mit mega-tokyo.com)
> > Dann wuerde ich vorschlagen, oslod.s zu aendern. Ich wuerde ab
> > einem bestimmten Offset eine 'blocklist' einbauen, die aus
> > bis zu 12 4 Byte Eintraegen besteht und den Speicherort des
> > Kernels auf einer FAT12 Diskette beinhaltet. Der Vorteil:
> > Der Kern kann sich zerstreut auf der Diskette befinden und trotzdem
> > geladen werden. Ich habe so einen loader schon einmal geschrieben
> > und auch ein Programm, das die Blocklist fuellt, indem es heraus-
> > findet, wo auf der Diskette der Kernel ist. Aehnlich kann
> > so eine blocklist in bootsec.s eingebaut werden, um oslod zu laden.
> > Das wuerde theoretisch mit jedem Dateisystem gehen und man muesste
> > den Kernel usw. nicht an feste Stellen auf Diskette/HD schreiben.
> > Er muss halt innerhalb der ersten 1024 Zylinder sein.
>
> Keine schlechte Idee. W=FCrde das auch hei=DFen, dass der Kernel dann als
> normale Datei auf die Diskette gespeichert werden k=F6nnte?
Ja. Man muss bloss ein 'installboot' Programm aufrufen, das die Lage
des Kernels herausfindet und in die blocklist eintraegt. Das wird
u.a in OpenBSD so gemacht, da hab ich das auch her.
> > Das kann ich schreiben, wenn ich den Terminaltreiber so einigermassen
> > hinbekommen oder aber noch davor.
>
> Das w=E4re super! Das jetzige Bootprogramm ist ja nicht die optimale
> L=F6sung - sondern eher die "dateisystemlose" Testvariante (okay,
> M=FCllvariante :)).
Ich mach das jetzt schon. Der Kernel wollte nicht mehr booten
und ich habe davon die Schnauze voll. Ich weiss nicht, ob ein
Fehler im Code vorliegt oder ob der Kernel an der falschen Stelle
gespeichert wird. Ich denke ich schreibe bootsec.s und oslod.s
komplett neu.
> cu
>
> FG
cheers,
Stefan
---
This is not SPAM! You can unsubscribe sending an e-mail to
hydrixos-request@xxxxxxxxxxxxx with subject "unsubscribe". If
you've got questions contact webmaster@xxxxxxxxxxxx
hydrixOS kernel: http://www.hydrixos.de/downl.htm
Other related posts: