Re: [coreboot] [Mohon Peak] Memtest86+
Hi guys, I answer to myself. I solved this part of the issue. First, referring to: http://www.coreboot.org/Memtest86, I built a coreboot including memtest86+ as payload. Then, using cbfstool I extracted it to a file, ignoring the warning concerning the raw type. At last, rebuild a coreboot with seabios as payload, and add the previous file with cbfstool as another payload. That way, in combination with sgabios, I'm able to boot the Mohon Peak, 'ESC' to the boot menu and choose the 'Memtest86+' entry. The RAM test is then performing in a loop. What remains to fix is the keyboard entry through the serial link in order to access to the memtest86+ menu... (Almost the same as in http://www.coreboot.org/pipermail/coreboot/2015-February/079173.html) Hope it helps. Regards, Patrick agrain Le 14/04/2015 16:22, Patrick Agrain a écrit : Hello, I try to perform some memory test on the Mohon Peak CRB with memtest86+. I downloaded memtest86+ v5.01 and compile it. So far, so good. Following the thread: http://www.coreboot.org/pipermail/coreboot/2015-January/079143.html concerning this topic, I modified the given values, so that now: [root@localhost memtest86+-5.01]# readelf -e memtest1modified ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x1 Start of program headers: 52 (bytes into file) Start of section headers: 151580 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 40 (bytes) Number of section headers: 3 Section header string table index: 2 Section Headers: [Nr] Name TypeAddr Off Size ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .data PROGBITS0001 001000 024008 00 WA 0 0 1 [ 2] .shstrtab STRTAB 025008 11 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x01 0x0001 0x0001 0x24008 0x24008 RW 0x20 Section to Segment mapping: Segment Sections... 00 .shstrtab [root@localhost memtest86+-5.01]# What gives the same scheme as in the previously mentionned thread. Now the logs of the booting Mohon Peak (from begin of Seabios): SeaBIOS (version rel-1.8.0-12-ga1ac886-dirty-20150402_003540-localhost.localdomain) init usb EHCI init on dev 00:16.0 (regs=0xdfe89420) set_address 0x7fd41b80 config_usb: 0x7fd41a50 device rev=0200 cls=09 sub=00 proto=01 size=64 init serial Found 2 legacy serial ports init hard drives init ahci AHCI controller at 17.0, iobase dfe88000, irq 15 AHCI: cap 0xc720ff03, ports_impl 0x0 AHCI controller at 18.0, iobase dfe88800, irq 0 AHCI: cap 0xc3309f01, ports_impl 0x1 AHCI/0: probing AHCI/0: link up AHCI/0: ... finished, status 0x51, ERROR 0x4 Searching bootorder for: /pci@i0cf8/*@18/drive@0/disk@0 AHCI/0: registering: AHCI/0: ST500DM002-1BD142 ATA-8 Hard-Disk (465 GiBytes) Registering bootable: AHCI/0: ST500DM002-1BD142 ATA-8 Hard-Disk (465 GiBytes) (type:2 prio:103 data:f3ef0) Searching bootorder for: /rom@img/Memtest86+ Registering bootable: Payload [Memtest86+] (type:32 prio: data:ffe23240) Scan for option roms Attempting to init PCI bdf 00:00.0 (vd 8086:1f08) Attempting to init PCI bdf 00:01.0 (vd 8086:1f10) Attempting to init PCI bdf 00:03.0 (vd 8086:1f12) Attempting to init PCI bdf 00:0e.0 (vd 8086:1f14) Attempting to init PCI bdf 00:0f.0 (vd 8086:1f16) Attempting to init PCI bdf 00:13.0 (vd 8086:1f15) Attempting to init PCI bdf 00:14.0 (vd 8086:1f41) Attempting to init PCI bdf 00:14.1 (vd 8086:1f41) Attempting to init PCI bdf 00:16.0 (vd 8086:1f2c) Attempting to init PCI bdf 00:17.0 (vd 8086:1f22) Attempting to init PCI bdf 00:18.0 (vd 8086:1f32) Attempting to init PCI bdf 00:1f.0 (vd 8086:1f38) Attempting to init PCI bdf 00:1f.3 (vd 8086:1f3c) Attempting to init PCI bdf 01:00.0 (vd 1415:c158) Attempting to init PCI bdf 02:00.0 (vd 10b5:8624) Attempting to init PCI bdf 03:04.0 (vd 10b5:8624) Attempting to init PCI bdf 03:05.0 (vd 10b5:8624) Attempting to init PCI bdf 03:08.0 (vd 10b5:8624) Attempting to init PCI bdf 05:00.0 (vd 8086:1528
[coreboot] [Mohon Peak] Memtest86+
- 00018000 = 1 RAM Jump to int19 enter handle_19: NULL Booting from CBFS... Run img/Memtest86+ Segment 464c457f 16777216@0xffe23268 - 256@0x02000300 No support for compression type 10101 enter handle_18: NULL Booting from :7c00 GRUB Loading stage2. Output on the SERIAL line.. enter handle_12: a= b= c= d=0080 ds= es= ss= si=811e di=00028da8 bp=1ff0 sp=1ff4 cs= ip=8a82 f=0297 no switch back. GRUB version 0.5.96 (638K lower / 2093604K upper memory) +-+ | Boot GNU/Linux [ll-ttyS1-115K2] | | Boot GNU/Linux [xx-ttyS1-115K2] | | Boot GNU/Linux [xx-ttyS1-115K2] | | Boot GNU/Linux [default]| | Install GRUB into the hard disk | | | | | | | | | | | | | | | +-+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. After pressing 'ESC' and select '2', I'm not able to boot memtest86+, and fall back to the hard drive. Has anyone already faced this behavior. Thanks in advance. Best regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Solved][Mohon Peak] Console output on external UARTs behind PCIe
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 :01:00.0 vendor=1415 device=c158 class=0700 irq=10 (pin 1) BAR[0] PCI memory @0xdf60, Useful size is 16384. : 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:03F8 irq:4 tx:0 rx:0 1: uart:16550A port:02F8 irq:3 tx:59 rx:0 RTS|DTR 2: uart:unknown port:03E8 irq:11 3: uart:unknown port:02E8 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: irq:0 7: uart:unknown port: 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
Re: [coreboot] [Almost solved][Mohon Peak] Console output on external UARTs behind PCIe
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 :01:00.0 vendor=1415 device=c158 class=0700 irq=10 (pin 1) BAR[0] PCI memory @0xdf60, Useful size is 16384. : 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:03F8 irq:4 tx:0 rx:0 1: uart:16550A port:02F8 irq:3 tx:59 rx:0 RTS|DTR 2: uart:unknown port:03E8 irq:11 3: uart:unknown port:02E8 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: irq:0 7: uart:unknown port: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Almost solved][Mohon Peak] Console output on external UARTs behind PCIe
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 -[: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 df60 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at df20 (32-bit, non-prefetchable) [size=2M] Region 2: Memory at df40 (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 0700 should be 0100 :01:00.0: ttyS2 at MMIO 0xdf601000 (irq = 16) is a 16C950/954 ttyS3: detected caps 0700 should be 0100 :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
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
] 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 0xfef0 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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
Thanks Marc and Kyösti for your hints. As I'm just discovering coreboot and its multiple possibilities, please apologize if my questions seems too simple... ;-) A) UART Type --- From Kconfig file in ./src/drivers/uart, the valid ID for the oxpcie is 1415:c158. I can obtain this ID on my Startech board only when I strapped it as native UART (Startech documentation), that is : memory-mapped. From Kconfig file in ./src/console, there is following sentence : Supporting multiple different types of UARTs in one build is not supported.. Q: Am I correct if I translate this like : Use only memory-mapped or IO-mapped UARTs, but not both at the same time. ? B) Memory-mapped UART required options -- From the answers received, I would say that the required options (in make menuconfig) would be: - In Generic Drivers: validate Oxford OXPCIe952 and de-validate Serial Port on SuperIO. - In Devices: Set the device and function numbers of the PCie bridge, behind which is connected the Startech board. On Mohon Peak, it's D1-F0. Q: What about the MMIO window base ? Is it the memory address of the UARTs, defined by the values in the BAR registers ? - in Console: Validate Serial Port Console Output. Q: What about the index of the Serial Port console output ? IMHO, there are only valid for IO-mapped UART. Correct ? Q: Am I missing anything ? Thanks in advance for the time you want to spent on it. Regards, Patrick Le 06/03/2015 19:01, Marc Jones a écrit : Hi Patrick, You can look at the Oxford pcie card and 8250MEM drivers for reference: src/drivers/uart/oxpcie* src/drivers/uart/uart8250mem* Marc On Fri, Mar 6, 2015 at 9:37 AM Patrick Agrain patrick.agr...@alcatel-lucent.com mailto:patrick.agr...@alcatel-lucent.com 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 ? 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 ? Thanks in advance. Best regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org mailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
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 ? 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 ? Thanks in advance. Best regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [SOLVED] Read the Coreboot version in the .rom binary
Hi Patrick, Thanks for the tip and the related code snippet. It works like a charm. Best regards, Patrick Agrain Am 2015-01-28 15:39, schrieb Patrick Agrain: Is there a way to read the coreboot version (as a string or as binary chain) from inside the build coreboot.rom file. On x86, it's stored through src/arch/x86/lib/id.inc It's a somewhat arcane format (historically grown), and is typically ends 0x80 bytes before the end of the image. The last 4 qwords are the .long values from which you can calculate the address of the version field http://review.coreboot.org/gitweb?p=filo.git;a=blob;f=flashupdate/flashupdate.c;h=c0f337d94dc2d4d6cd5c6c4a1746248206d202e7;hb=dd51816080264c2719781ffc5fb40b4de2b0b3d2#l69 test_id_section() and its caller provide an example for parsing that. Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Read the Coreboot version in the .rom binary
Hello all, Is there a way to read the coreboot version (as a string or as binary chain) from inside the build coreboot.rom file. We wish to upgrade the binary in the flash ROM (by a userspace tool calling 'flashrom') only when necessary. Reading the flashed version can be made by a 'cat /sys/class/dmi/id/bios_version'. What is missing is the version of the new binary to compare them. Kind regards, Patrick Agrain -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SOLVED] Internal Ethernet controller on Mohon Peak CRB failed to get activated
Hello, This issue is solved. Fei, your tip concerning the Intel Firmware Descriptor was good. Another tip came from here: http://www.sublab.org/wiki/coreboot-x201/ I've found an Intel tool 'fict', with which I could build a valid descriptor (checked by the 'ifdtool'). Enabling the INCLUDE_ME and ME_PATH in coreboot does the rest. Now, the Mohon Peak CRB boots with all internal GbE enabled and functionning. Thank to all. Kind regards, Patrick Agrain Le 05/01/2015 15:37, Alexander Couzens a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 5 Jan 2015 13:49:05 +0100 Patrick Agrain patrick.agr...@alcatel-lucent.com wrote: Hello Fei, Thanks for your answer. Indeed, the INCLUDE_ME and ME_PATH are not configured, because I do not really know what is the constitution of a descriptor.bin file. May anybody have any pointer which could explain me what it is ? It's the intel management engine. It's does some power management and a lot other things. It's a cpu and has access to *everything* like ram, chipset, ... http://www.coreboot.org/Intel_Management_Engine Best, lynxis - -- Alexander Couzens mail: lyn...@fe80.eu jabber: lyn...@jabber.ccc.de mobile: +4915123277221 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJUqqGTAAoJEMKenaag34YEWukP/j0HO36Y9L/ruP2r1Jfk04Ti RqBIP1tzWVcBEjTTJqF55bO5+Dz5sWsbqTxYfdfWxYE+EOHyxm/eET2vgYNsL4Se XZUdw09RWGHP3nwvp0KpGgWDYn+mUhjr6zGnI6Bx+mhiW0k+T82c4IlSMJsLZhRD e73Gzp5Br6Aa2VA9KY9HCvG7jS04eAOVG4ewVDfj1yR0UA6hTSfrmdiINU4R+BVc wneKp5xcdKIoHNT2TrgTBefyibeiGzoltGR0dZ5B03VMxxvBT56dcsCQt7LlaOTm 48ZkkQl3/uPnISXkGXD5BDpwEOq730lNlF0ldmRG0KQpOdg0w9JE/9M9onuKU0tm fmkrgNXWjVit7AFzay9pe0xAzzQaseJHjZ+PbA/HEziDEOYGpan0w4e+cZHjlOZM ZO9b41yLAkTcYq9SPHu6EWoCExFXvvgZCd7u7UFrfeha+rdqcrIBqWw3WNTspVam PSBxmotfSaPWQLhApj0n4vnZRR8Y7kid8AZE2wfyD8ro7paB8wLqYMZFtTrKQv85 QCbveDJbzMqa7s4sB1nSuoTWYQzoY2uNrZUoFZhKF1HU8nrTi+u8s5ZsqMgZZyEl DhOFuaiA/mpVhlWEikv6T+6IEgEN5yND8LTck50MxvCMcDHJ4OEQM5k8WddXKVWo McmgvLZ5qufpka30pafL =WE05 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
