some new documentation

4 files changed, 96 insertions, 0 deletions

diff --git a/documentation/UEFI general/ESP b/documentation/UEFI general/ESP
new file mode 100644
index 0000000..4780a0d
--- /dev/null
+++ b/documentation/UEFI general/ESP
@@ -0,0 +1,17 @@
+EFI System Partition (Wikipedia)
+=======================
+
+When a computer is booted, UEFI Firmware loads files stored on the ESP to start installed operating systems and various utilities.
+
+ESP contains: boot loaders or kernel images, device driver files, system utility programs that are intended to be run before an operating system is booted, and data files such as error logs.
+
+ The globally unique identifier (GUID) for the EFI system partition in the GUID Partition Table (GPT) scheme is C12A7328-F81F-11D2-BA4B-00A0C93EC93B, while its ID in the master boot record (MBR) partition-table scheme is 0xEF. Both GPT- and MBR-partitioned disks can contain an EFI system partition, as UEFI firmware is required to support both partitioning schemes.
+
+UEFI firmware does not execute the code in the MBR, except when booting in legacy BIOS mode through the Compatibility Support Module (CSM)
+
+a boot loader needs to be stored according to the standard ESP file hierarchy
+The EFI system partition is formatted with a file system whose specification is based on the FAT file system and maintained as part of the UEFI specification; therefore, the file system specification is independent from the original FAT specification. 
+
+LINUX
+--------
+The mount point for the EFI system partition is usually /boot/efi, where its content is accessible after Linux is booted
diff --git a/documentation/UEFI_from_spec/mafiadoc.com_white-paper-a-tour-beyond-bios-memory-map-and-_59e074311723dd7ed9476f2c.pdf b/documentation/UEFI_from_spec/mafiadoc.com_white-paper-a-tour-beyond-bios-memory-map-and-_59e074311723dd7ed9476f2c.pdf
deleted file mode 100644
index 78741fe..0000000
--- a/documentation/UEFI_from_spec/mafiadoc.com_white-paper-a-tour-beyond-bios-memory-map-and-_59e074311723dd7ed9476f2c.pdf
+++ /dev/null
diff --git a/documentation/general/ACPI b/documentation/general/ACPI
new file mode 100644
index 0000000..47c8513
--- /dev/null
+++ b/documentation/general/ACPI
@@ -0,0 +1,5 @@
+Advanced Configuration and Power Interface (https://wiki.osdev.org/ACPI)
+===========================================================================
+
+needed for APIC
+There are 2 main parts to ACPI. The first part is the tables used by the OS for configuration during boot (these include things like how many CPUs, APIC details, NUMA memory ranges, etc).
diff --git a/documentation/general/RSDP b/documentation/general/RSDP
new file mode 100644
index 0000000..cd5ac96
--- /dev/null
+++ b/documentation/general/RSDP
@@ -0,0 +1,74 @@
+Root System Description Pointer (https://wiki.osdev.org/RSDP)
+
+In ACPI Version 1.0 it has this structure:
+
+struct RSDPDescriptor {
+ char Signature[8];
+ uint8_t Checksum;
+ char OEMID[6];
+ uint8_t Revision;
+ uint32_t RsdtAddress;
+} __attribute__ ((packed));
+
+since Version 2.0 it has been extended, and the following new fields have been added:
+
+struct RSDPDescriptor20 {
+ RSDPDescriptor firstPart;
+ 
+ uint32_t Length;
+ uint64_t XsdtAddress;
+ uint8_t ExtendedChecksum;
+ uint8_t reserved[3];
+} __attribute__ ((packed));
+
+ Detecting the RSDP
+=========================
+
+The RSDP is either located within the first 1 KB of the EBDA (Extended BIOS Data Area) (a 2 byte real mode segment pointer to it is located at 0x40E), or in the memory region from 0x000E0000 to 0x000FFFFF (the main BIOS area below 1 MB). To find the table, the Operating System has to find the "RSD PTR " string (notice the last space character) in one of the two areas. This signature is always on a 16 byte boundary.
+
+If you're using UEFI, you can find it somewhere in EFI_SYSTEM_TABLE. Thus, there's no need for searching the RAM.
+
+Note: The standard methods to find the RSDP may not work on UEFI systems. Because of that, finding it inside EFI_SYSTEM_TABLE is the correct and reliable method (see ACPI 6.2 section 5.2.5.2 'Finding the RSDP on UEFI Enabled Systems'). 
+
+ Validating the RSDP
+
+Once you have found the RSDP Table you have to see what version of ACPI the BIOS is using, then you must check that the checksum is valid.
+Detecting ACPI Version
+
+The ACPI Version can be detected using the Revision field in the RSDP. If this field contains 0, then ACPI Version 1.0 is used. For subsequent versions (ACPI version 2.0 to 6.1), the value 2 is used [1]. The exact version of ACPI can be deduced via the FADT table.
+Checksum validation
+
+Before the RSDP is relied upon you should check that the checksum is valid. For ACPI 1.0 (the first structure) you add up every byte in the structure and make sure the lowest byte of the result is equal to zero. For ACPI 2.0 and later you'd do exactly the same thing for the original (ACPI 1.0) part of the second structure, and then do it again for the fields that are part of the ACPI 2.0 extension.
+Explaining the fields
+Always present
+Signature
+
+This 8-byte string (not null terminated!) must contain "RSD PTR ". It stands on a 16-byte boundary.
+Checksum
+
+The value to add to all the other bytes (of the Version 1.0 table) to calculate the Checksum of the table. If this value added to all the others and casted to byte isn't equal to 0, the table must be ignored.
+OEMID
+
+The specification says: "An OEM-supplied string that identifies the OEM".
+Revision
+
+The revision of the ACPI. Larger revision numbers are backward compatible to lower revision numbers. See Detecting ACPI Version for further information.
+Rsdt Address
+
+32-bit physical (I repeat: physical) address of the RSDT table.
+Since Version 2.0
+Length
+
+The size of the entire table since offset 0 to the end.
+Xsdt Address
+
+64-bit physical address of the XSDT table. If you detect ACPI Version 2.0 you should use this table instead of RSDT even on x86, casting the address to uint32_t.
+Extended Checksum
+
+This field is used to calculate the checksum of the entire table, including both checksum fields.
+Reserved
+
+3 bytes to be ignored in reading and that must not be written.
+What's next?
+
+Well, you should now parse the RSDT (or XSDT).