diff options
Diffstat (limited to 'documentation')
48 files changed, 0 insertions, 2011 deletions
diff --git a/documentation/Data Models and Sizes b/documentation/Data Models and Sizes deleted file mode 100644 index 305cb40..0000000 --- a/documentation/Data Models and Sizes +++ /dev/null @@ -1,18 +0,0 @@ -(https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcpx01/datatypesize64.htm) - - ILP32 (32-bit environment) LP64 (64-bit environment) - size in bytes size in bytes - =========================== ================================ -char 1 1 -short 2 2 -int 4 4 -long 4 8 -long long 8 8 -float 4 4 -double 8 8 -long double 16 16 -pointer 4 8 -wchar_t 2 4 Other UNIX platforms usually have wchar_t 4 bytes for both - 32-bit and 64-bit mode -size_t 4 8 unsigned type -ptrdiff_t 4 8 signed type diff --git a/documentation/UEFI general/EDK2.odt b/documentation/UEFI general/EDK2.odt Binary files differdeleted file mode 100644 index 28484c6..0000000 --- a/documentation/UEFI general/EDK2.odt +++ /dev/null diff --git a/documentation/UEFI general/ESP b/documentation/UEFI general/ESP deleted file mode 100644 index 4780a0d..0000000 --- a/documentation/UEFI general/ESP +++ /dev/null @@ -1,17 +0,0 @@ -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 general/UEFI Overview b/documentation/UEFI general/UEFI Overview deleted file mode 100644 index f173bfb..0000000 --- a/documentation/UEFI general/UEFI Overview +++ /dev/null @@ -1,20 +0,0 @@ -Reference: https://wiki.osdev.org/UEFI - - -UEFI VS LEGACY BIOS - -Both motherboards come with BIOS ROMs, which contains firmware that performs the initial power-on configuration of the -system before loading some third-party code into memory and jumping to it. -Differences: - - where they find that code - - how to prepare system before jumping to it - - what convenience functions they provide for the code to call while running - -PLATFORM INITIALIZATION - -BIOS: performs all the usual platform initialization (memory controller configuration, PCI bus configuration and BAR mapping, - graphics card initialization, etc...) but then drops into a backwards-compatible real mode environment. - Bootloader must enable A20 gate, configure a GDT and an IDT, switch to protected mode, and for x86-64 CPUs, - configure paging and switch to long mode. -UEFI firmware: performs those same steps but also prepares a protected mode environment with flat segmentation and for x86-64 CPUs, - a long mode environment with identity-mapped paging. The A20 gate is enabled as well. diff --git a/documentation/UEFI general/UEFI Programming with FASM b/documentation/UEFI general/UEFI Programming with FASM deleted file mode 100644 index 472b757..0000000 --- a/documentation/UEFI general/UEFI Programming with FASM +++ /dev/null @@ -1,146 +0,0 @@ -UEFI Programming with FASM - -As an extra, I will also demonstrate same Hello World example in assembly (using FASM, that currently has experimental UEFI support since version 1.67.28): - -First we need some to create simple UEFI headers (efi.inc): - -;for 32/64 portability and automatic natural align in structure definitions - -struc int8 { - . db ? -} -struc int16 { - align 2 - . dw ? -} -struc int32 { - align 4 - . dd ? -} -struc int64 { - align 8 - . dq ? -} -struc intn { - align 8 - . dq ? -} -struc dptr { - align 8 - . dq ? -} - -;symbols - -EFIERR = 0x8000000000000000 -EFI_SUCCESS = 0 -EFI_LOAD_ERROR = EFIERR or 1 -EFI_INVALID_PARAMETER = EFIERR or 2 -EFI_UNSUPPORTED = EFIERR or 3 -EFI_BAD_BUFFER_SIZE = EFIERR or 4 -EFI_BUFFER_TOO_SMALL = EFIERR or 5 -EFI_NOT_READY = EFIERR or 6 -EFI_DEVICE_ERROR = EFIERR or 7 -EFI_WRITE_PROTECTED = EFIERR or 8 -EFI_OUT_OF_RESOURCES = EFIERR or 9 -EFI_VOLUME_CORRUPTED = EFIERR or 10 -EFI_VOLUME_FULL = EFIERR or 11 -EFI_NO_MEDIA = EFIERR or 12 -EFI_MEDIA_CHANGED = EFIERR or 13 -EFI_NOT_FOUND = EFIERR or 14 -EFI_ACCESS_DENIED = EFIERR or 15 -EFI_NO_RESPONSE = EFIERR or 16 -EFI_NO_MAPPING = EFIERR or 17 -EFI_TIMEOUT = EFIERR or 18 -EFI_NOT_STARTED = EFIERR or 19 -EFI_ALREADY_STARTED = EFIERR or 20 -EFI_ABORTED = EFIERR or 21 -EFI_ICMP_ERROR = EFIERR or 22 -EFI_TFTP_ERROR = EFIERR or 23 -EFI_PROTOCOL_ERROR = EFIERR or 24 - -;helper macro for definition of relative structure member offsets - -macro struct name -{ - virtual at 0 - name name - end virtual -} - -;structures - -struc EFI_TABLE_HEADER { - .Signature int64 - .Revision int32 - .HeaderSize int32 - .CRC32 int32 - .Reserved int32 -} -struct EFI_TABLE_HEADER - -struc EFI_SYSTEM_TABLE { - .Hdr EFI_TABLE_HEADER - .FirmwareVendor dptr - .FirmwareRevision int32 - .ConsoleInHandle dptr - .ConIn dptr - .ConsoleOutHandle dptr - .ConOut dptr - .StandardErrorHandle dptr - .StdErr dptr - .RuntimeServices dptr - .BootServices dptr - .NumberOfTableEntries intn - .ConfigurationTable dptr -} -struct EFI_SYSTEM_TABLE - -struc SIMPLE_TEXT_OUTPUT_INTERFACE { - .Reset dptr - .OutputString dptr - .TestString dptr - .QueryMode dptr - .SetMode dptr - .SetAttribute dptr - .ClearScreen dptr - .SetCursorPosition dptr - .EnableCursor dptr - .Mode dptr -} -struct SIMPLE_TEXT_OUTPUT_INTERFACE - -And here is the assembly code itself (hello.asm): - -format pe64 dll efi -entry main - -section '.text' code executable readable - -include 'efi.inc' - -main: - sub rsp, 4*8 ; reserve space for 4 arguments - - mov [Handle], rcx ; ImageHandle - mov [SystemTable], rdx ; pointer to SystemTable - - lea rdx, [_hello] - mov rcx, [SystemTable] - mov rcx, [rcx + EFI_SYSTEM_TABLE.ConOut] - call [rcx + SIMPLE_TEXT_OUTPUT_INTERFACE.OutputString] - - add rsp, 4*8 - mov eax, EFI_SUCCESS - retn - - -section '.data' data readable writeable - -Handle dq ? -SystemTable dq ? -_hello du 'Hello World',13,10,'(From EFI app written in FASM)',13,10,0 - -section '.reloc' fixups data discardable - -Compile and link it with fasm.exe hello_world.asm. diff --git a/documentation/UEFI general/UEFI general b/documentation/UEFI general/UEFI general deleted file mode 100644 index 093dfdb..0000000 --- a/documentation/UEFI general/UEFI general +++ /dev/null @@ -1,59 +0,0 @@ -Wikipedia? - -Schnittstellen-Definition für Computer Firmware. Nachfolger des BIOS. Zentrale Schnittstelle zwischen der Plattform-Firmware und dem Betriebssystem. -Ab EFI-Version 2.0 gitb wa offiziell eine 64-bit Implementierung auf x86. -CSM: Compability Support Modul-BIOS-Kompabilitätsschicht, mit der UEFI voll zum BIOS rückwärtskompatibel bleibt. Seit ca. 2010 löst UEFI schrittweise das BIOS ab, welches daher auch als Legacy bezeichnet wird. - -wesentliche Merkmale: GUID-Partitionstabelle, zum vom BIOS genutzten Master-Boot Record teil-kompatibel, Framebuffer-basierte Grafikunterstützung, Netzwerkfunktionalität, seit v2.3.1 Secure Boot: beschränkt das Booten auf corher signierte Bootloader und hindert Schadsoftware + andere unerwünschte Programme am starten. - -+-----------+ -| OS | -+-----------+ - ^ - | Vorteil gegenüber BIOS: -+-----------+ - Unabhängig vom Typ der CPU. Booten von verschiedenen Arten von Ssystemen, ua. ARM x64 -| EFI | - GPT (GUID-Partitionstabelle) lässt > 2TB Festplatten verwenden -+-----------+ - Alle Dateien und Programme in Form von herkömmlichen Dateien in eigener Partition im VFAT Format. - | Kein unveränderlicher Speicherbereich wie MBR im BIOS. - v - Netzwerkfähig, erlaubt direkt das Booten über Netzwerk -+-----------+ - Generell modulares, erweiterbares Desgin in Strukturen -| Firmware | zb Aufrufen von UEFI-Shell im Rahmen des Bootvorgangs -+-----------+ - Das permanente Speichern best. Daten erfolgt im NVRAM. - - Skim, um nicht signierte GRUB im Secure Boot laden zu können. In praktisch allen Linux Distributionen verwendet. -+-----------+ - CSM/Compability Support Module zur Wahrung der Kompatibilität zu vorhandenen OS, die UEFI nicht unterstützen -| HW | und ein BIOS voraussetzen -+-----------+ - Treiber können als Mpdul in das EFI integriert werden, so dass sie nicht mehr vom OS geladen werden-> - ermöglicht systemunabhängige Treiber - - Sandbox Modus: Netzwerk- und Speicherverwaltung laufen auf Firmware anstatt auf OS - - Auswahlmöglichkeit für installierte OS - -wide range of functionality even before OS startsloading, modular (you can add custom code or drivers), runs on various platforms, applications and drivers for it can be written in C not in assembly (- more portable). Besides native CPU code, EDI supports custom byte-code, so drivers can be compiled st. they are portable between CPU architectures without need for compilation. -Unified EFI because Intel, AMD, AMI, Apple, Dell, HP, IBM, Microsoft, Phoenix,... joined to create common standard - -Since UEFI standard defines exact binary interface, standalone UEFI drivers and applications are portable between various implementations - all versions backward compatible. UEFI standard also supports old-sytle boot via 16-bit real mode code, so it can be used with OSes that don't have UEFI support -> but in their case UEFI runtime drivers do not work. - -EFI Development ----------------- -EFI Development Kit (EDK) and EFI Toolkit --> contains TianoCore (public part of reference UEFI implementation by Intel), along with many examples and binaries of EFI Shell - -EFI Toolkit ------------- -extra applications: FTP Client, Python port, text editor,... - -Platform Initialization Specification ---------------------------------------- -Implementation of UEFI initialization stages (before dirvers are loaded and applications can be executed). Interface of routines used to implement UEFI = description of Tiano UEFI Implementation. More lowlevel control than UEFI - -64-bit C-compiler - -EFI Shell ------------ -Enter commands to browse disk, run applications, configure system -For 64-bit UEFI implementation, the path to file that is booted is \EFI\BOOT\BOOTx64.EFI -UEFI bootloader searches all filesystems it can access for this file. If not found + booting continues with legacy BIOS. UEFI boot loader can reach MBR or GPT partition tables, can read only FAT32 partitions. --> copy binary of EFI shell to partition (it's in EDK: -{EDK}\Other\Maintained\Application\UefiShell\bin\x64\Fhell_full.efi - - - diff --git a/documentation/UEFI general/get memory map b/documentation/UEFI general/get memory map deleted file mode 100644 index 14c246f..0000000 --- a/documentation/UEFI general/get memory map +++ /dev/null @@ -1,32 +0,0 @@ -http://hypervsir.blogspot.com/2014/09/approach-to-retrieving-bios-memory-map.html - - - -BIOS routine: INT 0x15, AX=0xE820 -_______________ -GetMemoryMap() is one of the boot services. -EFI System Table -> Boot Services Table pointer -> function pointer (physical address) of GetMemoryMap. -Preboot Software must be in protected mode and be consistent with EFI environment (e.g. both 32bit or 64bit environment, -if not, processor mode switch must be preceded before calling); -the Page must be disabled, otherwise SetVirtualAddressMap() must be called for memory "fix-up" e.g. converting physical memory to virtual memory; and there are many other calling conventions e.g. interrupt status, eflags, stack space and alignment, for details, please read the UEFI specification. - -After calling this function, the OS bootloader can get the system memory map information for each region with the structure EFI_MEMORY_DESCRIPTOR. In this structure, there are some fields like memory type, memory start address, number of pages (the length), and memory attributes (cacheability attributes, e.g. WT/WB/UC/WC, and protection attributes, e.g. write/execution/read protections). - - - - - - - - - - - - - - - - - - - diff --git a/documentation/UEFI general/qemu_kvm_for_debug b/documentation/UEFI general/qemu_kvm_for_debug deleted file mode 100644 index e166637..0000000 --- a/documentation/UEFI general/qemu_kvm_for_debug +++ /dev/null @@ -1,26 +0,0 @@ -This is how I generally use qemu for debugging: - -sudo qemu-system-x86_64 -L . -serial pty -serial pty -monitor stdio \ - -drive file=/dev/local/virt-ovmf,if=ide,id=drive-ide0-0-0 \ - -nographic -S - -This command: - - Creates two serial ports: one for the OVMF debug output, and one for a usable serial console - - Uses a LVM block device, /dev/local/virt-ovmf as the local storage - Disables graphic output - Starts the qemu monitor prompt on stdio - Tells qemu not to start the machine right away. - -I then: - - start two screen sessions on the PTYs that qemu prints - - start it by typing c at the monitor prompt - -During boot, I get the OVMF debug output on the first screen session, and once the machine is booted, I get a login prompt on the second screen session. For this to work, you'll need to configure init to create a getty session on the serial ports. To do this from within your virtual machine: - -cd /etc/init/ -sed s/tty1/ttyS0 < tty1.conf | sudo dd of=ttyS0.conf -sed s/tty1/ttyS1 < tty1.conf | sudo dd of=ttyS1.conf diff --git a/documentation/UEFI_from_spec/Access SMBIOS b/documentation/UEFI_from_spec/Access SMBIOS deleted file mode 100644 index cd20f5f..0000000 --- a/documentation/UEFI_from_spec/Access SMBIOS +++ /dev/null @@ -1,26 +0,0 @@ -(several forums) - -INSIDE UEFI: - EFI_CONFIGURATION_TABLE contains entries pointing to the SMBIOS2 and/or SMBIOS3 tables - -FROM UEFI Shell: - SmbiosView command - -FROM LINUX: - SMBIOS decoder: dmidecode(8) - -WINDOWS: - WMI - -Generating SMBIOS data: -Table&structure creation is normally up to the system firmware/BIOS. -UEFI Platform Initialization (PI) spec includes SMBIOS protocol (EFI_SMBIOS_PROTOCOL) that allows components -to submit SMBIOS structures for incluseion, enables producer to create SMBIOS table for a platform. - -Some hardware information is available through ACPI and DMI. The ACPI tables are technically provided through UEFI, -by virtue of passing one pointer (and supposed by leaving the relevant memory reserved, in the memory map -which the IS is passed by UEFI. - -Platform virtualization software can also generate SMBIOS tables for use inside VMs, for instance qemu. - ---> Desktop Management BIOS Specification 2/3 diff --git a/documentation/UEFI_from_spec/AllocatePool b/documentation/UEFI_from_spec/AllocatePool deleted file mode 100644 index 090a434..0000000 --- a/documentation/UEFI_from_spec/AllocatePool +++ /dev/null @@ -1,27 +0,0 @@ -Allocates pool memory - -typedef -EFI_STATUS -AllocatePool ( - IN EFI_MEMORY_TYPE PoolType, - IN UINTN Size, - OUT VOID **Buffer - ); - - -PoolType Type of pool to allocate. PoolType values in range 0x80000000...0xFFFFFFFF reserved for use by - UEFI OS loaders that are provided by operating system vendors. Only illegal memory type values - are those in the range EfiMaxMemoryType..0x7FFFFFFFF -Size Number of bytes to allocate from pool. -Buffer Pointer to a pointer to the allocated buffer if the call succeeds. undefined otherwise. - -Description -The AllocatePool() function allocates a memory region of Size bytes from memory of type -PoolType and returns the address of the allocated memory in the location referenced by Buffer. -This function allocates pages from EfiConventionalMemory as needed to grow the requested -pool type. All allocations are eight-byte aligned. -The allocated pool memory is returned to the available pool with the FreePool() function. -Status Codes Returned -EFI_SUCCESS The requested number of bytes was allocated. -EFI_OUT_OF_RESOURCES The pool requested could not be allocated. -EFI_INVALID_PARAMETER PoolType was invalid. diff --git a/documentation/UEFI_from_spec/EFI_BOOT_SERVICES b/documentation/UEFI_from_spec/EFI_BOOT_SERVICES deleted file mode 100644 index 44fe43f..0000000 --- a/documentation/UEFI_from_spec/EFI_BOOT_SERVICES +++ /dev/null @@ -1,99 +0,0 @@ -EFI Boot Services Table - contains a table header and pointers to all of the boot services. Except for the table header, all elements - in the EFI Boot Services Tables are prototypes of function pointers to functions as defined in Section 7. - The function pointers in this table are not valid after the operating system has taken control of the platform with a call to - EFI_BOOT_SERVICES.ExitBootServices(). - - - -typedef struct { - EFI_TABLE_HEADER Hdr; - - // Task Priority Services - EFI_RAISE_TPL RaiseTPL Raises the task priority level. - EFI_RESTORE_TPL RestoreTPL RestoreTPL Restores/lowers the task priority level - - // Memory Services - EFI_ALLOCATE_PAGES AllocatePages Allocates pages of a particular type - EFI_FREE_PAGES FreePages Frees allocated pages - EFI_GET_MEMORY_MAP GetMemoryMap Returns the current boot services memory map and memory map key - EFI_ALLOCATE_POOL AllocatePool Allocates a pool of a particular type - EFI_FREE_POOL FreePool Frees allocated pool - - // Event & Timer Services - EFI_CREATE_EVENT CreateEvent Creates a general-purpose event structure - EFI_SET_TIMER SetTimer Sets an event to be signaled at a particular time - EFI_WAIT_FOR_EVENT WaitForEvent Stops execution until an event is signaled - EFI_SIGNAL_EVENT SignalEvent Signals an event - EFI_CLOSE_EVENT CloseEvent Closes and frees an event structure - EFI_CHECK_EVENT CheckEvent Checks whether an event is in the signaled state - - // Protocol Handler Services - EFI_INSTALL_PROTOCOL_INTERFACE InstallProtocolInterface Installs a protocol interface on a device handle - EFI_REINSTALL_PROTOCOL_INTERFACE ReinstallProtocolInterface Reinstalls a protocol interface on a device handle - EFI_UNINSTALL_PROTOCOL_INTERFACE UninstallProtocolInterface Removes a protocol interface from a device handle - EFI_HANDLE_PROTOCOL HandleProtocol Queries a handle to determine if it supports - a specified protocol - VOID* Reserved Reserved. Must be NULLs - EFI_REGISTER_PROTOCOL_NOTIFY RegisterProtocolNotify Registers an event that is to be signaled whenever an interface is - installed for a specified protocol - EFI_LOCATE_HANDLE LocateHandle Returns an array of handles that support a specified protocol - EFI_LOCATE_DEVICE_PATH LocateDevicePath Locates all devices on a device path that support a specified - protocol and returns the handle to the device that is closest to - the path - EFI_INSTALL_CONFIGURATION_TABLE InstallConfigurationTable Adds, updates, or removes a configuration table from - the EFI System Table - - //Image Services - EFI_IMAGE_LOAD LoadImage Loads an EFI image into memory - EFI_IMAGE_START StartImage Transfers control to a loaded image’s entry point - EFI_EXIT Exit Exits the image’s entry point - EFI_IMAGE_UNLOAD UnloadImage Unloads an image - EFI_EXIT_BOOT_SERVICES ExitBootServices Terminates boot service - - // Miscellaneous Services - EFI_GET_NEXT_MONOTONIC_COUNT GetNextMonotonicCount Returns a monotonically increasing count for the platform - EFI_STALL Stall Stalls the processor - EFI_SET_WATCHDOG_TIMER SetWatchdogTimer Resets and sets a watchdog timer used during boot services time - - // DriverSupport Services - EFI_CONNECT_CONTROLLER ConnectController Uses a set of precedence rules to find the best set of drivers - to manage a controller - EFI_DISCONNET_CONTROLLER DisconnectController Informs a set of drivers to stop managing a controller - - // Open and Close Protocol Services - EFI_OPEN_PROTOCOL OpenProtocol Adds elements to the list of agents consuming a protocol interface - EFI_CLOSE_PROTOCOL CloseProtocol Removes elements from the list of agents consuming a protocol interface - EFI_OPEN_PROTOCOL_INFORMATION OpenProtocolInformation Retrieve the list of agents that are currently consuming a protocol interface - - // Library Services - EFI_PROTOCOLS_PER_HANDLE ProtocolsPerHandle Retrieves the list of protocols installed on a handle. - The return buffer is automatically allocated - EFI_LOCATE_HANDLE_BUFFER LocateHandleBuffer Retrieves the list of handles from the handle database that - meet the search criteria. The return buffer is automatically - allocated - EFI_LOCATE_PROTOCOL LocateProtocol Finds the first handle in the handle database the supports - the requested protocol - EFI_INSTALL_MULTIPLE_PROTOCOL_INTERFACES InstallMultipleProtocolInterfaces Installs one or more protocol interfaces onto a handle - EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES UninstallMultipleProtocolInterfaces Uninstalls one or more protocol interfaces from a handle - - // 32-bit CRC Services - - EFI_CALCULATE_CRC32 CalculateCrc32 Computes and returns a 32-bit CRC for a data buffer - - // Miscellaneous Services - EFI_COPY_MEM CopyMem Copies the contents of one buffer to another buffer - EFI_SET_MEM SetMem Fills a buffer with a specified value - EFI_CREATE_EVENT_EX CreateEventEx Creates an event structure as part of an event group - } EFI_BOOT_SERVICES - - - - - -References -[1] UEFI Specification 2.8 Errata A - 4.4 Boot Services - pp 93 - - -References -[1] UEFI Specification 2.8 Errata A, February 2020 - 4.4 EFI Boot Services Table - pp 93 diff --git a/documentation/UEFI_from_spec/EFI_CONFIGURATION_TABLE b/documentation/UEFI_from_spec/EFI_CONFIGURATION_TABLE deleted file mode 100644 index 949febf..0000000 --- a/documentation/UEFI_from_spec/EFI_CONFIGURATION_TABLE +++ /dev/null @@ -1,70 +0,0 @@ -EFI_MM_SYSTEM_TABLE - -The Management Mode System TAble (MMST) is a table that contains a collection of common services for managing MMRAM allocation and providinh basic I/O services. These services are intended for both preboot and runtime usage. - -UINTNNumberOfTableEntries; -EFI_CONFIGURATION_TABLE*SmmConfigurationTable; - -MmConfigurationTable -A pointer to the UEFI Configuration Tables. The number of entries in the table is -NumberOfTableEntries. Type EFI_CONFIGURATION_TABLE is defined in -the UEFI Specification, section 4.6. - - -______________________________________________________ - -Contains a set of GUID/pointer pairs comprised of the ConfigurationTable field in the EFI System Table - -typedef struct { - EFI_GUID VendorGuid - VOID *VendorTable - } EFI_CONFIGURATION_TABLE - - -This list is not exhaustive and does not show GUIDS for all possible UEFI Configuration tables - -#define EFI_ACPI_20_TABLE_GUID \ -{0x8868e871,0xe4f1,0x11d3,\ -{0xbc,0x22,0x00,0x80,0xc7,0x3c,0x88,0x81}} -#define ACPI_TABLE_GUID \ -{0xeb9d2d30,0x2d88,0x11d3,\ -{0x9a,0x16,0x00,0x90,0x27,0x3f,0xc1,0x4d}} -#define SAL_SYSTEM_TABLE_GUID \ -{0xeb9d2d32,0x2d88,0x11d3,\ -{0x9a,0x16,0x00,0x90,0x27,0x3f,0xc1,0x4d}} -#define SMBIOS_TABLE_GUID \ -{0xeb9d2d31,0x2d88,0x11d3,\ -{0x9a,0x16,0x00,0x90,0x27,0x3f,0xc1,0x4d}} -#define SMBIOS3_TABLE_GUID \ -{0xf2fd1544, 0x9794, 0x4a2c,\ -{0x99,0x2e,0xe5,0xbb,0xcf,0x20,0xe3,0x94}) -#define MPS_TABLE_GUID \ -{0xeb9d2d2f,0x2d88,0x11d3,\ -{0x9a,0x16,0x00,0x90,0x27,0x3f,0xc1,0x4d}} -// -// ACPI 2.0 or newer tables should use EFI_ACPI_TABLE_GUID -// -#define EFI_ACPI_TABLE_GUID \ -{0x8868e871,0xe4f1,0x11d3,\ -{0xbc,0x22,0x00,0x80,0xc7,0x3c,0x88,0x81}} -#define EFI_ACPI_20_TABLE_GUID EFI_ACPI_TABLE_GUID -#define ACPI_TABLE_GUID \ -{0xeb9d2d30,0x2d88,0x11d3,\ -{0x9a,0x16,0x00,0x90,0x27,0x3f,0xc1,0x4d}} -#define ACPI_10_TABLE_GUID ACPI_TABLE_GUID - - - - - - - - - - - - - - -References -[1] UEFI Specification 2.8 Errata A - 4.6 EFI Configuration Table & Properties Table - pp 99 diff --git a/documentation/UEFI_from_spec/EFI_GUID b/documentation/UEFI_from_spec/EFI_GUID deleted file mode 100644 index 521b083..0000000 --- a/documentation/UEFI_from_spec/EFI_GUID +++ /dev/null @@ -1,6 +0,0 @@ -typedef struct { -UINT32 Data1 ; -UINT16 Data2 ; -UINT16 Data3 ; -UINT8 Data4[8]; -} EFI_GUID; diff --git a/documentation/UEFI_from_spec/EFI_IMAGE_ENTRY_POINT b/documentation/UEFI_from_spec/EFI_IMAGE_ENTRY_POINT deleted file mode 100644 index 0716335..0000000 --- a/documentation/UEFI_from_spec/EFI_IMAGE_ENTRY_POINT +++ /dev/null @@ -1,97 +0,0 @@ -System Table contains pointers to the active concole devices, a pointer to the Boot Services Table, -a pointer to the Runtime Services Table, and a pointer to the list of system configuration tables such as -ACPI, SMBIOS and the SAL System Table. - -Entry point is the same for UEFI applications and UEDI drivers. - - -PROTOTYPE - typedef - EFI_STATUS - (EFIAPI *EFI_IMAGE_ENTRY_POINT) ( - IN EFI_HANDLE ImageHandle, - IN EFI_SYSTEM_TABLE *SystemTable - ); - -PARAMETERS - ImageHandle The firmware allocated handle for the UEFI image - SystemTable A pointer to the EFI System Table. Contains standard output and input handles, - plus pointers to the EFI_BOOT_SERVICES and EFI RUNTIME_SERVICES tables. - The service tables contain the entry points in the firmware for accessing the core EFI system - functionality. The handles in the system table are used to obtain basci access to the console. - In addition, the System Table contains pointers to other standard tables that a loaded image - may use if the associated pointers are initialized to nonzero values. - Example of such tables: ACPI, SMBIOS, SAL System Table, ... - - - -If the UEFI image is a UEFI application that is not a UEFI OS loader, then the application executes and -either returns or calls the EFI Boot Services EFI_BOOT_SERVICES.Exit(). A UEFI application is always -unloaded from memory when it exits, and its return status is returned to the component that started the -UEFI application. - -EFI_TABLE_HEADER -Datastructure that precedes all of the standard EFI table types - -typedef struct { - UINT64 Signature; - UINT32 Revision; - UINT32 HeaderSize; - UINT32 CRC32; - UINT32 Reserved; - } EFI_TABLE_HEADER; - - -EFI_SYSTEM_TABLE -Except for the table header, all elements in the service tables are pointers to functions as defined -in Section7 (Services - Boot Services) and Section8 (Services - Runtime Services). - -Prior to a call to EFI_BOOT_SERVICES.ExitBootServices(), all of the fields of the EFI System Table are valid. -After an operating system has taken control of the platform with a call to ExitBootServices(), pmöy -Hdr, FirmwareVendor, FirmwareRevision, RuntimeServices, NumberOfTableEntries, ConfigurationTable fields -are valid. - -typedef struct { - EFI_TABLE_HEADER Hdr; - CHAR16 *FirmwareVendor; - UINT32 FirmwareRevision; - EFI_HANDLE ConsoleInHandle; - EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; - EFI_HANDLE ConsoleOutHandle; - EFI_SYSTEM_TEXT_OUTPUT_PROTOCOL *ConOut; - EFI_HANDLE StandardErrorHandle; - EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *stdErr; - EFI_RUNTIME_SERVICES *RuntimeServices: - EFI_BOOT_SERVICES *BootServices; - UINTN NumberOfTableEntries; - EFI_CONFIGURATION_TABLE *Configuration_Table; - } EFI_SYSTEM_TABLE; - -PARAMETERS - ConcoleHandle The handle for the active console input device. This handle must support - EFI_SIMPLE_TEXT_INPUT_PROTOCOL and EFI_SIMPLE_TECT_INPUT_EX_PROTOCOL. - ConIn A pointer to the EFI_SIMPLE_TEXT_INPUT_PROTOCOL interface that is - associated with ConsoleInHandle. - ConsoleOutHandle The handle for the active console output device. This handle must - EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. - ConOut A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL interface that is - associated with ConsoleOutHandle. - StandardErrorHandle The handle for the active standard error console device. Must support - EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. - StdErr A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL inte4rface that is - assiciated with StandardErrorHandle - RuntimeServices A pointer to the EFI Runtime Services Table (Section 4.5) - BootServices Section 4.4 - NumberOfTableEntries Number of system configuration tables in the buffer ConfigurationTable - ConfigurationTable A pointer to the system configuration tables. Number of entries in the table is - NumberOfTableEntries. - - - - - - - - -References -[1] UEFI Specification 2.8 Errata A, February 2020 - 4.1 UEFI Image Entry Point - pp 89 diff --git a/documentation/UEFI_from_spec/EFI_MEMORY_DESCRIPTOR b/documentation/UEFI_from_spec/EFI_MEMORY_DESCRIPTOR deleted file mode 100644 index 72e8cc9..0000000 --- a/documentation/UEFI_from_spec/EFI_MEMORY_DESCRIPTOR +++ /dev/null @@ -1,60 +0,0 @@ -typedef struct { - UINT32 Type; - EFI_PHYSICAL_ADDRESS PhysicalStart; - EFI_VIRTUAL_ADDRESS VirtualStart; - UINT64 NumberOfPages; - UINT64 Attribute; -} EFI_MEMORY_DESCRIPTOR; - - -Type Type of the memory region. Type EFI_MEMORY_TYPE is defined in the AllocatePages() function description. -PhysicalStart Physical address of the first byte in the memory region. Physical start must be aligned on a 4 KB boundary. - -VirtualStart Virtual address of the first byte in the memory region. Virtual start must be aligned on a 4 KB boundary. NumberOfPages Number of 4 KB pages in the memory region. -Attribute Attributes of the memory region that describe the bit mask of capabilities for that memory region, and not - necessarily the current settings for that memory region. - - - -//******************************************************* -// Memory Attribute Definitions -//******************************************************* -// These types can be “ORed” together as needed. -#define EFI_MEMORY_UC 0x0000000000000001 -#define EFI_MEMORY_WC 0x0000000000000002 -#define EFI_MEMORY_WT 0x0000000000000004 -#define EFI_MEMORY_WB 0x0000000000000008 -#define EFI_MEMORY_UCE 0x0000000000000010 -#define EFI_MEMORY_WP 0x0000000000001000 -#define EFI_MEMORY_RP 0x0000000000002000 -#define EFI_MEMORY_XP 0x0000000000004000 -#define EFI_MEMORY_RUNTIME 0x8000000000000000 - -EFI_MEMORY_UC Memory cacheability attribute: The memory region supports being configured as not cacheable. -EFI_MEMORY_WC Memory cacheability attribute: The memory region supports being configured as write combining. -EFI_MEMORY_WT Memory cacheability attribute: The memory region supports being configured as cacheable with - a “write through” policy. Writes that hit in the cache will also be written to main memory. -EFI_MEMORY_WB Memory cacheability attribute: The memory region supports being configured as cacheable with - a “write back” policy. Reads and writes that hit in the cache do not propagate to main memory. - Dirty data is written back to main memory when a new cache line is allocated. -EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports being configured as not cacheable, - exported, and supports the “fetch and add” semaphore mechanism. -EFI_MEMORY_WP Physical memory protection attribute: The memory region supports being configured as - write-protected by system hardware. -EFI_MEMORY_RP Physical memory protection attribute: The memory region supports being configured as - read-protected by system hardware. -EFI_MEMORY_XP Physical memory protection attribute: The memory region supports being configured so it is - protected by system hardware from executing code. -EFI_MEMORY_RUNTIME Runtime memory attribute: The memory region needs to be given a virtual mapping by the - operating system when SetVirtualAddressMap() is called (described in Chapter 7.3.) - - -//******************************************************* -//EFI_VIRTUAL_ADDRESS -//******************************************************* -typedef UINT64 -EFI_VIRTUAL_ADDRESS; -//******************************************************* -// Memory Descriptor Version Number -//******************************************************* -#define EFI_MEMORY_DESCRIPTOR_VERSION 1 diff --git a/documentation/UEFI_from_spec/GetMemoryMap b/documentation/UEFI_from_spec/GetMemoryMap deleted file mode 100644 index 362228c..0000000 --- a/documentation/UEFI_from_spec/GetMemoryMap +++ /dev/null @@ -1,29 +0,0 @@ -Returns current memory map - -typedef -EFI_STATUS -GetMemoryMap ( - IN OUT UINTN *MemoryMapSize, - IN OUT EFI_MEMORY_DESCRIPTOR *MemoryMap, - OUT UINTN *MapKey, - OUT UINTN *DescriptorSize, - OUT UINT32 *DescriptorVersion - ); - - -MemoryMapSize Pointer to the size in bytes of MemoryMap buffer. On input, it's the site of the buffer allocated by the caller. - On output, size of the buffer returned by the firmware if the buffer was large enough, or the size of the - buffer needed to contain the map if the buffer was too small. - -MemoryMap A pointer to the buffer in which firmware places the current memory map. Map is array of EFI_MEMORY_DESCRIPTORs. - -MapKey Pointer to the location in which firmware returns the key for the current memory map. - -DescriptorSize Pointer to location in which firmware returns the size in bytes of an individual EFI_MEMORY_DESCRIPTOR - -DescriptorVersion Pointer to location in which firmware returns version number associated with EFI_MEMORY_DESCRIPTOR. - - - -The memory map is only used to describe memory that is present in the system. Memory descriptors are never used to describe holes in the system memory map. Until ExitBootServices(), the memory map is owned by the firmware. The firmware's MapKey is changed every time something in the memory map changes. In order to successfully invoke ExitBootServices() the caller must provide the current memory map key. - diff --git a/documentation/UEFI_from_spec/Memory Map Design b/documentation/UEFI_from_spec/Memory Map Design deleted file mode 100644 index dc21d30..0000000 --- a/documentation/UEFI_from_spec/Memory Map Design +++ /dev/null @@ -1,137 +0,0 @@ -Intel - White Paper - A Tour beyond BIOS Memory Map Design in UEFI BIOS - Feb 2015 - -* -* -* INTRODUCTION TO MEMORY MAP -* -* - -Typical memory map includes the storage accessed by processor directly - 1) Physical memory (Main Memory, SMRAM (SMM stolen memory), integrated graphic stolen memory) - 2) Memory Mapped IO (PCI-Express Memory Mapped Configuration Space, PCI device MMO BAR, CPU Local APIC, - legacy video buffer, memory mapped flash device, TPM memory map configuration space. - -Memory Map does not include: - 1) Cache, eg CPU internal cache - 2) Disk, eg ATA hard driver, SCSI hard drive, CDROM/DVDROM, USB storage device - -* -* -* MEMORY MAP - HARDWARE PERSPECTIVE -* -* - -typical Intel x86 platform as example - -System Memory = main dynamic random access memory (DRAM) -------------- - Classification: - 1) Legacy region lesser than 1MiB - 2) Main memory between 1MiB and 4GiB - 3) Main memory greater than 4GiB - ------Legacy Region is for legacy OS or device consideration. 0 - 1 MiB. Areas: - (0x9FFFF = 0009_FFFFh) - - * 0 - 640KiB (0 - 0x9FFFF): DOS Area. The normal DRAM is for legacy OS (DOS) or boot loader usage - * 640 - 768KiB (0xA0000 - 0xBFFFF): SMRAM/Legacy Video Buffer Area. This region can be configured as SMM memory, - or mapped IO for legacy video buffer. - * 768 - 896KiB (0xC0000 - 0xDFFFF): Expansion Area for legacy option ROM. This region is DRAM and could be locked read-only. - * 869KiB - 1MiB (0xE0000 - 0xFFFFF): System BIOS Area. This region could be DRAM or could be configured as memory IO to flash region. - + 0xE0000 - 0xEFFFF: Extended System BIOS (Lower) - + 0xF0000 - 0xFFFFF: System BIOS (Upper) - ------Traditional OS. 1MiB - 4GiB - Occupied by memory-mapped IO, like flash, CPU APIC, TPM - dedicated register TOLUD: Top of Low Usable DRAM to indicate the bar. Areas: - * Normal DRAM: Used by OS - * ISA Hole (15MiB - 16MiB): Optional feature. If enabled, the normal DRAM is disabled by opening the hole. - * Protected Memory Range (DPR): Optional feature. If enabled, this DRAM cannot be accessed by DMA. - * Top memory for SMM: TSEG (Top Segment) SMRAM. If enabled, this DRAM can be accessed if and only if CPU in SMM mode. - * Top memory for integrated graphic device (IGD): IGD stolen memory. If enabled, this DRAM is served for IGD. - * Top memory for Intel Manageability Engine (ME): ME stolen memory. If enabled, this DRAM is served for ME. If total memory - greater than 4GiB, the ME stolen memory will be greater than 4BiG. So this region is always on top of physical memory and - it is not covered by TOLUD. - - -* -* -* MEMORY MAP - FIRMWARE PERSPECTIVE -* -* -Memory Map in PI Specification (PEI Phase): memory map is the PEI Hand-of-Block (HOB) (PI specification, vol 3,5.5 Resource Descriptor HOB) -Resource types: - * EFI_RESOURCE_SYSTEM_MEMORY: Memory that persists out of the HOB producer phase - * EFI_RESOURCE_MEMORY_MAPPED_IO: Memory-mapped I/O that is programmed in the HOB producer phase - * EFI_RESOURCE_FIRMWARE_DEVICE: Memory-mapped firmware devices - * EFI_RESOURCE_MEMORY_MAPPED_IO_PORT: Memory that is decoded to produce I/O cycles - -Memory Map in PI Specification (DXE Phase): ... - - -# -# -# Memory Map in UEFI specification -# -# -functions: AllocatePages(), AllocatePool(), FreePages(), FreePool() -When memory is allocated, it is "typed" according to the values EFI_MEMORY_TYPE (UEFI specification Table 25. Memory Type Usage before ExitBootServices()) -example types: - * EfiReservedMemoryType: not used by OS. According to ACPI specification, one of possible reasons a BIOS need this memory type is: - the address range contains RAM in use by the ROM - * EfiLoaderCode/EfiLoaderData: Used for UEFI application - * EfiBootServicesCode/EfiBootServicesData: Used for UEFI boot services driver. - * EfiRuntimeServicesCode/EfiRuntimeServicesData: Used for UEFI runtime services driver - * EfiACPIReclaimMemory: Used for most ACPI tables. The memory is to be preserved by the loader and OS until ACPI is enabled. - Once ACPI is enabled, the memory in this range is available for general use. - * EfiACPIMemoryNVS: Address space reserved for use by the firmware (eg ACPI FACS). The OS and loader must preserve this memory - range in the working ACPI S1-S3 states - * EfiMemoryMappedIO: Used by system firmware to request that a memory-mapped IO region be mapped by the OS to a virtual - address so it can be accessed ny EFI runtime services. The OS does not use this memorx. All system memory-mapped I/O - port space information should come from ACPI tables. - - -GetMemoryMap() interface returns an array of UEFI memory descriptors. These descriptors define a system memory map of all the installed RAM and of physical memory ranges reserved by the firmware. Each descriptor contains memory base and site at page level, as well as memory type and attributes. Memory attributes defined in UEFI specification - Memory Attribute Definitions. - * Memory cache ability attribute: EFI_MEMORY_UC, EFI_MEMORY_WC, EFI_MEMORY_WT, EFI_MEMORY_WB, EFI_MEMORY_UCE. - It means the memory region supports to be configured as cache attributes. - On x86, those attributes can be set to CPU MSR [see IA32SDM] - * Physical memory protection attribute: EFI_MEMORY_WP, EFI_MEMORY_RP, EFI_MEMORY_XP - Means memory region supports to be configured as write-protected, read-protected, or execution-protected by system hardware. - On x86, those attributes can be set to CPU page table. [see IA32SDM] - * Runtime memory attribute: EFI_MEMORY_RUNTIME. It means the memory region needs to be given a virtual mapping by the operating - system when SetVirtualAddressMap() is called. - - -According to ACPI specification, 15.4 UEFI Assumptions and Limitations, below memory range need to be reported: - * Current system memory configuration - * Chipset-defined address holes that are not being used by devices as reserved. - * Baseboard memory-mapped I/O devices, such as APICs, are returned as reserved. - * All occurrences of the system firmware are mapped as reserved. Including the areas below 1 MB, at 16 MB - (if present), and at end of the 4-GB address space. - * All of lower memory is reported as normal memory. The OS must handle standard RAM locations that are - reserved for specific uses, such as the interrupt vector table (0:0) and the BIOS data area (40:0). - * Memory mapped I/O and memory mapped I/O port space allowed for virtual mode calls to UEFI run-time functions. - -Below memory range does not need to be reported: - * Memory mapping of PCI devices, ISA Option ROMs, and ISA Plug and Play cards. - Because the OS has mechanisms available to detect them. For example, PCI BAR MMIO can be got by - standard PCI bus enumeration. On-board device (e.g. TPM) MMIO could be got by ACPI _CRS method. - * Standard PC address ranges are not reported. For example, video memory at 0xA0000 to 0xBFFFF physical - addresses are not described by this function. - - - -# -# -# Memory Map in ACPI specification -# -# - - - - - - - - - diff --git a/documentation/UEFI_from_spec/UEFI Shell commands b/documentation/UEFI_from_spec/UEFI Shell commands deleted file mode 100644 index bae61bf..0000000 --- a/documentation/UEFI_from_spec/UEFI Shell commands +++ /dev/null @@ -1,101 +0,0 @@ -Shell Boot Commands ------------------------- -autoboot view or set autoboot timeout variable -bcfg displays/modifies the driver/boot configuration -boottest set/view BootTest bots -clearlogs clears FPL and SEL logs -dblk displays the contents of blocks from a block device -lanboot performs boot over lan from EFI shell -mount mounts a file system on a block device -reset resets the system -tftp tftp to a boot/dhcp enabled unix boot server -vol displays volume information of the file system - -Shell Configuration Commands --------------------------------- - -cpuconfig Deconfigure or reconfigure cpus -date Displays the current date or sets the systemdate -err Displays or changes the error level -esiproc Make an ESI call -errdump View/Clear logs -info Display hardware information -monarch View or set the monarch processor -palproc Make a PAL call -salproc Make a SAL call -time Displays the current time or sets the system time -ver Displays the version information - -Shell Device Commands ------------------------- - -baud Set serial port com settings -connect Binds an EFI driver to a device and starts the driver -devices Displays the devices being managed by EFI drivers -devtree Displays the tree of devices of the EFI Driver Model -disconnect Disconnects one or more drivers from a device -dh Displays the handles in the EFI environment -drivers Displays the list of drivers of the EFI Driver Model -drvcfg Invokes the Driver Configuration Protocol -drvdiag Invokes the Driver Diagnostics Protocol -guid Displays all the GUIDs in the EFI environment -lanaddress Display LAN MAC addresses -load Loads and optionally connected EFI drivers -loadpcirom Loads a PCI Option ROM -map Displays or defines mappings -openinfo Displays the protocols on a handle and the agents -optload Lists all optional ROM-based efi drivers and apps -pci Displays PCI devices or PCI function config space -reconnect Reconnects one or more drivers from a device -unload Unloads a protocol image - -Shell Memory Commands -------------------------- - -default Sets, Resets, or Clears default NVM values -dmpstore Displays all NVRAM variables -dmem Displays the contents of memory -memmap Displays the memory map -mm Displays or modifies MEM/IO/PCI -pdt View or set page deallocation table - -Generic Shell Commands ------------------------- - -alias Displays, creates, or deletes aliases in the EFI shell -attrib Displays or changes the attributes of files or directories -cd Displays or changes the current directory -cls Clears the standard output with an optional background color -comp Compares the contents of two files -cp Copies one or more files/directories to another location -edit Edits an ASCII or UNICODE file in full screen -eficompress Compress a file -efidecompress Compress a file -exit Exits the EFI Shell -help Displays help menus, command list, or verbose help of a command -hexedit Edits with hex mode in full screen -ls Displays a list of files and subdirectories in a directory -mkdir Creates one or more directories -mode Displays or changes the mode of the console output device -mv Moves one or more files/directories to destination -rm Deletes one or more files or directories -set Displays, creates, changes or deletes - -EFI environment variables ----------------------------- - -setsize Sets the size of the file -touch Updates time with current time -type Displays the contents of a file -xchar Turn on/off extended character features - -Shell Script Commands ------------------------- - -echo Displays messages or turns command echoing on or off for/endfor -- Executes commands for each item in a set of items -goto Makes batch file execution jump to another location if/endif -- Executes commands in specified conditions -pause Prints a message and suspends for keyboard input -stall Stalls the processor for some microseconds - - - diff --git a/documentation/assembler/at&t b/documentation/assembler/at&t deleted file mode 100644 index 3fde006..0000000 --- a/documentation/assembler/at&t +++ /dev/null @@ -1,19 +0,0 @@ -ADRESSING MEMORY -==================== - -mov (%ebx), %eax /* Load 4 bytes from the memory address in EBX into EAX. */ -mov %ebx, var(,1) /* Move the contents of EBX into the 4 bytes at memory address var. - (Note, var is a 32-bit constant). */ -mov -4(%esi), % /* Move 4 bytes at memory address ESI + (-4) into EAX. */ -mov %cl, (%esi,%eax,1) /* Move the contents of CL into the byte at address ESI+EAX. */ -mov (%esi,%ebx,4), %edx /* Move the 4 bytes of data at address ESI+4*EBX into EDX. */ - -OPERATION SUFFIXES -===================== -movb $2, (%ebx) /* Move 2 into the single byte at the address stored in EBX. */ -movw $2, (%ebx) /* Move the 16-bit integer representation of 2 into the 2 bytes starting at the address in EBX. */ -movl $2, (%ebx) /* Move the 32-bit integer representation of 2 into the 4 bytes starting at the address in EBX. */ - -In assembly language, all the labels and numeric constants used as immediate operands (i.e. not in an address calculation -like 3(%eax,%ebx,8) ) are always prefixed by a dollar sign. When needed, hexadecimal notation can be used with the 0x -prefix (e.g. $0xABC ). Without the prefix, numbers are interpreted in the decimal basis. diff --git a/documentation/assembler/general b/documentation/assembler/general deleted file mode 100644 index 9619c1b..0000000 --- a/documentation/assembler/general +++ /dev/null @@ -1,46 +0,0 @@ -REGISTER - -eax general purpose, spezielle Bedeutung bei Arithmetikbefehlen -ebx general purpose -ecx general purpose, spezielle Bedeutung bei Schleifen -edx general purpose -ebp basepointer -esi source for stringoperations -edi destination for stringoperations -esp stackpointer - -SEGMENT REGISTERS - -cs codesegment -ds data segment -ss stacksegment -es beliebiges Segment -fs beliebiges Segment -gs beliebiges Segment - -FURTHER REGISTERS -eip instruction pointer -ef flags - - - -eax, ebx, ecx, edx: - - eax ---------------------------- - | ax - -------------- - ah | al - ------- ------ - - - - -[SECTION .data] -gruss: db 'hello, world' -unglueck: dw 13 -million: dd 1000000 - - -[SECTION .text] - mov ax,[million] diff --git a/documentation/c_tutorial/praeprozessor_direktiven b/documentation/c_tutorial/praeprozessor_direktiven deleted file mode 100644 index ba0c01d..0000000 --- a/documentation/c_tutorial/praeprozessor_direktiven +++ /dev/null @@ -1,90 +0,0 @@ -#DEFINE ---------- - -zb um parametrisierte Makros zu schreiben: - -#define MAX(x,y) ( (x)<=(y) ?(y) :(x) ) - ----beachte, dass x und y auch in der Funktion in Klammern stehen müssen. -Beim Aufruf braucht man kein Emikolon am Ende, es ist aber auch nicht falsch - -#define TAUSCHE(x,y) { \ - int j; \ - j=x; x=y; y=j; \ - } - -Bedenke, dass der Präprozessor das Makro ersetzt. Zu lange Ausdrücke blähen den Code unnötig auf. Statt dessen sollte man manchmal lieber eine Funktion benutzen. - -Die define-Direktive ist im Übrigen eine rein für die Programmiersprache C gedachte Direktive. Ein reiner C++-Compiler wird define deshalb nicht erkennen und kompilieren. Die meisten Compiler kennen aber sowohl C als auch C++. - -Der Geltungsbereich von symbolischen Konstanten bzw. Makros reicht vom Punkt der Deklaration mit #define bis zur Aufhebung mit #undef. Die Aufhebung mittels #undef ist aber optional. Wird #undef nicht verwendet, reicht der Geltungsbereich bis zum Dateiende. - -#ifndef __STDIO_H - #define __STDIO_H -#endif - --------------- -#define FERTIG - -int main(void) { - printf("Programmstart!\n"); - -#ifdef FERTIG - #error "Das Programm ist noch nicht fertig gestellt!!\n" Kompilererror. Das Programm lässt sichn nicht übersetzen -#endif - - -BEDINGTE KOMPILIERUNG UND VORDEFINIERTE MAKROS ------------------------------------------------ -__LINE__ Zeilennummer innerhalb der aktuellen Quellcodedatei -__FILE__ Name der aktuellen Quellcodedatei -__DATE__ Datum, wann das Programm compiliert wurde (als Zeichenkette) -__TIME__ Uhrzeit, wann das Programm compiliert wurde (als Zeichenkette) -__STDC__ Liefert eine 1, wenn sich der Compiler nach dem Standard-C richtet. -__STDC_VERSION__ Liefert die Zahl 199409L, wenn sich der Compiler nach dem C95-Standard richtet; die Zahl 199901L, wenn sich der Compiler nach dem C99-Standard richtet. Ansonsten ist dieses Makro nicht definiert. - -Vordefiniertes Makro Compiler -_MSC_VER Microsoft C ab Version 6.0 -_QC Microsoft Quick C ab Version 2.51 -__TURBOC__ Borland Turbo C, Turbo C++ und BC++ -__BORLANDC__ Borland C++ -__ZTC__ Zortech C und C++ -__SC__ Symantec C++ -__WATCOMC__ WATCOM C -__GNUC__ GNU C -__EMX__ Emx GNU C - -Vordefiniertes Makro Betriebssystem -__unix__ UNIX-System -__unix UNIX-System -__MS_DOS__ MS-DOS -__WIN32__ MS Windows ab 95 -__OS2__ OS2 -_Windows Zielsystem MS Windows -__NT__ MS Windows NT -__linux__ Linux-System -__FreeBSD__ FreeBSD -__OpenBSD__ OpenBSD -_SGI_SOURCE SGI-IRIX mit Extension *.sgi -_MIPS_ISA SGI-IRIX -__hpux HP-UX - - -#ifdef symbol -#ifdef ( symbol ) - -#elif symbol -#elif ( symbol ) - -#else - -#endif - -Gute Möglichkeit zum Debuggen: - __func__ gibt den Namen der aktuellen Funktion aus -void eine_funktion(void) { - printf("Name der Funktion: %s\n",__func__); -} - - - -__________________________________________________________________________________________ diff --git a/documentation/c_tutorial/printf_formats b/documentation/c_tutorial/printf_formats deleted file mode 100644 index 84cab65..0000000 --- a/documentation/c_tutorial/printf_formats +++ /dev/null @@ -1,11 +0,0 @@ -Zeichen Umwandlung -%d oder %i int -%c einzelnes Zeichen -%e oder %E double im Format [-]d.ddd e±dd bzw. [-]d.ddd E±dd -%f double im Format [-]ddd.ddd -%o int als Oktalzahl ausgeben -%p die Adresse eines Zeigers -%s Zeichenkette ausgeben -%u unsigned int -%x oder %X int als Hexadezimalzahl ausgeben -%% Prozentzeichen diff --git a/documentation/c_tutorial/standard_header b/documentation/c_tutorial/standard_header deleted file mode 100644 index ebc4664..0000000 --- a/documentation/c_tutorial/standard_header +++ /dev/null @@ -1,28 +0,0 @@ -(C89) -assert.h Fehlersuche und Debugging -ctype.h Zeichentest und Konvertierung -errno.h Fehlercodes -float.h Limits/Eigenschaften für Gleitpunkttypen -limits.h Implementierungskonstanten -locale.h länderspezifische Eigenschaften -math.h mathematische Funktionen -setjmp.h unbedingte Sprünge -signal.h Signale -stdarg.h variable Parameterübergabe -stddef.h Standard Datentyp -stdio.h Standard-I/O -stdlib.h nützliche Funktionen -string.h Zeichenkettenoperationen -time.h Datum und Zeit - -(C95 / C99) -complex.h komplexe Arithmetik (Trigonometrie etc) -Fenv.h Kontrolle de GLeitpunktzahlen-Umgebung -inttypes.h für genauere Integertypen -iso646.h alternative Schreibweisen für logische Operatoren; zur Verwendung von Zeichensätzen im ISO-646-Format -stdbool.h boolesche Datentypen -stdint.h ganzzahlige Typen vorgegebener Breite -tgmath.h typengenerische Mathematik-Funktionen -wchar.h Umwandlung von Strings in Zahlenwerte für den erweiterten Zeichensatz; String- und Speicherbearbeitung für den erweiterten Zeichensatz; Ein- und Ausgabe für den erweiterten Zeichensatz -wctype.h Zeichenuntersuchung für den erweiterten Zeichensatz - diff --git a/documentation/c_tutorial/struct b/documentation/c_tutorial/struct deleted file mode 100644 index e08892b..0000000 --- a/documentation/c_tutorial/struct +++ /dev/null @@ -1,72 +0,0 @@ -struct index { - int seite; - char titel[30]; -} lib; - -entspricht -struct index lib; - -bzw wenn Strukturname unnötig: -struct { - int seite; - char titel[30]; -} lib; - - -struct index { - int seite; - char titel[30]; -} lib1, lib2, lib3; - -struct index { - int seite; - char titel[30]; -} lib = { 308, "Strukturen" }; - -struct index lib = { 55, "Einführung in C" }; - - -/* struct2.c */ -#include <stdio.h> -#include <stdlib.h> -#define MAX 30 - -struct adres { - char vname[MAX]; - char nname[MAX]; - long PLZ; - char ort[MAX]; - int geburtsjahr; -} adressen; - -/* Funktion zur Ausgabe des Satzes */ -void ausgabe(struct adres x) { - printf("\n\nSie gaben ein:\n\n"); - printf("Vorname.........:%s", x.vname); - printf("Nachname........:%s", x.nname); - printf("Postleitzahl....:%ld\n",x.PLZ); - printf("Ort.............:%s", x.ort); - printf("Geburtsjahr.....:%d\n", x.geburtsjahr); -} - -int main(void) { - printf("Vorname : "); - fgets(adressen.vname, MAX, stdin); - printf("Nachname : "); - fgets(adressen.nname, MAX, stdin); - printf("Postleitzahl : "); - do { - scanf("%5ld",&adressen.PLZ); - } while(getchar()!= '\n'); - printf("Wohnort : "); - fgets(adressen.ort, MAX, stdin); - printf("Geburtsjahr : "); - do { - scanf("%4d",&adressen.geburtsjahr); - } while(getchar()!='\n' ); - - ausgabe(adressen); - return EXIT_SUCCESS; -} - -struct index lib = { 55, "Einführung in C" }; diff --git a/documentation/code examples/boot_services.c b/documentation/code examples/boot_services.c deleted file mode 100644 index 1cb57d7..0000000 --- a/documentation/code examples/boot_services.c +++ /dev/null @@ -1,55 +0,0 @@ - /* -extern EFI_BOOT_SERVICES *gBS; -EFI_EXIT_BOOT_SERVICES gOrigExitBootServices; - - - -EFI_STATUS -EFIAPI -ExitBootServicesHook(IN EFI_HANDLE ImageHandle, IN UINTN MapKey){ - - // <hook related fun> - // Do fun hook-related stuff here - // </hook-related fun> - - // Fix the pointer in the boot services table - // If you don't do this, sometimes your hook method will be called repeatedly, which you don't want - gBS->ExitBootServices = gOrigExitBootServices; - - // Get the memory map - UINTN MemoryMapSize; - EFI_MEMORY_DESCRIPTOR *MemoryMap; - UINTN LocalMapKey; - UINTN DescriptorSize; - UINT32 DescriptorVersion; - MemoryMap = NULL; - MemoryMapSize = 0; - - - do { - Status = gBS->GetMemoryMap(&MemoryMapSize, MemoryMap, &LocalMapKey, &DescriptorSize,&DescriptorVersion); - if (Status == EFI_BUFFER_TOO_SMALL){ - MemoryMap = AllocatePool(MemoryMapSize + 1); - Status = gBS->GetMemoryMap(&MemoryMapSize, MemoryMap, &LocalMapKey, &DescriptorSize,&DescriptorVersion); - } else { - // Status is likely success - let the while() statement check success - } - DbgPrint(L"This time through the memory map loop, status = %r\n",Status); - - } while (Status != EFI_SUCCESS); - - return gOrigExitBootServices(ImageHandle,LocalMapKey); - -} -EFI_STATUS -EFIAPI -HookDriverMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable){ - - // Store off the original pointer and replace it with your own - gOrigExitBootServices = gBS->ExitBootServices; - gBS->ExitBootServices = ExitBootServicesHook; - - // It's hooked! Return EFI_SUCCESS so your driver stays in memory - return EFI_SUCCESS; -} - */ diff --git a/documentation/developer manual x86-64/0_0 general_information b/documentation/developer manual x86-64/0_0 general_information deleted file mode 100644 index 1fb2bca..0000000 --- a/documentation/developer manual x86-64/0_0 general_information +++ /dev/null @@ -1,20 +0,0 @@ -Intel 64 and IA-32 Architectures Software Developer's Manual - -Volume 1: Basic Architecture (Order no 253665) -Volume 2 (A|B|C|D): Instruction Set Reference (253666|253667|326018|334569) - + opcode structure - Chapter - 1 About this Manual - 2 Instruction Format - 3 Instruction Set Reference A-L - 4 Instruction Set Reference M-U - 5 Instruction Set Reference V-Z - 6 Safer Mode Extensions Reference - Appendix - A Opcode Map - B Instructions Format and Encodings - C Intel C/C++ Compiler Intrinsics and Functional Equivalents - -Volume 3 (A|B|C|D): System Programming Guide (253668|253669|326019|332831) - operating system support environment. Target OS and BIOS designers. - 3B: programming environment for classes of software that host os. diff --git a/documentation/developer manual x86-64/2_1.3 Notational Conventions b/documentation/developer manual x86-64/2_1.3 Notational Conventions deleted file mode 100644 index 5ace83e..0000000 --- a/documentation/developer manual x86-64/2_1.3 Notational Conventions +++ /dev/null @@ -1,92 +0,0 @@ -1.3.1 Bits and Bytes ---------------------- - Little Endian - bytes of a word are numbered starting from least significant byte - Data Structure - Highest_addr Byte_Offest - 28 - 24 - 20 - 16 - 12 - 8 - 4 - Lowest_addr 0 - Byte3 Byte2 Byte1 Byte0 - Bit_Offset 0 - 7 8 - 15 16 - 23 24 - 31 - -1.3.2 Reserved Bits --------------------- - Avoid any software dependence upon the state of reserved bits. They should be regarded as unpredictable. - -1.3.3 Instruction Operands ---------------------------- - When symbolically represented: label: mnemonic argument1, argument2, argument3 - label: identifier - mnemonic: reserved name for a class if instruction opcodes - arguments: optional. Either literals or identifiers for data items. - identifiers: either reserved names of registers - or assigned to data items - if two: right - source, left - destination - !! Some assembly languages put the source and destination in reverse order !! - -1.3.4 Hexadecimal and Binary Numbers -------------------------------------- - Base 16: string of hexadecimal digits followed by the character H (eg F82EH) - Base 2: string of 1s and 0s, sometimes followed by B - -1.3.5 Segmented Addressing ---------------------------- - Processor uses byte addressing -> memory organized and accessed as a sequence of bytes. - address space: range of memory that can be addressed. - - Segmented addressing: program may have many independet address spaces (segments). - eg keep code (instructions) and stack in separate segments. - Specify a byte address within a segment: - Segment-register:Byte-address - - examples: - DS:FF79H DS: segment pointed by the DS register, FF79H: address - CS:EIP CS: code segment, EIP: address of instruction - - -1.3.6 Exceptions ------------------ - example: - #PF(fault code) PF: Page-fault exception, reports error code - #GP(0) GP: general-protection exception, error code = 0 - -1.3.7 A new Syntax for CPUID, CR, and MSR Values -------------------------------------------------- --- CPUID: optain feature flags, status and system information - - CPUID.01H:ECX.SSE[bit 25] = 1 - | | |_ Value (or range) of output - | |_ Output register and feature flag - | or field name with bit pos - |__ Input value for EAX register - --- CR: check control register bits - - CR4.OSFXSR[bit 9] = 1 - | | |_ Value (or range) of output - | |_ Feature flag or field name with bit position(s) - |_ Example CR name - --- MSR: read model-specific registers - - IA32_MISC_ENABLE.ENABLEOPCODE[bit 2] = 1 - | | |_ Value (or range) of output - | |_ Feature flag or field name with bit position(s) - |_ Example MSR name - - - - - - - - - - - - diff --git a/documentation/edk documentation/edk module writer guide b/documentation/edk documentation/edk module writer guide deleted file mode 100644 index 626b1d0..0000000 --- a/documentation/edk documentation/edk module writer guide +++ /dev/null @@ -1,113 +0,0 @@ -EDK II Module Writer's Guide -March 2010 -Revision 0.7 - - -A package must contain a package metadata file (DEC), and possibly a platform metadata file (DSC). These metadata files and the module’s INF files are used by the EDK II build system to automatically generate makefiles and a single module tip or whole flash tip, according to the build options used. The FDF is only required if flash output is required. - -1.1.3 EDK II Development Lifecycle - -1.1.3.1 Phase 1: Create a package - ------------------------------ - Don't place into MdePkg, MdeModulePkg, IntelFrameworkPkg, IntelFrameworkModulePkg - DEC file to define the package's interfaces, including: - - include directories for modules from other packages - - value of GUIDs - - value of Protocol GUIDs - - value of PPI GUIDs - - declaration of the PCD entries published by this package - -1.1.3.2 Phase 2: Create module metadata/Implement basic functionality - ------------------------------------------------------------------ - INF file to indicate the module's behaviour, including: - - module type - - required library classes - - required ppi/protocol/guid/PCD - - dependency relationship with other modules - -1.1.3.3 Phase 3: Create DSC to build - --------------------------------- - DSC describes build behaviour of the package, including: - - modules needed to be built - - chosen library instances for the various module type - - the configuration of the PCD entries used by modules - -1.1.3.4 Phase 4: Tune modules - ----------------------- - To tune modules - - use EDK II librries for code reuse - - use EDK II PCD mechanism for configuration - -Note: In the EDK II module development, developers are strongly discouraged from -using a conditional macro to control procedure behavior. The PCD mechanism -provides a unified interface, and developers should use it to configure a module’s -behavior. - - - -1.1.4 Build Infrastructure - ------------------------ -In brief, the EDK II build tool parses the metadata files (DSC, DECs, and INFs) to -generate corresponding one top-level makefile and a separate set of makefile and -autogen.c/autogen.h files for every module. -In the autogen files, the EDK II build tool generates all definitions of guids, protocols, -ppis, and PCDs used by the module, and automatically invokes all of the constructors -of used library instances in the module’s entry point implementations. - - -2.1.2 Package Directory - -------------------- - Include: All public header - Library: Directories for each library instance included - Application: Directories for each UEFI application module included - Driver: Directories for each driver group and for each driver. - -A module is not permitted to depend on source files from another module directory. Only depends on files under its directory or on public header files. - -3.1 What is an EDK II module? - -------------------------- - - A driver or application which is built to *.efi binary file and put into FFS file as EFI_PE_SECTION - - Raw data binary. For example, $(WORKSPACE)\MdeModulePkg\Logo\Logo.inf is a raw binary module which - contains logo bitmap image. - - An option ROM driver that is put into a device’s option ROM. - - A standalone UEFI driver - - A standalone UEFI application. - - A library instance that is built to a library object file (.lib) and statically linked to another module. - - -3.1.1 Module Types - -------------- - UEFI_APPLICATION This module type is used by UEFI Applications that are compliant with the UEFI Specification. - UEFI Applications are always unloaded when they exit. - - - -3.2.6.1 PCD Types - ------------ - EDK II provides the following types of PCDs: - Feature flag type PCD This PCD type replaces a switch MACRO to enable or disable a feature. - This is a Boolean value, and is either TRUE or FALSE. - Fixed at build type PCD This PCD type replaces a macro that produced a customizable value, such - as the PCI Express base address. The value of this PCD type is determined - at build time and is stored in the code section of a module’s PE image. - Patchable in module type PCD This PCD type is very similar to the fixed at build PCD type, but the value - is stored in the data section, rather than the code section, of the module’s - PE image. - Dynamic type PCD This PCD type is different from the other PCD types listed. The value is - assigned by one module and is accessed by other modules in execution - time. The PEIM PcdPeim and the DXE Driver PcdDXE each maintain a PCD - database that contains all dynamic PCD information used by platform in - their respective phase. - - - - - -3.7.5 Build module image - ---------------------- - - - - - - diff --git a/documentation/general/ACPI b/documentation/general/ACPI deleted file mode 100644 index 47c8513..0000000 --- a/documentation/general/ACPI +++ /dev/null @@ -1,5 +0,0 @@ -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/APIC b/documentation/general/APIC deleted file mode 100644 index b150f07..0000000 --- a/documentation/general/APIC +++ /dev/null @@ -1,16 +0,0 @@ -APIC - Advanced Programmable Interrupt Controller (Wikipedia) - -Particularly enabling the construction of multiprocessor systems. -One of several architectural designs intended to solve interrupt routing efficiency issues in multiprocessor computer systems. - -Split architecture design: local component (LAPIC) and optional I/O APIC on a system bus. - -Intel: One LAPIC in each CPU and typically one I/O APIC for each peripheral bus in the system. - -Each APIC, whether a discrete chip or integrated in a CPU, has a version register containing a four-bit version number for its specific APIC implementation. For example, the 82489DX has an APIC version number of 0, while version 1 was assigned to the first generation of local APICs integrated in the Pentium 90 and 100 processors - -INTEGRATED LOCAL APICS ------------------------ -Manage all external interrupts for some specific processor in an SMP system. -In addition, able to accept and generate inter-processor interrupts (IPIs) between LAPICS. - diff --git a/documentation/general/ATA_ATAPI b/documentation/general/ATA_ATAPI deleted file mode 100644 index 6ec6e68..0000000 --- a/documentation/general/ATA_ATAPI +++ /dev/null @@ -1,9 +0,0 @@ -ATA - AT Attachment --------------------- - -standard for parallel data transfer between hard disc storages and the corresponding interface of a computer. - - -ATAPI - AT Attachment Packet Interface ---------------------------------------- -uses this interface and expands the protocol st it can transport SCSI-pakets. Additionally supports diff --git a/documentation/general/GDT b/documentation/general/GDT deleted file mode 100644 index c4e0091..0000000 --- a/documentation/general/GDT +++ /dev/null @@ -1,4 +0,0 @@ -Global Descriptor Table -========================= - -Specific to IA32 architecture. diff --git a/documentation/general/IPI b/documentation/general/IPI deleted file mode 100644 index 5daed95..0000000 --- a/documentation/general/IPI +++ /dev/null @@ -1,10 +0,0 @@ -Inter-Processor Interrupt -============================== - -An inter-processor interrupt (IPI) is a special type of interrupt by which one processor may interrupt another processor in a multiprocessor system if the interrupting processor requires action from the other processor. Actions that might be requested include: - - - flushes of memory management unit caches, such as translation lookaside buffers, - on other processors when memory mappings are changed by one processor; - - stopping when the system is being shut down by one processor. - -On IBM PC compatible computers that use the Advanced Programmable Interrupt Controller (APIC), IPI signalling is often performed using the APIC. When a CPU wishes to send an interrupt to another CPU, it stores the interrupt vector and the identifier of the target's local APIC in the Interrupt Command Register (ICR) of its own local APIC. A message is then sent via the APIC bus to the target's local APIC, which therefore issues a corresponding interrupt to its own CPU. diff --git a/documentation/general/MMX b/documentation/general/MMX deleted file mode 100644 index 14a8a89..0000000 --- a/documentation/general/MMX +++ /dev/null @@ -1,9 +0,0 @@ -MMX is a single instruction, multiple data (SIMD) instruction set designed by Intel. (Wikipedia) - -Defines eight registers, MM0 to MM7 and operations that operate on them. Each register: 64 bits wide and can hold either 64-bit integers -or multiple smaller integers in a packed format. - -MMX provides only integer operations. -To avoid compatibility problems with the context switch mechanisms in existing operating systems, the MMX registers are aliases for the existing x87 FPU registers, which context switches would already save and restore. Unlike the x87 registers, which behave like a stack, the MMX registers are each directly addressable (random access). - -Any operation involving the floating point stack might also affect the MMX registers and vice versa, so this aliasing makes it difficult to work with floating point and SIMD operations in the same application.[10] To maximize performance, programmers often used the processor exclusively in one mode or the other, deferring the relatively slow switch between them as long as possible. diff --git a/documentation/general/PAE b/documentation/general/PAE deleted file mode 100644 index 9661fc9..0000000 --- a/documentation/general/PAE +++ /dev/null @@ -1,11 +0,0 @@ -PAE - Physical Address Extension (Wikipedia) ---------------------------------------------- -Memory management feature for the x86 architecture, - -Page-table hierarchy of three levels (instead of two), with table entries of 64 bits instead of 32, -allowing CPUs to directly access a physical address space larger than 4 gigabytes. - -Page-table structure used by x86-64 CPUs when operating in long mode firther extends page table hierarchy to -four levels, extending the virtual address space and uses additional physical address bits at all levels of the page table, extending the physical address space. Also uses the topmost bit of 64bit page table entry as a no-executive or "NX" bit, indicating that code cannot be executed from the associated page. - -With PAE, the page table entry of the x86 architecture is enlarged from 32 to 64 bits. This allows more room for the physical page address, or "page frame number" field, in the page table entry. In the initial implementations of PAE the page frame number field was expanded from 20 to 24 bits. The size of the "byte offset" from the address being translated is still 12 bits, so total physical address size increases from 32 bits to 36 bits (i.e. from 20+12 to 24+12). This increased the physical memory that is theoretically addressable by the CPU from 4 GB to 64 GB. diff --git a/documentation/general/RSDP b/documentation/general/RSDP deleted file mode 100644 index cd5ac96..0000000 --- a/documentation/general/RSDP +++ /dev/null @@ -1,74 +0,0 @@ -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). diff --git a/documentation/general/SSE b/documentation/general/SSE deleted file mode 100644 index e69de29..0000000 --- a/documentation/general/SSE +++ /dev/null diff --git a/documentation/gnu_efi/Makefile b/documentation/gnu_efi/Makefile deleted file mode 100644 index fee95e3..0000000 --- a/documentation/gnu_efi/Makefile +++ /dev/null @@ -1,31 +0,0 @@ -ARCH = $(shell uname -m | sed s,i[3456789]86,ia32,) - -OBJS = HelloWorld.o -TARGET = HelloWorld.efi - -EFIINC = /usr/include/efi -EFIINCS = -I$(EFIINC) -I$(EFIINC)/$(ARCH) -I$(EFIINC)/protocol -LIB = /usr/lib64 -EFILIB = /usr/lib -EFI_CRT_OBJS = $(EFILIB)/crt0-efi-$(ARCH).o -EFI_LDS = $(EFILIB)/elf_$(ARCH)_efi.lds - -CFLAGS = $(EFIINCS) -fno-stack-protector -fpic \ - -fshort-wchar -mno-red-zone -Wall -ifeq ($(ARCH),x86_64) - CFLAGS += -DEFI_FUNCTION_WRAPPER -endif - -LDFLAGS = -nostdlib -znocombreloc -T $(EFI_LDS) -shared \ - -Bsymbolic -L $(EFILIB) -L $(LIB) $(EFI_CRT_OBJS) -L /home/koenigr/Uni/memtest86/edk/edk2 - -all: $(TARGET) - -HelloWorld.so: $(OBJS) - ld $(LDFLAGS) $(OBJS) -o $@ -lefi -lgnuefi - -%.efi: %.so - objcopy -j .text -j .sdata -j .data -j .dynamic \ - -j .dynsym -j .rel -j .rela -j .reloc \ - --target=efi-app-$(ARCH) $^ $@ - diff --git a/documentation/gnu_efi/compile_with_gnu_efi.sh b/documentation/gnu_efi/compile_with_gnu_efi.sh deleted file mode 100644 index ed8d4b8..0000000 --- a/documentation/gnu_efi/compile_with_gnu_efi.sh +++ /dev/null @@ -1,4 +0,0 @@ -#!/bin/bash -clang -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -fno-stack-protector -fpic -fshort-wchar -mno-red-zone -DHAVE_USE_MS_ABI -c -o src/HelloWorld.o src/HelloWorld.c -ld -nostdlib -znocombreloc -T /usr/lib/elf_x86_64_efi.lds -shared -Bsymbolic -L /usr/lib /usr/lib/crt0-efi-x86_64.o src/HelloWorld.o -o huehuehuehuehue.so -lefi -lgnuefi -objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel -j .rela -j .reloc --target=efi-app-x86_64 huehuehuehuehue.so huehuehuehuehue.efi diff --git a/documentation/memtest86+ code/config_c_h b/documentation/memtest86+ code/config_c_h deleted file mode 100644 index a27eca0..0000000 --- a/documentation/memtest86+ code/config_c_h +++ /dev/null @@ -1,86 +0,0 @@ -TODO ----- -- why is there pop and pop2? - - - - -config.h ---------- - -Macro Description Value Effect - -CONSERVATIVE_SMP 0 Enable SMP - 1 Disable SMP (default) - -BEEP_MODE Beep on error 0 Off (default) - 1 On - -BEEP_END_NO_ERROR Beep at end of each pass 0 Off (default) - if no error 1 On - -PARITY_MEM Enables support for reporting - memory parity errors - -SERIAL_CONSOLE_DEFAULT Slows down testing 0 Off (default) - 1 On - -SERIAL_TTY Default serial port. 0 tty0 (Default) - 1 tty1 - -SERIAL_BAUD_RATE Baud rate for serial console 9600 - -APM_OFF Turns off APM at boot time - to avoid blanking the screen - -USB_WAR Enables workaround for errors - caused by BIOS USB keyboard and - mouse support - -DEFINED IN TSET.H ------------------- -POP_W 34 -POP_H 15 -POP_X 11 -POP_Y 8 -POP2_W 74 -POP2_H 21 -POP2_X 3 -POP2_Y 2 - -config.c ---------- - -char save[2][POP_H =15][POP_W =34]; -char save2[2][POP2_H =21][POP2_W =74]; - -void get_config() {} - -void popup() {} - -void popdown() {} - -void popclear() {} - -void pop2up() {} - -void pop2down() {} - -void pop2clear() {} - -void adj_mem(void) {} - - - - - - - - - - - - - - - diff --git a/documentation/memtest86+ code/cpuid_c_h b/documentation/memtest86+ code/cpuid_c_h deleted file mode 100644 index 39d2069..0000000 --- a/documentation/memtest86+ code/cpuid_c_h +++ /dev/null @@ -1,69 +0,0 @@ -*.h contains data structures required for CPUID implementation - -CPUID_VENDOR_LENGTH 3 3 GPRs hold Vendor ID -CPUID_VENDOR_STR_LENGTH (CPUID_VENDOR_LENGTH * sizeof(uint32_t) + 1) uint32_t = unsigned int -CPUID_BRAND_LENGTH 12 12 GPRs hold vendor ID -CPUID_BRAND_STR_LENGTH (CPUID_BRAND_LENGTH * sizeof(uint32_t) + 1) extra byte for '\0' - -ASM Code: -static inline void __cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx) {} ------------------------------------------------------------------------------------------------------------ -TODO - -static inline void cpuid(unsigned int op,unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx) {} ---------------------------------------------------------------------------------------------------------------------------- -TODO - - -/* Some CPUID calls want 'count' to be placed in ecx */ -static inline void cpuid_count(unsigned int op, int count, unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx) {} ------------------------------------------------------------------------------------------------------------------------------------------- -TODO - - -typedef union / bitfields: - LENGTH -cpuid_cache_info_t Store cache information -cpuid_vendor_string_t Store the CPUID Vendor String -cpuid_brand_string_t Store CPUID Brand String -cpuid_version_t 32 Store CPUID Version -cpuid_proc_info_t 32 Store CPUID Processor Information -cpuid_custom_features 1 ?? Store CPUID Feature flags -cpuid_feature_flags_t 96 Store CPUID Feature flags - - -struct: - -cpu_ident Overall structure to cache all of the CPUID information -cpuid4_eax TODO -cpuid4_ebx TODO -cpuid4_ecx TODO - - - -*.c ------ - -void get_cpuid() {} ---------------------- -Get max std cpuid & vendor ID - op = 0x0 - -Get processor family information & feature flags - op = 0x00000001 - -Get the digital thermal sensor & power management status bits - op = 0x00000006 - -Get the max extended cpuid - op = 0x80000000 - -Get extended feature flags, only save EDX - op = 0x80000001 - -Get the brand ID - op = 0x80000002 0x80000003 0x80000004 - -Get cache information - switch AMD or Intel. Intel is done in init.c - diff --git a/documentation/memtest86+ code/main_c b/documentation/memtest86+ code/main_c deleted file mode 100644 index ffeba34..0000000 --- a/documentation/memtest86+ code/main_c +++ /dev/null @@ -1,60 +0,0 @@ -cpu_id defined in cpuid.c -barrier_s in smp.h -barrier_s *barr in smp.c - - -void next_test() {} --------------------- - - -void set_defaults() {} ------------------------ - - -short tidx = 25; -void btrace(int me, int line, char *msg, int wait, long v1, long v2) {} ------------------------------------------------------------------------- - - -static void run_at(unsigned long addr, int cpu) {} ----------------------------------------------------- - - -static void switch_to_main_stack(unsigned cpu_num) {} -------------------------------------------------------- - - -static void parse_command_line() {} ------------------------------------- - - -void clear_screen() {} ------------------------- - - -void test_start(void) {} -------------------------- - - -void test_setup() {} ----------------------- - - -int do_test(int my_ord) {} ---------------------------- - - -int find_chunks(int tst) {} ------------------------------ - - -void find_ticks_for_pass(void) {} ----------------------------------- - - -static int find_ticks_for_test(int tst) {} --------------------------------------------- - - -static int compute_segments(struct pmap win, int me) {} --------------------------------------------------------- diff --git a/documentation/memtest86+ code/memsize_c_h b/documentation/memtest86+ code/memsize_c_h deleted file mode 100644 index edc4d7a..0000000 --- a/documentation/memtest86+ code/memsize_c_h +++ /dev/null @@ -1,2 +0,0 @@ -mem_info_t mem_info defined in head.S and test.h -mem_info_t defined in test.h diff --git a/documentation/memtest86+ code/screenbuffer_c_h b/documentation/memtest86+ code/screenbuffer_c_h deleted file mode 100644 index 0beb974..0000000 --- a/documentation/memtest86+ code/screenbuffer_c_h +++ /dev/null @@ -1,62 +0,0 @@ -Todo -------- -Where do we need SCREEN_BUFFER_H_1010F83B_INCLUDED? -why is pi_top < pi_bottom in tty_print_region? -Why is tty_print_line comparing text with screen_buf and - then writing it again although never changed? - - -scren_buffer.h ---------------- -SCREEN_BUFFER_H_1010F83B_INCLUDED - - -screen_buffer.c ------------------ - -SCREEN_X 80 -SCREEN_Y 25 -Y_SIZE SCREEN_Y -X_SIZE SCREEN_X + 1 // room for ending '\0' -static char screen_buf[Y_SIZE][X_SIZE] - -Macro CHECK_BOUNDS(y, x) is defined if SCRN_DEBUG is defined else empty - - -char get_scrn_buf(const int y, const int x) {} ------------------------------------------------- -returns one element (char) of screen_buf. x,y can be out of limits if CHECK_BOUNDS empty - - -void set_scrn_buf(const int y, const int x, const char val) {} ---------------------------------------------------------------- -sets on element to val. x,y can be out of limits if CHECK_BOUNDS empty - - -void clear_screen_buf() {} ---------------------------- -sets all elements to ' ' or to '\0' at end of line. x,y can be out of limits if CHECK_BOUNDS empty - - -void tty_print_region(const int pi_top, pi_left, pi_bottom, pi_right) {} -------------------------------------------------------------------------- -prints given region via ttyprint(int y, int x, const char *p). Replaces temporarily the last elements -of each line with '\0'. Undo the replacement after printing. - - -void tty_print_line(int y, int x, const char *text) {} -------------------------------------------------------- -TODO - - -void tty_print_screen(void) {} --------------------------------- -prints whole scrn_buf. If SCRN_DEBUG is set, it first prints the padding into every line - - -void print_error(char *pstr) {} ---------------------------------- -prints error message and goes in infinite empty loop - - - diff --git a/documentation/memtest86+ code/struct_tables_etc b/documentation/memtest86+ code/struct_tables_etc deleted file mode 100644 index 7b58299..0000000 --- a/documentation/memtest86+ code/struct_tables_etc +++ /dev/null @@ -1,20 +0,0 @@ -tseq[] --------- -type short short short short short char -field sel cpu_sel pat iter errors *msg -meaning element enabled? ==0 indicates test # # of iter error count msg passed - end of tseq[] to run update on - test run - 0 1 -1 0 6 0 "[Address test, walking ones, no cache] - 1 1 -1 1 6 0 - 2 1 32 2 6 0 - 3 1 32 3 6 0 - 4 1 32 5 3 0 - 5 1 32 6 30 0 - 6 1 32 7 81 0 - 7 1 1 8 3 0 - 8 1 32 9 48 0 - 9 1 32 10 6 0 - 10 1 1 11 240 0 - 11 1 0 0 0 0 - diff --git a/documentation/pxe/pxe wiki b/documentation/pxe/pxe wiki deleted file mode 100644 index 3d05dac..0000000 --- a/documentation/pxe/pxe wiki +++ /dev/null @@ -1,16 +0,0 @@ -Wikipedia - -Preboot Execution EnvironmentVon Intel entwickeltes Client-Server Modell um netzwerfähige Clients von einem Server ausgehend über ein lokales Rechnernetz zu booten. Server stellt nötigen Daten oder Bootimages zur Verfügung. Clients müssen über eine PXE-fähige Netzwerkkarte bzw PXE-Unterstützung im BIOS oder UEFI verfügen. PXE basiert auf bestehenden Netzwerkprotokollen DHCP (PXE-spezifische Erweiterungen von DHCP im RFC4578) und Trivial File Transfer Protocol (TFTP). Einsatz primär in LANs basierend auf Ethernet. - -ABLAUF -======== -Serverseite: DHCP-Server und TFTP-Server -Client: PXE-fähige Netzwerkkarte oder Unterstützung im BIOS. -PXE Code befindet sich nur auf der Clientseite. Auf Serverseite werden von Serveradministration nur bestimmte DHCP-Konfigurationen vorgenommen und auf TFTP Server Daten bereitgestellt. - -- PXE Code führt am Client über DHCP eine Konfiguration der Netzwerkschnittstelle durch. Server stellt IP-Netzwerkadresse, Netzmaske ein und überträgt zusätzliche Daten zur Unterstützung xon PXE. -- Client überträgt Daten wie Systemarchitektur, GUID -- Server gibt eine initiale Bootloaderdatei und Netzwerkadresse von einem TFTP Server an. -- Client bezieht initiales Network Bootstrap Programm vom TFTP Server und führt sie im Arbeitsspeicher aus. Bootloaderdatei muss zur Architektur passen und der Binärcode muss vom Prozessor ausgeführt werden können. - -Ein weiterer möglicher Bootloader stellt die Verwendung einer netzwerkfähigen Version von GRUB2 dar, welcher in Kombination mit Zusatzprogrammen wie dem englisch UEFI shim loader, ein Booten über PXE im Modus des Unified Extensible Firmware Interface (UEFI) erlaubt.[5] Mit entsprechenden signierten shim-Bootloader und GRUB2 ist damit im Rahmen von UEFI auch ein Secure Boot, beispielsweise von Linux über das Netzwerk, möglich. diff --git a/documentation/questions b/documentation/questions deleted file mode 100644 index 835f66e..0000000 --- a/documentation/questions +++ /dev/null @@ -1 +0,0 @@ -Presentation: Show differences in implementation for BIOS and UEFI? diff --git a/documentation/todo b/documentation/todo deleted file mode 100644 index 11f0958..0000000 --- a/documentation/todo +++ /dev/null @@ -1,6 +0,0 @@ -Uefi Spec 4.4 EFI Boot Services -UEFI Boot -UEFI applications - - -Is there a benefit of conOut over standard print or EFI Print? |