As an additional information, I've seen that :
1) coreboot was running at 0x4000. I've changed Options.lb in mainboard\intel\truxton :
-- default CONFIG_RAMBASE=0x00004000 ++ default CONFIG_RAMBASE=0x00100000
This did not compile so I've had to add :
++ uses CONFIG_LB_MEM_TOPK ++ default CONFG_LB_MEM_TOPK = 2 * 1024 * 1024
This did not change anything to the VGA problem, I think I will keep this that way, what you guys are thinking about this?
2) My auto.c patch is not consistent as this is called prior the enable_resource function in fact. The function enable_resource is using logical or operations. In this case I still gets some unwanted bits obviously. Actually yesterday I was very tired I guess. The value 0xb means 0b1011 :
2PERRE = 1, 2SERRE = 1 and VGAEN = 1.
I am not sure 2PERRE or 2SERRE would be any relevant around my problem. But the legacy BIOS do not set these to 1, this is a fact.
Actually what is the best way to get pciexp_porta.c to be included and replace the default PCI functions in src\devices ?
As an additional question:
1) Can these memory holes be cached or not. I guess these ranges should not correspond to a cacheable RAM section. Does coreboot cache the complete 0x0 to CONFIG_LB_MEM_TOPK area. The chipset configuration provide the complete memory range as coherent memory.
Thank you
Arnaud
Arnaud Maye wrote:
Myles Watson wrote:
The ep80579 has two x4 lanes peripherals (00:02.0 and 00:03.0) both of
You mean the i3100 here, right?
Yeah the EP80579 is a SOC ( System on chip ). It includes a IA32 core, a North Bridge and a South Bridge all on the same chip. In this respect talking about i3100 is not very correct I believe. It is clear they have a i3100 core there inside. it is just not named in fact. The ep80579 has an IMCH and a IICH.
The northbridge and southbridge are connected by a NSI ( North-South Interface ). This is in fact a custom transparent PCIe implementation. So finally most of the devices are on bus 0.
them having a register 0x3E. If you set ISAEN on 00:02.00 you have to set ISAEN on 00:03.00 as well. This is a requirement provided by Intel in fact. It makes sense as the address decoding is different as soon ISAEN is set. All th bridges should be set correctly.
These two peripherals can be coupled together providing x8 lanes.
Note that ISAEN is not set by the legacy BIOS, and the VGA output is working flawlessly. So in fact I just want to write 0x8 instead 0xb in register 0x3E. But this I can already do, just not at the correct place.
So where have you tried? File and function?
It looks like if that's the bit you want to set you need to have your own enable_resources function in pciexp_porta.c. Right now you're using the default.
In auto.c ( mainboard\intel\truxton ) I've created a enable_vga() function which only pci_write_config(dev, 0x3e, 8).
This function is called at the end of auto.c's main() after the ram_fill/ram_verify.
I agree, I need my own enable_resources function. This is the patch I've tried to do. I've attached the patch. In fact it is not called because I did not include it. I did expect this file to be correctly included as it is part of the initial port.
As you can see I have added a printk in pcie_init and I do not see that on the log.
With the GFX card connected to SLOT0, the PCIe is operating in coupled mode and actually configured as x8. This is because the current coreboot port does not set PEACAPA.SIMP to 1 in both bridge. As soon both 00:02.0 and 00:03.0 get PEACAPA.SIMP is set to 1, the two port are configured in x4. We can see that in PEALNKCAP.MLW. Checking legacy BIOS settings confirm PEACAPA.SIMP should be 1 in both PCIe ports.
So this should probably be done even earlier. That's not something that is fixed, right? Or do you want it coupled (or not) depending on what card gets plugged in?
Actually for a very generic port we should come up with some config options. About the truxton board, We have an architecture like the following :
PCIe PEA0 (4x) -> SLOT0 PCIe PEA1 (4x) -> PCIe SWITCH -> SLOT1 (1x), SLOT2 (1x), SLOT3 (1x), SLOT4 (1x)
For a truxton BSP we should not have both ports coupled as a (8x), Just imagine if you decide to have a GFX card on slot 0 and a ethernet card on SLOT2, this is not going to go very well.
I think having some CONFIG option for this would be great. And I think this should indeed happen in pcie_init().
Actually, there a are a few other things like that which are not important to describe so far I believe. Verifying all the registers value takes time. lspci legacy vs coreboot shows a lot of differences and in this respect I am checking them one by one using the datasheet. So it is likely some other things will pop up.
I guess the only thing left is that coreboot does not allocate a hole for the VGA, two holes are required I guess, MEM and IO. how can I check if a hole is actually reserved or not?
Look through the last resource tree in the boot log. It should be there.
You can always add them in read_resources.
I have attached my last log. I believe we have the correct hole :
PCI_DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 3 PCI_DOMAIN: 0000 resource base c0000 size 1ff40000 align 0 gran 0 limit 0 flags e0004200 index 4
We do not have anything between 0xa0000 and 0xc0000. These areas are in fact VGAA, MDA and VGAB.
Anything else I should verify?
Thank you,
Arnaud
* *
coreboot was running at 0x4000. I've changed Options.lb in mainboard\intel\truxton :
-- default CONFIG_RAMBASE=0x00004000 ++ default CONFIG_RAMBASE=0x00100000
This did not compile so I've had to add :
++ uses CONFIG_LB_MEM_TOPK ++ default CONFG_LB_MEM_TOPK = 2 * 1024 * 1024
This did not change anything to the VGA problem, I think I will keep this that way, what you guys are thinking about this?
It's fine with me. I guess it might make a difference for ACPI suspend/resume support.
My auto.c patch is not consistent as this is called prior the enable_resource function in fact. The function enable_resource is using logical or operations. In this case I still gets some unwanted bits obviously. Actually yesterday I was very tired I guess. The value 0xb means 0b1011 :
2PERRE = 1, 2SERRE = 1 and VGAEN = 1.
I am not sure 2PERRE or 2SERRE would be any relevant around my problem. But the legacy BIOS do not set these to 1, this is a fact.
I don't think they should be a problem, but you can set any value you'd like once we get your driver loading.
Actually what is the best way to get pciexp_porta.c to be included and replace the default PCI functions in src\devices ?
The boot log helped, see below.
As an additional question:
Can these memory holes be cached or not. I guess these ranges should not correspond to a cacheable RAM section. Does coreboot cache the complete 0x0 to CONFIG_LB_MEM_TOPK area.
Coreboot doesn't cache the VGA hole.
Arnaud Maye wrote:
Myles Watson wrote:
The ep80579 has two x4 lanes peripherals (00:02.0 and 00:03.0) both of
You mean the i3100 here, right?
Yeah the EP80579 is a SOC ( System on chip ). It includes a IA32 core, a North Bridge and a South Bridge all on the same chip. In this respect talking about i3100 is not very correct I believe. It is clear they have a i3100 core there inside. it is just not named in fact. The ep80579 has an IMCH and a IICH.
OK. I think we're going to get there. It looks like your driver doesn't get registered for the device because the PCI IDs don't match.
From your boot log:
PCI: 00:02.0 subordinate bus PCI Express PCI: 00:02.0 [8086/5024] enabled PCI: 00:03.0 subordinate bus PCI Express PCI: 00:03.0 [8086/5025] enabled
Those IDs match the EP80579 defines in /src/include/device/pci_ids.h, but there is no driver defined which uses that ID.
Copy the drivers in /src/northbridge/intel/i3100/pciexp_porta.c, rename them, and have them use the correct PCI IDs. That should make your functions get called.
Thanks, Myles
Myles Watson wrote:
coreboot was running at 0x4000. I've changed Options.lb in mainboard\intel\truxton :
-- default CONFIG_RAMBASE=0x00004000 ++ default CONFIG_RAMBASE=0x00100000
This did not compile so I've had to add :
++ uses CONFIG_LB_MEM_TOPK ++ default CONFG_LB_MEM_TOPK = 2 * 1024 * 1024
This did not change anything to the VGA problem, I think I will keep this that way, what you guys are thinking about this?
It's fine with me. I guess it might make a difference for ACPI suspend/resume support.
My auto.c patch is not consistent as this is called prior the enable_resource function in fact. The function enable_resource is using logical or operations. In this case I still gets some unwanted bits obviously. Actually yesterday I was very tired I guess. The value 0xb means 0b1011 :
2PERRE = 1, 2SERRE = 1 and VGAEN = 1.
I am not sure 2PERRE or 2SERRE would be any relevant around my problem. But the legacy BIOS do not set these to 1, this is a fact.
I don't think they should be a problem, but you can set any value you'd like once we get your driver loading.
Actually what is the best way to get pciexp_porta.c to be included and replace the default PCI functions in src\devices ?
The boot log helped, see below.
As an additional question:
Can these memory holes be cached or not. I guess these ranges should not correspond to a cacheable RAM section. Does coreboot cache the complete 0x0 to CONFIG_LB_MEM_TOPK area.
Coreboot doesn't cache the VGA hole.
Arnaud Maye wrote:
Myles Watson wrote:
The ep80579 has two x4 lanes peripherals (00:02.0 and 00:03.0) both of
You mean the i3100 here, right?
Yeah the EP80579 is a SOC ( System on chip ). It includes a IA32 core, a North Bridge and a South Bridge all on the same chip. In this respect talking about i3100 is not very correct I believe. It is clear they have a i3100 core there inside. it is just not named in fact. The ep80579 has an IMCH and a IICH.
OK. I think we're going to get there. It looks like your driver doesn't get registered for the device because the PCI IDs don't match.
From your boot log:
PCI: 00:02.0 subordinate bus PCI Express PCI: 00:02.0 [8086/5024] enabled PCI: 00:03.0 subordinate bus PCI Express PCI: 00:03.0 [8086/5025] enabled
Those IDs match the EP80579 defines in /src/include/device/pci_ids.h, but there is no driver defined which uses that ID.
Copy the drivers in /src/northbridge/intel/i3100/pciexp_porta.c, rename them, and have them use the correct PCI IDs. That should make your functions get called.
Thanks, I am going to try that as soon I reach the office on Monday. I will keep you updated.
Would it make sense to create an ep80579 folder for both the north and south bridges? That way we would avoid having things like ep80579_raminit.c and raminit.c in the i3100 folder.
src/northbridge/intel/ep80579/ and src/southbridge/ep80579
i3100's codename is toledo and ep80579's codename is tolapai
Thank you,
Arnaud
OK. I think we're going to get there. It looks like your driver
doesn't
get registered for the device because the PCI IDs don't match.
From your boot log:
PCI: 00:02.0 subordinate bus PCI Express PCI: 00:02.0 [8086/5024] enabled PCI: 00:03.0 subordinate bus PCI Express PCI: 00:03.0 [8086/5025] enabled
Those IDs match the EP80579 defines in /src/include/device/pci_ids.h,
but
there is no driver defined which uses that ID.
Copy the drivers in /src/northbridge/intel/i3100/pciexp_porta.c, rename them, and have them use the correct PCI IDs. That should make your functions get called.
Thanks, I am going to try that as soon I reach the office on Monday. I will keep you updated.
Thanks.
Would it make sense to create an ep80579 folder for both the north and south bridges? That way we would avoid having things like ep80579_raminit.c and raminit.c in the i3100 folder. src/northbridge/intel/ep80579/ and src/southbridge/ep80579
I don't know. How much code would get duplicated? If they're very similar it might not be worth it. I realize it causes confusion, though.
Thanks, Myles
Myles Watson wrote:
OK. I think we're going to get there. It looks like your driver
doesn't
get registered for the device because the PCI IDs don't match.
From your boot log:
PCI: 00:02.0 subordinate bus PCI Express PCI: 00:02.0 [8086/5024] enabled PCI: 00:03.0 subordinate bus PCI Express PCI: 00:03.0 [8086/5025] enabled
Those IDs match the EP80579 defines in /src/include/device/pci_ids.h,
but
there is no driver defined which uses that ID.
Copy the drivers in /src/northbridge/intel/i3100/pciexp_porta.c, rename them, and have them use the correct PCI IDs. That should make your functions get called.
Thanks, I am going to try that as soon I reach the office on Monday. I will keep you updated.
Thanks.
Would it make sense to create an ep80579 folder for both the north and south bridges? That way we would avoid having things like ep80579_raminit.c and raminit.c in the i3100 folder. src/northbridge/intel/ep80579/ and src/southbridge/ep80579
I don't know. How much code would get duplicated? If they're very similar it might not be worth it. I realize it causes confusion, though.
I guess, we will decide that later on, I would love to get VGA working even if the files remain in the i3100 folder.
Let's see that next week. I have an important amount of code to write for a few other projects over the week-end.
Talk you you next week, enjoy your free time this we if you have any.
Thanks Myles and Ron for all your time spent around this with me, this is well appreciated and invaluable.
Myles Watson wrote:
OK. I think we're going to get there. It looks like your driver
doesn't
get registered for the device because the PCI IDs don't match.
From your boot log:
PCI: 00:02.0 subordinate bus PCI Express PCI: 00:02.0 [8086/5024] enabled PCI: 00:03.0 subordinate bus PCI Express PCI: 00:03.0 [8086/5025] enabled
Those IDs match the EP80579 defines in /src/include/device/pci_ids.h,
but
there is no driver defined which uses that ID.
Copy the drivers in /src/northbridge/intel/i3100/pciexp_porta.c, rename them, and have them use the correct PCI IDs. That should make your functions get called.
Thanks, I am going to try that as soon I reach the office on Monday. I will keep you updated.
Thanks.
Hello Gents,
So by following your advices I could get my function called. I had no time to retrieve the current sources patch from the development board, but basically I've pretty much got same settings and status as the legacy BIOS does.
Unfortunately, I still cannot get a VGA output. I start to get coherent graphic output as soon Linux loads the driver, but not before that.
Would you guys have a few additional pointers I could check?
Thank you
Arnaud
* *
So by following your advices I could get my function called. I had no time to retrieve the current sources patch from the development board, but basically I've pretty much got same settings and status as the legacy BIOS does.
I'm glad that worked for you.
Unfortunately, I still cannot get a VGA output. I start to get coherent graphic output as soon Linux loads the driver, but not before that.
Would you guys have a few additional pointers I could check?
I would look in targets/intel/truxton/truxton/fallback/ldoptions
Check the values of CONFIG_VGA, CONFIG_CONSOLE_VGA...
maybe cat targets/intel/truxton/truxton/fallback/ldoptions | grep VGA cat targets/intel/truxton/truxton/fallback/ldoptions | grep ROM
make sure that you have it configured as you expect.
If that doesn't help, send the log file and ldoptions to the list.
Thanks, Myles
I would look in targets/intel/truxton/truxton/fallback/ldoptions
Check the values of CONFIG_VGA, CONFIG_CONSOLE_VGA...
maybe cat targets/intel/truxton/truxton/fallback/ldoptions | grep VGA cat targets/intel/truxton/truxton/fallback/ldoptions | grep ROM
make sure that you have it configured as you expect.
If that doesn't help, send the log file and ldoptions to the list.
This is not going to be required. I have the VGA output.. Actually "Global SMRAM Enable" was set to '1'
The description of this bit is quite confusing.
0 = The compatible SMRAM functions are disabled. 1 = The compatible SMRAM functions are enabled, providing 128 Kbyte of DRAM accessible at the 0xA0000 address while in SMM (ADS# with SMM decode).
The SMM configuration of a few other bits would cause this range to be open as well as non locked so this seemed to be correct, I've actually I've tried to disable this bit a few days ago but then the memory test failed on the 0xA0000 range. By failed I mean the value read back from the memory at this time was always 0xFFFFFFFF. I assumed this a a misbehavior and did set back this bit to '1' as it was initially.
Today I've been trying to disable the memory test and reset this bit again. This made that the VGA output is consistent and as expected.
So actually the PCIe configuration was not in cause. Even if quite a few bits in the PCIe configuration does not match the Intel recommendation it seems they are not such a big deal. I will however keep my pciexp_porta_ep80579 file in there.
I still have some work around the southbridge configuration (PS2 input), I will keep you guys updated.
Thank you for your help guys!
Arnaud
* *