[coreboot] [Mohon Peak] Console output on external UARTs behind PCIe

Patrick Agrain patrick.agrain at alcatel-lucent.com
Thu Mar 12 10:02:27 CET 2015


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 at mohon_peak ~]# lspci -t
-[0000: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 at mohon_peak ~]#
[root at 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 df600000 (32-bit, non-prefetchable) [size=16K]
         Region 1: Memory at df200000 (32-bit, non-prefetchable) [size=2M]
         Region 2: Memory at df400000 (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 at mohon_peak ~]#
[root at 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 00000700 should be 00000100
0000:01:00.0: ttyS2 at MMIO 0xdf601000 (irq = 16) is a 16C950/954
ttyS3: detected caps 00000700 should be 00000100
0000:01:00.0: ttyS3 at MMIO 0xdf601200 (irq = 16) is a 16C950/954
[root at 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] Error 1
----

Hope it helps.
Best regards,
Patrick


On Wed, 2015-03-11 at 16:21 +0100, Patrick Agrain wrote:
>/  Hello Kyösti,
/>/  
/>/  I tried what you suggested below:
/>/  
/>/  - Enabled EARLY_PCI_BRIDGE
/>/  - Set Bridge at D:1 F:0
/>/  - Enabled OXI PCIe952 and disabled SERIAL_PORT_ON_SUPERIO.
/>/  Reboot Mohon Peak CRB: failed. No output. POST code at 0xA9.
/>/  
/
You also need to set EARLY_PCI_MMIO_BASE. If you cannot boot this board
to OS yet and run lspci command, try with 0xfef00000 that should be
safely out of the way of other resources.

I don't think post 0xA9 originates from coreboot proper.

>/  Will try to get further.
/>/  If anybody has an idea...
/
If by any means possible, boot your Mohon Peak board to OS, check your
serial terminal parameters and cables, and prepare the OS for logins
over serial line. Then return here with the lspci -vv output so we have
something to work with.


Kyösti



Le 11/03/2015 17:44, Patrick Agrain a écrit :
> Hi,
>
> More information on this.
>
> The POST code sequence (as far I can see, but I'm not Steeve 
> Austin...) is:
> 40h -> 47h -> A9h
>
> IMHO, we are parsing following code from 
> ./src/southbridge/intel/fsp_rangeley/romstage.c
> void main(FSP_INFO_HEADER *fsp_info_header)
> {
>     uint32_t fd_mask = 0;
>     uint32_t func_dis = DEFAULT_PBASE + PBASE_FUNC_DIS;
>
>     /*
>      * Do not use the Serial Console before it is setup.
>      * This causes the I/O to clog and a side effect is
>      * that the reset button stops functioning.  So
>      * instead just use outb so it doesn't output to the
>      * console when CONFIG_CONSOLE_POST.
>      */
>     outb(0x40, 0x80);
>
>     /* Rangeley UART POR state is enabled */
>     console_init();
>     post_code(0x41);
>
>     /* Enable GPIOs BAR */
>     pci_write_config32(SOC_LPC_DEV, GBASE, DEFAULT_GPIOBASE|0x02);
>
>     early_mainboard_romstage_entry();
>
>     post_code(0x42);
>     rangeley_sb_early_initialization();
>
>     post_code(0x46);
>     /* Program any required function disables */
>     get_func_disables(&fd_mask);
>
>     if (fd_mask != 0) {
>         write32(func_dis, read32(func_dis) | fd_mask);
>         /* Ensure posted write hits. */
>         read32(func_dis);
>     }
>
>   /*
>    * Call early init to initialize memory and chipset. This function 
> returns
>    * to the romstage_main_continue function with a pointer to the HOB
>    * structure.
>    */
>     post_code(0x47);
>     printk(BIOS_DEBUG, "Starting the Intel FSP (early_init)\n");
>     fsp_early_init(fsp_info_header);
>     die("Uh Oh! fsp_early_init should not return here.\n");
> }
>
> ... and I'm affraid we get stucked in the fsp_early_init() function 
> ... :-(
>
> Regards.
> Patrick Agrain
>
> Le 11/03/2015 16:21, Patrick Agrain a écrit :
>> Hello Kyösti,
>>
>> I tried what you suggested below:
>>
>> - Enabled EARLY_PCI_BRIDGE
>> - Set Bridge at D:1 F:0
>> - Enabled OXI PCIe952 and disabled SERIAL_PORT_ON_SUPERIO.
>> Reboot Mohon Peak CRB: failed. No output. POST code at 0xA9.
>>
>> Will try to get further.
>> If anybody has an idea...
>>
>> Regards,
>> Patrick Agrain
>>
>> 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150312/fcb95f85/attachment.html>


More information about the coreboot mailing list