<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello,<br>
<br>
System is working again.<br>
<br>
Following "patches" have to be applied in coreboot to get an
external Startech UART board working on a Mohon Peak CRB:<br>
<br>
- 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 ?).<br>
<br>
- 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').<br>
<br>
- 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.<br>
<br>
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 ?<br>
<br>
- in 'make menuconfig': <br>
-- set MMIO_BASE_WINDOWS with the value returned by an 'lspci'
command. See an example below. This is system and slot-dependant.<br>
-- set UART_FOR_CONSOLE at '0' for the first COM port and '1' for
the second COM port.<br>
<br>
Hope it helps.<br>
Regards,<br>
Patrick Agrain<br>
<br>
PS: Kyösti, you told me about a possible patch for Seabios. Had
you the opportunity to find it ?<br>
<br>
Le 17/03/2015 08:23, Patrick Agrain a écrit :<br>
</div>
<blockquote cite="mid:5507D66A.5090409@alcatel-lucent.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<pre>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@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@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@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:
><i> Hello,
</i>><i>
</i>><i> One step further !!
</i>><i>
</i>><i> I succeed to get it working.
</i>><i>
</i>><i> Several modification has to be made. I will try (next week) to get them
</i>><i> in a "readable form".
</i>><i> - in ./src/device/pci_early.c:pci_early_bridge_init() :
</i>><i> -- secondary = 1 for Mohon Peak.
</i>
The value of 'secondary' should not matter here, it does not need to
match with the value you later see in lspci.
><i> -- remove udelay() in PCI_VENDOR_ID reading (that's the big point). I
</i>><i> will try to have a look at it. Probably something very specific to this
</i>><i> chipset.
</i>
No clue about that.
><i> -- Put 'if (ret)' condition on the last
</i>><i> 'pci_bridge_set_secondary(p2p_bridge, 0);'.
</i>
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.
><i> - in ./src/drivers/uart/oxpcie_early.c:pci_early_device_probe() :
</i>><i> -- uart1base is at CONFIG_EARLY_PCI_MMIO_BASE + 0x1200 for the Startech
</i>><i> board I have.
</i>><i>
</i>
What PCI ID did your card report again? Different IDs will use different
resource mapping, I'll need to compare against the datasheet.
><i> BTW, I also included the patch covered by
</i>><i> <a moz-do-not-send="true" href="http://review.coreboot.org/#/c/8660/.">http://review.coreboot.org/#/c/8660/.</a> Compiler does not complain anymore
</i>><i> (and 'in fine' it works).
</i>><i>
</i>
I have submitted iteration #2 of this change.
><i> Logs are now available from 'coreboot-<...> ramstage starting'.
</i>><i>
</i>
Let's try to make it work from the ".. romstage starting" message.
><i> Thanks for your support.
</i>><i> Regards,
</i>><i> Patrick Agrain
</i>><i>
</i>
Kyösti</pre>
</blockquote>
<br>
</body>
</html>