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

Wed Mar 18 13:49:41 CET 2015

Hello,

System is working again.

Following "patches" have to be applied in coreboot to get an external 
Startech UART board working on a Mohon Peak CRB:

- in ./src/device/pci_early.c:pci_early_bridge_init(): remove (for the 
moment) the udelay(10), otherwise the board will freeze after POST code 
40h -> 47h -> A9h. IMHO, the udelay() has to be fixed for that kind of 
processor (, chipset ?).

- in ./src/device/pci_early.c:pci_early_bridge_init(): add 'if (ret)' 
condition on the last 'pci_bridge_set_secondary(p2p_bridge, 0);', 
otherwise the board will freeze at POST code 80h (whatever the value of 
'secondary').

- in ./src/drivers/uart/oxpcie_early.c:global and oxford_remap(): modify 
the uart1_base shift from 0x2000 to 0x1200. Tested. There must a typo in 
the datasheet of the OxPCI952. See also the memory dump below.

Note: I don't know how to implement these modification on the source 
tree, because I have no other board to test potential regression. Put 
them with a #if CONFIG_BOARD_INTEL_MOHONPEAK ?

- in 'make menuconfig':
-- set MMIO_BASE_WINDOWS with the value returned by an 'lspci' command. 
See an example below. This is system and slot-dependant.
-- set UART_FOR_CONSOLE at '0' for the first COM port and '1' for the 
second COM port.

Hope it helps.
Regards,
Patrick Agrain

PS: Kyösti, you told me about a possible patch for Seabios. Had you the 
opportunity to find it ?

Le 17/03/2015 08:23, Patrick Agrain a écrit :
> Hello,
>
> Yesterday morning, I tried to switch back with my modification, as suggested below.
>
> a) put secondary at 15: OK.
> b) remove if(ret) condition: OK.
>
> Then I tried to have a closer look at the second UART on the Startech board. Set the UART console index to 1
> and reboot the board.
>
>  From that time the board always blocks at POST code 80h. I cannot figure out what I've done so that this board does
> not boot anymore when enabling the OXPCIe MEM serial port (it's OK with the legacy IO serial port)... :-(
> I even pulled the source code from github to the latest available code...
> To be followed.
>
> Concerning c), the base address of the second UART:
>  From a datasheet point of view, I agree with the default code: the registers of the second UART are given to be located
> at base+2000h. But, if I dump the memory content, there is nothing at 2000h, but it seems to be be some data at 1200h:
>
> [root at mohon_peak ~]# pcidump -v -b 1 -d 0 -f 0 -r 0 -x 2100
>
> Detected Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART
> 0000:01:00.0 vendor=1415 device=c158 class=0700 irq=10 (pin 1)
> BAR[0] PCI memory @0xdf600000, Useful size is 16384.
>          0000 : 00 02 00 07 02 00 00 00 00 00 00 00 ff ff 00 00 : ................
>          0010 : 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 : ................
> <...>
>          0ff0 : 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 : ................
>          1000 : fc 05 c1 13 0b 60 30 02 fc 05 c1 13 0b 60 30 02 : .....`0......`0.
>          1010 : fc 05 c1 13 0b 60 30 02 fc 05 c1 13 0b 60 30 02 : .....`0......`0.
>          1020 : fc 05 c1 13 0b 60 30 02 fc 05 c1 13 0b 60 30 02 : .....`0......`0.
> <...>
>          11f0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
>          1200 : 78 00 01 00 00 60 00 00 78 00 01 00 00 60 00 00 : x....`..x....`..
>          1210 : 78 00 01 00 00 60 00 00 78 00 01 00 00 60 00 00 : x....`..x....`..
>          1220 : 78 00 01 00 00 60 00 00 78 00 01 00 00 60 00 00 : x....`..x....`..
> <...>
>          1ff0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
>          2000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
>          2010 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
>          2020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
> <...>
> And this is more or less confirmed by the base address in:
>
> [root at mohon_peak ~]# cat /proc/tty/driver/serial
> serinfo:1.0 driver revision:
> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
> 1: uart:16550A port:000002F8 irq:3 tx:59 rx:0 RTS|DTR
> 2: uart:unknown port:000003E8 irq:11
> 3: uart:unknown port:000002E8 irq:13
> 4: uart:16C950/954 mmio:0xDF601000 irq:16 tx:3156 rx:0 RTS|CTS|DTR|DSR
> 5: uart:16C950/954 mmio:0xDF601200 irq:16 tx:0 rx:0
> 6: uart:unknown port:00000000 irq:0
> 7: uart:unknown port:00000000 irq:0
> [root at mohon_peak ~]#
>
> Note: I increased to 8 the CONFIG_SERIAL_8250_RUNTIME_UARTS in the kernel.
>
> Now, I will first try to get (again !) a working version of coreboot with the OXPCIe board.
>
> Regards,
> Patrick
>
> On Fri, 2015-03-13 at 16:47 +0100, Patrick Agrain wrote:
> >/  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.
> /
> The value of 'secondary' should not matter here, it does not need to
> match with the value you later see in lspci.
>
> >/  -- 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.
> /
> No clue about that.
>
> >/  -- Put 'if (ret)' condition on the last
> />/  'pci_bridge_set_secondary(p2p_bridge, 0);'.
> /
> Don't, as you would leave _some_ bridge claiming the bus number
> 'secondary', and PCI tree enumeration later in ramstage may try to
> assign the same number to another bridge. If you find this is really
> required, you would need to use a large value of 'secondary' to avoid
> such a collision.
>
> >/  - 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.
> />/  
> /
> What PCI ID did your card report again? Different IDs will use different
> resource mapping, I'll need to compare against the datasheet.
>
> >/  BTW, I also included the patch covered by
> />/  http://review.coreboot.org/#/c/8660/.  Compiler does not complain anymore
> />/  (and 'in fine' it works).
> />/  
> /
> I have submitted iteration #2 of this change.
>
> >/  Logs are now available from 'coreboot-<...> ramstage starting'.
> />/  
> /
> Let's try to make it work from the ".. romstage starting" message.
>
> >/  Thanks for your support.
> />/  Regards,
> />/  Patrick Agrain
> />/  
> /
> Kyösti

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