The PAE flag might be enabled on some x86-32 UEFI platforms, causing a crash in the kernel.
```
Assertion C:\reactos-master\reactos\ntoskrnl\mm\ARM3\miarm.h(971): PointerPte->u.Hard.Valid == 0
nt!MI_WRITE_VALID_PTE+0x28:
822d1d08 cd2c int 2Ch
```
Tested using qemu with `OVMF32_CODE_4M.fd` firmware, and with 32bit UEFI in VMware.
- Make the menu contents more dynamic; inspired by PR #8871 by Ahmed Arif.
- advopts.c: Double-relicense ntldropts.c/h to GPL-2.0-or-later or MIT,
as most of the code in this file has been rewritten for years now.
- options.c (FreeLoader setup options menu):
Double-relicense options.c/h to GPL-2.0-or-later or MIT, as most
of the code in this file has been rewritten since commit 9ff4e4b9ef.
CORE-9069, CORE-13525, RELEASE-11
This new BootCD contains the functionality of both the original bootcd
(text-mode 1st-stage installer) and the livecd (that will include the
1st-stage GUI installer later).
Our separate livecd ISOs become obsolete, and this completely removes
the need for the so-called "hybridcd" ISO.
Some details:
- The "hybridcd" build target is completely removed, since now the new
BootCD *is* basically what we used to call "hybridcd".
- The "livecd" build target is kept so far (to minimize the code changes),
but internally I start to refer to it as "LiveImage", and is reduced
to a minimum.
A minimal non-bootable "liveimg.iso" is built (but currently not
included within the BootCD). Its purpose will be to implement the
"ReactOS Live" functionality as a RAMDISK.
(We currently don't support other file formats apart from ISO and
flat disk for a RAMDISK).
The "ReactOS Live" (non-RAMDISK) is implemented by adding to the
BootCD file tree the files from the LiveImage.
These files add two root directories, "Profiles" and "reactos"
(which is the SystemRoot for the non-ramdisk LiveImage).
- The minimal text-mode ReactOS installation used for the 1st-stage
installer, including USETUP itself, and the executable for the
1st-stage GUI installer and the reactos.cab (installation source),
are moved to the root directory called "i386" (ideally, one directory
per architecture).
- The "bootcdregtest" target, i.e. the ISOs we feed our testbots with,
are left untouched, i.e. they are only constituted of the 1st-stage
text-mode installation only, but placed in a per-architecture root
directory ("i386", etc. as for the bootcd).
- Remove the ACPI APIC/SMP entries from bootcd.ini. They will be made
available via the Advanced Boot Options F8 menu in Debug builds, for
testing purposes only, in a subsequent commit.
This commit is based upon an older SVN one:
svn path=/branches/setup_improvements/; revision=75273
And slightly improve the search loop.
- Unconditionally look into the root directory as well, in order to cover
all possible boot disk layouts in case someone customizes the ReactOS
boot media layout.
- Improve the `InfOpenFile()` call error handling, in order to show the
erroneous line _iff_ the call failed because of a wrong syntax in
TXTSETUP.SIF . Distinguish it from a failure because the file doesn't
exist in the source path being tested (in which case, no error is shown).
The legide.sys driver, introduced in commit ae2827f481, is compiled *ONLY*
for the x86 platform (not x64 nor the others) as specified in commit 7d33f7503b.
Fix the file installation copy by moving its entry into the x86-specific section.
Addendum to commit 7174935d73 (PR #8888). CORE-17256
After merging the new ATA driver, FreeLdr complains about not being able
to load legide.sys. Fix that by adding legide.sys driver to txtsetup.sif
so FreeLoader can load it.
Addendum to ae2827f481. CORE-17256
These two registry values, stored in `HKEY_LOCAL_MACHINE\SYSTEM\Setup`,
are generated at runtime by the kernel; they are based on the current
values of: `LoaderBlock->NtHalPathName` and `LoaderBlock->ArcBootDeviceName`
respectively.
In particular, hardcoding `SystemPartition` to a default value
"\Device\Harddisk0\Partition1" , would be as random as hardcoding it
to anything else, since nothing justifies that there exists a partition
on the first harddisk, and if there is one, nothing guarantees that it
is one that was used to boot the operating system... Especially when
booting a LiveCD!
instead of the MBR-specific PARTITION_TABLE_ENTRY structure.
Simplify also some aspects of the code:
- for MBR code, avoid copying around partition entries, but use
pointers instead;
- more generally, use the actual disk sector size instead of guessing,
and pass it to the partition interface routines.
- `ArcBootDeviceName`: Given a theoretically valid ARC boot path
of the form:
`multi(0)disk(0)rdisk(0)partition(2)ReactOS\\weird)name`
correctly determine `ArcBootDeviceName` to be:
`multi(0)disk(0)rdisk(0)partition(2)`
and `SystemRoot` to be what follows it:
`ReactOS\\weird)name`
Usual paths like: `multi(0)disk(0)rdisk(0)partition(2)\\ReactOS`
are still correctly handled, of course.
- The `ArcHalDeviceName` path is the ARC path to the system partition,
where the firmware started the bootloader from. For historical reasons
it's called Arc **HAL**, because on older (and non-x86) Windows versions
the HAL was to be placed next to the OS loader in the system partition,
while the rest of the OS (kernel, etc.) was placed elsewhere.
So, in order to correctly set `ArcHalDeviceName`, pass the determined
SystemPartition all the way down to `WinLdrInitializePhase1()`.
For fixed-disks (i.e. not floppy nor CD-ROM), check in `disk.c!DiskInitialize()`
whether the disk being enumerated is GPT. If so, retrieve its disk GUID.
Pass this information to `AddReactOSArcDiskInfo()` when filling the ARC
disk information block, which sets the `IsGpt` and `GptSignature` members
of the `ARC_DISK_SIGNATURE` structure accordingly.
Debugging output example, where the first disk (0x80) is MBR, while the
second (0x81) is GPT:
```
(freeldr\disk\disk.c:100) err: DiskInitialize(0x80, 'multi(0)disk(0)rdisk(0)', Type: 25)
(freeldr\disk\disk.c:125) err: Signature: 163fbb9d
(freeldr\disk\disk.c:134) err: Checksum: 47699104
(freeldr\disk\disk.c:137) err: IsPartitionValid: TRUE
(freeldr\disk\disk.c:100) err: DiskInitialize(0x81, 'multi(0)disk(0)rdisk(1)', Type: 25)
(freeldr\disk\disk.c:125) err: Signature: 0
(freeldr\disk\disk.c:134) err: Checksum: 9cb5ff90
(freeldr\disk\disk.c:137) err: IsPartitionValid: TRUE
(freeldr\disk\disk.c:157) err: Disk 0x81 is GPT, DiskGuid: {1e4e8972-e026-4d5f-b213-7be3f2fad3f8}
```
----
This fixes the BSOD 0x7B `INACCESSIBLE_BOOT_DEVICE` that happens when
trying to boot a ReactOS installation present in a partition on a GPT
partitioned disk.
In the kernel IO manager:
`IopCreateArcNamesDisk()`, invoked by `IopCreateArcNames()`, tries to
map the list of disks dynamically detected by the boot disk drivers
with those detected by the bootloader, by matching their disk signatures.
- The signatures of the disks detected by the boot disk drivers are
obtained when querying their drive layout and partition table (which
also tells whether the disk is MBR or GPT partitioned);
- while the signatures of the disks detected by the bootloader are
enumerated in the `LoaderBlock->ArcDiskInformation->DiskSignatureListHead`
linked-list (inside `ARC_DISK_SIGNATURE` structures).
The routine compares the disk signatures by invoking `IopVerifyDiskSignature()`,
which, depending on whether the disk is MBR or GPT (as reported in the
drive layout), compares the signature with that of `ARC_DISK_SIGNATURE`
`Signature` (for MBR) or `GptSignature` (for GPT) structure members.
In case the boot disk turns out to not be mapped -- which was the case
until now if it was GPT-partitioned -- then the `IopMarkBootPartition()`
routine invoked later, wouldn't be able to find and open the boot disk,
and would trigger the BSOD 0x7B, as the result.
so that it can be used for other platforms.
Based upon suggestions by Daniel Victor (@iLauncherDev).
partition.c: Double-license GPL-2.0-or-later and MIT
This fixes boot regression on Xbox, introduced in 3964c936cb.
A new `call writestr` on early boot leads to `writechr` helper call,
which uses INT 10h BIOS service. This ends up in early boot crash,
as the original Xbox doesn't have VGA BIOS, nor the BIOS Data Area.
Fix the problem by adding Xbox-specific assembly helpers.
CORE-16216, CORE-19882
CORE-9023
In case FREELDR.INI is missing, or there are no operating systems listed
and available (either the corresponding section is missing, or is empty),
fall back to the FreeLoader Setup and Configuration F2 menu, that allows
performing a minimal number of operations (enabling FreeLoader debugging;
doing a custom boot... and more to come!)
Fix also a bug in `InitOperatingSystemList()`, that would allow
allocating an empty list with zero items. Now it returns NULL if
no operating systems are found.
Default to the Minimal text UI instead of the fullfledged one, if no
"MinimalUI" option can be found in FREELDR.INI (or if the INI is missing).
CORE-9023
Make also the advanced boot menu depend on the operating system type.
It can be opened by pressing F8, or F5, as in the Windows' bootloader.
The FreeLoader-specific options are moved to a separate menu,
accessible via the F2 key from the main menu.
Work-in-progress: display the boot options that correspond to the
currently-selected boot entry.
Use `NtLdrGetNextOption()` to loop over each individual option and move
it to its proper place. This automatically trims any '/' option
separator, including repeated ones and whitespaces, and allow for
straightforward replacement with one single space.
instead of returning an erroneous value, since the rosload.exe entry point
`RunLoader()` doesn't return any value. This allows exiting from rosload.exe
and NOT having the `LaunchSecondStageLoader()` returning 0, for example,
which would then be interpreted as an error condition and showing the
"Unable to load second stage loader." error box.
- `AtaInit()` returns the number of detected ATA devices. Therefore,
when iterating over them, go from index 0 to the count _minus_ 1,
in `Pc98InitializeBootDevices()` and in `XboxDiskInit()`.
- Initialize `DiskDrive->Type` to `DRIVE_TYPE_HDD` for detected SCSI
hard-disk drives in `pc98disk.c!InitScsiDrive()`.
- Rearrange `XboxDiskInit()` and reduce its indentation level.
Move the `DiskReportError()` and `DiskError()` routines into the
`freeldr/disk/disk.c` file, reviving it as a collection of disk
devices helpers (and more in the future).
The architecture-specific disk modules only define the error code mapping
`DiskGetErrorCodeString()` function, that is then used by `DiskError()`.
- Let it take a `MachFindPciBios` parameter, similar to the
`GET_SERIAL_PORT MachGetSerialPort` parameter of `DetectSerialPorts()`.
- Remove the `FindPciBios` global.
- Reduce indentation level.
Skip x86 BIOS emulator initialization on EFI boots by having FreeLdr populate EFI boot state in the loader block and making HAL consume it.
This keeps BIOS behavior unchanged while avoiding legacy BIOS/INT10 setup in the EFI path and preventing early EFI boot failures caused by entering the BIOS emulator path at all.
* [FREELDR][UEFI] Add BGRT logo support and center it on the loading screen
* [FREELDR][UEFI] Rework BGRT support and localize ACPI definitions
* [FREELDR][UEFI] Handle signed BGRT BMP height explicitly
* [FREELDR][UEFI] Use shared ACPI BGRT definitions
---------
Co-authored-by: Ahmed ARIF <arif.ing@outlook.com>
- Fix #GP crash on UEFI x64 boot caused by `call ExecuteLoaderCleanly[rip]` and `mov rax, UefiExitBootServices[rip]; call rax` generating indirect calls that read function code bytes as a pointer.
- Reload CS and data segments after `lgdt` to avoid #GP from stale UEFI selectors (e.g. CS=0x38) exceeding the new GDT limit.
Detect whether we run on XBOX or PC98 (on x86 builds), or on (U)EFI or on
a BIOS-based PC, or whether a generic linear framebuffer mode is used, in
order to choose the correct bootvid module to load, based from a predefined
file names list (ideally it should be derived from txtsetup.sif...).
Supersedes PR #8701.
Use `KeFindConfiguration*Entry()` to spelunk the hardware configuration
tree in the NT loader module.
Alternatively, allow the user to override the choice with a new `BOOTVID=`
boot option. In any case, if the selected bootvid module failed to be loaded,
silently fall back to the default bootvid.dll file. The fallback is done
by just letting the PE loader resolve the necessary exports from hal.dll
and ntoskrnl.exe.
This is the same feature as the one that already exists in the
NTOS:KD!kdmain.c module used by the in-kernel KDBG debugger
(GCC builds), first introduced in commit 4ce30245de (r54473),
and documented at:
https://reactos.org/wiki/Debugging#Changing_the_serial_port_address
This feature is useful if one uses a PCI, PCIe, PCMCIA, or ExpressCard
serial card on real hardware (these cards are used e.g. with laptops
without a built-in serial port), or with AMT serial over LAN.
After determining the serial port I/O address (say, 0xCC00), specify
the debug port as follows:
/DEBUGPORT=COM:0xCC00
instead of the usual syntax: /DEBUGPORT=COMn (n an integer).
The same syntax can be used for debugging FreeLoader as well: in the
FREELDR.INI file, add a "Debug" line in the "FREELOADER" section,
as follows:
```
[FREELOADER]
Debug=/DEBUG /DEBUGPORT=COM:0xCC00 /BAUDRATE=115200
```
----
NOTE for KDCOM/KDGDB:
Since `strtoul()` is used, but isn't exported by ntoskrnl, link against
the "strtol" static library that has been introduced in commit d317d4fbcc
(r71481).
Don't loop past the end of the command-line buffer, if the command-line
terminates with a lone "DEBUGPORT" without any extra parameter following.
For example: "some things DEBUGPORT "
- Don't hardcode constant string lengths.
- Use `_strnicmp()` -- Ideally we shouldn't have to unconditionally upcase
the global kernel command-line string to perform substrings comparisons.
- Cast `atol()` returned value to `ULONG`.
- The "IRQ" debugger option was introduced in commit 5a6adb4f13 (r2546).
It was used by the in-kernel GDB stub, to manually wire an interrupt
handler `GspBreakIn()` to allow the debugger to break into the system
when a command is received on the GDB serial port.
Side-remark:
The hooking was done via `HalGetInterruptVector()` + `IoConnectInterrupt()`,
but only at phase 1 initialization when the memory manager was up, which
can be "late" enough during system boot initialization.
Instead of using `IoConnectInterrupt()`, one could have used explicit
`KeInitializeInterrupt()` + `KeConnectInterrupt()` calls that would
have worked much earlier in the boot stage.
- This functionality was soon after disabled in commit c804ca06be (r2946)
in the GDB stub (see `ntoskrnl/kd/gdbstub.c!KdGdbStubInit()`), never
to be re-enabled again.
It was removed completely in commit e160c0fb26 (r14799).
- Since ReactOS was (until recently) always debugged locally using the
in-kernel KDBG debugger, break-in was done with TAB-K keypress,
intercepted by the keyboard driver that triggered a `DbgBreakPoint()`,
thus no break-in via serial port interrupt was necessary.
- Remote debugger break-in detection, which is the standard method that
is used when remote-debugging using KD transport DLLs and WinDbg, was
introduced in commit 12e7593f24 (r25984). As with the rest of debugger
communication and as done on Windows, detection is done by polling the
serial port at certain times, namely in the `KeUpdateSystemTime()`
kernel procedure periodically invoked by the timer interrupt.
This break-in detection was then erroneously removed in commit bf8b9467dc
(r45140), and reinstated in commit 014b23b9a (r56194).
- Parsing of this "IRQ" option was copy-pasted in other modules (FreeLoader,
KDCOM, and KDGDB), even though it was never used. The parsing was then
removed in KDBG itself in commit 95faf65ebf, but left in the other
modules... until now!
CORE-11954, CORE-16216, CORE-17518, CORE-17604, CORE-17977
The mkisofs options are quite long and repetitive (mostly duplicated 4 times
for the current 4 different ISO targets), and are also hard to read (i.e.
which group of options go together).
Reorganize the mkisofs ISO boot-related options in different thematic sets
and make them modular too. This also allow to conditionally add/remove ISO
boot entries for different platforms, for example:
- BIOS-based PC builds (only x86/x64) get the BIOS bootsector (excluded from IA64 and ARM32/64);
- EFI-based architectures get the EFI boot entry.
Based on a suggestion by Mark Jansen (see PR #4407).
Dedicated to Justin Miller ;)
EMS support isn't platform-specific, so we can compile it everywhere
(as this is already done for the kernel and the SAC driver).
The only platform-specific code currently existing is the retrieval of
the system GUID, which is done on BIOS-based PC by reading the SMBIOS
table in the low-MB ROM region, but should be done differently on other
platforms. Add a compile-time warning for this.
- Fix incorrect IDE controller ownership leading to strange and inconsistent behavior during boot.
- Fix a mismatch between the type and flags of the drive.
- Remove obsolete definitions.
- Use SAL2 annotations.
CORE-17977
