[coreboot] Intel P35/Q35/G33/Q33/G31/P31
Here is a patch for inteltool to print the registers values
for the P31..Q35 chipset. The registers are (as far as I
can tell) unchanged with respect to those of the PM965.
I've no strong ideas on the names: I've chosen
PCI_DEVICE_ID_INTEL_82[PQG]3[135] as Northbridge
names, they can obviously be changed to anything else. I've
given Q35, P35/G33/G31/P31 and Q33 as descriptions,
they can also be freely changed.
Signed-off-by: Loïc Grenié loic.gre...@gmail.com
Description: adds 82Q35/P35/Q33/G33/G31/P31 capability.
Please consider for applying,
Thanks,
Loïc
Index: inteltool.h
===
--- inteltool.h (revision 4892)
+++ inteltool.h (working copy)
@@ -52,6 +52,9 @@
#define PCI_DEVICE_ID_INTEL_82945GM 0x27a0
#define PCI_DEVICE_ID_INTEL_PM965 0x2a00
#define PCI_DEVICE_ID_INTEL_82975X 0x277c
+#define PCI_DEVICE_ID_INTEL_82Q35 0x29b0
+#define PCI_DEVICE_ID_INTEL_82G33 0x29c0
+#define PCI_DEVICE_ID_INTEL_82Q33 0x29d0
#define PCI_DEVICE_ID_INTEL_X58 0x3405
#define PCI_DEVICE_ID_INTEL_82443LX 0x7180
Index: pcie.c
===
--- pcie.c (revision 4892)
+++ pcie.c (working copy)
@@ -39,6 +39,9 @@
epbar_phys = pci_read_long(nb, 0x40) 0xfffe;
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
epbar_phys = pci_read_long(nb, 0x40) 0xfffe;
epbar_phys |= ((uint64_t)pci_read_long(nb, 0x44)) 32;
break;
@@ -86,6 +89,9 @@
dmibar_phys = pci_read_long(nb, 0x4c) 0xfffe;
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
dmibar_phys = pci_read_long(nb, 0x68) 0xfffe;
dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) 32;
break;
@@ -135,6 +141,9 @@
pciexbar_reg = pci_read_long(nb, 0x48);
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
pciexbar_reg = pci_read_long(nb, 0x60);
pciexbar_reg |= ((uint64_t)pci_read_long(nb, 0x64)) 32;
break;
Index: memory.c
===
--- memory.c (revision 4892)
+++ memory.c (working copy)
@@ -40,6 +40,9 @@
mchbar_phys = pci_read_long(nb, 0x44) 0xfffe;
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
mchbar_phys = pci_read_long(nb, 0x48) 0xfffe;
mchbar_phys |= ((uint64_t)pci_read_long(nb, 0x4c)) 32;
break;
Index: inteltool.c
===
--- inteltool.c (revision 4892)
+++ inteltool.c (working copy)
@@ -39,6 +39,9 @@
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82945GM, i945GM },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PM965, PM965 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82975X, i975X },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q35, Q35 },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82G33, P35/G33/G31/P31 },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q33, Q33 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_X58, X58 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10R, ICH10R },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8M, ICH8-M },
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Error executing VGA ROM with coreboot
Mansoor wrote: maybe the graphics driver in Linux has the ability to initialize hardware completely? I tried this option. But it didn't initialize VGA Ok. If you prefer this solution you could, as I mentioned, try to contact the Linux graphics driver developers. There are people from Intel working actively there. Search keyword is drm-intel Second, you can use both SeaBIOS and FILO together. Thanks for the detailed explanation. I am using this method as an alternative (coreboot loads SeaBIOS then SeaBIOS loads FILO, FILO loads Linux) now. And it works fine. Nice! Extra boot time is the seaBIOS hardware initialization time... and I say it is negligible compared to the 20-30 sec delay of factory BIOS. He-he. :) //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] D945GCLF
If anyone does want to work on the D945GCLF board then you need to update the sdram_enable_memory_clocks in northbridge/intel/i945/raminit.c in a way that does not break the mobile version. The desktop version of the chipset has more clocks and so uses more bits in C0DCLKDIS and C1DCLKDIS to control them. Instead of bits 01 and 23, you need to use bits 012 and 345. A quick and dirty hack to get this going would seem to be to define OVERRIDE_CLOCK_DISABLE. Sorry but I don't have time to do this myself but I thought the information might be useful to somebody. It should be enough to get RAM init working. Andrew -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot hangs on my AMD fam10 board(updatedebugmessage).
On Mon, Nov 02, 2009 at 02:25:23PM +0800, Bao, Zheng wrote: Now I found that the system doesn't hang. It just decompresses the image. It is unbearably slow. Do you guys know why it does so slowly? Ah! I saw that too on Fam10. Mansoor suggested setting CONFIG_XIP_ROM_BASE to solve this. Does that help? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4905 - trunk/util/inteltool
Author: hailfinger
Date: 2009-11-02 16:01:49 +0100 (Mon, 02 Nov 2009)
New Revision: 4905
Modified:
trunk/util/inteltool/inteltool.c
trunk/util/inteltool/inteltool.h
trunk/util/inteltool/memory.c
trunk/util/inteltool/pcie.c
Log:
Add 82Q35/P35/Q33/G33/G31/P31 support to inteltool.
The registers are (as far as I can tell) unchanged with respect to those
of the PM965.
Signed-off-by: Lo?\195?\175c Greni?\195?\169 loic.gre...@gmail.com
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Modified: trunk/util/inteltool/inteltool.c
===
--- trunk/util/inteltool/inteltool.c2009-11-01 09:18:23 UTC (rev 4904)
+++ trunk/util/inteltool/inteltool.c2009-11-02 15:01:49 UTC (rev 4905)
@@ -39,6 +39,9 @@
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82945GM, i945GM },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PM965, PM965 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82975X, i975X },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q35, Q35 },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82G33, P35/G33/G31/P31 },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q33, Q33 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_X58, X58 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10R, ICH10R },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8M, ICH8-M },
Modified: trunk/util/inteltool/inteltool.h
===
--- trunk/util/inteltool/inteltool.h2009-11-01 09:18:23 UTC (rev 4904)
+++ trunk/util/inteltool/inteltool.h2009-11-02 15:01:49 UTC (rev 4905)
@@ -52,6 +52,9 @@
#define PCI_DEVICE_ID_INTEL_82945GM0x27a0
#define PCI_DEVICE_ID_INTEL_PM965 0x2a00
#define PCI_DEVICE_ID_INTEL_82975X 0x277c
+#define PCI_DEVICE_ID_INTEL_82Q35 0x29b0
+#define PCI_DEVICE_ID_INTEL_82G33 0x29c0
+#define PCI_DEVICE_ID_INTEL_82Q33 0x29d0
#define PCI_DEVICE_ID_INTEL_X580x3405
#define PCI_DEVICE_ID_INTEL_82443LX0x7180
Modified: trunk/util/inteltool/memory.c
===
--- trunk/util/inteltool/memory.c 2009-11-01 09:18:23 UTC (rev 4904)
+++ trunk/util/inteltool/memory.c 2009-11-02 15:01:49 UTC (rev 4905)
@@ -40,6 +40,9 @@
mchbar_phys = pci_read_long(nb, 0x44) 0xfffe;
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
mchbar_phys = pci_read_long(nb, 0x48) 0xfffe;
mchbar_phys |= ((uint64_t)pci_read_long(nb, 0x4c)) 32;
break;
Modified: trunk/util/inteltool/pcie.c
===
--- trunk/util/inteltool/pcie.c 2009-11-01 09:18:23 UTC (rev 4904)
+++ trunk/util/inteltool/pcie.c 2009-11-02 15:01:49 UTC (rev 4905)
@@ -39,6 +39,9 @@
epbar_phys = pci_read_long(nb, 0x40) 0xfffe;
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
epbar_phys = pci_read_long(nb, 0x40) 0xfffe;
epbar_phys |= ((uint64_t)pci_read_long(nb, 0x44)) 32;
break;
@@ -86,6 +89,9 @@
dmibar_phys = pci_read_long(nb, 0x4c) 0xfffe;
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
dmibar_phys = pci_read_long(nb, 0x68) 0xfffe;
dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) 32;
break;
@@ -135,6 +141,9 @@
pciexbar_reg = pci_read_long(nb, 0x48);
break;
case PCI_DEVICE_ID_INTEL_PM965:
+ case PCI_DEVICE_ID_INTEL_82Q35:
+ case PCI_DEVICE_ID_INTEL_82G33:
+ case PCI_DEVICE_ID_INTEL_82Q33:
pciexbar_reg = pci_read_long(nb, 0x60);
pciexbar_reg |= ((uint64_t)pci_read_long(nb, 0x64)) 32;
break;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel P35/Q35/G33/Q33/G31/P31
On 02.11.2009 10:12, Loïc Grenié wrote: Here is a patch for inteltool to print the registers values for the P31..Q35 chipset. The registers are (as far as I can tell) unchanged with respect to those of the PM965. I've no strong ideas on the names: I've chosen PCI_DEVICE_ID_INTEL_82[PQG]3[135] as Northbridge names, they can obviously be changed to anything else. I've given Q35, P35/G33/G31/P31 and Q33 as descriptions, they can also be freely changed. Signed-off-by: Loïc Grenié loic.gre...@gmail.com Description: adds 82Q35/P35/Q33/G33/G31/P31 capability. Thanks for your patch! Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net and committed in r4905. Regards, Carl-Daniel -- Developer quote of the week: We are juggling too many chainsaws and flaming arrows and tigers. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]
Myles, Setting it to 1 or 2 gives what looks like the same output. It causes coreboot to fail with the following error: Initializing CBMEM area to 0x3fff (65536 bytes) Adding CBMEM entry as no. 1 Moving GDT to 3fff0200...ok High Tables Base is 3fff. Copying Interrupt Routing Table to 0x000f... done. Adding CBMEM entry as no. 2 Copying Interrupt Routing Table to 0x3fff0400... done. PIRQ table: 176 bytes. Looking for bad PCIX MHz input get_pbus: dev is NULL! -- Hugh Greenberg Myles Watson wrote: It turns out that SB_HT_CHAIN_ON_BUS_0 was set incorrectly. I should have had you test if it should have been 2, but at least setting it to 1 should let SeaBIOS find your devices. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]
Setting it to 1 or 2 gives what looks like the same output. It causes coreboot to fail with the following error: I guess I shouldn't have committed it until it worked, but 0 was the wrong value. Initializing CBMEM area to 0x3fff (65536 bytes) Adding CBMEM entry as no. 1 Moving GDT to 3fff0200...ok High Tables Base is 3fff. Copying Interrupt Routing Table to 0x000f... done. Adding CBMEM entry as no. 2 Copying Interrupt Routing Table to 0x3fff0400... done. PIRQ table: 176 bytes. Looking for bad PCIX MHz input That message comes from mainboard/arima/hdama/mptable.c The bus numbers are hard-coded. The easiest thing to do would be to: 1. Choose 1 or 2 for that config value 2. Find the bus and device numbers in the output 3. Change the hard coded values Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] The filo crashes if the filo and coreboot overlap.
If the coreboot and filo overlap, it will slice off a piece at the
beginning or end. In the beginning case, a new segment is inserted
before the current one. The ptr will move forward and doesn't seem to
have any chance to process the new segment.
ptr -+ move ---
|
V
++ ++
|| ||
| new | --- |current | --- .
|| ||
++ ++
Now we change the ptr to the previous one and restart the loop. The
new and current segment will both be processed.
+ptr move ---
|
V
++++ ++
|||| ||
| prev | --- | new | --- |current | --- .
|||| ||
++++ ++
It is tested on my Family 10 board.
Zheng
Signed-off-by: Zheng Bao zheng@amd.com
Index: src/boot/selfboot.c
===
--- src/boot/selfboot.c (revision 4892)
+++ src/boot/selfboot.c (working copy)
@@ -211,19 +211,21 @@
return !((end = lb_start) || (start = lb_end));
}
-static void relocate_segment(unsigned long buffer, struct segment *seg)
+static int relocate_segment(unsigned long buffer, struct segment *seg)
{
/* Modify all segments that want to load onto coreboot
* to load onto the bounce buffer instead.
*/
- unsigned long start, middle, end;
+ /* ret: 1 : A new segment is inserted before the seg.
+* 0 : A new segment is inserted after the seg, or no new
one. */
+ unsigned long start, middle, end, ret = 0;
printk_spew(lb: [0x%016lx, 0x%016lx)\n,
lb_start, lb_end);
/* I don't conflict with coreboot so get out of here */
if (!overlaps_coreboot(seg))
- return;
+ return 0;
start = seg-s_dstaddr;
middle = start + seg-s_filesz;
@@ -270,6 +272,8 @@
new-s_dstaddr,
new-s_dstaddr + new-s_filesz,
new-s_dstaddr + new-s_memsz);
+
+ ret = 1;
}
/* Slice off a piece at the end
@@ -319,6 +323,8 @@
seg-s_dstaddr,
seg-s_dstaddr + seg-s_filesz,
seg-s_dstaddr + seg-s_memsz);
+
+ return ret;
}
@@ -446,7 +452,10 @@
/* Modify the segment to load onto the bounce_buffer if
necessary.
*/
- relocate_segment(bounce_buffer, ptr);
+ if (relocate_segment(bounce_buffer, ptr)) {
+ ptr = (ptr-prev)-prev;
+ continue;
+ }
printk_debug(Post relocation: addr: 0x%016lx memsz:
0x%016lx filesz: 0x%016lx\n,
ptr-s_dstaddr, ptr-s_memsz, ptr-s_filesz);
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Monday, November 02, 2009 11:25 AM
To: Patrick Georgi
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.
In relocate_segment().
If the coreboot and filo overlap, it will slice off a piece at the
beginning or end. A new segment is allocated. If it is inserted before
the seg that is being processed, is there any chance that the new
segment will be processed? I am confused about it. On my fam 10 board,
it seems that the new segment was not processed and an error happens
when the code jumps to filo which is actually middle of nowhere.
Zheng
-Original Message-
From: coreboot-bounces+zheng.bao=amd@coreboot.org
[mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of
Patrick Georgi
Sent: Sunday, November 01, 2009 12:13 AM
To: Zheng Bao
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.
Am Samstag, den 31.10.2009, 15:43 + schrieb Zheng Bao:
The filo crashes if the filo and coreboot overlap.
Since the CBFS is the must-have feature, my family 10
board crashes when it jumps to filo. I am trying to
find out why. I need help.
Based on current code, the AMD Family 10 will cause the filo
and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
will return 1. But I am not sure if it will make the system
crashes.
What revision is that? There was an issue like that but I fixed it
several weeks ago.
If anybody explains briefly what happens if they
overlap.
When coreboot and payload overlap, coreboot uses a bounce buffer. The
bounce buffer is twice the size of coreboot. The first half is for the
part of the payload that overlaps coreboot, the other half is for
