When USB keyboard detection is enabled, physical memory pages are reserved
for use by the USB drivers. The physical memory map exposed by pmem.h does
not indicate where the ACPI tables reside, so we may end up using pages
that contain ACPI tables (or for that matter, the boot parameters and boot
command line). So rather than introduce a more complicated memory allocation
scheme, make sure we have finished with all the data passed to us by the
BIOS and/or boot loader before we start probing for USB devices.
The only downside to this is that it is no longer possible to interactively
disable parsing of the ACPI tables - that can now only be done by using the
"nosmp" boot option.
* Improve abstraction in vmem.h and limit memory benchmarking to first 2GB.
The third GB may get used for remapping memory regions that are only
accessed during startup, so it's not safe to use it for the memory
speed tests.
* Fix calculation of end limit for locating memory benchmark workspace.
* Document vmem.h.
* Use window number, not current start address, to detect first window.
* Increase the program low-load range from 1MB to 4MB and make more robust.
If the BIOS has reserved some parts of low memory, there may not be
enough contiguous space left to load the program there (issue #49).
So increase the low-load range to include the first 3MB of high
memory. Also guard against the program being initially loaded
straddling the new boundary.
Co-authored-by: Martin Whitaker <memtest@martin-whitaker.me.uk>
If the usbdebug option is present, pause at the end of the USB scan until
a key is pressed. Otherwise, if the keyboard=usb option is present and no
USB keyboards were discovered, pause for 10 seconds. Otherwise don't pause.
* Add preliminary support for TTY Serial/UART (#15)
* Use shadow_buffer instead of VGA buffer to get a framebuffer-agnostic TTY supprot
* Added menu browsing & inputs from Serial TTY (#15)
* Add fix for degree symbol on TTY. Correct serial.c & serial.h file created with CRLF (#15)
* Move tty_error_redraw() to insure correct redraw when a error occurs
* Many reindent / cleanup
* Various optimization from @martinwhitaker comments
There is an unavoidable race between one core halting after decrementing
the barrier count and another core sending it the wakeup NMI. This can
only occur if the core sending the wakeup is running at many times the
speed of the core halting, but it has been observed on an Intel Icelake
mobile processor.
The old barrier implementation was very slow when running on a multi-socket
machine (pcmemtest issue 16).
The new implementation provides two options:
- when blocked, spin on a thread-local flag
- when blocked, execute a HLT instruction and wait for a NMI
The first option might be faster, but we need to measure it to find out. A
new boot command line option is provided to select between the two, with a
third setting that uses a mixture of the two.
That optimisation occasionally caused a hang if the CPU sequencing
mode was reconfigured after testing had started. It didn't make a
significant difference to the startup delay, so just drop it.
Leave the APs running whilst the BSP repeats the dummy runs. This means
we need to bypass the barriers during a dummy run. The APs will wait at
the first barrier until the BSP starts the first real run.
Martin Whitaker
martinwhitakerandMartin Whitaker
Sam Demeulemeester
Sam Demeulemeester
Martin Whitaker
Lionel Debroux