Change Details

This collection of changes fixes serial console output on the AWS EC2 a1 (Graviton) instances. ## Unbreak manual UART settings (hw.uart.console) on aarch64 For initial debugging, I configured the loader tunable: `hw.uart.console="br:115200,mm:0x90A0000,sb:1"` — it didn't work, because: `uart_getenv` sets `di->bas.bst = uart_bus_space_mem;` `uart_cpu_getdev` sets `uart_bus_space_mem = di->bas.bst;` So it was passing the garbage uninitialized value back and forth. Let's initialize the correct value for the memory space, similar to `bus_space_tag_t uart_bus_space_mem = X86_BUS_SPACE_MEM;` on amd64. ## Pick up `regshft` from `AccessWidth` ACPI SPCR property The ARM SBSA recommended UARTs need a `regshift` of `2`, but the Amazon EC2 virtual PCI UART is a 16550-compatible one that needs the default `0` value. Let's set the value based on the `AccessWidth` — hopefully it tells the truth on systems that need `2`. (The only system known to have errata for this field is the APM X-Gene, a really old and obsolete aarch64 system.) ## Match PCI UART devices using PCI data from the ACPI SPCR table `uart_bus_probe` matches discovered devices to system devices using resource addresses (`uart_cpu_eqres(&sc->sc_bas, &sysdev->bas)`). The EC2 UART has different addresses in ACPI (`0x90A0000`) and PCI (`0x80118000`). Let's use the PCI address from the SPCR table to match PCI UART devices. This fixes `/dev/console` (without an UART device, there's no tty, only kernel prints worked). ## Fix the PCI ID for Amazon's UART device On AArch64 instances, it does not have a `0x1d0f` subvendor. Amazon's "consistency" in setting the `card` IDs is excellent: ``` uart0@pci0:0:1:0: class=0x070003 card=0x00000000 chip=0x82501d0f rev=0x00 hdr=0x00 nvme0@pci0:0:4:0: class=0x010802 card=0x00001d0f chip=0x80611d0f rev=0x00 hdr=0x00 ena0@pci0:0:5:0: class=0x020000 card=0xec201d0f chip=0xec201d0f rev=0x00 hdr=0x00 ``` --- Reference: * NetBSD acpi_platform code: https://github.com/NetBSD/src/blob/a08328adbe6fad187925e5268bba2f403af849c3/sys/arch/arm/acpi/acpi_platform.c#L144-L178 * Linux discussion: https://patchwork.kernel.org/patch/9460959/

This collection of changes fixes serial console output on the AWS EC2 a1 (Graviton) instances. ## ~~Unbreak manual UART settings (hw.uart.console) on aarch64~~ [[ https://svnweb.freebsd.org/base?view=revision&revision=345406 | r345406 ]] For initial debugging, I configured the loader tunable: `hw.uart.console="br:115200,mm:0x90A0000,sb:1"` — it didn't work, because: `uart_getenv` sets `di->bas.bst = uart_bus_space_mem;` `uart_cpu_getdev` sets `uart_bus_space_mem = di->bas.bst;` So it was passing the garbage uninitialized value back and forth. Let's initialize the correct value for the memory space, similar to `bus_space_tag_t uart_bus_space_mem = X86_BUS_SPACE_MEM;` on amd64. ## ~~Pick up `regshift` from `AccessWidth` ACPI SPCR property~~ [[ https://svnweb.freebsd.org/base?view=revision&revision=345405 | r345405 ]] The ARM SBSA recommended UARTs need a `regshift` of `2`, but the Amazon EC2 virtual PCI UART is a 16550-compatible one that needs the default `0` value. Let's set the value based on the `AccessWidth` — hopefully it tells the truth on systems that need `2`. ~~(The only system known to have errata for this field is the APM X-Gene, a really old and obsolete aarch64 system.)~~ see below ## Add workaround for wrong AccessWidth values The SPCR table on the Lenovo HR330A Ampere eMAG server indicates 8-bit access, but 32-bit access is required for the PL011 to work. [[ https://lore.kernel.org/patchwork/patch/657928/#843090 | PL011 on SBSA platforms always supports 32-bit access ]] (and that was hardcoded here before my EC2 fix), let's use 32-bit access for PL011 and 32BIT interface types. ## Match PCI UART devices using PCI data from the ACPI SPCR table `uart_bus_probe` matches discovered devices to system devices using resource addresses (`uart_cpu_eqres(&sc->sc_bas, &sysdev->bas)`). The EC2 UART has different addresses in ACPI (`0x90A0000`) and PCI (`0x80118000`). Let's use the PCI address from the SPCR table to match PCI UART devices. This fixes `/dev/console` (without an UART device, there's no tty, only kernel prints worked). ## ~~Fix the PCI ID for Amazon's UART device~~ [[ https://svnweb.freebsd.org/base?view=revision&revision=345369 | r345369 ]] On AArch64 instances, it does not have a `0x1d0f` subvendor. Amazon's "consistency" in setting the `card` IDs is excellent: ``` uart0@pci0:0:1:0: class=0x070003 card=0x00000000 chip=0x82501d0f rev=0x00 hdr=0x00 nvme0@pci0:0:4:0: class=0x010802 card=0x00001d0f chip=0x80611d0f rev=0x00 hdr=0x00 ena0@pci0:0:5:0: class=0x020000 card=0xec201d0f chip=0xec201d0f rev=0x00 hdr=0x00 ``` --- Reference: * NetBSD acpi_platform code: https://github.com/NetBSD/src/blob/a08328adbe6fad187925e5268bba2f403af849c3/sys/arch/arm/acpi/acpi_platform.c#L144-L178 * Linux discussion: https://patchwork.kernel.org/patch/9460959/

