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

Patrick Agrain patrick.agrain at alcatel-lucent.com
Fri Mar 13 16:47:46 CET 2015


Hello,

One step further !!

I succeed to get it working.

Several modification has to be made. I will try (next week) to get them 
in a "readable form".
- in ./src/device/pci_early.c:pci_early_bridge_init() :
-- secondary = 1 for Mohon Peak.
-- remove udelay() in PCI_VENDOR_ID reading (that's the big point). I 
will try to have a look at it. Probably something very specific to this 
chipset.
-- Put 'if (ret)' condition on the last 
'pci_bridge_set_secondary(p2p_bridge, 0);'.
- in ./src/drivers/uart/oxpcie_early.c:pci_early_device_probe() :
-- uart1base is at CONFIG_EARLY_PCI_MMIO_BASE + 0x1200 for the Startech 
board I have.

BTW, I also included the patch covered by 
http://review.coreboot.org/#/c/8660/. Compiler does not complain anymore 
(and 'in fine' it works).

Logs are now available from 'coreboot-<...> ramstage starting'.

Thanks for your support.
Regards,
Patrick Agrain

Le 12/03/2015 10:02, Patrick Agrain a écrit :
> 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/20150313/fc528288/attachment-0001.html>


More information about the coreboot mailing list