__pv_stub (x, t, "hinzufügen", __PV_BITS_31_24) ... warum __PV_BITS_31_24 ist 0x8100_0000?

Question

Die Funktion

__virt_to_phys(unsigned long x) 

die

__pv_stub(x, t, "add", __PV_BITS_31_24); 

__pv_stub Makro

expandiert nach

läuft darauf hinaus

add t, x, 0x8100_0000 

Apart einen Zeiger auf diese Anweisung in .pv_table Abschnitt aus eingeführt wird, die dazu verwendet werden können, um diesen Befehl während des Startvorgangs zu patchen. Meine Frage bezieht sich auf die Konstante __PV_BITS_31_24. Gibt es einen Grund, den Wert 0x8100_0000 dafür zu verwenden?

Nach meinem Verständnis macht dieser Wert 12 Bit sofortiges Codierungsfeld von add Anweisung als 481 hex. Zur Laufzeit während der Boot-Funktion __fix_pv_table ändert es auf 4C0 hex (angenommen, dass die erste mem bank bei 0x8000_0000 gestartet wird). Ist der Wert 0x8100_0000 so üblich, dass Leute sich entschieden haben, ihn während der Kompilierung als Standardwert zu verwenden, und wenn dieser dann anders ist, wird er während des Bootens behoben? Oder gibt es einen anderen Grund dafür, den ich nicht verstehen kann?

Answer 1

Kurz gesagt, da die Bits 31 und 24 gesetzt sind, ergibt sich somit die entsprechende Befehlskodierung zum Patchen des MSB des Offsets.

Denken Sie daran, dass die unmittelbaren Konstanten in ARM-Anweisungen aus einem 8-Bit-Wert gebildet werden, der an einer von 16 Positionen im 32-Bit-Wort gedreht wird. Das Zusammensetzen des Anfangswerts von 0x81000000 garantiert, dass die geeignete Drehung für die Bits 31:24 codiert ist, so dass dann jeder andere 8-Bit-Wert über das untere Byte des Befehls geschrieben werden kann, ohne sich um den Rest kümmern zu müssen.

Es könnte auch 0xff000000 (oder irgendeinen anderen Wert, der mindestens Bit 24 und 30 oder 31 gesetzt hatte) sein, aber anscheinend that particular value was was a relatively arbitrary decision by the maintainer.