Low and full speed USB devices that are attached directly to an EHCI port
have to be handled by a companion controller (either UHCI or OHCI). We hand
over ports when we detect a low or full speed device is attached by setting
the Port Owner bit in the Port Status and Control register. However some AMD
companion controllers fail to detect the device after this has been done.
Resetting the EHCI controller works around this quirk.
This fixes issue #6 and issue #71.
In a .code16 section, the default coding for the lgdt instruction only loads
a 24 bit base address from the GDT descriptor. When loaded above 16MB, we
need it to load the full 32 bits.
This shouldn't be needed because we don't set the relocatable_kernel flag,
but the GRUB linuxefi command pays no attention to that. Currently the
linuxefi command also ignores the alignment values, but set them now in
case that changes in the future.
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.
Previously every second transfer was dropped. We didn't notice, because
they were normally key release events, which we ignored anyway. However
the new keyboard report handler needs to see the release events.
A USB keyboard may return key codes in any of the 6 key code array
positions (issue #48). So we have to compare the latest report to
the previous one to detect new key presses and handle rollover. As
the same change is needed for all HCI types, factor out the common
code into the base driver.
* 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>
