Page MenuHomeFreeBSD

Use ACPI SPCR on x86
ClosedPublic

Authored by cperciva on May 22 2019, 6:11 PM.

Details

Summary

This takes the SPCR code currently in uart_cpu_arm64.c, moves it into a new uart_cpu_acpi.c, and uses it from both arm64 and x86. (In the process there is some refactoring and I added some comments to help me understand the code.)

Test Plan

Test on EC2 i3.metal instance: Successful.

Test on EC2 A1 instances: Successful.

Test on other arm64 instances... hoping that someone can do this for me.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

cperciva created this revision.May 22 2019, 6:11 PM
emaste added a subscriber: manu.May 22 2019, 9:04 PM

Tested on Ampere eMAG (along with WIP I brought over from @manu).

That same kernel did not boot on ThunderX2, but I do not know which specific changes were responsible.

greg_unrelenting.technology added inline comments.
sys/dev/uart/uart_cpu_acpi.c
132 ↗(On Diff #57708)

Lost comment about zero.. I guess it's not very valuable but still

This revision is now accepted and ready to land.May 22 2019, 10:58 PM

That same kernel did not boot on ThunderX2

Oh, I tested without options NUMA so this is not surprising. @manu retesting on TX2 w/ NUMA

manu added inline comments.May 23 2019, 12:56 AM
sys/dev/uart/uart_cpu_acpi.c
132 ↗(On Diff #57708)

I disagree, the spec says that value 0-2, 5, 8-255 are reserved so if we handle one of those value differently because $reason we should preserve the comment.

manu accepted this revision.May 23 2019, 1:10 AM

good for me, please just commit with the baudrate 0 comment preserved, I'm sure this will help someone in the future.

please just commit with the baudrate 0 comment preserved

OK in my testing too, agreed on the comment.

cperciva added inline comments.May 23 2019, 5:35 PM
sys/dev/uart/uart_cpu_acpi.c
132 ↗(On Diff #57708)

Which spec are you looking at?

https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table

says "0 = as is, operating system relies on the current configuration of serial port until the full featured driver will be initialized."

I'll add the comment back anyway...

This revision was automatically updated to reflect the committed changes.