Hi,
On Sun, 23 Feb 2020 12:18:37 +0100 (CET)
Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>> Date: Sat, 22 Feb 2020 10:40:13 +0900 (JST)
>> From: YASUOKA Masahiko <yasu...@openbsd.org>
>> efiboot is using ACPI UID to determine the minor number of comX.
(snip)
>> I originally wrote this code, because I thought ACPI UID enumeration
>> is better than the order of handles by EFI.
>>
>> On qemu or vmware, 2 serials mappped like the following:
>>
>> EFI handle ACPI UID I/O addr efiboot kernel
>> 0 0 0x3f8 com0 com0
>> 1 1 0x2f8 com1 com1
>>
>> EFI handle order and ACPI UID enumeration are same and they also match
>> I/O address assignment.
>>
>> But on "HPE DL20 Gen10", 2 serials mappped like the following:
>>
>> EFI handle ACPI UID I/O addr efiboot kernel
>> 0 1 0x3f8 com1 com0
>> 1 0 0x2f8 com0 com1
>>
>> Note that EFI handle order and ACPI UID enumeration is different and
>> ACPI UID enumeration doesn't match the order in I/O address
>> assignment. In this case, since com0 or com1 are mixed up between
>> efiboot and kernel, if serial is usable on efiboot, it becomes not
>> usable on kernel.
>>
>> Fortunately we can use "machine comaddr" to fix up the problem.
>>
>>
>> Also I don't know any actual case such that EFI handle order is wrong
>> but ACPI UID is correct. If using ACPI UID is useless, we can apply
>> the diff attached at last.
>>
>> comment?
>
> I fear using the EFI handle order is going to cause similar problems
> on some other machine. What we really need here is the io port
> address. Unfortunately we can't map the UID into an address without a
> full AML parser, which is not something we want in the bootloader.
>
> On arm64 we use the SPCR table to select the serial port. This table
> does contain the io address of the serial port. Unfortunately not all
> machines have an SPCR table so we want to retain some of the existing
> logic in case an SPCR table isn't provided.
Thank you for the comment.
I suppose we need to accept the behavior for amd64 until we found any
good way.
Also I'd like to commit the diff attached.
When working around the problem with the boot.conf like below,
machine comaddr 0x3f8
set tty com1
this expects the kernel selects com0 for console. But actually
existing com(4) doesn't work so.
ok?
Update the console device always when attaching the real device
driver. The information by the driver is supposed more reliable than
the information which was set up earlier.
Index: sys/dev/ic/com.c
===================================================================
RCS file: /var/cvs/openbsd/src/sys/dev/ic/com.c,v
retrieving revision 1.171
diff -u -p -r1.171 com.c
--- sys/dev/ic/com.c 5 Feb 2020 10:21:17 -0000 1.171
+++ sys/dev/ic/com.c 2 Mar 2020 06:35:01 -0000
@@ -1498,8 +1498,8 @@ com_attach_subr(struct com_softc *sc)
if (cdevsw[maj].d_open == comopen)
break;
- if (maj < nchrdev && cn_tab->cn_dev == NODEV)
- cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
+ KASSERT(maj < nchrdev);
+ cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
printf("%s: console\n", sc->sc_dev.dv_xname);
}
