coreboot

Placeholder

I will try and be more clear of the problem. The realtek card is not detected during coreboot initialization: Seabios cannot boot with the correct ipxe rom for this model 10ec:8168 because there is no card present.
During coreboot pci initialization of the 1c.1 root port:
PCI: Static device PCI: 00:03:00.0 not found, disabling it.
Once linux boots the card is found and operates correctly under the same root port 1c.1

Motherboard: Asus p5g41c-m lx
CPU : Pentium(R) Dual-Core CPU E6500 @ 2.93GHz
Superio: Winbond W83627DHG-P/-PT
Coreboot: 26.06
Payload: Seabios 17.0

It is likely that the PCIe root port on the southbridge (device pci 1c.X in the devicetree/overridetree, where X is a number between 0 and 5) used for LAN on your board is disabled. You could try enabling all 6 PCIe root ports and see if this helps.

Note that cross-flashing (i.e. flashing a firmware image for board A to board B) is highly discouraged, and in extreme cases might even cause damage to the board due to e.g. improper GPIO configuration. Ideally, support for the P5G41C-M LX would be added as another variant. You can use https://github.com/Th3Fanbus/gpio-scripts/blob/50a31df72c7a3305338472c13abf269cf1f29546/gengpio.c to create a gpio.c for your mainboard (replace the values in lines 23 to 36 with the values from util/inteltool/inteltool -g while running vendor firmware on the P5G41C-M LX). The Super I/O settings should also be checked as they might be different on your board.

Hi Angel,

Thank you for your response. I turned on all the pcie ports that you mentioned and that did not help.
I am very aware of the not using gpio from a different board. Kyosti Malkki was kind enough to help me out with this. So I did create the gpio.c specifically for this board.
The superio settings do actually affect whether the card eventually appears once linux boots. It seems to be one of the following:

irq 0xf3 = 0x09
irq 0xf4 = 0x64
irq 0xf5 = 0xce

Here is the OEM superiotool dump of the GPIOs

LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5)
idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fe
val 0d ff 21 20 ff 00 00 00 ff ff ff ff ff ff 09 64 ce 00 00 00 ff ff ff
def 00 ff 00 00 ff 00 00 00 00 00 00 ff 00 00 00 ff 00 00 00 00 00 00 00

Here is what I get with coreboot:
NOTE: I have tried setting 0xe2 to 0x20, but if I do that 0xe1 changes to 0x01 and 0xe2 changes to 0x00

LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5)
idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fe
val 0d ff 21 00 ff 00 00 00 ff 80 00 ff ff ff 09 64 ce 00 00 00 ff ff ff
def 00 ff 00 00 ff 00 00 00 00 00 00 ff 00 00 00 ff 00 00 00 00 00 00 00

Thanks again.

Hi Gabriel,

You may want to check the Super I/O datasheet to see what the registers do. Each GPIO bank has a set of registers, with one bit per GPIO:

• I/O register: controls whether GPIOs are inputs or outputs
• Data register: shows/controls the logic level of GPIOs (read-only for inputs, read-write for outputs)
• Inversion register: controls whether the value in the data register is inverted ("data register value" = "actual GPIO logic level" XOR "inversion register value")
• Status register: read to clear, set when a rising/falling edge is detected on a GPIO

I'm not sure what 0xf3 controls, the bits being set to one appear as reserved in my datasheet. But 0xf4/0xf5 are GPIO4 I/O and data registers respectively. Looking at the boardview, pin 79 (GP46) is directly connected to the "ISOLATE" pin of the Realtek NIC, which makes the NIC stop responding over PCIe as long as the pin is asserted (not sure if it's active-high or active-low). To make this work, you may want to try programming the Super I/O GPIOs in bootblock/romstage. At the very least, program the registers for GPIO4.

