Skip to content

Hacks to get a working serial environment#1

Open
adventureloop wants to merge 6 commits intomhorne:udbc2from
adventureloop:udbc2
Open

Hacks to get a working serial environment#1
adventureloop wants to merge 6 commits intomhorne:udbc2from
adventureloop:udbc2

Conversation

@adventureloop
Copy link
Copy Markdown

I have a working test environment between a morefine m6 (alderlake-n xhci controller) and my framework 13.

These hacks are what I had to do to get a stable serial connection between the machines. I am yet to try live kernel debugging or testing to see which I can remove.

mhorne and others added 6 commits March 17, 2025 13:41
For serial/parallel drivers.
- Add the udbc(4) client driver.
- Add the "udbc" console backend to the UEFI loader.
- Add the "udbcons" console backend to the kernel.
- Add the /dev/udbcons device node.

See https://wiki.freebsd.org/HirokiSato/xhci for more details.

xhci: Support multiple xhci(4) devices

hw.usb.xhci.dbc.pci_rid specifies PCI RID for the console.  If not specified, the first found instance will be used.
Disable USBDBC for this loader variant, for the time being.

Authored by: bz
We now use llvm-objcopy by default (as of commit 1cae712), but it
does not support efi-app-x86_64 and similar ouptut formats (for more
detail see LLVM issue 108609[1]).

Go back to installing ELF Tool Chain's version of objcopy as elfcopy
(the standard upstream name) and use it for EFI builds.

[1] llvm/llvm-project#108609).

PR:		280771
Reviewed by:	andrew
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49362
With these hacks (some are probably not needed), I am able to use xhci
debug as a serial connection from both loader and the kernel.

The target is a morefine m6 Intel N200 based system with an Alderlake-N
based xhci controller and the host is a 13th Gen Framework 13 (that
part shouldn't matter). The target is a virtual machine on the m6
running in bhyve with pcie passthrough of the xhci controller.

I am using a Datapro xhci debug cable (USB 3.0 Super-Speed A/A
Debugging Cable).

	https://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html
mhorne pushed a commit that referenced this pull request Jul 22, 2025
Multiple issues existed within the powerpc FP/VSX save/restore functionality,
leading to register corruption and loss of register contents in specific
scenarios involving high signal load and use of both floating point and VSX
instructions.

Issue #1

On little endian systems the PCB used the wrong location for the shadowed
FP register within the larger VSX register.  This appears to have been an
attempt to correct issue freebsd#2 without understanding how the vector load/store
instructions actually operate.

Issue freebsd#2

On little endian systems, the VSX state save/restore routines swapped 32-bit
words within the 64-bit aliased double word for the associated floating point
register.  This was due to the use of a word-oriented load/store vs. doubleword
oriented load/store.

Issue freebsd#3

The FPU was turned off in the PCB but not in hardware, leading to a potential
race condition if the same thread was scheduled immediately after sigreturn.

The triggering codebase for this is Go, which makes heavy use of signals and
and generates an unusual mix of floating point and VSX assembler.  As a result,
when combined with th powerpc lazy FPU restore, a condition was repeatedly hit
whereby the thread was interrupted in FP+VSX mode, then restored in FP only
mode, thus reliably triggering the issues above.

Also clean up the associated asm() style issue flagged by GitHub Actions.

Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>

MFC after:	1 week
Pull Request:	freebsd#1756
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants