While iterating over a USB descriptor in GetExpectedDescriptor(),
the "Len" variable always uses the 1st byte in the buffer,
This is only true for the 1st iteration, thereafter the variable should
advance as the descriptor advances.
Signed-off-by: Leon Theunissen <leon.theunissen@etion.co.za>
Convert the line endings stored for all text files in the repository to
LF. The majority previously used DOS-style CRLF line endings. Add a
.gitattributes file to enforce this and treat certain extensions as
never being text files.
Update PatchCheck.py to insist on LF line endings rather than CRLF.
However, its other checks fail on this commit due to lots of
pre-existing complaints that it only notices because the line endings
have changed.
Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch
needs to be treated as binary since it contains a mixture of line
endings.
This change has implications depending on the client platform you are
using the repository from:
* Windows
The usual configuration for Git on Windows means that text files will
be checked out to the work tree with DOS-style CRLF line endings. If
that's not the case then you can configure Git to do so for the entire
machine with:
git config --global core.autocrlf true
or for just the repository with:
git config core.autocrlf true
Line endings will be normalised to LF when they are committed to the
repository. If you commit a text file with only LF line endings then it
will be converted to CRLF line endings in your work tree.
* Linux, MacOS and other Unices
The usual configuration for Git on such platforms is to check files out
of the repository with LF line endings. This is probably the right thing
for you. In the unlikely even that you are using Git on Unix but editing
or compiling on Windows for some reason then you may need to tweak your
configuration to force the use of CRLF line endings as described above.
* General
For more information see
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings .
Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400
Signed-off-by: Mike Crowe <mac@mcrowe.com>
When multiple USB mass storage devices are connected to the
target, it is not clear to the end user which one is selected
for boot. This patch added code to print the USB mass storage
device manufacturer and product name string. In this way, it
is easier for the end user to identify specific USB device.
It can also be used to determine the HwPart field for USB boot
option. HwPart for USB boot option is mapped to the USB mass
storage device index detected on the platform. BTW, to allow
boot from multiple USB mass storage devices, the optoin
ENABLE_MULTI_USB_BOOT_DEV needs to be enabled. So this patch
enabled ENABLE_MULTI_USB_BOOT_DEV by default.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
This patch added function UsbDeinitDevice() in UsbBusLib to free
memory allocated for all USB devices.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
This will fully support PatchCheck.py.
- Remove all trailing whitespace
- Convert LF to CRLF by default
- Update EFI_D_* to DEBUG_*
- Re-enable CRLF check in PatchCheck.py
Signed-off-by: Aiden Park <aiden.park@intel.com>
Previous USB keyboard console support commit worked fine on APL real
platform, but it has issue on QEMU. This patch further enables USB
keyboard console support for QEMU. A new PcdUsbKeyboardPollingTimeout
is added. It will be used to control the USB keyboard interrupt
transfer polling timeout. For QEMU, it needs a larger number due to
timing issue. As part of it, booting from USB device is also enabled
by this patch. This patch fixes#30.
To test USB keyboard console in QEMU, please first change
CONSOLE_IN _DEVICE_MASK in BoardConfig.py to 3, and then add the
following in the QEMU command line to add XHCI controller and USB KB:
-device qemu-xhci,id=xhci,bus=pcie.0,addr=4 -device usb-kbd,bus=xhci.0
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
