Hi :) (sorry that it took me so long, i thought i was automatically
subscribed)
PhysicalMapSize is the size a map needs for itself in memory to contain
the information.
In the setup_ function, PhysicalMapSize gets the value
PhysicalMapSize = PHYSICAL_FPM >> 5;
PHYSICAL_FPM means "Physical Frames per Map" and indicates, how many
frames are managed by one single map. Because we "manage" every frame
with a single bit we need PHYSICAL_FPM bits to store the information.
But because a size value in bits is not very useful, i transform it into
a 4byte size value by dividing through 32 (this is what ">> 5" does)
PhysicalSuperMapSize is the same but for the supermap, which manages the
maps.
Every map is "displayed" as a single bit, so we need PhysicalMapsCount
bits, which i divide through 32 again. This time i had to add +31 before
dividing to round up. (Otherwise, if you had 33 maps, you would only use
4 bytes, which is not enough, you need with this implementation 8 bytes)
The writes are not very important at the moment. I even think about
deleting them, because the purpose of these writes (storing the physical
management information at a secure place) can be achieved by the linker
(by not putting the variables into startup_data)
But actually the information is written directly behind the end of the
kernel (as it has been loaded by grub)
Its important to notice again, that here are only physical addresses.
So the addresses from .linked and .linked_data are virtual addresses and
not (at this point) usable.
These two sections are compiled/linked as if the were loaded to the
higher memory 0xFFC00000 but in fact they are right behind the other
code (concerning their physical address)
|
