[Mohon Peak] Console output on external UARTs behind PCIe

[Patrick Agrain]

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

[Kyösti Mälkki]

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

[Mohon Peak] Console output on external UARTs behind PCIe

[Patrick Agrain]

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

[Mohon Peak] Console output on external UARTs behind PCIe

[Patrick Agrain]

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@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@mohon_peak ~]#
[root@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@mohon_peak ~]#
[root@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@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

[Kyösti Mälkki]

On Thu, 2015-03-12 at 10:02 +0100, Patrick Agrain wrote:
> 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...

Ok, just checking.

I need to correct my previous statement in that I do not know anyone
(yet) using OxPCIe with the specific intel chipset you have there, but
an older one. It is possible those PCI-e root ports are not yet
initialized/trained when we attempt the PCI ID detection for the UART
card.
> Here are the lspci information from a Mohon Peak.
> [root@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@mohon_peak ~]#
> [root@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

I think EARLY_PCI parameters are fine if you also assigned MMIO_BASE
with 0xdf000000.
> [root@mohon_peak ~]#
> [root@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@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

Ah.. there is a recent regression with source. With complain like that
it will not build you a new firmware binary at all, so it makes me
wonder what you were actually testing before.

Here is quick (but untested) fix for the build problem:

http://review.coreboot.org/#/c/8660/

For a test run, I would need to disassemble a samsung/lumpy that I know
OxPCIe works well with. That won't happen for at least a week.

Kyösti

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

[Patrick Agrain]

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@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@mohon_peak ~]#
> [root@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@mohon_peak ~]#
> [root@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@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

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

[Kyösti Mälkki]

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

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

[Patrick Agrain]

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

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

[Patrick Agrain]

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@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