Re: [coreboot] H8DME-2 woes, hints?
Joe Korty joe.ko...@ccur.com writes: As a first time coreboot user, I thought that I should first try it out on a supported board. That way I would learn the ropes a bit before even thinking about doing something more challenging. Naturally I am having troubles. I suspect that as a newbie I am probably doing something stupid. But then I've heard that mb manufacturers like to change things around without notice, so maybe I'm doing things right and what was once a supported mb, no longer is. The hardware: SuperMicro H8DME-2. Four 1Gbyte DDR2-667/533/400 Registered ECC SDRAM sticks from Crucial. Two Quad-Core AMD 2378 2.4 GHz Processors. Onboard video. One SATA disk. One PATA DVD-ROM reader. NULL modem serial cable from COM1 to COM1 on another PC. The details: When booting coreboot, nothing happens for about 45 seconds. Then the fans speed up to high and some messages start appearing on the serial line. These messages print rather slowly (maybe 1 second/message). They are: coreboot-4.0-r5521M Wed May 5 10:53:42 EDT 2010 starting... *sysinfo range: [000cf000,000cf730] bsp_apicid=00 Enabling routing table for node 00 done. Enabling SMP settings (0,1) link=00 This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. -- Arne. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8DME-2 woes, hints?
On Fri, May 07, 2010 at 05:57:35AM -0400, Arne Georg Gleditsch wrote: Joe Korty joe.ko...@ccur.com writes: As a first time coreboot user, I thought that I should first try it out on a supported board. That way I would learn the ropes a bit before even thinking about doing something more challenging. Naturally I am having troubles. I suspect that as a newbie I am probably doing something stupid. But then I've heard that mb manufacturers like to change things around without notice, so maybe I'm doing things right and what was once a supported mb, no longer is. The hardware: SuperMicro H8DME-2. Four 1Gbyte DDR2-667/533/400 Registered ECC SDRAM sticks from Crucial. Two Quad-Core AMD 2378 2.4 GHz Processors. Onboard video. One SATA disk. One PATA DVD-ROM reader. NULL modem serial cable from COM1 to COM1 on another PC. The details: When booting coreboot, nothing happens for about 45 seconds. Then the fans speed up to high and some messages start appearing on the serial line. These messages print rather slowly (maybe 1 second/message). They are: coreboot-4.0-r5521M Wed May 5 10:53:42 EDT 2010 starting... *sysinfo range: [000cf000,000cf730] bsp_apicid=00 Enabling routing table for node 00 done. Enabling SMP settings (0,1) link=00 This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. Thanks Arne! I'll have to figure out how to proceed from here. On a side note, it _looks_ like the slowdown might be due to the udelay unification. Still bisecting. Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8DME-2 woes, hints?
The hardware: SuperMicro H8DME-2. Four 1Gbyte DDR2-667/533/400 Registered ECC SDRAM sticks from Crucial. Two Quad-Core AMD 2378 2.4 GHz Processors. Onboard video. One SATA disk. One PATA DVD-ROM reader. NULL modem serial cable from COM1 to COM1 on another PC. The details: When booting coreboot, nothing happens for about 45 seconds. Then the fans speed up to high and some messages start appearing on the serial line. These messages print rather slowly (maybe 1 second/message). They are: coreboot-4.0-r5521M Wed May 5 10:53:42 EDT 2010 starting... *sysinfo range: [000cf000,000cf730] bsp_apicid=00 Enabling routing table for node 00 done. Enabling SMP settings (0,1) link=00 This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. Thanks Arne! I'll have to figure out how to proceed from here. On a side note, it _looks_ like the slowdown might be due to the udelay unification. Still bisecting. I'm surprised you found a revision that works, since it has never supported fam10. I think it would be more fruitful for you to look at one of the boards that has both fam10 and k8 support, and try to put together an h8dme_fam10 port. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8DME-2 woes, hints?
On Fri, May 07, 2010 at 07:30:08AM -0600, Myles Watson wrote: This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. Thanks Arne! I'll have to figure out how to proceed from here. On a side note, it _looks_ like the slowdown might be due to the udelay unification. Still bisecting. I'm surprised you found a revision that works, since it has never supported fam10. I think it would be more fruitful for you to look at one of the boards that has both fam10 and k8 support, and try to put together an h8dme_fam10 port. For the record, I've been trying to get that going for a while, but have not had much success - very early hangs in the fam10 code on this board. Cf. the problems Knut is having, I think... 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
Re: [coreboot] PATCH: model_6bx CPUs can go in a lot of places
On Thu, 6 May 2010 23:31:49 -0400, Keith Hui buu...@gmail.com wrote: Hi all, Intel model 6bx CPUs (specifically 6B1 and 6B4) can end up in a lot of places, specifically Slot 1 and Socket 370. Ever since references to them were removed from cpu/intel/model_6xx my coreboot would die when initializing CPU with a Unknown cpu error. This patch fixes it by adding references to model_6bx to cpu/intel/slot_1 and cpu/intel/socket_PGA370. Also included are before and after boot logs with relevant sections highlighted. Before boot log: http://coreboot.pastebin.com/CGWgihaG After boot log: http://coreboot.pastebin.com/GLgnpZT6 Signed-off-by: Keith Hui buu...@gmail.com - Begin patch - Index: src/cpu/intel/slot_1/Makefile.inc === --- src/cpu/intel/slot_1/Makefile.inc (revision 5527) +++ src/cpu/intel/slot_1/Makefile.inc (working copy) @@ -20,6 +20,7 @@ obj-y += slot_1.o subdirs-y += ../model_6xx +subdirs-y += ../model_6bx subdirs-y += ../../x86/tsc subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/lapic Index: src/cpu/intel/socket_PGA370/Makefile.inc === --- src/cpu/intel/socket_PGA370/Makefile.inc (revision 5527) +++ src/cpu/intel/socket_PGA370/Makefile.inc (working copy) @@ -20,6 +20,7 @@ obj-y += socket_PGA370.o subdirs-y += ../model_6xx +subdirs-y += ../model_6bx subdirs-y += ../../x86/tsc subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/lapic - End patch - Hello Keith, I kind of saw this coming. That is why I left the 6bx's in model_6xx. The new model_6bx is intended for CAR, so I don't know how well it will work with romcc. My advice is to either get CAR running on your board, or we put back the 6bx's in model_6xx for the interim. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]Support tinybootblock on broadcom/bcm5785
Hi,
attached patch adds the rom-enable function on bcm5785 to a
tinybootblock build, allowing for 4MB ROMs (instead of the default
configuration which seems to be 1MB).
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Index: src/southbridge/broadcom/bcm5785/Kconfig
===
--- src/southbridge/broadcom/bcm5785/Kconfig(Revision 5526)
+++ src/southbridge/broadcom/bcm5785/Kconfig(Arbeitskopie)
@@ -1,2 +1,8 @@
config SOUTHBRIDGE_BROADCOM_BCM5785
bool
+ select HAVE_HARD_RESET
+
+config BOOTBLOCK_SOUTHBRIDGE_INIT
+ string
+ default southbridge/broadcom/bcm5785/bootblock.c
+ depends on SOUTHBRIDGE_BROADCOM_BCM5785
Index: src/southbridge/broadcom/bcm5785/bcm5785_early_setup.c
===
--- src/southbridge/broadcom/bcm5785/bcm5785_early_setup.c (Revision 5526)
+++ src/southbridge/broadcom/bcm5785/bcm5785_early_setup.c (Arbeitskopie)
@@ -4,21 +4,8 @@
*/
#include reset.h
-static void bcm5785_enable_rom(void)
-{
-unsigned char byte;
-device_t addr;
+#include bcm5785_enable_rom.c
-/* Enable 4MB rom access at 0xFFC0 - 0x */
-/* Locate the BCM 5785 SB PCI Main */
-addr = pci_locate_device(PCI_ID(0x1166, 0x0205), 0); // 0x0201?
-
-/* Set the 4MB enable bit bit */
-byte = pci_read_config8(addr, 0x41);
-byte |= 0x0e;
-pci_write_config8(addr, 0x41, byte);
-}
-
static void bcm5785_enable_lpc(void)
{
Index: src/southbridge/broadcom/bcm5785/bcm5785_enable_rom.c
===
--- src/southbridge/broadcom/bcm5785/bcm5785_enable_rom.c (Revision 0)
+++ src/southbridge/broadcom/bcm5785/bcm5785_enable_rom.c (Revision 0)
@@ -0,0 +1,14 @@
+static void bcm5785_enable_rom(void)
+{
+ unsigned char byte;
+ device_t addr;
+
+ /* Enable 4MB rom access at 0xFFC0 - 0x */
+ /* Locate the BCM 5785 SB PCI Main */
+ addr = pci_locate_device(PCI_ID(0x1166, 0x0205), 0); // 0x0201?
+
+ /* Set the 4MB enable bit bit */
+ byte = pci_read_config8(addr, 0x41);
+ byte |= 0x0e;
+ pci_write_config8(addr, 0x41, byte);
+}
Index: src/southbridge/broadcom/bcm5785/bootblock.c
===
--- src/southbridge/broadcom/bcm5785/bootblock.c(Revision 0)
+++ src/southbridge/broadcom/bcm5785/bootblock.c(Revision 0)
@@ -0,0 +1,5 @@
+#include bcm5785_enable_rom.c
+
+static void bootblock_southbridge_init(void) {
+bcm5785_enable_rom();
+}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool patch: Added support to ICH9 chipset family
Added support to ICH9 chipset family
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
diff -c inteltool//gpio.c inteltool2//gpio.c
*** inteltool//gpio.c 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//gpio.c 2010-05-07 14:49:35.0 +0400
***
*** 114,119
--- 114,138
{ 0x3C, 4, GPIO_USE_SEL Override (HIGH) }
};
+ static const io_register_t ich9_gpio_registers[] = {
+ { 0x00, 4, GPIO_USE_SEL },
+ { 0x04, 4, GP_IO_SEL },
+ { 0x08, 4, RESERVED },
+ { 0x0c, 4, GP_LVL },
+ { 0x10, 4, RESERVED },
+ { 0x14, 4, RESERVED },
+ { 0x18, 4, GPO_BLINK },
+ { 0x1c, 4, GP_SER_BLINK },
+ { 0x20, 4, GP_SB_CMDSTS },
+ { 0x24, 4, GP_SB_DATA },
+ { 0x28, 4, RESERVED },
+ { 0x2c, 4, GPI_INV },
+ { 0x30, 4, GPIO_USE_SEL2 },
+ { 0x34, 4, GP_IO_SEL2 },
+ { 0x38, 4, GP_LVL2 },
+ { 0x3C, 4, RESERVED }
+ };
+
int print_gpios(struct pci_dev *sb)
{
***
*** 124,129
--- 143,158
printf(\n= GPIOS =\n\n);
switch (sb-device_id) {
+ case PCI_DEVICE_ID_INTEL_ICH9DH:
+ case PCI_DEVICE_ID_INTEL_ICH9DO:
+ case PCI_DEVICE_ID_INTEL_ICH9R:
+ case PCI_DEVICE_ID_INTEL_ICH9:
+ case PCI_DEVICE_ID_INTEL_ICH9M:
+ case PCI_DEVICE_ID_INTEL_ICH9ME:
+ gpiobase = pci_read_word(sb, 0x48) 0xfffc;
+ gpio_registers = ich9_gpio_registers;
+ size = ARRAY_SIZE(ich9_gpio_registers);
+ break;
case PCI_DEVICE_ID_INTEL_ICH8M:
gpiobase = pci_read_word(sb, 0x48) 0xfffc;
gpio_registers = ich8_gpio_registers;
diff -c inteltool//inteltool.c inteltool2//inteltool.c
*** inteltool//inteltool.c 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//inteltool.c 2010-05-07 14:39:17.0 +0400
***
*** 45,52
{ 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 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7MDH, ICH7-M DH },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7M, ICH7-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7, ICH7 },
--- 45,59
{ 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_GS45MEGMCH, GS45ME-GMCH }, // Northbridge in GS45
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10R, ICH10R },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9DH, ICH9DH },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9DO, ICH9DO },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9R, ICH9R },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9, ICH9 },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9M, ICH9M },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9ME, ICH9M-E },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8M, ICH8-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7MDH, ICH7-M DH },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7M, ICH7-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7, ICH7 },
diff -c inteltool//inteltool.h inteltool2//inteltool.h
*** inteltool//inteltool.h 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//inteltool.h 2010-05-07 14:05:50.0 +0400
***
*** 44,51
--- 44,59
#define PCI_DEVICE_ID_INTEL_ICH7M 0x27b9
#define PCI_DEVICE_ID_INTEL_ICH7MDH 0x27bd
#define PCI_DEVICE_ID_INTEL_ICH8M 0x2815
+ #define PCI_DEVICE_ID_INTEL_ICH9DH 0x2912
+ #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914
+ #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916
+ #define PCI_DEVICE_ID_INTEL_ICH90x2918
+ #define PCI_DEVICE_ID_INTEL_ICH9M 0x2919
+ #define PCI_DEVICE_ID_INTEL_ICH9ME 0x2917
#define PCI_DEVICE_ID_INTEL_ICH10R 0x3a16
+ #define PCI_DEVICE_ID_INTEL_GS45MEGMCH 0x2a40 // northbridge GS45
+
#define PCI_DEVICE_ID_INTEL_82810 0x7120
#define PCI_DEVICE_ID_INTEL_82810DC 0x7122
#define PCI_DEVICE_ID_INTEL_82830M 0x3575
diff -c inteltool//memory.c inteltool2//memory.c
*** inteltool//memory.c 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//memory.c 2010-05-07 14:25:25.0 +0400
***
*** 54,59
--- 54,63
case PCI_DEVICE_ID_INTEL_82830M:
printf(This northbrigde does not have MCHBAR.\n);
return 1;
+ case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
+ mchbar_phys = pci_read_long(nb, 0x48) 0xfffe;
+ mchbar_phys |= ((uint64_t)pci_read_long(nb, 0x4c)) 32;
+ break;
default:
printf(Error: Dumping MCHBAR on this northbridge is not (yet) supported.\n);
return 1;
diff -c inteltool//pcie.c inteltool2//pcie.c
***
Re: [coreboot] Linux booting hangs when booted by FILO
Hi, Yes, SeaBIOS works (well, with some minor issues). After putting a VGA bios into coreboot, the following are also displayed after the Jumping to entry point... message, but the system still freezes: Jumping to entry point... out of memory while allocating output buffer -- System halted Does anyone have any idea regarding the cause of the out of memory while allocating output buffer error? Thank you in advance. -John -Original Message- From: Kevin O'Connor [mailto:ke...@koconnor.net] Sent: Saturday, May 01, 2010 6:23 PM To: limp Cc: coreboot@coreboot.org Subject: Re: [coreboot] Linux booting hangs when booted by FILO On Fri, Apr 30, 2010 at 03:34:43AM +0100, limp wrote: I have loaded coreboot with FILO on a Kontron 986LCD-M board and when I am trying to boot Linux from FILO, it freezes at the Jumping to entry point... bit. Out of curiosity, does SeaBIOS work? -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8DME-2 woes, hints?
On Fri, May 07, 2010 at 07:30:08AM -0600, Myles Watson wrote: This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. Thanks Arne! I'll have to figure out how to proceed from here. On a side note, it _looks_ like the slowdown might be due to the udelay unification. Still bisecting. I'm surprised you found a revision that works, since it has never supported fam10. I think it would be more fruitful for you to look at one of the boards that has both fam10 and k8 support, and try to put together an h8dme_fam10 port. For the record, I've been trying to get that going for a while, but have not had much success - very early hangs in the fam10 code on this board. Cf. the problems Knut is having, I think... Sorry I forgot that. The Supermicro names all blend together for me. Have you tried adding the extra bits to the masks in resourcemap.c? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool patch: Added support to ICH9 chipset family
Added support to ICH9 chipset family
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
Index: gpio.c
===
--- gpio.c (revision 5527)
+++ gpio.c (working copy)
@@ -114,7 +114,26 @@
{ 0x3C, 4, GPIO_USE_SEL Override (HIGH) }
};
+static const io_register_t ich9_gpio_registers[] = {
+ { 0x00, 4, GPIO_USE_SEL },
+ { 0x04, 4, GP_IO_SEL },
+ { 0x08, 4, RESERVED },
+ { 0x0c, 4, GP_LVL },
+ { 0x10, 4, RESERVED },
+ { 0x14, 4, RESERVED },
+ { 0x18, 4, GPO_BLINK },
+ { 0x1c, 4, GP_SER_BLINK },
+ { 0x20, 4, GP_SB_CMDSTS },
+ { 0x24, 4, GP_SB_DATA },
+ { 0x28, 4, RESERVED },
+ { 0x2c, 4, GPI_INV },
+ { 0x30, 4, GPIO_USE_SEL2 },
+ { 0x34, 4, GP_IO_SEL2 },
+ { 0x38, 4, GP_LVL2 },
+ { 0x3C, 4, RESERVED }
+};
+
int print_gpios(struct pci_dev *sb)
{
int i, size;
@@ -124,6 +143,16 @@
printf(\n= GPIOS =\n\n);
switch (sb-device_id) {
+case PCI_DEVICE_ID_INTEL_ICH9DH:
+case PCI_DEVICE_ID_INTEL_ICH9DO:
+case PCI_DEVICE_ID_INTEL_ICH9R:
+case PCI_DEVICE_ID_INTEL_ICH9:
+case PCI_DEVICE_ID_INTEL_ICH9M:
+case PCI_DEVICE_ID_INTEL_ICH9ME:
+gpiobase = pci_read_word(sb, 0x48) 0xfffc;
+ gpio_registers = ich9_gpio_registers;
+ size = ARRAY_SIZE(ich9_gpio_registers);
+ break;
case PCI_DEVICE_ID_INTEL_ICH8M:
gpiobase = pci_read_word(sb, 0x48) 0xfffc;
gpio_registers = ich8_gpio_registers;
Index: inteltool.h
===
--- inteltool.h (revision 5527)
+++ inteltool.h (working copy)
@@ -44,8 +44,16 @@
#define PCI_DEVICE_ID_INTEL_ICH7M 0x27b9
#define PCI_DEVICE_ID_INTEL_ICH7MDH 0x27bd
#define PCI_DEVICE_ID_INTEL_ICH8M 0x2815
+#define PCI_DEVICE_ID_INTEL_ICH9DH 0x2912
+#define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914
+#define PCI_DEVICE_ID_INTEL_ICH9R 0x2916
+#define PCI_DEVICE_ID_INTEL_ICH90x2918
+#define PCI_DEVICE_ID_INTEL_ICH9M 0x2919
+#define PCI_DEVICE_ID_INTEL_ICH9ME 0x2917
#define PCI_DEVICE_ID_INTEL_ICH10R 0x3a16
+#define PCI_DEVICE_ID_INTEL_GS45MEGMCH 0x2a40 // northbridge GS45
+
#define PCI_DEVICE_ID_INTEL_82810 0x7120
#define PCI_DEVICE_ID_INTEL_82810DC 0x7122
#define PCI_DEVICE_ID_INTEL_82830M 0x3575
Index: pcie.c
===
--- pcie.c (revision 5527)
+++ pcie.c (working copy)
@@ -43,6 +43,7 @@
case PCI_DEVICE_ID_INTEL_82Q35:
case PCI_DEVICE_ID_INTEL_82G33:
case PCI_DEVICE_ID_INTEL_82Q33:
+case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
epbar_phys = pci_read_long(nb, 0x40) 0xfffe;
epbar_phys |= ((uint64_t)pci_read_long(nb, 0x44)) 32;
break;
@@ -51,7 +52,7 @@
case PCI_DEVICE_ID_INTEL_82830M:
printf(This northbrigde does not have EPBAR.\n);
return 1;
- default:
+default:
printf(Error: Dumping EPBAR on this northbridge is not (yet) supported.\n);
return 1;
}
@@ -95,15 +96,15 @@
case PCI_DEVICE_ID_INTEL_82Q35:
case PCI_DEVICE_ID_INTEL_82G33:
case PCI_DEVICE_ID_INTEL_82Q33:
+case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
dmibar_phys = pci_read_long(nb, 0x68) 0xfffe;
dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) 32;
break;
case PCI_DEVICE_ID_INTEL_82810:
case PCI_DEVICE_ID_INTEL_82810DC:
- case PCI_DEVICE_ID_INTEL_82830M:
printf(This northbrigde does not have DMIBAR.\n);
return 1;
- default:
+default:
printf(Error: Dumping DMIBAR on this northbridge is not (yet) supported.\n);
return 1;
}
@@ -149,6 +150,7 @@
case PCI_DEVICE_ID_INTEL_82Q35:
case PCI_DEVICE_ID_INTEL_82G33:
case PCI_DEVICE_ID_INTEL_82Q33:
+case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
pciexbar_reg = pci_read_long(nb, 0x60);
pciexbar_reg |= ((uint64_t)pci_read_long(nb, 0x64)) 32;
break;
Index: powermgt.c
===
--- powermgt.c (revision 5527)
+++ powermgt.c (working copy)
@@ -21,47 +21,47 @@
#include stdio.h
#include inteltool.h
-static const io_register_t ich7_pm_registers[] = {
- { 0x00, 2, PM1_STS },
- { 0x02, 2, PM1_EN },
- { 0x04, 4, PM1_CNT },
- { 0x08, 4, PM1_TMR },
+static const io_register_t ich9_pm_registers[] = {
+ { 0x00, 2, PM1_STS }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK
+ { 0x02, 2, PM1_EN }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2
+ { 0x04, 4, PM1_CNT }, // PM1 Control; ACPI pointer: PM1a_CNT_BLK
+ { 0x08, 4, PM1_TMR }, // PM1 Timer; ACPI pointer: PMTMR_BLK
{ 0x0c, 4, RESERVED },
- { 0x10, 4, PROC_CNT },
+ { 0x10, 4, PROC_CNT }, // Processor Control; ACPI pointer: P_BLK
#if DANGEROUS_REGISTERS
/* These registers return 0 on read, but reading them may cause
- * the system to enter C2/C3/C4 state, which might hang the system.
+ * the system to enter Cx states, which might hang the system.
*/
- { 0x14, 1, LV2 (Mobile/Ultra Mobile) },
- { 0x15, 1, LV3 (Mobile/Ultra
[coreboot] #161: Improve USB debug port configuration
#161: Improve USB debug port configuration +--- Reporter: oxygene | Owner: ste...@… Type: enhancement |Status: new Priority: trivial | Milestone: Component: coreboot | Keywords: Dependencies: | Patchstatus: there is no patch +--- Right now, the right port number is configured in DBGP_DEFAULT without much documentation anywhere. It's even defined in boards that don't use the value at all. Maybe move it to Kconfig? Document it? Just clean up the copypasted useless values? -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/161 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #161: Improve USB debug port configuration
#161: Improve USB debug port configuration +--- Reporter: oxygene | Owner: ste...@… Type: enhancement |Status: new Priority: trivial | Milestone: Component: coreboot | Keywords: Dependencies: | Patchstatus: there is no patch +--- Comment(by stuge): Definately mainboard Kconfig! -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/161#comment:1 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH: model_6bx CPUs can go in a lot of places
I think I should get CAR running. But CAR is not quite developed for the rest of the 6xx family. If you look at the boot log you'll see that it got through to SeaBIOS just fine. My coreboot is still on romcc. What are the steps needed to enable CAR on a board? Thanks Keith On 5/7/10, Joseph Smith j...@settoplinux.org wrote: On Thu, 6 May 2010 23:31:49 -0400, Keith Hui buu...@gmail.com wrote: Hi all, Intel model 6bx CPUs (specifically 6B1 and 6B4) can end up in a lot of places, specifically Slot 1 and Socket 370. Ever since references to them were removed from cpu/intel/model_6xx my coreboot would die when initializing CPU with a Unknown cpu error. This patch fixes it by adding references to model_6bx to cpu/intel/slot_1 and cpu/intel/socket_PGA370. Also included are before and after boot logs with relevant sections highlighted. Before boot log: http://coreboot.pastebin.com/CGWgihaG After boot log: http://coreboot.pastebin.com/GLgnpZT6 Signed-off-by: Keith Hui buu...@gmail.com - Begin patch - Index: src/cpu/intel/slot_1/Makefile.inc === --- src/cpu/intel/slot_1/Makefile.inc(revision 5527) +++ src/cpu/intel/slot_1/Makefile.inc(working copy) @@ -20,6 +20,7 @@ obj-y += slot_1.o subdirs-y += ../model_6xx +subdirs-y += ../model_6bx subdirs-y += ../../x86/tsc subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/lapic Index: src/cpu/intel/socket_PGA370/Makefile.inc === --- src/cpu/intel/socket_PGA370/Makefile.inc (revision 5527) +++ src/cpu/intel/socket_PGA370/Makefile.inc (working copy) @@ -20,6 +20,7 @@ obj-y += socket_PGA370.o subdirs-y += ../model_6xx +subdirs-y += ../model_6bx subdirs-y += ../../x86/tsc subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/lapic - End patch - Hello Keith, I kind of saw this coming. That is why I left the 6bx's in model_6xx. The new model_6bx is intended for CAR, so I don't know how well it will work with romcc. My advice is to either get CAR running on your board, or we put back the 6bx's in model_6xx for the interim. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH: model_6bx CPUs can go in a lot of places
On Fri, 7 May 2010 13:00:37 -0400, Keith Hui buu...@gmail.com wrote: I think I should get CAR running. But CAR is not quite developed for the rest of the 6xx family. Correct, and it will never get done if we don't step forward. If you look at the boot log you'll see that it got through to SeaBIOS just fine. My coreboot is still on romcc. What are the steps needed to enable CAR on a board? Take a look at Thomson IP1000. Hope that helps. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Query, known-good CPUs to use in a H8DME-2 mb?
On Fri, May 07, 2010 at 09:37:54AM -0400, Ward Vandewege wrote: On Fri, May 07, 2010 at 07:30:08AM -0600, Myles Watson wrote: This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. I'm surprised you found a revision that works, since it has never supported fam10. I think it would be more fruitful for you to look at one of the boards that has both fam10 and k8 support, and try to put together an h8dme_fam10 port. For the record, I've been trying to get that going for a while, but have not had much success - very early hangs in the fam10 code on this board. Cf. the problems Knut is having, I think... What AMD Processor model numbers have you folks been using on the SuperMicro H8DME-2 mainboards? I'd like to buy a pair of known-working CPUs. I currently have a pair of AMD model #2378 Processors, which are of the fam10 line, with a pair of model # CPUs, which are of the K8 line. Thoughts? Regards, Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Query, known-good CPUs to use in a H8DME-2 mb?
On Fri, May 07, 2010 at 01:59:12PM -0400, Joe Korty wrote: What AMD Processor model numbers have you folks been using on the SuperMicro H8DME-2 mainboards? I'd like to buy a pair of known-working CPUs. I currently have a pair of AMD model #2378 Processors, which are of the fam10 line, with a pair of model # CPUs, which are of the K8 line. The port for that board was done on a pair of 2216 HE CPUs. You may be hard pressed to find those for sale these days... 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] AMD CAR II
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I examined a bit how does it works. Maybe if one can read this http://en.wikipedia.org/wiki/CPU_cache and then continue here :) I was particularly curious because we do writeback - writeback copy of data from CAR to ram (to copy stack and sysinfo, which must cause L1 evictions), and also we do DQS memory training (which writes to RAM during CAR) and we use cache to cache ROM too. This means not only L1 is used but we must be using L2 too. Here are some notes why I think it works :) Here is what I found: AMD L2 cache is exclusive, it means it only contains data evicted from L1 caches. In other words there is never same data in both caches. I could not find any info if it is valid for the Icache too. If the icache gets moved to L2 or not. It should but it does not seem to happen during CAR. L1 Data cache: Size: 64Kb 2-way associative. lines per tag=1 line size=64 bytes. L1 Instruction cache: Size: 64Kb 2-way associative. lines per tag=1 line size=64 bytes. 512KB/core L2 cache: Size: 1024Kb16-way associative. lines per tag=1 line size=64 bytes. Here is basic math how to calculate cache organization: line size = tells how many bytes are stored in one cache line (exploits the spatial locality of data). Here it is 64 bytes so bits of address 5:0 are used. Index: it tells how many cache lines do we have. The level of associativity tells how many addresses which compete for same index can be stored in cache simultaneously. For L1 we have: 64*1024 / 64 / 2 = 512 is the number of cache lines. We have 2 (assoc is 2) arrays each has 64 bytes/per line and total size is 64KB. The index is therefore on addresses 14:6. The rest of address is used as tag (tag identifies the actual location of data in memory together with the cache line index) One can say each 14:0 bit of address compete for same index. We have asoc level of 2 so each 16 bits of addr will fill whole cache. For L2 here it is 512KB assoc is 16. We have 32KB / 64 indexes = 512 (lines) so addresses 14:6 build up the index. Rest is tag. The CAR idea on AMD is just to use it and never cause an eviction from L2 cache to main memory (which is not functioning). Step 0) enable cache and WB mtrrs for any ranges 1) all lines are invalid, validate them by dummy read exactly as big as max L1 cache. For instruction cache enough is a instr fetch. 2) The dummy read region can be now used to store data - it is simply an arbitrary address range 0-64KB max. 3) caching of ROM works too because: a) MTRR for rom is set (currently only for part of it) it could be WP type but we use WB, no harm here because we do not modify any code ;) b) L1 instruction cache is filled from flash chip directly (remember L2 is exclusive cache on AMD) c) if L1 instr cache is not evicted into L2 then on cache miss it L1 line is simply invalidated and refilled from flash rom. I tried to check this using performance counters but there is not a counter for this. This is uninteresting case because it does not complicate anything. c) if L1 instr cache gets evicted into L2, (which I dont know if is true), then we can run into following I) no L1 data cache lines was evicted into L2 - again not interesting case because nothing gets wrong. II) we have some L1 data cache evicted into L2. This really happens in our CAR! print_debug(Copying data from cache to RAM -- switching to use RAM as stack...); memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); It happens here because we do copy from CAR region to RAM while CAR is still running. Both regions are WB so we must evict some L1 cache lines for sure, and performance counters confirm this. You may say this is not an issue because RAM is running normally, but for example while we resume from S3 we cannot overwrite random memory with out CAR... I think this evictions so far happens only here and still things works nice here is why: We have at most 64KB or dirty data, we can spread it into L2 nicely and still have a lot of free space even on systems where we have 128KB L2. In this case no evictions into system because we can have the data still in L2. Now lets go back, what if CPU instruction cache gets evicted into L2? Here it would cause problems because in L2 would be L1 data cache data and random L1 instr cache code competing for the space. I think here it works because dirty data is evicted with lowest priority. I think if all lanes of cache are full, the lane with clean data is invalidated first. This saves the day for us because it guarantees that our L1 data will not fall off the cache never ever - only if we exceed the L2 cache size with dirty data. We examined so far the ROM caching and oversized L1 handling. But the memory training uses writes to not yet initialized RAM. How it works here? I checked and the memory write uses the instruction
Re: [coreboot] AMD CAR II
II) we have some L1 data cache evicted into L2. This really happens in our CAR! print_debug(Copying data from cache to RAM -- switching to use RAM as stack...); memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); It happens here because we do copy from CAR region to RAM while CAR is still running. Both regions are WB so we must evict some L1 cache lines for sure, and performance counters confirm this. You may say this is not an issue because RAM is running normally, but for example while we resume from S3 we cannot overwrite random memory with out CAR... I think this evictions so far happens only here and still things works nice here is why: Are you sure they're both WB? Since CAR is running, we don't disable the cache and enable it again, which is recommended when setting an MTRR. I commented out the line that sets that MTRR and can't tell a difference. I like the rest of analysis. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD CAR II
Hi Rudolf, Good detailed email. Yes, this is how I think it works, and as far as I know, the L1 instruction cache also writes to the L2. The L2 is the main reason that CAR works. I have never been happy with the post_car code. Something about it doesn't seem right, but I have never found it. I do think that more care needs to happen with cache en/disable and the MTRR settings. Marc On Fri, May 7, 2010 at 12:10 PM, Rudolf Marek r.ma...@assembler.cz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I examined a bit how does it works. Maybe if one can read this http://en.wikipedia.org/wiki/CPU_cache and then continue here :) I was particularly curious because we do writeback - writeback copy of data from CAR to ram (to copy stack and sysinfo, which must cause L1 evictions), and also we do DQS memory training (which writes to RAM during CAR) and we use cache to cache ROM too. This means not only L1 is used but we must be using L2 too. Here are some notes why I think it works :) Here is what I found: AMD L2 cache is exclusive, it means it only contains data evicted from L1 caches. In other words there is never same data in both caches. I could not find any info if it is valid for the Icache too. If the icache gets moved to L2 or not. It should but it does not seem to happen during CAR. L1 Data cache: Size: 64Kb 2-way associative. lines per tag=1 line size=64 bytes. L1 Instruction cache: Size: 64Kb 2-way associative. lines per tag=1 line size=64 bytes. 512KB/core L2 cache: Size: 1024Kb 16-way associative. lines per tag=1 line size=64 bytes. Here is basic math how to calculate cache organization: line size = tells how many bytes are stored in one cache line (exploits the spatial locality of data). Here it is 64 bytes so bits of address 5:0 are used. Index: it tells how many cache lines do we have. The level of associativity tells how many addresses which compete for same index can be stored in cache simultaneously. For L1 we have: 64*1024 / 64 / 2 = 512 is the number of cache lines. We have 2 (assoc is 2) arrays each has 64 bytes/per line and total size is 64KB. The index is therefore on addresses 14:6. The rest of address is used as tag (tag identifies the actual location of data in memory together with the cache line index) One can say each 14:0 bit of address compete for same index. We have asoc level of 2 so each 16 bits of addr will fill whole cache. For L2 here it is 512KB assoc is 16. We have 32KB / 64 indexes = 512 (lines) so addresses 14:6 build up the index. Rest is tag. The CAR idea on AMD is just to use it and never cause an eviction from L2 cache to main memory (which is not functioning). Step 0) enable cache and WB mtrrs for any ranges 1) all lines are invalid, validate them by dummy read exactly as big as max L1 cache. For instruction cache enough is a instr fetch. 2) The dummy read region can be now used to store data - it is simply an arbitrary address range 0-64KB max. 3) caching of ROM works too because: a) MTRR for rom is set (currently only for part of it) it could be WP type but we use WB, no harm here because we do not modify any code ;) b) L1 instruction cache is filled from flash chip directly (remember L2 is exclusive cache on AMD) c) if L1 instr cache is not evicted into L2 then on cache miss it L1 line is simply invalidated and refilled from flash rom. I tried to check this using performance counters but there is not a counter for this. This is uninteresting case because it does not complicate anything. c) if L1 instr cache gets evicted into L2, (which I dont know if is true), then we can run into following I) no L1 data cache lines was evicted into L2 - again not interesting case because nothing gets wrong. II) we have some L1 data cache evicted into L2. This really happens in our CAR! print_debug(Copying data from cache to RAM -- switching to use RAM as stack...); memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); It happens here because we do copy from CAR region to RAM while CAR is still running. Both regions are WB so we must evict some L1 cache lines for sure, and performance counters confirm this. You may say this is not an issue because RAM is running normally, but for example while we resume from S3 we cannot overwrite random memory with out CAR... I think this evictions so far happens only here and still things works nice here is why: We have at most 64KB or dirty data, we can spread it into L2 nicely and still have a lot of free space even on systems where we have 128KB L2. In this case no evictions into system because we can have the data still in L2. Now lets go back, what if CPU instruction cache gets evicted into L2? Here it would cause problems because in L2 would be L1 data cache data and random L1 instr
Re: [coreboot] FILO bug disk not seen at ata-0 (Doesn't try to detect on ATA only SIL3114)
Joop Boonen wrote: I have an issue with FILO the disk at ata-0 isn't seen. I've been trying some more. I've used the old IDE in FILO. It now recognises the drive connected to the SIL3114. But still not the ATA drive. Curious. Maybe I can ask you to try even older code? I did a bunch of work on the IDE driver in FILO 0.5 but haven't kept up with current code. If you'd like to try the latest 0.5: svn co svn://coreboot.org/filo/branches/filo-0.5 Please disable the GRUB junk (comment out USE_GRUB), enable filesystems you need, and enable DEBUG_BLOCKDEV, DEBUG_PCI, and DEBUG_IDE. Thanks. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH: model_6bx CPUs can go in a lot of places
On Fri, May 7, 2010 at 7:01 PM, Idwer Vollering vid...@gmail.com wrote: 2010/5/7 Keith Hui buu...@gmail.com I think I should get CAR running. But CAR is not quite developed for the rest of the 6xx family. If you look at the boot log you'll see that it got through to SeaBIOS just fine. My coreboot is still on romcc. What are the steps needed to enable CAR on a board? Example: see attached patch (as an example/reference only because USE_PRINTK_IN_CAR, in src/mainboard/asus/p2b/Kconfig, somehow breaks booting/serial output.. waiting for my pci post card to arrive). All that I can find with importance is two Kconfig options... Booting failed with POST code 0x10. Digging into code now. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