You should also make sure that the BSEL code for the other two variants (early_init.c) doesn't interfere with these Super I/O GPIO settings. On this board, looks like Super I/O pins 82 and 81 (GP43 and GP44) are connected to BSEL1 and BSEL2, respectively. BSEL0 does not seem to be connected to the Super I/O. However, on the boardview I am looking at, it seems that some resistors are missing so the Super I/O GPIOs do not actually connect to the BSELx pins at all, so you may want to skip the code in setup_sio_gpio() (which actually overwrites GPIO4 values).

About 0xe1/0xe2: 0xe2 is GPIO5 inversion register, and 0xe1 is GPIO5 data register. 0xe0 is GPIO5 input/output register and its value is 0xff (all GPIOs are inputs). So, writing 0x20 to 0xe2 will flip the value of the corresponding bit in 0xe1. Given that, I would program 0xe2 the same as vendor firmware, even if the value in 0xe1 is "more different" in this case (0xe1 is just showing the values on GPIO5 pins, which are configured as inputs).

Hi Angel,

Since I am not much of a programmer, I took your suggestion and just looked in early_init.c and commented out the gpio4, gp43 and gp44 settings. POOF not only does the realtek card now show up, but the board does not do an infinite reset loop when using the reboot command (I would have to do a full power off to reboot cleanly). Not sure how I can formally transform this into a proper port, but as far as I now know everything works well. Thank you very much.

Gabriel

Gabriel Turlea wrote in #note-10:

Not sure how I can formally transform this into a proper port

For a start you can copy the whole variants/p5g41t-m_lx and rename the folder and add all the Kconfig(.name) options to your port by copy pasting the earlier P5G41T_M_LX variant as an example and also inside the variant folder replace the gpio.c with yours as far as I understand your overridetree.cb remained the same? Do note that Kconfig itself uses only underscores _ and CAPITALS for its references, so don't get confused naming your variant which has a dash-!

Than you may add a elif (CONFIG(BOARD_ASUS_P5G41C_M_LX)) {#bsel/gpio stuff} to the early_init.c to make a extra condition for your specific port use the exact same name you called it in the Kconfig and copy paste the bsel/gpio changes you need there. You probably also need to add a similar condition at the end for your SPD map aswell since you have 4 DIMM slots vs the 2 DIMMS used in the earlier 2 variants.

If the original BOARD_ASUS_P5QPL_AM & P5G41T_M_LX variants still build with their original make -jX BUILD_TIMELESS=1 CONFIG_INCLUDE_CONFIG_FILE=n hash as before you started using all your edited code, and your own BOARD_ASUS_P5G41C_M_LX also builds with these new guarded conditions you may have a working 1st variant port :D?

After that you may do a gerrit commit see coreboot docs tutorial part 2?

Thank you Walter. I will do that.

Hi Walter,

To finish this up I tried to enable the DDR2 slots in early_init.c with the spd_map directive.
DDR2 fails to boot with : coreboot could not find common memory frequency and cas

Cheers,
Gabriel

Perhaps the note from src/mb/asus/p5ql-em/early_init.c note applies?

/* This board has first dimm slot of each channel hooked up to
	   rank0 and rank1, while the second dimm slot is only connected
	   to rank1. The raminit does not support such setups. So only the
	   first dimms of each channel are used. */

Did 4 DIMM's work for you on the OEM firmware or with coreboot? If so can you check on OEM firmware with 1 DIMM at the time the output of i2cdetect -l lookup SMBus number if it resides at position 0 do i2cdetect -r 0 type y and look how the hex table changes at row 50 while you move the DIMM to the next slot on the next boot till you separate tested each individual slot and logged the i2c hex. You may need to modprobe i2c-dev ? i2c-smbus first?

Perhaps try?:

spd_map[0] = 0x50; /* channel 0 DIMM 0 */
spd_map[1] = 0x52; /* channel 0 DIMM 1 */
spd_map[2] = 0x51; /* channel 1 DIMM 0 */
spd_map[3] = 0x53; /* channel 1 DIMM 1 */