Serial kprintf not working from Mac mini 2018

[joevt]

I have connected a Sonnet Echo Express III-D with PCIe serial card and have setup serial debug output from OpenCore. I am trying to determine why my patches to displaypolicyd (using my fork of Lilu/WhateverGreen) sometimes cause macOS Monterey 12.4 boot to hang. I am unable to get xnu to do kprintf to the PCIe serial card with the Mac mini 2018 like I could with my iMac 27 inch 2013. The OpenCore log says it patched xnu successfully:

42:251 00:013 OCAK: Registering PCI serial device PMIO port 0x4008
42:259 00:008 OCAK: Registering PCI serial device register stride 1
42:329 00:070 OCAK: Patched CustomPciSerialDevice PMIO port 56 times
42:337 00:007 OCAK: Patch success CustomPciSerialDevice

I verified that the PMIO address of 0x4008 is unchanged in macOS (using lspci) I verified that the serial card is usable in macOS using Serial.app (requires PCIeSerialThunderboltEnable.kext; requires that PCIeSerialDisable.kext is not enabled for the port to be tested)

The last line I usually see in the serial output is this:

42:947 00:009 AAPL: #[EB|LOG:EXITBS:START] 2022-07-06T00:43:52

If I have Send early prints to serial port and/or Enable early serial output on RELEASE kernel patches enabled, then I can see these lines appear after the above line:

i386_init
kernel_startup_bootstrap
tunables
locks_early
kprintf
PE_init_printf
i386_vm_init
power_management_init
machine_startup
vm_mem_bootstrap
vm_page_bootstrap
pmap_steal
vm_page_buckets
vm_page_bucket_locks
pmap_startup
page_frame_init
vm_page_bootstrap complete
zone_bootstrap
vm_object_bootstrap
vm_map_init
kmem_init
kmem
pmap_init
vm_fault_init
zalloc
atm_init
percpu
locks
codesigning
oslog
telemetry_init
console_init
stackshot_init
sched_init
mac_policy_init
mach_ipc
PMAP_ACTIVATE_KERNEL
mapping_free_prime
machine_init
thread_machine_init_template
clock_init
coalitions_init
task_init
thread_init
restartable_init
workq_init
turnstiles_init
mach_init_activity_id
bank_init
ipc_pthread_priority_init
exception_init
sfi_init
kernel_thread_create
load_context - done
idle_thread_create
sched_startup
thread_daemon_init
thread_call
thread_bind
mapping_adjust
clock_service_create
kdp_init
hv_support_init
bootprofile_init
sysctl
PE_init_iokit
early_boot
mac_policy_initmach
dtrace_early_init
trust_cache_init
OSKextRemoveKextBootstrap
machine_lockdown
PE_lockdown_iokit

I believe my boot-args are set correctly for serial kprintf (same as my iMac 2013)

I guess I need to figure out if PE_init_kprintf is being called and if it is setting or clearing disable_serial_output.

Is it possible to make a patch to xnu that jumps to some new code, rather than just changing a few bytes? Perhaps xnu can jump into OpenCoreRuntime or some other block of code that is loaded at EFI time? Is there an example of such a patch?

[vit9696]

I suspect on Macmini it might use mmio. As for jumping to new code, there is no such support right now, and I am afraid it will be too much effort to add it.

[joevt]

I don't think the PCIe serial port card that I have connected with Thunderbolt uses mmio. And the source code for serial_init seems to indicate that mmio can be bypassed using boot-arg mmio_uart=0

I will do some testing to see if legacy_uart_probe can detect my PCIe serial port card.

[joevt]

I did a test where I call serial_init directly from Lilu. This causes serial output from macOS to work but there's an eventual hang booting Ventura. The hang might be due to IOPCIConfigurator stuff happening while logging to the PCIe serial card. I eliminated the hang by reducing serial port output (I was logging all calls to PE_parse_boot_argn which is called for boot-arg ioimageloader.logging many times so I made it not log that boot-arg).

It may be that IOPCIConfigurator or something might disable PMIO to the serial port even when PCIeSerialDisable.kext is injected (this is in Ventura on Mac mini 2018; I need to check other OS's to see if this is new behaviour). In that case, the following command will reenable I/O: sudo lspci -s $pciaddress COMMAND=1:1 where $pciaddress is the bus:device.function in hex (IOReg property pcidebug has this info in decimal). I suppose it might be useful for PCIeSerialDisable.kext to have code to reenable I/O (the kext was meant to stop only macOS user processes from accessing the serial port).

The mystery remains why serial_init isn't working properly before Lilu. I can try to see how the pe_serial.c globals are setup before Lilu calls serial_init but the variables are static so I have to access them by offset instead of name (the offsets are in the kernel dSYM file in the KDK).

[joevt]

My changes to fix this issue are at https://github.com/joevt/PCIeSerialDisable

[vit9696]

@PMheart, please update the docs :)

[PMheart]

Done.