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:
/ 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