* [PATCH] SPCR: check bit width for the 16550 UART @ 2016-12-05 13:05 Aleksey Makarov 2016-12-05 18:51 ` Duc Dang 0 siblings, 1 reply; 16+ messages in thread From: Aleksey Makarov @ 2016-12-05 13:05 UTC (permalink / raw) To: Rafael J . Wysocki Cc: linux-acpi, linux-serial, linux-kernel, Greg Kroah-Hartman, Russell King, Peter Hurley, Aleksey Makarov, Jon Masters, Mark Salter, Duc Dang, Graeme Gregory, Len Brown Check the 'Register Bit Width' field of the ACPI Generic Address Structure that specifies the address of the UART registers to decide if the driver should use "mmio32" access instead of "mmio". If the driver is other than 16550 the access with is defined by the Interface Type field of the SPCR table. For discussion: https://lkml.kernel.org/r/7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Reported-by: Heyi Guo <heyi.guo@linaro.org> --- drivers/acpi/spcr.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index e8d7bc7..6c6710b 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -70,6 +70,10 @@ int __init parse_spcr(bool earlycon) break; case ACPI_DBG2_16550_COMPATIBLE: case ACPI_DBG2_16550_SUBSET: + if (table->serial_port.space_id == + ACPI_ADR_SPACE_SYSTEM_MEMORY && + table->serial_port.bit_width == 32) + iotype = "mmio32"; uart = "uart"; break; default: -- 2.10.2 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-05 13:05 [PATCH] SPCR: check bit width for the 16550 UART Aleksey Makarov @ 2016-12-05 18:51 ` Duc Dang 2016-12-05 23:27 ` Jon Masters 0 siblings, 1 reply; 16+ messages in thread From: Duc Dang @ 2016-12-05 18:51 UTC (permalink / raw) To: Aleksey Makarov Cc: Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Jon Masters, Mark Salter, Graeme Gregory, Len Brown On Mon, Dec 5, 2016 at 5:05 AM, Aleksey Makarov <aleksey.makarov@linaro.org> wrote: > Check the 'Register Bit Width' field of the ACPI Generic Address > Structure that specifies the address of the UART registers to > decide if the driver should use "mmio32" access instead of "mmio". > > If the driver is other than 16550 the access with is defined > by the Interface Type field of the SPCR table. > > For discussion: > > https://lkml.kernel.org/r/7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com Tested on X-Gene 1 and X-Gene 2 platforms. Tested-by: Duc Dang <dhdang@apm.com> > > Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> > Reported-by: Heyi Guo <heyi.guo@linaro.org> > --- > drivers/acpi/spcr.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c > index e8d7bc7..6c6710b 100644 > --- a/drivers/acpi/spcr.c > +++ b/drivers/acpi/spcr.c > @@ -70,6 +70,10 @@ int __init parse_spcr(bool earlycon) > break; > case ACPI_DBG2_16550_COMPATIBLE: > case ACPI_DBG2_16550_SUBSET: > + if (table->serial_port.space_id == > + ACPI_ADR_SPACE_SYSTEM_MEMORY && > + table->serial_port.bit_width == 32) > + iotype = "mmio32"; > uart = "uart"; > break; > default: > -- > 2.10.2 > Thanks, Duc Dang. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-05 18:51 ` Duc Dang @ 2016-12-05 23:27 ` Jon Masters 2016-12-05 23:52 ` Duc Dang 0 siblings, 1 reply; 16+ messages in thread From: Jon Masters @ 2016-12-05 23:27 UTC (permalink / raw) To: Duc Dang, Aleksey Makarov Cc: Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown Duc, Aleksey, all, I have a question about this... On 12/05/2016 01:51 PM, Duc Dang wrote: > On Mon, Dec 5, 2016 at 5:05 AM, Aleksey Makarov > <aleksey.makarov@linaro.org> wrote: >> Check the 'Register Bit Width' field of the ACPI Generic Address >> Structure that specifies the address of the UART registers to >> decide if the driver should use "mmio32" access instead of "mmio". >> >> If the driver is other than 16550 the access with is defined >> by the Interface Type field of the SPCR table. I have two questions about this: 1). Why is this not a full 16550 (ACPI_DBG2_16550_COMPATIBLE)? 2). Why is it a ACPI_DBG2_16550_SUBSET you are assuming here? The SPCR and DBG2 spec clearly state that the _SUBSET is intended to represent a UART compatible with the earlier DGBP specification, not that a UART is a "subset" of a full 16550 (which seems to be the assumption in this patch). It's important we get this right. I built a test kernel with this patch and updated ACPI tables earlier, but it didn't boot with a console because I had left it a subtype 0, but just changed the width to 32 bit, which is what I expected. Further, I've heard back from Microsoft and they're looking at adding a specific subtype for this. If they do, I'm inclined to address existing designs with your patch (but I would favor this check because against the full 16550) and then switch newer APM based designs to the new subtype. Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-05 23:27 ` Jon Masters @ 2016-12-05 23:52 ` Duc Dang 2016-12-06 0:03 ` Jon Masters ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Duc Dang @ 2016-12-05 23:52 UTC (permalink / raw) To: Jon Masters Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown Hi Jon, On Mon, Dec 5, 2016 at 3:27 PM, Jon Masters <jcm@redhat.com> wrote: > Duc, Aleksey, all, > > I have a question about this... > > On 12/05/2016 01:51 PM, Duc Dang wrote: >> On Mon, Dec 5, 2016 at 5:05 AM, Aleksey Makarov >> <aleksey.makarov@linaro.org> wrote: >>> Check the 'Register Bit Width' field of the ACPI Generic Address >>> Structure that specifies the address of the UART registers to >>> decide if the driver should use "mmio32" access instead of "mmio". >>> >>> If the driver is other than 16550 the access with is defined >>> by the Interface Type field of the SPCR table. > > I have two questions about this: > > 1). Why is this not a full 16550 (ACPI_DBG2_16550_COMPATIBLE)? > > 2). Why is it a ACPI_DBG2_16550_SUBSET you are assuming here? The patch is actually applied for both ACPI_DBG2_16550_COMPATIBLE and ACPI_DBG2_16500_SUBSET. Or I misunderstood your question? The end result after applying the patch on linux-next is like this: switch (table->interface_type) { case ACPI_DBG2_ARM_SBSA_32BIT: iotype = "mmio32"; /* fall through */ case ACPI_DBG2_ARM_PL011: case ACPI_DBG2_ARM_SBSA_GENERIC: case ACPI_DBG2_BCM2835: uart = "pl011"; break; case ACPI_DBG2_16550_COMPATIBLE: case ACPI_DBG2_16550_SUBSET: if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY && table->serial_port.bit_width == 32) iotype = "mmio32"; uart = "uart"; break; default: err = -ENOENT; goto done; } > > The SPCR and DBG2 spec clearly state that the _SUBSET is intended > to represent a UART compatible with the earlier DGBP specification, > not that a UART is a "subset" of a full 16550 (which seems to be > the assumption in this patch). It's important we get this right. > > I built a test kernel with this patch and updated ACPI tables earlier, > but it didn't boot with a console because I had left it a subtype 0, > but just changed the width to 32 bit, which is what I expected. On Mustang 3.06.25 firmware, DBG2 table has 'Port Type = 0x8000', 'Port subtype = 0x0001' But I am still curious why setting subtype to '0' does not work on your board. Are you using Mustang or m400? > > Further, I've heard back from Microsoft and they're looking at > adding a specific subtype for this. If they do, I'm inclined to > address existing designs with your patch (but I would favor this > check because against the full 16550) and then switch newer APM > based designs to the new subtype. Yes, we will look out for the new subtype information. > > Jon. > > -- > Computer Architect | Sent from my Fedora powered laptop > Regards, Duc Dang. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-05 23:52 ` Duc Dang @ 2016-12-06 0:03 ` Jon Masters 2016-12-06 0:05 ` Jon Masters 2016-12-06 0:31 ` Duc Dang 2 siblings, 0 replies; 16+ messages in thread From: Jon Masters @ 2016-12-06 0:03 UTC (permalink / raw) To: Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown On 12/05/2016 06:52 PM, Duc Dang wrote: > Hi Jon, > > On Mon, Dec 5, 2016 at 3:27 PM, Jon Masters <jcm@redhat.com> wrote: >> Duc, Aleksey, all, >> >> I have a question about this... >> >> On 12/05/2016 01:51 PM, Duc Dang wrote: >>> On Mon, Dec 5, 2016 at 5:05 AM, Aleksey Makarov >>> <aleksey.makarov@linaro.org> wrote: >>>> Check the 'Register Bit Width' field of the ACPI Generic Address >>>> Structure that specifies the address of the UART registers to >>>> decide if the driver should use "mmio32" access instead of "mmio". >>>> >>>> If the driver is other than 16550 the access with is defined >>>> by the Interface Type field of the SPCR table. >> >> I have two questions about this: >> >> 1). Why is this not a full 16550 (ACPI_DBG2_16550_COMPATIBLE)? >> >> 2). Why is it a ACPI_DBG2_16550_SUBSET you are assuming here? > > The patch is actually applied for both ACPI_DBG2_16550_COMPATIBLE and > ACPI_DBG2_16500_SUBSET. Or I misunderstood your question? No, I had missed the fall through for both conditions since it hadn't worked in my quick boot test with the other type earlier. It's probably only applicable in the general 16550 case, not in the subset case, but I don't have any objections at this. My bad. Now as to why it's not actually triggering on my test machine is something I'll check. I set the port width in the address struct in the ACPI table to 32-bit and it didn't see mmio32 just mmio, so I then re-read the patch itself and had assumed Aleksey meant it to be only for the subtype. Be right back after I poke... Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-05 23:52 ` Duc Dang 2016-12-06 0:03 ` Jon Masters @ 2016-12-06 0:05 ` Jon Masters 2016-12-06 0:31 ` Duc Dang 2 siblings, 0 replies; 16+ messages in thread From: Jon Masters @ 2016-12-06 0:05 UTC (permalink / raw) To: Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown On 12/05/2016 06:52 PM, Duc Dang wrote: > But I am still curious why setting subtype to '0' does not work on > your board. Are you using Mustang or m400? m400 with updated tables (that are correctly overriding not appending) provided via INITRD override. I am looking at why it's not working. [ 0.000000] ACPI: Table Upgrade: override [SPCR-HPE -ProLiant] [ 0.000000] ACPI: SPCR 0x0000004FF7F30000 Physical table override, new table: 0x0000004FFFFF0000 [ 0.000000] ACPI: SPCR 0x0000004FFFFF0000 000050 (v02 HPE ProLiant 00001337 INTL 20160527) Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-05 23:52 ` Duc Dang 2016-12-06 0:03 ` Jon Masters 2016-12-06 0:05 ` Jon Masters @ 2016-12-06 0:31 ` Duc Dang 2016-12-06 2:27 ` Jon Masters 2 siblings, 1 reply; 16+ messages in thread From: Duc Dang @ 2016-12-06 0:31 UTC (permalink / raw) To: Jon Masters Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown On Mon, Dec 5, 2016 at 3:52 PM, Duc Dang <dhdang@apm.com> wrote: > Hi Jon, > > On Mon, Dec 5, 2016 at 3:27 PM, Jon Masters <jcm@redhat.com> wrote: >> Duc, Aleksey, all, >> >> I have a question about this... >> >> On 12/05/2016 01:51 PM, Duc Dang wrote: >>> On Mon, Dec 5, 2016 at 5:05 AM, Aleksey Makarov >>> <aleksey.makarov@linaro.org> wrote: >>>> Check the 'Register Bit Width' field of the ACPI Generic Address >>>> Structure that specifies the address of the UART registers to >>>> decide if the driver should use "mmio32" access instead of "mmio". >>>> >>>> If the driver is other than 16550 the access with is defined >>>> by the Interface Type field of the SPCR table. >> >> I have two questions about this: >> >> 1). Why is this not a full 16550 (ACPI_DBG2_16550_COMPATIBLE)? >> >> 2). Why is it a ACPI_DBG2_16550_SUBSET you are assuming here? > > The patch is actually applied for both ACPI_DBG2_16550_COMPATIBLE and > ACPI_DBG2_16500_SUBSET. Or I misunderstood your question? The end > result after applying the patch on linux-next is like this: > switch (table->interface_type) { > case ACPI_DBG2_ARM_SBSA_32BIT: > iotype = "mmio32"; > /* fall through */ > case ACPI_DBG2_ARM_PL011: > case ACPI_DBG2_ARM_SBSA_GENERIC: > case ACPI_DBG2_BCM2835: > uart = "pl011"; > break; > case ACPI_DBG2_16550_COMPATIBLE: > case ACPI_DBG2_16550_SUBSET: > if (table->serial_port.space_id == > ACPI_ADR_SPACE_SYSTEM_MEMORY && > table->serial_port.bit_width == 32) > iotype = "mmio32"; > uart = "uart"; > break; > default: > err = -ENOENT; > goto done; > } > >> >> The SPCR and DBG2 spec clearly state that the _SUBSET is intended >> to represent a UART compatible with the earlier DGBP specification, >> not that a UART is a "subset" of a full 16550 (which seems to be >> the assumption in this patch). It's important we get this right. >> >> I built a test kernel with this patch and updated ACPI tables earlier, >> but it didn't boot with a console because I had left it a subtype 0, >> but just changed the width to 32 bit, which is what I expected. > > On Mustang 3.06.25 firmware, DBG2 table has 'Port Type = 0x8000', > 'Port subtype = 0x0001' To clarify, for SPCR table, this is what we have on Mustang: [0004] Signature : "SPCR" [Serial Port Console Redirection table] [0004] Table Length : 00000050 [0001] Revision : 02 [0001] Checksum : 62 [0006] Oem ID : "APMC0D" [0008] Oem Table ID : "XGENESPC" [0004] Oem Revision : 00000000 [0004] Asl Compiler ID : "INTL" [0004] Asl Compiler Revision : 20141107 [0001] Interface Type : 00 [0003] Reserved : 000000 [0012] Serial Port Register : [Generic Address Structure] [0001] Space ID : 00 [SystemMemory] [0001] Bit Width : 20 [0001] Bit Offset : 00 [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 000000001c020000 [0001] Interrupt Type : 08 [0001] PCAT-compatible IRQ : 00 [0004] Interrupt : 0000006C [0001] Baud Rate : 07 [0001] Parity : 00 [0001] Stop Bits : 01 [0001] Flow Control : 00 [0001] Terminal Type : 00 [0001] Reserved : 00 [0002] PCI Device ID : FFFF [0002] PCI Vendor ID : FFFF [0001] PCI Bus : 00 [0001] PCI Device : 00 [0001] PCI Function : 00 [0004] PCI Flags : 00000000 [0001] PCI Segment : 00 [0004] Reserved : 00000000 So the "Interface Type" is also set to 00. > > But I am still curious why setting subtype to '0' does not work on > your board. Are you using Mustang or m400? >> >> Further, I've heard back from Microsoft and they're looking at >> adding a specific subtype for this. If they do, I'm inclined to >> address existing designs with your patch (but I would favor this >> check because against the full 16550) and then switch newer APM >> based designs to the new subtype. > > Yes, we will look out for the new subtype information. > >> >> Jon. >> >> -- >> Computer Architect | Sent from my Fedora powered laptop >> > Regards, > Duc Dang. Regards, Duc Dang. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 0:31 ` Duc Dang @ 2016-12-06 2:27 ` Jon Masters 2016-12-06 3:55 ` Duc Dang 0 siblings, 1 reply; 16+ messages in thread From: Jon Masters @ 2016-12-06 2:27 UTC (permalink / raw) To: Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown [-- Attachment #1: Type: text/plain, Size: 3600 bytes --] Hi Duc, all, So after regenerating the initrd override (I must have fat fingered) it is now detecting the correct bit width on boot (attached dmesg log). HOWEVER while the console does come up, the use of "earlycon" on the command line (with no parameters) doesn't result in the early SPCR console coming up correctly. I see some garbled characters that suggest the baud (or register access width) is off somewhere. Here are the first few lines from my screen boot log: EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... ^E^B^B^B<8A>r<A2><92><A2><92>ʺ<EA><81>console [ttyS0] enabled [ 1.424297] console [ttyS0] enabled [ 1.507860] bootconsole [uart0] disabled Can you double check you've actually seen the SPCR used for earlycon, as the machine was booting, and actually generating correct output? Here's the SPCR override I am using on that machine: /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20160527-64 * Copyright (c) 2000 - 2016 Intel Corporation * * Disassembly of SPCR.aml, Sat Dec 3 03:49:54 2016 * * ACPI Data Table [SPCR] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "SPCR" [Serial Port Console Redirection table] [004h 0004 4] Table Length : 00000050 [008h 0008 1] Revision : 02 [009h 0009 1] Checksum : 41 [00Ah 0010 6] Oem ID : "HPE " [010h 0016 8] Oem Table ID : "ProLiant" [018h 0024 4] Oem Revision : 00001337 [01Ch 0028 4] Asl Compiler ID : "INTL" [020h 0032 4] Asl Compiler Revision : 20160527 [024h 0036 1] Interface Type : 00 [025h 0037 3] Reserved : 000000 [028h 0040 12] Serial Port Register : [Generic Address Structure] [028h 0040 1] Space ID : 00 [SystemMemory] [029h 0041 1] Bit Width : 20 [02Ah 0042 1] Bit Offset : 00 [02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy] [02Ch 0044 8] Address : 000000001C021000 [034h 0052 1] Interrupt Type : 08 [035h 0053 1] PCAT-compatible IRQ : 00 [036h 0054 4] Interrupt : 0000006D [03Ah 0058 1] Baud Rate : 03 [03Bh 0059 1] Parity : 00 [03Ch 0060 1] Stop Bits : 01 [03Dh 0061 1] Flow Control : 02 [03Eh 0062 1] Terminal Type : 01 [04Ch 0076 1] Reserved : 00 [040h 0064 2] PCI Device ID : FFFF [042h 0066 2] PCI Vendor ID : FFFF [044h 0068 1] PCI Bus : 00 [045h 0069 1] PCI Device : 00 [046h 0070 1] PCI Function : 00 [047h 0071 4] PCI Flags : 00000000 [04Bh 0075 1] PCI Segment : 00 [04Ch 0076 4] Reserved : 00000000 Raw Table Data: Length 80 (0x50) 0000: 53 50 43 52 50 00 00 00 02 41 48 50 45 4A 43 4D // SPCRP....AHPEJCM 0010: 50 72 6F 4C 69 61 6E 74 01 00 00 00 49 4E 54 4C // ProLiant....INTL 0020: 27 05 16 20 0D 00 00 00 00 08 00 00 00 10 02 1C // '.. ............ 0030: 00 00 00 00 08 00 6D 00 00 00 03 00 01 02 01 00 // ......m......... 0040: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 // ................ Jon. -- Computer Architect | Sent from my Fedora powered laptop [-- Attachment #2: dmesg-4.9.0-rc7.ecam_jcm2+-m400-spcr-works.txt --] [-- Type: text/plain, Size: 29464 bytes --] [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.9.0-rc7.ecam_jcm2+ (root@hp-moonshot-02-c08.khw.lab.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #2 SMP Mon Dec 5 14:27:33 EST 2016 [ 0.000000] Boot CPU: AArch64 Processor [500f0001] [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: EFI v2.60 by HPE [ 0.000000] efi: ACPI 2.0=0x4ff8000000 SMBIOS 3.0=0x4ff7a90000 MEMATTR=0x4ff23fe018 [ 0.000000] cma: Reserved 512 MiB at 0x00000040e0000000 [ 0.000000] ACPI: SPCR ACPI table found in initrd [kernel/firmware/acpi/spcr.aml][0x50] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x0000004FF8000000 000024 (v02 HP ) [ 0.000000] ACPI: XSDT 0x0000004FF7FF0000 000084 (v01 HP ProLiant 00000001 01000013) [ 0.000000] ACPI: FACP 0x0000004FF7FB0000 000114 (v06 HPE ProLiant 00000001 HP 00000001) [ 0.000000] ACPI: DSDT 0x0000004FF7F80000 0023CA (v05 HPE DSDT 00000001 INTL 20160527) [ 0.000000] ACPI: SSDT 0x0000004FF7FE0000 000032 (v02 HPE UARTCLKS 00000001 01000013) [ 0.000000] ACPI: BERT 0x0000004FF7FD0000 000030 (v01 HPE ProLiant 00000002 INTL 20160527) [ 0.000000] ACPI: HEST 0x0000004FF7FC0000 0002A8 (v01 HPE ProLiant 00000002 INTL 20160527) [ 0.000000] ACPI: DBG2 0x0000004FF7FA0000 0000A8 (v00 HPE ProLiant 00000000 INTL 20160527) [ 0.000000] ACPI: GTDT 0x0000004FF7F90000 0000E0 (v02 HPE ProLiant 00000001 INTL 20160527) [ 0.000000] ACPI: APIC 0x0000004FF7F70000 0002C4 (v03 HPE ProLiant 00000001 HP 00000001) [ 0.000000] ACPI: MCFG 0x0000004FF7F60000 00003C (v01 APM XGENE 00000001 HP 00000001) [ 0.000000] ACPI: SPMI 0x0000004FF7F50000 000041 (v05 HPE ProLiant 00000001 HP 00000001) [ 0.000000] ACPI: RASF 0x0000004FF7F40000 000030 (v01 HPE ProLiant 00000001 HP 00000001) [ 0.000000] ACPI: Table Upgrade: override [SPCR-HPE -ProLiant] [ 0.000000] ACPI: SPCR 0x0000004FF7F30000 Physical table override, new table: 0x0000004FFFFF0000 [ 0.000000] ACPI: SPCR 0x0000004FFFFF0000 000050 (v02 HPE ProLiant 00001337 INTL 20160527) [ 0.000000] ACPI: SSDT 0x0000004FF7F20000 000313 (v02 HPE PCISSDT 00000002 HPAG 00020000) [ 0.000000] ACPI: SPCR: console: uart,mmio32,0x1c021000,9600 [ 0.000000] earlycon: uart0 at MMIO32 0x000000001c021000 (options '9600') [ 0.000000] bootconsole [uart0] enabled [ 0.000000] ACPI: NUMA: Failed to initialise from firmware [ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x0000004fffffffff] [ 0.000000] NUMA: Adding memblock [0x4000000000 - 0x4001ffffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x40023a0000 - 0x4ff733ffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff7340000 - 0x4ff77cffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff77d0000 - 0x4ff79cffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff79d0000 - 0x4ff7e7ffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff7e80000 - 0x4ff7e8ffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff7e90000 - 0x4ff7efffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff7f10000 - 0x4ff800ffff] on node 0 [ 0.000000] NUMA: Adding memblock [0x4ff8010000 - 0x4fffffffff] on node 0 [ 0.000000] NUMA: Initmem setup node 0 [mem 0x4000000000-0x4fffffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x4fffff2680-0x4fffffffff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000004000000000-0x00000040ffffffff] [ 0.000000] Normal [mem 0x0000004100000000-0x0000004fffffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000004000000000-0x0000004001ffffff] [ 0.000000] node 0: [mem 0x00000040023a0000-0x0000004ff733ffff] [ 0.000000] node 0: [mem 0x0000004ff7340000-0x0000004ff77cffff] [ 0.000000] node 0: [mem 0x0000004ff77d0000-0x0000004ff79cffff] [ 0.000000] node 0: [mem 0x0000004ff79d0000-0x0000004ff7e7ffff] [ 0.000000] node 0: [mem 0x0000004ff7e80000-0x0000004ff7e8ffff] [ 0.000000] node 0: [mem 0x0000004ff7e90000-0x0000004ff7efffff] [ 0.000000] node 0: [mem 0x0000004ff7f10000-0x0000004ff800ffff] [ 0.000000] node 0: [mem 0x0000004ff8010000-0x0000004fffffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000004000000000-0x0000004fffffffff] [ 0.000000] On node 0 totalpages: 1048517 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 65478 pages, LIFO batch:1 [ 0.000000] Normal zone: 960 pages used for memmap [ 0.000000] Normal zone: 983039 pages, LIFO batch:1 [ 0.000000] psci: is not implemented in ACPI. [ 0.000000] percpu: Embedded 3 pages/cpu @fffffe0fffdd0000 s117504 r8192 d70912 u196608 [ 0.000000] pcpu-alloc: s117504 r8192 d70912 u196608 alloc=3*65536 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [ 0.000000] Detected PIPT I-cache on CPU0 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1047493 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-rc7.ecam_jcm2+ root=/dev/mapper/rhel_hp--moonshot--02--c08-root ro crashkernel=auto rd.lvm.lv=rhel_hp-moonshot-02-c08/root rd.lvm.lv=rhel_hp-moonshot-02-c08/swap LANG=en_US.UTF-8 earlycon acpi=on [ 0.000000] PID hash table entries: 4096 (order: -1, 32768 bytes) [ 0.000000] software IO TLB [mem 0x40dbff0000-0x40dfff0000] (64MB) mapped at [fffffe00dbff0000-fffffe00dffeffff] [ 0.000000] Memory: 66378880K/67105088K available (8252K kernel code, 1588K rwdata, 3712K rodata, 1472K init, 6969K bss, 201920K reserved, 524288K cma-reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] modules : 0xfffffc0000000000 - 0xfffffc0008000000 ( 128 MB) [ 0.000000] vmalloc : 0xfffffc0008000000 - 0xfffffdff5fff0000 ( 2045 GB) [ 0.000000] .text : 0xfffffc0008080000 - 0xfffffc0008890000 ( 8256 KB) [ 0.000000] .rodata : 0xfffffc0008890000 - 0xfffffc0008c40000 ( 3776 KB) [ 0.000000] .init : 0xfffffc0008c40000 - 0xfffffc0008db0000 ( 1472 KB) [ 0.000000] .data : 0xfffffc0008db0000 - 0xfffffc0008f3d200 ( 1589 KB) [ 0.000000] .bss : 0xfffffc0008f3d200 - 0xfffffc000960b640 ( 6970 KB) [ 0.000000] fixed : 0xfffffdff7e7d0000 - 0xfffffdff7ec00000 ( 4288 KB) [ 0.000000] PCI I/O : 0xfffffdff7ee00000 - 0xfffffdff7fe00000 ( 16 MB) [ 0.000000] vmemmap : 0xfffffdff80000000 - 0xfffffe0000000000 ( 2 GB maximum) [ 0.000000] 0xfffffdff80000000 - 0xfffffdff84000000 ( 64 MB actual) [ 0.000000] memory : 0xfffffe0000000000 - 0xfffffe1000000000 ( 65536 MB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 64. [ 0.000000] RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=8. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=8 [ 0.000000] NR_IRQS:64 nr_irqs:64 0 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] arm_arch_timer: Architected cp15 timer(s) running at 50.00MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns [ 0.000002] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns [ 0.003981] Console: colour dummy device 80x25 [ 0.006216] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=50000) [ 0.011276] pid_max: default: 32768 minimum: 301 [ 0.013629] ACPI: Core revision 20160831 [ 0.017684] ACPI: 3 ACPI AML tables successfully acquired and loaded [ 0.020906] Security Framework initialized [ 0.022907] Yama: becoming mindful. [ 0.024615] SELinux: Initializing. [ 0.026555] SELinux: Starting in permissive mode [ 0.027295] Dentry cache hash table entries: 8388608 (order: 10, 67108864 bytes) [ 0.041804] Inode-cache hash table entries: 4194304 (order: 9, 33554432 bytes) [ 0.050630] Mount-cache hash table entries: 131072 (order: 4, 1048576 bytes) [ 0.054084] Mountpoint-cache hash table entries: 131072 (order: 4, 1048576 bytes) [ 0.058491] ftrace: allocating 30406 entries in 8 pages [ 0.085825] ASID allocator initialised with 65536 entries [ 0.089388] Remapping and enabling EFI services. [ 0.091670] EFI remap 0x0000000010510000 => 0000000020000000 [ 0.094517] EFI remap 0x0000000010548000 => 0000000020018000 [ 0.097363] EFI remap 0x0000000017000000 => 0000000020020000 [ 0.100209] EFI remap 0x000000001c024000 => 0000000020034000 [ 0.103055] EFI remap 0x000000001f2a0000 => 0000000020040000 [ 0.105901] EFI remap 0x0000004002310000 => 0000000020050000 [ 0.108747] EFI remap 0x0000004ff7340000 => 00000000200b0000 [ 0.111591] EFI remap 0x0000004ff79d0000 => 0000000020540000 [ 0.114806] Detected PIPT I-cache on CPU1 [ 0.114836] CPU1: Booted secondary processor [500f0001] [ 0.115059] Detected PIPT I-cache on CPU2 [ 0.115080] CPU2: Booted secondary processor [500f0001] [ 0.115308] Detected PIPT I-cache on CPU3 [ 0.115322] CPU3: Booted secondary processor [500f0001] [ 0.115541] Detected PIPT I-cache on CPU4 [ 0.115562] CPU4: Booted secondary processor [500f0001] [ 0.115769] Detected PIPT I-cache on CPU5 [ 0.115782] CPU5: Booted secondary processor [500f0001] [ 0.115992] Detected PIPT I-cache on CPU6 [ 0.116013] CPU6: Booted secondary processor [500f0001] [ 0.116226] Detected PIPT I-cache on CPU7 [ 0.116239] CPU7: Booted secondary processor [500f0001] [ 0.116279] Brought up 8 CPUs [ 0.149233] SMP: Total of 8 processors activated. [ 0.151529] CPU features: detected feature: 32-bit EL0 Support [ 0.154376] CPU: All CPU(s) started at EL2 [ 0.157238] devtmpfs: initialized [ 0.159264] SMBIOS 3.0.0 present. [ 0.160999] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns [ 0.166217] atomic64_test: passed [ 0.167867] pinctrl core: initialized pinctrl subsystem [ 0.170808] NET: Registered protocol family 16 [ 0.177003] cpuidle: using governor menu [ 0.178924] PCCT header not found. [ 0.180630] vdso: 2 pages (1 code @ fffffc00088b0000, 1 data @ fffffc0008dd0000) [ 0.184242] hw-breakpoint: found 4 breakpoint and 4 watchpoint registers. [ 0.187955] DMA: preallocated 256 KiB pool for atomic allocations [ 0.190960] ACPI: bus type PCI registered [ 0.192919] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.196146] Serial: AMBA PL011 UART driver [ 0.204385] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.207495] HugeTLB registered 512 MB page size, pre-allocated 0 pages [ 0.211231] ACPI: Added _OSI(Module Device) [ 0.213278] ACPI: Added _OSI(Processor Device) [ 0.215447] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.217742] ACPI: Added _OSI(Processor Aggregator Device) [ 0.220411] ACPI: Executed 1 blocks of module-level executable AML code [ 0.227385] ACPI: Interpreter enabled [ 0.229180] ACPI: Using GIC for interrupt routing [ 0.231497] ACPI: MCFG table detected, 1 entries [ 0.236345] ACPI: Power Resource [SCVR] (off) [ 0.242061] ACPI: PCI Root Bridge [PCI3] (domain 0000 [bus 00-ff]) [ 0.245102] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 0.249284] acpi PNP0A08:00: _OSC: platform does not support [AER] [ 0.252462] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability] [ 0.256225] acpi PNP0A08:00: MCFG quirk: ECAM at [mem 0xa0d0000000-0xa0dfffffff] for [bus 00-ff] with xgene_v1_pcie_ecam_ops [ 0.262133] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0xa0d0000000-0xa0dfffffff] not reserved in ACPI namespace [ 0.267345] acpi PNP0A08:00: ECAM at [mem 0xa0d0000000-0xa0dfffffff] for [bus 00-ff] [ 0.271145] Remapped I/O 0x000000a100010000 to [io 0x0000-0xffff window] [ 0.274555] PCI host bridge to bus 0000:00 [ 0.276560] pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] (bus address [0x10000-0x1ffff]) [ 0.281230] pci_bus 0000:00: root bus resource [mem 0xa020000000-0xa03fffffff window] (bus address [0x20000000-0x3fffffff]) [ 0.286662] pci_bus 0000:00: root bus resource [mem 0xa060000000-0xa07fffffff window] (bus address [0x40000000-0x5fffffff]) [ 0.292094] pci_bus 0000:00: root bus resource [mem 0xa110000000-0xa14fffffff window] [ 0.295915] pci_bus 0000:00: root bus resource [bus 00-ff] [ 0.298606] pci 0000:00:00.0: [10e8:e004] type 01 class 0x060400 [ 0.298677] pci 0000:00:00.0: supports D1 D2 [ 0.299017] pci 0000:01:00.0: [15b3:1007] type 00 class 0x020000 [ 0.299340] pci 0000:01:00.0: reg 0x10: [mem 0xa020000000-0xa0200fffff 64bit] [ 0.299575] pci 0000:01:00.0: reg 0x18: [mem 0xa122000000-0xa123ffffff 64bit pref] [ 0.300007] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x000fffff pref] [ 0.301725] pci 0000:01:00.0: reg 0x134: [mem 0xa112000000-0xa113ffffff 64bit pref] [ 0.301728] pci 0000:01:00.0: VF(n) BAR2 space: [mem 0xa112000000-0xa121ffffff 64bit pref] (contains BAR2 for 8 VFs) [ 0.310980] pci_bus 0000:00: on NUMA node 0 [ 0.311001] pci 0000:00:00.0: BAR 15: assigned [mem 0xa110000000-0xa121ffffff 64bit pref] [ 0.314994] pci 0000:00:00.0: BAR 14: assigned [mem 0xa020000000-0xa0201fffff] [ 0.318523] pci 0000:01:00.0: BAR 2: assigned [mem 0xa110000000-0xa111ffffff 64bit pref] [ 0.322618] pci 0000:01:00.0: BAR 9: assigned [mem 0xa112000000-0xa121ffffff 64bit pref] [ 0.326714] pci 0000:01:00.0: BAR 0: assigned [mem 0xa020000000-0xa0200fffff 64bit] [ 0.330600] pci 0000:01:00.0: BAR 6: assigned [mem 0xa020100000-0xa0201fffff pref] [ 0.334296] pci 0000:00:00.0: PCI bridge to [bus 01] [ 0.336722] pci 0000:00:00.0: bridge window [mem 0xa020000000-0xa0201fffff] [ 0.340206] pci 0000:00:00.0: bridge window [mem 0xa110000000-0xa121ffffff 64bit pref] [ 0.344582] vgaarb: loaded [ 0.346136] SCSI subsystem initialized [ 0.348061] libata version 3.00 loaded. [ 0.348110] ACPI: bus type USB registered [ 0.350108] usbcore: registered new interface driver usbfs [ 0.352803] usbcore: registered new interface driver hub [ 0.355433] usbcore: registered new device driver usb [ 0.357929] pps_core: LinuxPPS API ver. 1 registered [ 0.360352] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 0.364814] PTP clock support registered [ 0.366839] Registered efivars operations [ 0.369532] NetLabel: Initializing [ 0.371200] NetLabel: domain hash size = 128 [ 0.373324] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.375768] NetLabel: unlabeled traffic allowed by default [ 0.378634] clocksource: Switched to clocksource arch_sys_counter [ 0.397897] VFS: Disk quotas dquot_6.6.0 [ 0.399882] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) [ 0.403578] pnp: PnP ACPI init [ 0.405431] pnp: PnP ACPI: found 0 devices [ 0.410892] NET: Registered protocol family 2 [ 0.413388] TCP established hash table entries: 524288 (order: 6, 4194304 bytes) [ 0.418344] TCP bind hash table entries: 65536 (order: 4, 1048576 bytes) [ 0.421984] TCP: Hash tables configured (established 524288 bind 65536) [ 0.425267] UDP hash table entries: 32768 (order: 4, 1048576 bytes) [ 0.428876] UDP-Lite hash table entries: 32768 (order: 4, 1048576 bytes) [ 0.432814] NET: Registered protocol family 1 [ 0.434982] PCI: CLS 64 bytes, default 128 [ 0.435088] Unpacking initramfs... [ 1.174825] Freeing initrd memory: 34496K (fffffe0f840f0000 - fffffe0f862a0000) [ 1.178611] kvm [1]: 8-bit VMID [ 1.180155] kvm [1]: IDMAP page: 4000884000 [ 1.182220] kvm [1]: HYP VA range: 20000000000:3ffffffffff [ 1.184993] kvm [1]: Hyp mode initialized successfully [ 1.187523] kvm [1]: GICV region size/alignment is unsafe, using trapping (reduced performance) [ 1.191788] kvm [1]: vgic-v2@780cf000 [ 1.193680] kvm [1]: vgic interrupt IRQ1 [ 1.195628] kvm [1]: virtual timer IRQ4 [ 1.197948] alg: No test for __ecb-aes-neon (__driver-ecb-aes-neon) [ 1.205081] alg: No test for __ecb-aes-neon (cryptd(__driver-ecb-aes-neon)) [ 1.209671] futex hash table entries: 2048 (order: 2, 262144 bytes) [ 1.212795] audit: initializing netlink subsys (disabled) [ 1.215486] audit: type=2000 audit(0.994:1): initialized [ 1.218263] Initialise system trusted keyrings [ 1.220588] workingset: timestamp_bits=37 max_order=20 bucket_order=0 [ 1.227179] zbud: loaded [ 1.229870] SELinux: Registering netfilter hooks [ 1.307511] alg: drbg: Test 0 failed for drbg_pr_ctr_aes128 [ 1.314332] alg: drbg: Test 0 failed for drbg_nopr_ctr_aes128 [ 1.317226] alg: drbg: Test 0 failed for drbg_nopr_ctr_aes192 [ 1.320114] alg: drbg: Test 0 failed for drbg_nopr_ctr_aes256 [ 1.323889] NET: Registered protocol family 38 [ 1.326065] Key type asymmetric registered [ 1.328068] Asymmetric key parser 'x509' registered [ 1.330502] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) [ 1.334172] io scheduler noop registered [ 1.336097] io scheduler deadline registered (default) [ 1.338641] io scheduler cfq registered [ 1.341021] xgene-gpio APMC0D14:00: X-Gene GPIO driver registered. [ 1.344119] pcieport 0000:00:00.0: can't derive routing for PCI INT A [ 1.347263] pcieport 0000:00:00.0: PCI INT A: no GSI [ 1.349839] pcie_pme: probe of 0000:00:00.0:pcie001 failed with error -22 [ 1.353168] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.355895] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 1.359295] acpi ACPI0007:00: CPPC data invalid or not present [ 1.362163] acpi ACPI0007:01: CPPC data invalid or not present [ 1.365025] acpi ACPI0007:02: CPPC data invalid or not present [ 1.367886] acpi ACPI0007:03: CPPC data invalid or not present [ 1.370747] acpi ACPI0007:04: CPPC data invalid or not present [ 1.373608] acpi ACPI0007:05: CPPC data invalid or not present [ 1.376468] acpi ACPI0007:06: CPPC data invalid or not present [ 1.379327] acpi ACPI0007:07: CPPC data invalid or not present [ 1.382692] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.419947] APMC0D08:00: ttyS0 at MMIO 0x1c021000 (irq = 23, base_baud = 3125000) is a U6_16550A [ 1.424257] console [ttyS0] enabled [ 1.507823] bootconsole [uart0] disabled [ 1.602024] msm_serial: driver initialized [ 1.651420] Failed to find cpu0 device node [ 1.701604] Unable to detect cache hierarchy from DT for CPU 0 [ 1.771776] hisi_sas: driver version v1.6 [ 1.820105] xgene-ahci APMC0D0D:00: skip clock and PHY initialization [ 1.897416] xgene-ahci APMC0D0D:00: controller can't do NCQ, turning off CAP_NCQ [ 1.986217] xgene-ahci APMC0D0D:00: AHCI 0001.0300 32 slots 2 ports 6 Gbps 0x3 impl platform mode [ 2.092730] xgene-ahci APMC0D0D:00: flags: 64bit sntf pm only pmp fbs pio slum part ccc [ 2.189861] xgene-ahci APMC0D0D:00: port 0 is not capable of FBS [ 2.262071] xgene-ahci APMC0D0D:00: port 1 is not capable of FBS [ 2.334670] scsi host0: xgene-ahci [ 2.375687] scsi host1: xgene-ahci [ 2.416569] ata1: SATA max UDMA/133 mmio [mem 0x1a800000-0x1a800fff] port 0x100 irq 24 [ 2.511608] ata2: SATA max UDMA/133 mmio [mem 0x1a800000-0x1a800fff] port 0x180 irq 24 [ 2.606787] libphy: Fixed MDIO Bus: probed [ 2.656122] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.734498] ehci-pci: EHCI PCI platform driver [ 2.787839] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.862022] ohci-pci: OHCI PCI platform driver [ 2.912755] ata2: SATA link down (SStatus 0 SControl 4300) [ 2.981166] uhci_hcd: USB Universal Host Controller Interface driver [ 3.057512] usbcore: registered new interface driver usbserial [ 3.127527] usbcore: registered new interface driver usbserial_generic [ 3.205885] usbserial: USB Serial support registered for generic [ 3.227642] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 4300) [ 3.227878] ata1.00: ATA-9: XR0120GEBLT, HPS4, max UDMA/133 [ 3.227880] ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32) [ 3.228096] ata1.00: configured for UDMA/133 [ 3.228413] scsi 0:0:0:0: Direct-Access ATA XR0120GEBLT HPS4 PQ: 0 ANSI: 5 [ 3.648943] mousedev: PS/2 mouse device common for all mice [ 3.716098] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0 [ 3.789459] device-mapper: uevent: version 1.0.3 [ 3.790937] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB) [ 3.790940] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 3.790966] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 3.791043] sd 0:0:0:0: [sda] Write Protect is off [ 3.791046] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 3.791077] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3.793587] sda: sda1 sda2 sda3 [ 3.794136] sd 0:0:0:0: [sda] Attached SCSI disk [ 4.322286] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-devel@redhat.com [ 4.424220] EFI Variables Facility v0.08 2004-May-17 [ 4.484877] hidraw: raw HID events driver (C) Jiri Kosina [ 4.549750] usbcore: registered new interface driver usbhid [ 4.616623] usbhid: USB HID core driver [ 4.662794] drop_monitor: Initializing network drop monitor service [ 4.738111] ip_tables: (C) 2000-2006 Netfilter Core Team [ 4.801877] Initializing XFRM netlink socket [ 4.853357] NET: Registered protocol family 10 [ 4.907124] mip6: Mobile IPv6 [ 4.942732] NET: Registered protocol family 17 [ 4.996370] registered taskstats version 1 [ 5.045555] Loading compiled-in X.509 certificates [ 5.106440] alg: No test for pkcs1pad(rsa,sha256) (pkcs1pad(rsa-generic,sha256)) [ 5.196694] Loaded X.509 cert 'Build time autogenerated kernel key: 77693cf6411eaf44ab625b1d7d0930f7f0e46073' [ 5.315787] zswap: loaded using pool lzo/zbud [ 5.388545] Key type big_key registered [ 5.434715] rtc-efi rtc-efi: setting system clock to 2016-12-06 02:19:40 UTC (1480990780) [ 5.532911] PM: Hibernation image not present or could not be loaded. [ 5.533113] Freeing unused kernel memory: 1472K (fffffe0000c40000 - fffffe0000db0000) [ 5.632739] random: systemd: uninitialized urandom read (16 bytes read) [ 5.712797] random: systemd: uninitialized urandom read (16 bytes read) [ 5.794155] systemd[1]: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN) [ 6.010535] systemd[1]: Detected architecture arm64. [ 6.070140] systemd[1]: Running in initial RAM disk. [ 6.239716] systemd[1]: Set hostname to <localhost.localdomain>. [ 6.355156] random: systemd: uninitialized urandom read (16 bytes read) [ 6.434605] random: systemd: uninitialized urandom read (16 bytes read) [ 6.514093] random: systemd: uninitialized urandom read (16 bytes read) [ 6.593596] random: systemd: uninitialized urandom read (16 bytes read) [ 6.674225] random: systemd: uninitialized urandom read (16 bytes read) [ 6.753902] random: systemd: uninitialized urandom read (16 bytes read) [ 6.833698] random: systemd: uninitialized urandom read (16 bytes read) [ 6.914164] random: systemd: uninitialized urandom read (16 bytes read) [ 7.042692] systemd[1]: Reached target Swap. [ 7.093948] systemd[1]: Starting Swap. [ 7.186678] systemd[1]: Created slice Root Slice. [ 7.243143] systemd[1]: Starting Root Slice. [ 7.345671] systemd[1]: Created slice System Slice. [ 7.404231] systemd[1]: Starting System Slice. [ 8.938879] mlx4_core: Mellanox ConnectX core driver v2.2-1 (Feb, 2014) [ 9.019600] mlx4_core: Initializing 0000:01:00.0 [ 15.550270] mlx4_core 0000:01:00.0: PCIe BW is different than device's capability [ 15.640098] mlx4_core 0000:01:00.0: PCIe link speed is 5.0GT/s, device supports 8.0GT/s [ 15.736190] mlx4_core 0000:01:00.0: PCIe link width is x8, device supports x8 [ 15.882999] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.2-1 (Feb 2014) [ 15.967853] mlx4_en 0000:01:00.0: Activating port:1 [ 16.029961] mlx4_en: 0000:01:00.0: Port 1: Using 64 TX rings [ 16.097883] mlx4_en: 0000:01:00.0: Port 1: Using 4 RX rings [ 16.164760] mlx4_en: 0000:01:00.0: Port 1: frag:0 - size:1522 prefix:0 stride:1536 [ 16.258065] mlx4_en: 0000:01:00.0: Port 1: Initializing port [ 16.326349] mlx4_en 0000:01:00.0: registered PHC clock [ 16.389365] mlx4_en 0000:01:00.0: Activating port:2 [ 16.452454] mlx4_en: 0000:01:00.0: Port 2: Using 64 TX rings [ 16.520376] mlx4_en: 0000:01:00.0: Port 2: Using 4 RX rings [ 16.587261] mlx4_en: 0000:01:00.0: Port 2: frag:0 - size:1522 prefix:0 stride:1536 [ 16.680480] mlx4_en: 0000:01:00.0: Port 2: Initializing port [ 16.753146] mlx4_core 0000:01:00.0 eno1d1: renamed from eth1 [ 16.836777] mlx4_core 0000:01:00.0 eno1: renamed from eth0 [ 17.055557] random: fast init done [ 17.574852] SGI XFS with ACLs, security attributes, no debug enabled [ 17.653835] XFS (dm-0): Mounting V5 Filesystem [ 17.823782] mlx4_en: eno1d1: Link Up [ 17.983396] XFS (dm-0): Ending clean mount [ 18.347323] systemd-journald[180]: Received SIGTERM from PID 1 (systemd). [ 18.365005] systemd: 20 output lines suppressed due to ratelimiting [ 18.391505] audit: type=1404 audit(1480990793.452:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 [ 18.848281] SELinux: 32768 avtab hash slots, 104865 rules. [ 18.881197] SELinux: 32768 avtab hash slots, 104865 rules. [ 18.960591] SELinux: 8 users, 14 roles, 4983 types, 301 bools, 1 sens, 1024 cats [ 18.960597] SELinux: 91 classes, 104865 rules [ 18.968800] SELinux: Permission validate_trans in class security not defined in policy. [ 19.113468] SELinux: Permission module_load in class system not defined in policy. [ 19.272181] SELinux: Class binder not defined in policy. [ 19.403441] SELinux: Class cap_userns not defined in policy. [ 19.539054] SELinux: Class cap2_userns not defined in policy. [ 19.675712] SELinux: the above unknown classes and permissions will be allowed [ 19.829076] SELinux: Completing initialization. [ 19.829077] SELinux: Setting up existing superblocks. [ 19.856737] audit: type=1403 audit(1480990794.921:3): policy loaded auid=4294967295 ses=4294967295 [ 20.007716] systemd[1]: Successfully loaded SELinux policy in 1.616305s. [ 20.166696] systemd[1]: RTC configured in localtime, applying delta of -300 minutes to system time. [ 20.376611] systemd[1]: Relabelled /dev and /run in 47.372ms. [ 20.673468] systemd-journald[566]: Received request to flush runtime journal from PID 1 [ 20.809453] RPC: Registered named UNIX socket transport module. [ 20.809455] RPC: Registered udp transport module. [ 20.809456] RPC: Registered tcp transport module. [ 20.809456] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 21.058899] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 21.610048] input: Power Button as /devices/LNXSYSTM:00/PNP0C0C:00/input/input0 [ 21.613434] xgene-slimpro-mbox APMC0D01:00: APM X-Gene SLIMpro MailBox registered [ 21.886503] ACPI: Power Button [PWRB] [ 21.889922] xgene-gpio-sb APMC0D15:00: Support 22 gpios, 6 irqs start from pin 8 [ 21.890221] xgene-gpio-sb APMC0D15:00: X-Gene GPIO Standby driver registered [ 21.890464] xgene-rng APMC0D18:00: Couldn't get the clock for RNG [ 21.890943] xgene-slimpro-i2c APMC0D40:00: i2c mailbox channel request failed [ 22.620698] Adding 11722688k swap on /dev/mapper/rhel_hp--moonshot--02--c08-swap. Priority:-1 extents:1 across:11722688k SSFS [ 22.623341] XFS (sda2): Mounting V5 Filesystem [ 22.673761] XFS (sda2): Ending clean mount [ 23.096976] XFS (dm-2): Mounting V5 Filesystem [ 23.183822] XFS (dm-2): Ending clean mount [ 23.284200] <mlx4_ib> mlx4_ib_add: mlx4_ib: Mellanox ConnectX InfiniBand driver v2.2-1 (Feb 2014) [ 23.442578] <mlx4_ib> mlx4_ib_add: counter index 2 for port 1 allocated 1 [ 23.590264] <mlx4_ib> mlx4_ib_add: counter index 3 for port 2 allocated 1 [ 23.824449] audit: type=1305 audit(1481008798.887:4): audit_pid=752 old=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1 [ 24.332140] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready [ 24.433128] mlx4_en: eno1: frag:0 - size:1522 prefix:0 stride:1536 [ 24.628498] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready [ 24.691182] Rounding down aligned max_sectors from 4294967295 to 4294967168 [ 24.863420] mlx4_en: eno1: Link Up [ 24.863506] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready [ 25.009606] IPv6: ADDRCONF(NETDEV_UP): eno1d1: link is not ready [ 25.035966] Loading iSCSI transport class v2.0-870. [ 25.077780] iscsi: registered transport (iser) [ 25.321485] RPC: Registered rdma transport module. [ 25.321487] RPC: Registered rdma backchannel transport module. [ 25.650039] mlx4_en: eno1d1: frag:0 - size:1522 prefix:0 stride:1536 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 2:27 ` Jon Masters @ 2016-12-06 3:55 ` Duc Dang 2016-12-06 6:34 ` Jon Masters 0 siblings, 1 reply; 16+ messages in thread From: Duc Dang @ 2016-12-06 3:55 UTC (permalink / raw) To: Jon Masters Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: > Hi Duc, all, > > So after regenerating the initrd override (I must have fat fingered) > it is now detecting the correct bit width on boot (attached dmesg log). > > HOWEVER while the console does come up, the use of "earlycon" on the > command line (with no parameters) doesn't result in the early SPCR > console coming up correctly. I see some garbled characters that > suggest the baud (or register access width) is off somewhere. My bad that I did not catch this in the morning. Yes, earlycon does not seems to work as expected. I can see that earlycon parameters seems to be correct, but the bootconsole message does not come out (the following is from 'dmesg') [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.9.0-rc7-next-20161202-00001-gbf2919a (dhdang@dhdang-workstation-01) (gcc version 4.9.3 20150218 (prerelease) (APM-8.0.10-le) ) #10 SMP PREEMPT Mon Dec 5 19:21:14 PST 2016 [ 0.000000] Boot CPU: AArch64 Processor [500f0001] [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: EFI v2.40 by X-Gene Mustang Board EFI Oct 17 2016 13:54:05 [ 0.000000] efi: ACPI=0x47fa700000 ACPI 2.0=0x47fa700014 SMBIOS 3.0=0x47fa9db000 ESRT=0x47ff006d18 [ 0.000000] esrt: Reserving ESRT space from 0x00000047ff006d18 to 0x00000047ff006d78. [ 0.000000] cma: Reserved 16 MiB at 0x00000040ff000000 [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000047FA700014 000024 (v02 APM ) [ 0.000000] ACPI: XSDT 0x00000047FA6F00E8 000084 (v01 APM XGENE 00000003 01000013) [ 0.000000] ACPI: FACP 0x00000047FA6C0000 00010C (v05 APM XGENE 00000003 INTL 20140724) [ 0.000000] ACPI: DSDT 0x00000047FA6D0000 005922 (v05 APM APM88xxx 00000001 INTL 20140724) [ 0.000000] ACPI: DBG2 0x00000047FA6E0000 0000AA (v00 APMC0D XGENEDBG 00000000 INTL 20140724) [ 0.000000] ACPI: GTDT 0x00000047FA6A0000 000060 (v02 APM XGENE 00000001 INTL 20140724) [ 0.000000] ACPI: MCFG 0x00000047FA690000 00003C (v01 APM XGENE 00000002 INTL 20140724) [ 0.000000] ACPI: SPCR 0x00000047FA680000 000050 (v02 APMC0D XGENESPC 00000000 INTL 20140724) [ 0.000000] ACPI: SSDT 0x00000047FA670000 00002D (v02 APM XGENE 00000001 INTL 20140724) [ 0.000000] ACPI: BERT 0x00000047FA660000 000030 (v01 APM XGENE 00000002 INTL 20140724) [ 0.000000] ACPI: HEST 0x00000047FA650000 0002A8 (v01 APM XGENE 00000002 INTL 20140724) [ 0.000000] ACPI: APIC 0x00000047FA640000 0002A4 (v03 APM XGENE 00000003 01000013) [ 0.000000] ACPI: SSDT 0x00000047FA630000 000063 (v02 REDHAT MACADDRS 00000001 01000013) [ 0.000000] ACPI: SSDT 0x00000047FA620000 000032 (v02 REDHAT UARTCLKS 00000001 01000013) [ 0.000000] ACPI: PCCT 0x00000047FA610000 000300 (v01 APM XGENE 00000003 01000013) [ 0.000000] ACPI: SPCR: console: uart,mmio32,0x1c020000,115200 [ 0.000000] earlycon: uart0 at MMIO32 0x000000001c020000 (options '115200') [ 0.000000] bootconsole [uart0] enabled > > Here are the first few lines from my screen boot log: > > EFI stub: Using DTB from configuration table > EFI stub: Exiting boot services and installing virtual address map... > ^E^B^B^B<8A>r<A2><92><A2><92>ʺ<EA><81>console [ttyS0] enabled I do not see garbage characters on Mustang. The garbage characters you saw may relate to the same issue that I asked a few weeks ago: https://www.spinics.net/lists/arm-kernel/msg537958.html There seems to be a race condition in accessing the UART hardware during switching between the bootconsole and the real console. > [ 1.424297] console [ttyS0] enabled > [ 1.507860] bootconsole [uart0] disabled > > Can you double check you've actually seen the SPCR used for earlycon, > as the machine was booting, and actually generating correct output? > > Here's the SPCR override I am using on that machine: > > /* > * Intel ACPI Component Architecture > * AML/ASL+ Disassembler version 20160527-64 > * Copyright (c) 2000 - 2016 Intel Corporation > * > * Disassembly of SPCR.aml, Sat Dec 3 03:49:54 2016 > * > * ACPI Data Table [SPCR] > * > * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue > */ > > [000h 0000 4] Signature : "SPCR" [Serial Port Console Redirection table] > [004h 0004 4] Table Length : 00000050 > [008h 0008 1] Revision : 02 > [009h 0009 1] Checksum : 41 > [00Ah 0010 6] Oem ID : "HPE " > [010h 0016 8] Oem Table ID : "ProLiant" > [018h 0024 4] Oem Revision : 00001337 > [01Ch 0028 4] Asl Compiler ID : "INTL" > [020h 0032 4] Asl Compiler Revision : 20160527 > > [024h 0036 1] Interface Type : 00 > [025h 0037 3] Reserved : 000000 > > [028h 0040 12] Serial Port Register : [Generic Address Structure] > [028h 0040 1] Space ID : 00 [SystemMemory] > [029h 0041 1] Bit Width : 20 > [02Ah 0042 1] Bit Offset : 00 > [02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy] > [02Ch 0044 8] Address : 000000001C021000 > > [034h 0052 1] Interrupt Type : 08 > [035h 0053 1] PCAT-compatible IRQ : 00 > [036h 0054 4] Interrupt : 0000006D > [03Ah 0058 1] Baud Rate : 03 > [03Bh 0059 1] Parity : 00 > [03Ch 0060 1] Stop Bits : 01 > [03Dh 0061 1] Flow Control : 02 > [03Eh 0062 1] Terminal Type : 01 > [04Ch 0076 1] Reserved : 00 > [040h 0064 2] PCI Device ID : FFFF > [042h 0066 2] PCI Vendor ID : FFFF > [044h 0068 1] PCI Bus : 00 > [045h 0069 1] PCI Device : 00 > [046h 0070 1] PCI Function : 00 > [047h 0071 4] PCI Flags : 00000000 > [04Bh 0075 1] PCI Segment : 00 > [04Ch 0076 4] Reserved : 00000000 > > Raw Table Data: Length 80 (0x50) > > 0000: 53 50 43 52 50 00 00 00 02 41 48 50 45 4A 43 4D // SPCRP....AHPEJCM > 0010: 50 72 6F 4C 69 61 6E 74 01 00 00 00 49 4E 54 4C // ProLiant....INTL > 0020: 27 05 16 20 0D 00 00 00 00 08 00 00 00 10 02 1C // '.. ............ > 0030: 00 00 00 00 08 00 6D 00 00 00 03 00 01 02 01 00 // ......m......... > 0040: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 // ................ > > Jon. > > -- > Computer Architect | Sent from my Fedora powered laptop > Regards, Duc Dang. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 3:55 ` Duc Dang @ 2016-12-06 6:34 ` Jon Masters 2016-12-06 6:53 ` Jon Masters 2016-12-07 15:23 ` Mark Salter 0 siblings, 2 replies; 16+ messages in thread From: Jon Masters @ 2016-12-06 6:34 UTC (permalink / raw) To: Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown On 12/05/2016 10:55 PM, Duc Dang wrote: > On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: >> Hi Duc, all, >> >> So after regenerating the initrd override (I must have fat fingered) >> it is now detecting the correct bit width on boot (attached dmesg log). >> >> HOWEVER while the console does come up, the use of "earlycon" on the >> command line (with no parameters) doesn't result in the early SPCR >> console coming up correctly. I see some garbled characters that >> suggest the baud (or register access width) is off somewhere. > > My bad that I did not catch this in the morning. Yes, earlycon does > not seems to work as expected. I can see that earlycon parameters > seems to be correct, but the bootconsole message does not come out > (the following is from 'dmesg') > [ 0.000000] ACPI: SPCR: console: uart,mmio32,0x1c020000,115200 > [ 0.000000] earlycon: uart0 at MMIO32 0x000000001c020000 (options '115200') > [ 0.000000] bootconsole [uart0] enabled The difference appears to be in the baud rate. When I explicitly specify "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we both know that the base clock on the X-Gene UART is weird. Maybe somehow we can explain this through the lack of setting a baud. I am pondering some more currently. If it's X-Gene specific, let's add that to the quirk (and to perhaps a more APM specific SPCR subtype). Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 6:34 ` Jon Masters @ 2016-12-06 6:53 ` Jon Masters 2016-12-06 7:13 ` Jon Masters 2016-12-07 15:23 ` Mark Salter 1 sibling, 1 reply; 16+ messages in thread From: Jon Masters @ 2016-12-06 6:53 UTC (permalink / raw) To: Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown On 12/06/2016 01:34 AM, Jon Masters wrote: > On 12/05/2016 10:55 PM, Duc Dang wrote: >> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: >>> Hi Duc, all, >>> >>> So after regenerating the initrd override (I must have fat fingered) >>> it is now detecting the correct bit width on boot (attached dmesg log). >>> >>> HOWEVER while the console does come up, the use of "earlycon" on the >>> command line (with no parameters) doesn't result in the early SPCR >>> console coming up correctly. I see some garbled characters that >>> suggest the baud (or register access width) is off somewhere. >> >> My bad that I did not catch this in the morning. Yes, earlycon does >> not seems to work as expected. I can see that earlycon parameters >> seems to be correct, but the bootconsole message does not come out >> (the following is from 'dmesg') > >> [ 0.000000] ACPI: SPCR: console: uart,mmio32,0x1c020000,115200 >> [ 0.000000] earlycon: uart0 at MMIO32 0x000000001c020000 (options '115200') >> [ 0.000000] bootconsole [uart0] enabled > > The difference appears to be in the baud rate. When I explicitly specify > "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with > the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we > both know that the base clock on the X-Gene UART is weird. Maybe > somehow we can explain this through the lack of setting a baud. > > I am pondering some more currently. If it's X-Gene specific, let's add > that to the quirk (and to perhaps a more APM specific SPCR subtype). Yeah, that's it. Here's the logic (8250_early.c): if (!device->baud) { struct uart_port *port = &device->port; unsigned int ier; /* assume the device was initialized, only mask interrupts */ ier = serial8250_early_in(port, UART_IER); serial8250_early_out(port, UART_IER, ier & UART_IER_UUE); } else init_port(device); If we have a baud set we will call init_port and go messing with the 8250 UART clock and so on. While if we don't have one set we'll assume whatever the firmware gave to us. We know the base clock frequency is different, which made me wonder how the full 8250_dw drive was working on your hardware...until I noticed the following ;) Here's a snippet of the DSDT on m400: Device (UAR0) { Name (_HID, "APMC0D08") // _HID: Hardware ID Name (_DDN, "UAR0") // _DDN: DOS Device Name Name (_UID, "UAR0") // _UID: Unique ID Name (_STR, Unicode ("APM88xxxx UART0 Controller")) // _STR: Descri ption String Name (_ADR, 0x1C021000) // _ADR: Address Name (_CID, "NS16550A") // _CID: Compatible ID ... Method (_DSD, 0, NotSerialized) // _DSD: Device-Specific Data { Local0 = Package (0x02) { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, Package (0x01) { Package (0x02) { "clock-frequency", Zero } } } DerefOf (DerefOf (Local0 [One]) [Zero]) [One] = UCLK /* External reference */ Return (Local0) } ...and here's what's sneakily in the first SSDT table: DefinitionBlock ("", "SSDT", 2, "HPE ", "UARTCLKS", 0x00000001) { Name (\UCLK, Package (0x01) { 0x02FAF080 }) } I suspect Mustang is doing similar. So you read the magic frequency info and pass this in through a DSD in the AML. It's ok, I've made my peace with this (but obviously we're trying to kill all DSD hacks), but it explains how this "works" after boot, but not for early console. To fix this, we're going to need to be able to know that your 8250 is both needful of 32-bit accesses *AND* needs a different base UART clock. Fortunately our good friends at Microsoft are amenable to adding a subtype that covers this and are going to followup tomorrow for me. We'll need to accept that on X-Gene platforms earlycon doesn't quite work properly for the moment until we can add the correct quirk. So Aleksey's patch kinda improves things in that it brings up the console (which didn't work before) and therefore is hugely beneficial, but it won't be able to enable the earlycon. Aleksey: you might want to annotate your patch thusly: "Discussion is still underway to add a new DBG2 (the table used to enumerate the various subtypes of serial port covered by the SPCR) 16550 UART subtype that may be needed for some additional platforms, such as those based upon AppliedMicro X-Gene ARMv8 SoCs" Your patch as-is /is/ useful because it enables the console, and most users care far more about that than the earlycon. Jon. P.S. I would note my usual anal pedantry. The reason I'm being a pedant here is that we need to test this stuff as a user would use it - making sure we get console output at the right moment - rather than just boot testing and checking logs. That's never the same. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 6:53 ` Jon Masters @ 2016-12-06 7:13 ` Jon Masters 2016-12-06 8:40 ` Aleksey Makarov 0 siblings, 1 reply; 16+ messages in thread From: Jon Masters @ 2016-12-06 7:13 UTC (permalink / raw) To: Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown, Rob Herring On 12/06/2016 01:53 AM, Jon Masters wrote: > On 12/06/2016 01:34 AM, Jon Masters wrote: >> On 12/05/2016 10:55 PM, Duc Dang wrote: >>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: > ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, > Package (0x01) > { > Package (0x02) > { > "clock-frequency", > Zero > } > } > I suspect Mustang is doing similar. So you read the magic frequency ^^^^^^^^^^^^^ spoiler, it is :) > info and pass this in through a DSD in the AML. It's ok, I've made my > peace with this (but obviously we're trying to kill all DSD hacks), > but it explains how this "works" after boot, but not for early console. > > To fix this, we're going to need to be able to know that your 8250 is > both needful of 32-bit accesses *AND* needs a different base UART clock. > Fortunately our good friends at Microsoft are amenable to adding a > subtype that covers this and are going to followup tomorrow for me. For the earlycon setup, you'll probably benefit from figuring out ahead of time how you'll want to handle this. The "easy" option is to remove the baud in the case of X-Gene with new subtype but that'll be potential fragile. You might also decide that struct earlycon_device wants to grow a "quirks" flag that you can set for this kind of thing (bound to be more). Copying Rob as well in case he has suggestions for you. Rob, as an FYI the AppliedMicro X-Gene 16550 "compatible" requires both 32-bit accesses (which Aleksey tried to address earlier in this thread) but also has a special non-standard clock (to be fair, it's not as if we architected a standard UART clock for arm64, we just assumed it was like x86 but didn't mandate this early when Applied were doing their design - another life lesson). Microsoft will add a new DBG2 subtype that allows for both of these situations. But you'll want to somehow convey this information (quirks) in one of the earlycon structures. Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 7:13 ` Jon Masters @ 2016-12-06 8:40 ` Aleksey Makarov 0 siblings, 0 replies; 16+ messages in thread From: Aleksey Makarov @ 2016-12-06 8:40 UTC (permalink / raw) To: Jon Masters, Duc Dang Cc: Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Mark Salter, Graeme Gregory, Len Brown, Rob Herring Hi Jon, On 12/06/2016 01:13 PM, Jon Masters wrote: > On 12/06/2016 01:53 AM, Jon Masters wrote: >> On 12/06/2016 01:34 AM, Jon Masters wrote: >>> On 12/05/2016 10:55 PM, Duc Dang wrote: >>>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: > >> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, >> Package (0x01) >> { >> Package (0x02) >> { >> "clock-frequency", >> Zero >> } >> } > >> I suspect Mustang is doing similar. So you read the magic frequency > ^^^^^^^^^^^^^ > spoiler, it is :) > >> info and pass this in through a DSD in the AML. It's ok, I've made my >> peace with this (but obviously we're trying to kill all DSD hacks), >> but it explains how this "works" after boot, but not for early console. >> >> To fix this, we're going to need to be able to know that your 8250 is >> both needful of 32-bit accesses *AND* needs a different base UART clock. >> Fortunately our good friends at Microsoft are amenable to adding a >> subtype that covers this and are going to followup tomorrow for me. > > For the earlycon setup, you'll probably benefit from figuring out > ahead of time how you'll want to handle this. The "easy" option > is to remove the baud in the case of X-Gene with new subtype > but that'll be potential fragile. You might also decide that > struct earlycon_device wants to grow a "quirks" flag that > you can set for this kind of thing (bound to be more). I don't see why new subtypes or quirk flags are required. My suggestion is to change SPCR spec so that - Access width should be specified by the "Bit width" subfield of the "Base address" field. When "Interface type" is ACPI_DBG2_ARM_SBSA_32BIT, disregard this value and use mmio32 (legacy case) - Add a new value 0 (now it is reserved) for "Baud rate" field with meaning "do not change pre-initialized clock rate" Then spcr.c should be fixed this way: diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index 6c6710b..9c6c0b4 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -37,7 +37,7 @@ int __init parse_spcr(bool earlycon) acpi_status status; char *uart; char *iotype; - int baud_rate; + char *baud_rate_string; int err; if (acpi_disabled) @@ -56,13 +56,19 @@ int __init parse_spcr(bool earlycon) goto done; } - iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ? - "mmio" : "io"; + if (table->interface_type == ACPI_DBG2_ARM_SBSA_32BIT) { + iotype = "mmio32"; + } else if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { + if (table->serial_port.bit_width == 32) + iotype = "mmio32"; + else + iotype = "mmio"; + } else { + iotype = "io"; + } switch (table->interface_type) { case ACPI_DBG2_ARM_SBSA_32BIT: - iotype = "mmio32"; - /* fall through */ case ACPI_DBG2_ARM_PL011: case ACPI_DBG2_ARM_SBSA_GENERIC: case ACPI_DBG2_BCM2835: @@ -70,10 +76,6 @@ int __init parse_spcr(bool earlycon) break; case ACPI_DBG2_16550_COMPATIBLE: case ACPI_DBG2_16550_SUBSET: - if (table->serial_port.space_id == - ACPI_ADR_SPACE_SYSTEM_MEMORY && - table->serial_port.bit_width == 32) - iotype = "mmio32"; uart = "uart"; break; default: @@ -82,25 +84,33 @@ int __init parse_spcr(bool earlycon) } switch (table->baud_rate) { + case 0: + /* + * This value is not standaritzed by ACPI SPCR for now. + * It means that hardware should not be re-initialized with + * new speed. + */ + baud_rate_string = ""; + break; case 3: - baud_rate = 9600; + baud_rate_string = ",9600"; break; case 4: - baud_rate = 19200; + baud_rate_string = ",19200"; break; case 6: - baud_rate = 57600; + baud_rate_string = ",57600"; break; case 7: - baud_rate = 115200; + baud_rate_string = ",115200"; break; default: err = -ENOENT; goto done; } - snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype, - table->serial_port.address, baud_rate); + snprintf(opts, sizeof(opts), "%s,%s,0x%llx%s", uart, iotype, + table->serial_port.address, baud_rate_string); pr_info("console: %s\n", opts); ------------------------------ All the best Aleksey Makarov > Copying Rob as well in case he has suggestions for you. Rob, as > an FYI the AppliedMicro X-Gene 16550 "compatible" requires both > 32-bit accesses (which Aleksey tried to address earlier in this > thread) but also has a special non-standard clock (to be fair, > it's not as if we architected a standard UART clock for arm64, > we just assumed it was like x86 but didn't mandate this early > when Applied were doing their design - another life lesson). > Microsoft will add a new DBG2 subtype that allows for both > of these situations. But you'll want to somehow convey this > information (quirks) in one of the earlycon structures. > > Jon. > ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-06 6:34 ` Jon Masters 2016-12-06 6:53 ` Jon Masters @ 2016-12-07 15:23 ` Mark Salter 2016-12-13 6:20 ` Jon Masters 1 sibling, 1 reply; 16+ messages in thread From: Mark Salter @ 2016-12-07 15:23 UTC (permalink / raw) To: Jon Masters, Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Graeme Gregory, Len Brown On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote: > On 12/05/2016 10:55 PM, Duc Dang wrote: > > > > On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: > > > > > > Hi Duc, all, > > > > > > So after regenerating the initrd override (I must have fat fingered) > > > it is now detecting the correct bit width on boot (attached dmesg log). > > > > > > HOWEVER while the console does come up, the use of "earlycon" on the > > > command line (with no parameters) doesn't result in the early SPCR > > > console coming up correctly. I see some garbled characters that > > > suggest the baud (or register access width) is off somewhere. > > My bad that I did not catch this in the morning. Yes, earlycon does > > not seems to work as expected. I can see that earlycon parameters > > seems to be correct, but the bootconsole message does not come out > > (the following is from 'dmesg') > > > > [ 0.000000] ACPI: SPCR: console: uart,mmio32,0x1c020000,115200 > > [ 0.000000] earlycon: uart0 at MMIO32 0x000000001c020000 (options '115200') > > [ 0.000000] bootconsole [uart0] enabled > The difference appears to be in the baud rate. When I explicitly specify > "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with > the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we > both know that the base clock on the X-Gene UART is weird. Maybe > somehow we can explain this through the lack of setting a baud. BTW, this behavior is same with devicetree. If you specify a baudrate with earlycon=, the driver tries to set that baudrate and if you have an 8250 with some non-standard baud clock, then it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon(). Then again, setup_earlycon() has this comment: * setup_earlycon - match and register earlycon console * @buf: earlycon param string * * Registers the earlycon console matching the earlycon specified * in the param string @buf. Acceptable param strings are of the form * <name>,io|mmio|mmio32|mmio32be,<addr>,<options> * <name>,0x<addr>,<options> * <name>,<options> * <name> * * Only for the third form does the earlycon setup() method receive the * <options> string in the 'options' parameter; all other forms set * the parameter to NULL. That part about the 3rd form doesn't seem to be true. I don't see where options gets set to NULL for forms other than the third. > > I am pondering some more currently. If it's X-Gene specific, let's add > that to the quirk (and to perhaps a more APM specific SPCR subtype). > > Jon. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-07 15:23 ` Mark Salter @ 2016-12-13 6:20 ` Jon Masters 2017-04-30 21:39 ` Jon Masters 0 siblings, 1 reply; 16+ messages in thread From: Jon Masters @ 2016-12-13 6:20 UTC (permalink / raw) To: Mark Salter, Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Graeme Gregory, Len Brown On 12/07/2016 10:23 AM, Mark Salter wrote: > On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote: >> On 12/05/2016 10:55 PM, Duc Dang wrote: >>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@redhat.com> wrote: >>>> HOWEVER while the console does come up, the use of "earlycon" on the >>>> command line (with no parameters) doesn't result in the early SPCR >>>> console coming up correctly. I see some garbled characters that >>>> suggest the baud (or register access width) is off somewhere. >>> My bad that I did not catch this in the morning. Yes, earlycon does >>> not seems to work as expected. I can see that earlycon parameters >>> seems to be correct, but the bootconsole message does not come out >>> (the following is from 'dmesg') >>> >>> [ 0.000000] ACPI: SPCR: console: uart,mmio32,0x1c020000,115200 >>> [ 0.000000] earlycon: uart0 at MMIO32 0x000000001c020000 (options '115200') >>> [ 0.000000] bootconsole [uart0] enabled >> The difference appears to be in the baud rate. When I explicitly specify >> "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with >> the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we >> both know that the base clock on the X-Gene UART is weird. Maybe >> somehow we can explain this through the lack of setting a baud. > > BTW, this behavior is same with devicetree. At least it's consistent :) > If you specify a baudrate with earlycon=, the driver tries to set that > baudrate and if you have an 8250 with some non-standard baud clock, then > it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon(). Yet they seem to explicitly want to do this...in my conversations with some others we agree that, in many cases, you really want to say "leave the baud whatever the firmware set it", which would work in this case, but might break some others. Then again, nobody on x86 Linux is really using the SPCR today due to it not having been something they used until now and due to the location of the COM ports being fairly well known ;) So who knows what folks will prefer, but we should at least get the spec to cover both situations by explicitly calling out Applied as special. > Then again, setup_earlycon() has this comment: > > * setup_earlycon - match and register earlycon console > * @buf: earlycon param string > * > * Registers the earlycon console matching the earlycon specified > * in the param string @buf. Acceptable param strings are of the form > * <name>,io|mmio|mmio32|mmio32be,<addr>,<options> > * <name>,0x<addr>,<options> > * <name>,<options> > * <name> > * > * Only for the third form does the earlycon setup() method receive the > * <options> string in the 'options' parameter; all other forms set > * the parameter to NULL. > > That part about the 3rd form doesn't seem to be true. I don't see where > options gets set to NULL for forms other than the third. I saw that also, and agree that it appears totally bogus. We'll want to get the documentation fixed as part of this cleanup. So I've been discussing some changes to the SPCR and the current proposal is that we have two new subtypes - one for 16550s that are non-standard register width/stride but use the typical base clock, and a specific additional type for SBSA level 0 compatible 16550 UARTs (Applied). I will followup when the specification document has been revised. Jon. P.S. I had a lot of fun over my birthday reading the original 8250 spec and learning about how the DLAB stuff works (I think those brain cells had died). Which - on a total tangent - finally helps with a long standing issue we have had. We (a small cabal) have wanted to sneak in an instruction into the ARM ISA or specs referring to DLAB (the initials of a certain person who owns the ARM ARM) and now we will get to do this into the SBBR ;) -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] SPCR: check bit width for the 16550 UART 2016-12-13 6:20 ` Jon Masters @ 2017-04-30 21:39 ` Jon Masters 0 siblings, 0 replies; 16+ messages in thread From: Jon Masters @ 2017-04-30 21:39 UTC (permalink / raw) To: Mark Salter, Duc Dang Cc: Aleksey Makarov, Rafael J . Wysocki, linux-acpi, linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman, Russell King, Peter Hurley, Graeme Gregory, Len Brown On 12/13/2016 01:20 AM, Jon Masters wrote: > On 12/07/2016 10:23 AM, Mark Salter wrote: >> If you specify a baudrate with earlycon=, the driver tries to set that >> baudrate and if you have an 8250 with some non-standard baud clock, then >> it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon(). > > Yet they seem to explicitly want to do this...in my conversations with some > others we agree that, in many cases, you really want to say "leave the baud > whatever the firmware set it", which would work in this case, but might > break some others. Then again, nobody on x86 Linux is really using the > SPCR today due to it not having been something they used until now and > due to the location of the COM ports being fairly well known ;) > > So who knows what folks will prefer, but we should at least get the spec > to cover both situations by explicitly calling out Applied as special. <snip> > So I've been discussing some changes to the SPCR and the current proposal > is that we have two new subtypes - one for 16550s that are non-standard > register width/stride but use the typical base clock, and a specific > additional type for SBSA level 0 compatible 16550 UARTs (Applied). I > will followup when the specification document has been revised. As an update. I've been speaking with friends at Microsoft on and off about this for quite some time. They've been very helpful (as usual) and we should get an SPCR update soon covering Applied's case. I have pinged the APM team to make sure that they're ready to post a patch. I would like this small fix squeezed in 4.12, but before 4.13. Jon. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-04-30 21:39 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-12-05 13:05 [PATCH] SPCR: check bit width for the 16550 UART Aleksey Makarov 2016-12-05 18:51 ` Duc Dang 2016-12-05 23:27 ` Jon Masters 2016-12-05 23:52 ` Duc Dang 2016-12-06 0:03 ` Jon Masters 2016-12-06 0:05 ` Jon Masters 2016-12-06 0:31 ` Duc Dang 2016-12-06 2:27 ` Jon Masters 2016-12-06 3:55 ` Duc Dang 2016-12-06 6:34 ` Jon Masters 2016-12-06 6:53 ` Jon Masters 2016-12-06 7:13 ` Jon Masters 2016-12-06 8:40 ` Aleksey Makarov 2016-12-07 15:23 ` Mark Salter 2016-12-13 6:20 ` Jon Masters 2017-04-30 21:39 ` Jon Masters
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).