Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
Hello, More on this topic. Kyösti, as required, here are the info. - I'm able to boot a Linux OS with (internal) uart1 from Atom. - I'm also to boot the Linux with following command-line : kernel /boot/vmlinuz-2.6.32-xx-dhs3 root=/dev/sda2 console=uart8250,mmio,0xdf601000,115200n8 panic=5. The kernel logs are then sent to the external UART, as soon as the serial driver is loaded.. So far so good... Here are the lspci information from a Mohon Peak. [root@mohon_peak ~]# lspci -t -[:00]-+-00.0 +-01.0-[01]00.0 +-03.0-[02-06]00.0-[03-06]--+-04.0-[04]-- | +-05.0-[05]--+-00.0 | |\-00.1 | \-08.0-[06]-- +-0e.0 +-0f.0 +-13.0 +-14.0 +-14.1 +-16.0 +-17.0 +-18.0 +-1f.0 \-1f.3 [root@mohon_peak ~]# [root@mohon_peak ~]# lspci -vv -d 1415:c158 01:00.0 Serial controller: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART (prog-if 02 [16550]) Subsystem: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 16 Region 0: Memory at df60 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at df20 (32-bit, non-prefetchable) [size=2M] Region 2: Memory at df40 (32-bit, non-prefetchable) [size=2M] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=55mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 128ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [b0] MSI-X: Enable- Count=16 Masked- Vector table: BAR=1 offset=001b3000 PBA: BAR=1 offset=001b2000 Capabilities: [100 v1] Device Serial Number 00-30-e0-11-11-00-01-50 Capabilities: [110 v1] Power Budgeting ? Kernel driver in use: serial [root@mohon_peak ~]# [root@mohon_peak ~]# dmesg | grep tty serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS2: detected caps 0700 should be 0100 :01:00.0: ttyS2 at MMIO 0xdf601000 (irq = 16) is a 16C950/954 ttyS3: detected caps 0700 should be 0100 :01:00.0: ttyS3 at MMIO 0xdf601200 (irq = 16) is a 16C950/954 [root@mohon_peak ~]# Kyösti, I agree with you concerning the A9h post code. IMHO, I think it is issued by the Intel FSP. BTW, compiler complains about a mismatch argument type on read8() and write8() in ./src/drivers/uart/uart8250mem.c src/drivers/uart/uart8250mem.c: In function 'uart8250_read': src/drivers/uart/uart8250mem.c:39:2: error: passing argument 1 of 'read8' makes pointer from integer without a cast [-Werror] return read8((uintptr_t) (base + reg)); ^ In file included from src/drivers/uart/uart8250mem.c:21:0: src/arch/x86/include/arch/io.h:145:54: note: expected 'const volatile void *' but argument is of type 'unsigned int' static inline __attribute__((always_inline)) uint8_t read8(const volatile void *addr) ^ src/drivers/uart/uart8250mem.c: In function 'uart8250_write': src/drivers/uart/uart8250mem.c:45:2: error: passing argument 1 of 'write8' makes pointer from integer without a cast [-Werror] write8((uintptr_t) (base + reg), data); ^ In file included from src/drivers/uart/uart8250mem.c:21:0: src/arch/x86/include/arch/io.h:160:51: note: expected 'volatile void *' but argument is of type 'unsigned int' static inline __attribute__((always_inline)) void write8(volatile void *addr, uint8_t value) ^ cc1: all warnings being treated as errors make: *** [build/drivers/uart/uart8250mem.romstage.o]
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
On Thu, 2015-03-12 at 10:02 +0100, Patrick Agrain wrote: Hello, More on this topic. Kyösti, as required, here are the info. - I'm able to boot a Linux OS with (internal) uart1 from Atom. - I'm also to boot the Linux with following command-line : kernel /boot/vmlinuz-2.6.32-xx-dhs3 root=/dev/sda2 console=uart8250,mmio,0xdf601000,115200n8 panic=5. The kernel logs are then sent to the external UART, as soon as the serial driver is loaded.. So far so good... Ok, just checking. I need to correct my previous statement in that I do not know anyone (yet) using OxPCIe with the specific intel chipset you have there, but an older one. It is possible those PCI-e root ports are not yet initialized/trained when we attempt the PCI ID detection for the UART card. Here are the lspci information from a Mohon Peak. [root@mohon_peak ~]# lspci -t -[:00]-+-00.0 +-01.0-[01]00.0 +-03.0-[02-06]00.0-[03-06]--+-04.0-[04]-- | +-05.0-[05]--+-00.0 | |\-00.1 | \-08.0-[06]-- +-0e.0 +-0f.0 +-13.0 +-14.0 +-14.1 +-16.0 +-17.0 +-18.0 +-1f.0 \-1f.3 [root@mohon_peak ~]# [root@mohon_peak ~]# lspci -vv -d 1415:c158 01:00.0 Serial controller: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART (prog-if 02 [16550]) Subsystem: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 16 Region 0: Memory at df60 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at df20 (32-bit, non-prefetchable) [size=2M] Region 2: Memory at df40 (32-bit, non-prefetchable) [size=2M] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=55mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 128ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [b0] MSI-X: Enable- Count=16 Masked- Vector table: BAR=1 offset=001b3000 PBA: BAR=1 offset=001b2000 Capabilities: [100 v1] Device Serial Number 00-30-e0-11-11-00-01-50 Capabilities: [110 v1] Power Budgeting ? Kernel driver in use: serial I think EARLY_PCI parameters are fine if you also assigned MMIO_BASE with 0xdf00. [root@mohon_peak ~]# [root@mohon_peak ~]# dmesg | grep tty serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS2: detected caps 0700 should be 0100 :01:00.0: ttyS2 at MMIO 0xdf601000 (irq = 16) is a 16C950/954 ttyS3: detected caps 0700 should be 0100 :01:00.0: ttyS3 at MMIO 0xdf601200 (irq = 16) is a 16C950/954 [root@mohon_peak ~]# Kyösti, I agree with you concerning the A9h post code. IMHO, I think it is issued by the Intel FSP. BTW, compiler complains about a mismatch argument type on read8() and write8() in ./src/drivers/uart/uart8250mem.c Ah.. there is a recent regression with source. With complain like that it will not build you a new firmware binary at all, so it makes me wonder what you were actually testing before. Here is quick (but untested) fix for the build problem: http://review.coreboot.org/#/c/8660/ For a test run, I would need to disassemble a samsung/lumpy that I know OxPCIe works well with. That won't happen for at least a week. Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
Thanks Marc and Kyösti for your hints. As I'm just discovering coreboot and its multiple possibilities, please apologize if my questions seems too simple... ;-) A) UART Type --- From Kconfig file in ./src/drivers/uart, the valid ID for the oxpcie is 1415:c158. I can obtain this ID on my Startech board only when I strapped it as native UART (Startech documentation), that is : memory-mapped. From Kconfig file in ./src/console, there is following sentence : Supporting multiple different types of UARTs in one build is not supported.. Q: Am I correct if I translate this like : Use only memory-mapped or IO-mapped UARTs, but not both at the same time. ? B) Memory-mapped UART required options -- From the answers received, I would say that the required options (in make menuconfig) would be: - In Generic Drivers: validate Oxford OXPCIe952 and de-validate Serial Port on SuperIO. - In Devices: Set the device and function numbers of the PCie bridge, behind which is connected the Startech board. On Mohon Peak, it's D1-F0. Q: What about the MMIO window base ? Is it the memory address of the UARTs, defined by the values in the BAR registers ? - in Console: Validate Serial Port Console Output. Q: What about the index of the Serial Port console output ? IMHO, there are only valid for IO-mapped UART. Correct ? Q: Am I missing anything ? Thanks in advance for the time you want to spent on it. Regards, Patrick Le 06/03/2015 19:01, Marc Jones a écrit : Hi Patrick, You can look at the Oxford pcie card and 8250MEM drivers for reference: src/drivers/uart/oxpcie* src/drivers/uart/uart8250mem* Marc On Fri, Mar 6, 2015 at 9:37 AM Patrick Agrain patrick.agr...@alcatel-lucent.com mailto:patrick.agr...@alcatel-lucent.com wrote: Hello everybody, Do you think that it would be possible to output the console messages from coreboot (seabios) on another UART port (strapped to be visible on Memory-based space or IO Space) connected on a PCIe slot ? I've purchased a StarTech UART board with an OXPCIe952 chip, with the same IDs as visible in ./src/drivers/uart/oxpcie.c. On http://www.coreboot.org/Serial_console#PCIe.2FMini_PCIe_based_serial_cards, what is behind the sentence: In order to use the card for romstage debugging, minimal setup of the PCIe bridge and the MPEX2S952 have to be added to romstage.c ? Thanks in advance. Best regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org mailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
On Fri, 2015-03-06 at 17:25 +0100, Patrick Agrain wrote: Hello everybody, Do you think that it would be possible to output the console messages from coreboot (seabios) on another UART port (strapped to be visible on Memory-based space or IO Space) connected on a PCIe slot ? Yes, it has been done before. I should have a hack for SeaBIOS to support memory-mapped UART somewhere, I will go and look. If I remember correctly SeaBIOS boot media selection only works from local keyboard, not over serial. I've purchased a StarTech UART board with an OXPCIe952 chip, with the same IDs as visible in ./src/drivers/uart/oxpcie.c. On http://www.coreboot.org/Serial_console#PCIe.2FMini_PCIe_based_serial_cards, what is behind the sentence: In order to use the card for romstage debugging, minimal setup of the PCIe bridge and the MPEX2S952 have to be added to romstage.c ? You need to enable OxPCIe support and set EARLY_PCI_BRIDGE_* variables in menuconfig. If you can boot to OS with that plaform, with the serial card installed, get the location of PCIe rootport (aka. parent bridge) for OxPCIe card with lspci -vv command. Once you have OS shell, both coreboot and SeaBIOS console messages are available from CBMEM console using 'cbmem -c' command. Thanks in advance. Best regards, Patrick Agrain HTH, Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
Hello everybody, Do you think that it would be possible to output the console messages from coreboot (seabios) on another UART port (strapped to be visible on Memory-based space or IO Space) connected on a PCIe slot ? I've purchased a StarTech UART board with an OXPCIe952 chip, with the same IDs as visible in ./src/drivers/uart/oxpcie.c. On http://www.coreboot.org/Serial_console#PCIe.2FMini_PCIe_based_serial_cards, what is behind the sentence: In order to use the card for romstage debugging, minimal setup of the PCIe bridge and the MPEX2S952 have to be added to romstage.c ? Thanks in advance. Best regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
Hi Patrick, You can look at the Oxford pcie card and 8250MEM drivers for reference: src/drivers/uart/oxpcie* src/drivers/uart/uart8250mem* Marc On Fri, Mar 6, 2015 at 9:37 AM Patrick Agrain patrick.agr...@alcatel-lucent.com wrote: Hello everybody, Do you think that it would be possible to output the console messages from coreboot (seabios) on another UART port (strapped to be visible on Memory-based space or IO Space) connected on a PCIe slot ? I've purchased a StarTech UART board with an OXPCIe952 chip, with the same IDs as visible in ./src/drivers/uart/oxpcie.c. On http://www.coreboot.org/Serial_console#PCIe.2FMini_PCIe_based_serial_cards , what is behind the sentence: In order to use the card for romstage debugging, minimal setup of the PCIe bridge and the MPEX2S952 have to be added to romstage.c ? Thanks in advance. Best regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