This collection of changes fixes serial console output on the AWS EC2 a1 (Graviton) instances. ## ~~Unbreak manual UART settings (hw.uart.console) on aarch64~~ [[ https://svnweb.freebsd.org/base?view=revision&revision=345406 | r345406 ]] For initial debugging, I configured the loader tunable: `hw.uart.console="br:115200,mm:0x90A0000,sb:1"` — it didn't work, because: `uart_getenv` sets `di->bas.bst = uart_bus_space_mem;` `uart_cpu_getdev` sets `uart_bus_space_mem = di->bas.bst;` So it was passing the garbage uninitialized value back and forth. Let's initialize the correct value for the memory space, similar to `bus_space_tag_t uart_bus_space_mem = X86_BUS_SPACE_MEM;` on amd64. ## ## ~~Pick up `regshft`ift` from `AccessWidth` ACPI SPCR property~~ [[ https://svnweb.freebsd.org/base?view=revision&revision=345405 | r345405 ]] The ARM SBSA recommended UARTs need a `regshift` of `2`, but the Amazon EC2 virtual PCI UART is a 16550-compatible one that needs the default `0` value. Let's set the value based on the `AccessWidth` — hopefully it tells the truth on systems that need `2`. ~~(The only system known to have errata for this field is the APM X-Gene, a really old and obsolete aarch64 system.)~~ see below ## Add workaround for wrong AccessWidth values The SPCR table on the Lenovo HR330A Ampere eMAG server indicates 8-bit access, but 32-bit access is required for the PL011 to work. [[ https://lore.kernel.org/patchwork/patch/657928/#843090 | PL011 on SBSA platforms always supports 32-bit access ]] (and that was hardcoded here before my EC2 fix), let's use 32-bit access for PL011 and 32BIT interface types. ## Match PCI UART devices using PCI data from the ACPI SPCR table `uart_bus_probe` matches discovered devices to system devices using resource addresses (`uart_cpu_eqres(&sc->sc_bas, &sysdev->bas)`). The EC2 UART has different addresses in ACPI (`0x90A0000`) and PCI (`0x80118000`). Let's use the PCI address from the SPCR table to match PCI UART devices. This fixes `/dev/console` (without an UART device, there's no tty, only kernel prints worked). ## ~~Fix the PCI ID for Amazon's UART device~~ [[ https://svnweb.freebsd.org/base?view=revision&revision=345369 | r345369 ]] On AArch64 instances, it does not have a `0x1d0f` subvendor. Amazon's "consistency" in setting the `card` IDs is excellent: ``` uart0@pci0:0:1:0: class=0x070003 card=0x00000000 chip=0x82501d0f rev=0x00 hdr=0x00 nvme0@pci0:0:4:0: class=0x010802 card=0x00001d0f chip=0x80611d0f rev=0x00 hdr=0x00 ena0@pci0:0:5:0: class=0x020000 card=0xec201d0f chip=0xec201d0f rev=0x00 hdr=0x00 ``` --- Reference: * NetBSD acpi_platform code: https://github.com/NetBSD/src/blob/a08328adbe6fad187925e5268bba2f403af849c3/sys/arch/arm/acpi/acpi_platform.c#L144-L178 * Linux discussion: https://patchwork.kernel.org/patch/9460959/