Re: [coreboot] [PATCH] New Socket370 and Model 68x for CAR
Index: src/cpu/intel/model_68x/model_68x_init.c
===
--- src/cpu/intel/model_68x/model_68x_init.c (revision 0)
+++ src/cpu/intel/model_68x/model_68x_init.c (revision 0)
[..]
+
+static struct cpu_device_id cpu_table[] = {
Do add 680 here too. In fact, if you add 680 all the others can be
omitted.
ok, why? 680 will cover everything?
Yes. It will mask the ID with fff0
ok
+ { X86_VENDOR_INTEL, 0x0681 },
+ { X86_VENDOR_INTEL, 0x0683 },
+ { X86_VENDOR_INTEL, 0x0686 },
+ { X86_VENDOR_INTEL, 0x068a },
+ { 0, 0 },
+};
+
+static const struct cpu_driver driver __cpu_driver = {
+ .ops =cpu_dev_ops,
+ .id_table = cpu_table,
+};
+
Hmm. If I add 0x0680 and delete the others I get:
Initializing CPU #0
CPU: vendor Intel device 68a
CPU: family 06, model 08, stepping 0a
Using generic cpu ops (good)
Enabling cache
microcode_info: sig = 0x068a pf=0x0010 rev = 0x
microcode updated to revision: 0001 from revision
Before I did not get the Using generic cpu ops (good) is that ok?
--
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] New Socket370 and Model 68x for CAR
On Mon, 21 Jun 2010 09:57:36 +0200, Peter Stuge pe...@stuge.se wrote: Joseph Smith wrote: Hmm. If I add 0x0680 and delete the others I get: CPU: vendor Intel device 68a CPU: family 06, model 08, stepping 0a Using generic cpu ops (good) Enabling cache Before I did not get the Using generic cpu ops (good) is that ok? The message seems to suggest so.. Hmm, to me it suggests it is using a _fail_safe_ because it can't find the correct (0x068a) device. It works fine eithor way but I don't think the _fail_safe_ is supposed to be the normal method. -- 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] New Socket370 and Model 68x for CAR
Joseph Smith wrote: Before I did not get the Using generic cpu ops (good) is that ok? The message seems to suggest so.. Hmm, to me it suggests it is using a _fail_safe_ because it can't find the correct (0x068a) device. It works fine eithor way but I don't think the _fail_safe_ is supposed to be the normal method. It says generic and good - not even default nor anything else that might suggest a failure to me. :) As could be expected from the code, that message is printed after the CPU is known when disregarding stepping. $ grep -rn 'Using generic cpu ops' .|grep -v '/\.svn/' ./arch/i386/lib/cpu.c:253: printk(BIOS_DEBUG, Using generic cpu ops (good)\n); //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] New Socket370 and Model 68x for CAR
On Mon, 21 Jun 2010 11:48:33 +0200, Peter Stuge pe...@stuge.se wrote:
Joseph Smith wrote:
Before I did not get the Using generic cpu ops (good) is that ok?
The message seems to suggest so..
Hmm, to me it suggests it is using a _fail_safe_ because it can't
find the correct (0x068a) device. It works fine eithor way but I
don't think the _fail_safe_ is supposed to be the normal method.
It says generic and good - not even default nor anything else
that might suggest a failure to me. :)
As could be expected from the code, that message is printed after the
CPU is known when disregarding stepping.
$ grep -rn 'Using generic cpu ops' .|grep -v '/\.svn/'
./arch/i386/lib/cpu.c:253: printk(BIOS_DEBUG, Using generic
cpu ops (good)\n);
Ok, now lets look at the whole function:
/* Lookup the cpu's operations */
set_cpu_ops(cpu);
if(!cpu-ops) {
/* mask out the stepping and try again */
cpu-device -= c.x86_mask;
set_cpu_ops(cpu);
cpu-device += c.x86_mask;
if(!cpu-ops) die(Unknown cpu);
printk(BIOS_DEBUG, Using generic cpu ops (good)\n);
}
Hmm, to me this is a _fail_safe_ or _fall_back_.
cpu-ops fails because it is not able to find cpu-device so it runs this
function to try again.
--
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] New Socket370 and Model 68x for CAR
On 6/21/10 12:15 PM, Joseph Smith wrote:
On Mon, 21 Jun 2010 11:48:33 +0200, Peter Stuge pe...@stuge.se wrote:
Joseph Smith wrote:
Before I did not get the Using generic cpu ops (good) is that ok?
The message seems to suggest so..
Hmm, to me it suggests it is using a _fail_safe_ because it can't
find the correct (0x068a) device. It works fine eithor way but I
don't think the _fail_safe_ is supposed to be the normal method.
It says generic and good - not even default nor anything else
that might suggest a failure to me. :)
As could be expected from the code, that message is printed after the
CPU is known when disregarding stepping.
$ grep -rn 'Using generic cpu ops' .|grep -v '/\.svn/'
./arch/i386/lib/cpu.c:253: printk(BIOS_DEBUG, Using generic
cpu ops (good)\n);
Ok, now lets look at the whole function:
/* Lookup the cpu's operations */
set_cpu_ops(cpu);
if(!cpu-ops) {
/* mask out the stepping and try again */
cpu-device -= c.x86_mask;
set_cpu_ops(cpu);
cpu-device += c.x86_mask;
if(!cpu-ops) die(Unknown cpu);
printk(BIOS_DEBUG, Using generic cpu ops (good)\n);
}
Hmm, to me this is a _fail_safe_ or _fall_back_.
cpu-ops fails because it is not able to find cpu-device so it runs this
function to try again
Yes, it tries without the mask, i.e for 681 - 68f it tries 680. Then, if
that does not match, it dies with Unknown CPU.
There is no failsafe nor fallback involved. What makes you think there
is? It just means adding 1 entry to the table instead of 16.
Stefan.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote: Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Thanks for testing. It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? Thanks, Myles Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 5:59 AM, Myles Watson myle...@gmail.com wrote:
On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote:
Hi Myles,
Everything seems fine with either patch - but there are some differences in
the boot output.
I also ran the 'sensors' command.
Output here:
http://ward.vandewege.net/coreboot/s2881/20100617-myles/
I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this
changeset), r5635 + patch 1 and r5635 + patch 2.
Thanks for testing.
It looks like only 5632 has the ADT7463 properly initialized
message. One problem is that patch 2 was meant to be applied after
patch 1, so the device didn't end up in the tree for that run. I'll
have to think about why the only message from the new device with
patch 1 is I2C: 00:d0 missing read_resources For some reason it
doesn't look like it got the correct ops.
I wonder why the temperature values look right in all cases. Does it
need to be cold booted in order for the initialization to be needed?
The ADM1027 doesn't expect to have children, so it has no scan_bus
method. I had thought that the ADM1027 was some kind of a controller
for the ADT4763, but it looks like the same type of device. Is there
really an ADM1027 on your board? I don't see it in your sensors
output.
So... the first two patches are the same as before. The third patch
adds a scan_bus method to the ADM1027 so that the ADT4763 can be
initialized, and the fourth patch replaces the ADM1027 with the
ADT4763 in the device tree, and removes the third patch.
I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4.
There may be some initialization that was done by the ADM1027 code
that needs to be moved to the ADT7463 code, since both were being run.
So 1 + 2 + 3 should give behavior that is closer to the original code,
but if there is no ADM1027, the right thing to do is 1 + 2 + 3 + 4 +
some ADM1027 code if necessary.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/mainboard/tyan/s2881/Makefile.inc
===
--- svn.orig/src/mainboard/tyan/s2881/Makefile.inc
+++ svn/src/mainboard/tyan/s2881/Makefile.inc
@@ -1 +1,2 @@
obj-y += ../../../drivers/i2c/adm1027/adm1027.o
+obj-y += ../../../drivers/i2c/adt7463/adt7463.o
Index: svn/src/mainboard/tyan/s2881/devicetree.cb
===
--- svn.orig/src/mainboard/tyan/s2881/devicetree.cb
+++ svn/src/mainboard/tyan/s2881/devicetree.cb
@@ -103,7 +103,12 @@ chip northbridge/amd/amdk8/root_complex
device i2c 57 on end
end
chip drivers/i2c/adm1027 # ADT7463A CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
-device i2c 2d on end
+device i2c 2d on
+chip drivers/i2c/adt7463
+device i2c d0 on
+end
+end
+end
end
chip drivers/generic/generic # Winbond HWM 0x54 CPU0/1 VRM temp, SYSFAN 4,CPU0 vid, CPU0/1 FAN
device i2c 2a on end
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -116,7 +116,7 @@ static void enable_dev(struct device *de
dev-ops = adt7463_operations;
}
-struct chip_operations mainboard_ops = {
+struct chip_operations drivers_i2c_adt7463_ops = {
CHIP_NAME(adt7463)
.enable_dev = enable_dev,
};
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -35,67 +35,56 @@
*/
static void adt7463_init(device_t dev)
{
- device_t smbus_dev, adt7463;
- struct device_path path;
+ device_t parent;
int result;
- /* Find the SMBus controller (AMD-8111). */
- smbus_dev = dev_find_device(0x1022, 0x746b, 0);
- if (!smbus_dev)
- die(SMBus controller not found\n);
- printk(BIOS_DEBUG, SMBus controller found\n);
-
- /* Find the ADT7463 device. */
- path.type = DEVICE_PATH_I2C;
- path.i2c.device = 0x2d;
- adt7463 = find_dev_path(smbus_dev-link_list, path);
- if (!adt7463)
- die(ADT7463 not found\n);
- printk(BIOS_DEBUG, ADT7463 found\n);
+ /* Find the ADT7463's parent device. */
+ parent = dev-bus-dev;
+ printk(BIOS_DEBUG,
Re: [coreboot] [PATCH] Simplify device enabling and initialization
If there is no adm1027, then the adt4763 needs to be initialized, not
its parent. Updated patch 4 attached.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/mainboard/tyan/s2881/Makefile.inc
===
--- svn.orig/src/mainboard/tyan/s2881/Makefile.inc
+++ svn/src/mainboard/tyan/s2881/Makefile.inc
@@ -1,2 +1 @@
-obj-y += ../../../drivers/i2c/adm1027/adm1027.o
obj-y += ../../../drivers/i2c/adt7463/adt7463.o
Index: svn/src/mainboard/tyan/s2881/devicetree.cb
===
--- svn.orig/src/mainboard/tyan/s2881/devicetree.cb
+++ svn/src/mainboard/tyan/s2881/devicetree.cb
@@ -102,13 +102,8 @@ chip northbridge/amd/amdk8/root_complex
chip drivers/generic/generic #dimm 1-1-1
device i2c 57 on end
end
-chip drivers/i2c/adm1027 # ADT7463A CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
-device i2c 2d on
-chip drivers/i2c/adt7463
-device i2c d0 on
-end
-end
-end
+chip drivers/i2c/adt7463 # CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
+device i2c 2d on end
end
chip drivers/generic/generic # Winbond HWM 0x54 CPU0/1 VRM temp, SYSFAN 4,CPU0 vid, CPU0/1 FAN
device i2c 2a on end
Index: svn/src/drivers/i2c/adm1027/adm1027.c
===
--- svn.orig/src/drivers/i2c/adm1027/adm1027.c
+++ svn/src/drivers/i2c/adm1027/adm1027.c
@@ -56,7 +56,6 @@ static void adm1027_noop(device_t dummy)
}
static struct device_operations adm1027_operations = {
- .scan_bus = scan_static_bus,
.read_resources = adm1027_noop,
.set_resources = adm1027_noop,
.enable_resources = adm1027_noop,
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -35,56 +35,53 @@
*/
static void adt7463_init(device_t dev)
{
- device_t parent;
int result;
- /* Find the ADT7463's parent device. */
- parent = dev-bus-dev;
- printk(BIOS_DEBUG, ADT7463 parent is %s\n, dev_path(parent));
+ printk(BIOS_DEBUG, ADT7463 is %s\n, dev_path(dev));
/* Set all fans to 'Fastest Speed Calculated by All 3 Temperature
* Channels Controls PWMx'.
*/
- result = smbus_write_byte(parent, 0x5c, 0xc2);
- result = smbus_write_byte(parent, 0x5d, 0xc2);
- result = smbus_write_byte(parent, 0x5e, 0xc2);
+ result = smbus_write_byte(dev, 0x5c, 0xc2);
+ result = smbus_write_byte(dev, 0x5d, 0xc2);
+ result = smbus_write_byte(dev, 0x5e, 0xc2);
/* Make sure that our fans never stop when temp. falls below Tmin,
* but rather keep going at minimum duty cycle (applies to automatic
* fan control mode only).
*/
- result = smbus_write_byte(parent, 0x62, 0xc0);
+ result = smbus_write_byte(dev, 0x62, 0xc0);
/* Set minimum PWM duty cycle to 25%, rather than the default 50%. */
- result = smbus_write_byte(parent, 0x64, 0x40);
- result = smbus_write_byte(parent, 0x65, 0x40);
- result = smbus_write_byte(parent, 0x66, 0x40);
+ result = smbus_write_byte(dev, 0x64, 0x40);
+ result = smbus_write_byte(dev, 0x65, 0x40);
+ result = smbus_write_byte(dev, 0x66, 0x40);
/* Set Tmin to 55C, rather than the default 90C. Above this temperature
* the fans will start blowing harder as temperature increases
* (automatic mode only).
*/
- result = smbus_write_byte(parent, 0x67, 0x37);
- result = smbus_write_byte(parent, 0x68, 0x37);
- result = smbus_write_byte(parent, 0x69, 0x37);
+ result = smbus_write_byte(dev, 0x67, 0x37);
+ result = smbus_write_byte(dev, 0x68, 0x37);
+ result = smbus_write_byte(dev, 0x69, 0x37);
/* Set THERM limit to 70C, rather than the default 100C.
* The fans will kick in at 100% if the sensors reach this temperature,
* (only in automatic mode, but supposedly even when hardware is
* locked up). This is a failsafe measure.
*/
- result = smbus_write_byte(parent, 0x6a, 0x46);
- result = smbus_write_byte(parent, 0x6b, 0x46);
- result = smbus_write_byte(parent, 0x6c, 0x46);
+ result = smbus_write_byte(dev, 0x6a, 0x46);
+ result = smbus_write_byte(dev, 0x6b, 0x46);
+ result =
[coreboot] Trac reminder: list of new ticket(s)
Ticket Owner Status Description #164 ste...@coresystems.de new Building Coreboot v4 r/5554 fails mysteriously on Debian lenny and etch (x86) #163 ste...@coresystems.de new Board still requires RAMBASE <1MB #162 oxygene new Move SYSTEM_TYPE to Kconfig #161 ste...@coresystems.de new Improve USB debug port configuration #160 oxygene new Build system: There's no convincing CFLAGS management for util/* #158 w...@gnu.org new buildrom svn error #156 hailfinger new Add Layout File capability to v3 and LAR tool #154 hailfinger new Flashing BIOSes from Fujitsu/Siemens is not supported #152 hailfinger new v3 Geode cs5536 UART2 wrongly configured #150 somebody new AMD DB800 dev board PLL strapping leaves CPU and GLIU in non-optimal clock #147 somebody new Linux kernel halts when scanning the PCI bus below 0:14.4 on RS690 #145 somebody new Fix CMOS handling #143 oxygene new unify intel car for model_6[ef]x #135 hailfinger new Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E) #129 stepan new etherboot payload does not work with HIGH_TABLES #128 somebody new Improve email user interface for trac #125 somebody new BCM5785 / HT1000 reset functions #111 somebody new Add i18n support for translating strings e.g. for bayou / coreinfo #110 somebody new Allow for per-device subsystem IDs #82 hailfinger new Fix the memory map in coreboot v3 #77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module #76 rminnich new coreboot messages should be accessible in dmesg #65 uwe new Unify SuperIO code? #45 somebody new Enforce consistent coding style #24 somebody new Remove all files which have a GPL-incompatible license #18 oxygene new autoprobe apic cluster and application processors on K8 systems #17 stepan new clean up coreboot table handling #16 ollie new I2C driver and mainboard Config.lb #11 yhlu new pirq table automation #8 uwe new Fully support all components of the ITE Super I/Os #5 uwe new Add license header to all source files #2 somebody new Complete tables of supported motherboards -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 05:59:52AM -0600, Myles Watson wrote: It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, Ah, whoops, I was wondering if I was doing the right thing there... so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? All boots were cold. 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] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 8:59 AM, Ward Vandewege w...@gnu.org wrote: On Mon, Jun 21, 2010 at 05:59:52AM -0600, Myles Watson wrote: It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, Ah, whoops, I was wondering if I was doing the right thing there... I should have been clearer. so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? All boots were cold. OK. Thanks for doing that. I guess I don't know what I'm looking at in the sensors output to see if the device initialization worked. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] New Socket370 and Model 68x for CAR
On Mon, 21 Jun 2010 09:23:36 -0600, Myles Watson myle...@gmail.com wrote: Yes, it tries without the mask, i.e for 681 - 68f it tries 680. Then, if that does not match, it dies with Unknown CPU. There is no failsafe nor fallback involved. What makes you think there is? It just means adding 1 entry to the table instead of 16. Ok, if it is not a _fail_safe_ or _fall_back_ why don't we just always do this as a default? My understanding is that barring errata, the stepping shouldn't matter. Just in case it does, we check it. If there isn't a specific entry for the stepping, we go to the normal case of using the ops without the stepping information. Correct, I get that. Why print out a generic message? I think it just means not-stepping-specific I like your verbage alot better than generic. Or even default would be better than generic. -- 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] New Socket370 and Model 68x for CAR
On 6/21/10 7:24 PM, Joseph Smith wrote: Why print out a generic message? I think it just means not-stepping-specific I like your verbage alot better than generic. Or even default would be better than generic. So, any native speakers with a good suggestion how the text should read out there? Using not-stepping-specific cpu ops sounds odd. Using default cpu ops is about as wrong as Using generic cpu ops because they're neither generic nor default. Maybe this? printk(BIOS_DEBUG, CPU: Using CPU ops for family %02x, model %02x (ignoring stepping %02x)\n, c.x86, c.x86_model, c.x86_mask); Or we just remove the message all together. I'll gladly ack a patch. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Nokia IP530 Finaly back to life.......
hey guys, i got my Nokia IP530 back to life, i build my own: - syslinux 3.86, - kernel 2.6.34 - busybox 1.16.2 - udev 1.41 and it boots very nicelly. The problem was in the kernel/udev of the debian distro... Why that is i dont know, but i will test the complete system to see if there are any problems. It was a big learing curve for me, and maybe i would be a nice idea to put together a howto to setup a basic image for booting linux with coreboot that gives stable results. Marc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Geode GX2 CAR.
Nils,
You can get the errata information from the AMD embedded dev site if
you want to sign up. http://wwwd.amd.com/dev.
I don't think that the GX2 has that bug and the register bit
definitions are completely different. I would leave it out.
Marc
On Sun, Jun 20, 2010 at 3:42 PM, Nils njaco...@hetnet.nl wrote:
Hi all,
I ported the Geode LX Cache As Ram code to GX2.
It works nice and it reduces the boot time with ~35 seconds.
Though there is a piece of code i would like some more information on.
It is in /src/northbridge/amd/lx/raminit.c :
/* SWAPSiF for PBZ 4112 (Errata 34) */
/* check for failed DLL settings now that we have done a memory write. */
msrnum = GLCP_DELAY_CONTROLS;
msr = rdmsr(msrnum);
if ((msr.lo 0x7FF) == 0x104) {
/* If you had it you would need to clear out the fail boot count flag */
/* (depending on where it counts from etc). */
/* The reset we are about to perform clears the PM_SSC register in the */
/* 5536 so will need to store the S3 resume flag in NVRAM otherwise */
/* it would do a normal boot */
/* Reset the system */
msrnum = MDD_SOFT_RESET;
msr = rdmsr(msrnum);
msr.lo |= 1;
wrmsr(msrnum, msr);
I omitted this routine in my patch because i could not find a description
about PBZ 4112 (Errata 34) and according to the LX databook the tested bit 8
is Reserved.
My questions are:
1. Where could i find information on Errata 34 ?
2.Would a similar test be needed/desired for GX2 ?
Thanks,Nils.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
http://se-eng.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5637 - in trunk/src: cpu/intel/socket_FC_PGA370 mainboard/intel/d810e2cb southbridge/intel/i82801bx
Author: linux_junkie
Date: Tue Jun 22 01:25:06 2010
New Revision: 5637
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5637
Log:
This patch adds support for the Intel D810E2CB (i810e/ICH2) desktop board.
Hurray, this is the first i810 board running CAR.
Signed-off-by: Joseph Smith j...@settoplinux.org
Acked-by: Stefan Reinauer ste...@coresystems.de
Added:
trunk/src/mainboard/intel/d810e2cb/
trunk/src/mainboard/intel/d810e2cb/Kconfig
trunk/src/mainboard/intel/d810e2cb/chip.h
trunk/src/mainboard/intel/d810e2cb/devicetree.cb
trunk/src/mainboard/intel/d810e2cb/gpio.c
trunk/src/mainboard/intel/d810e2cb/irq_tables.c
trunk/src/mainboard/intel/d810e2cb/mainboard.c
trunk/src/mainboard/intel/d810e2cb/romstage.c
Modified:
trunk/src/cpu/intel/socket_FC_PGA370/Kconfig
trunk/src/southbridge/intel/i82801bx/i82801bx.h
trunk/src/southbridge/intel/i82801bx/i82801bx_lpc.c
Modified: trunk/src/cpu/intel/socket_FC_PGA370/Kconfig
==
--- trunk/src/cpu/intel/socket_FC_PGA370/KconfigMon Jun 21 21:40:09
2010(r5636)
+++ trunk/src/cpu/intel/socket_FC_PGA370/KconfigTue Jun 22 01:25:06
2010(r5637)
@@ -23,3 +23,16 @@
select CPU_INTEL_MODEL_68X
select MMX
select SSE
+ select USE_PRINTK_IN_CAR
+ select USE_DCACHE_RAM
+ select TINY_BOOTBLOCK
+
+config DCACHE_RAM_BASE
+ hex
+ default 0xffdf8000
+ depends on CPU_INTEL_SOCKET_FC_PGA370
+
+config DCACHE_RAM_SIZE
+ hex
+ default 0x8000
+ depends on CPU_INTEL_SOCKET_FC_PGA370
Added: trunk/src/mainboard/intel/d810e2cb/Kconfig
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ trunk/src/mainboard/intel/d810e2cb/Kconfig Tue Jun 22 01:25:06 2010
(r5637)
@@ -0,0 +1,52 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Joseph Smith j...@settoplinux.org
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; version 2 of the License.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+##
+
+config BOARD_INTEL_D810E2CB
+ bool D810E2CB
+ select ARCH_X86
+ select CPU_INTEL_SOCKET_FC_PGA370
+ select NORTHBRIDGE_INTEL_I82810
+ select SOUTHBRIDGE_INTEL_I82801BX
+ select SUPERIO_SMSC_SMSCSUPERIO
+ select HAVE_PIRQ_TABLE
+ select UDELAY_TSC
+ select BOARD_ROMSIZE_KB_512
+ select HAVE_MAINBOARD_RESOURCES
+ select GFXUMA
+
+config MAINBOARD_DIR
+ string
+ default intel/d810e2cb
+ depends on BOARD_INTEL_D810E2CB
+
+config MAINBOARD_PART_NUMBER
+ string
+ default D810E2CB
+ depends on BOARD_INTEL_D810E2CB
+
+config HAVE_OPTION_TABLE
+ bool
+ default n
+ depends on BOARD_INTEL_D810E2CB
+
+config IRQ_SLOT_COUNT
+ int
+ default 7
+ depends on BOARD_INTEL_D810E2CB
+
Added: trunk/src/mainboard/intel/d810e2cb/chip.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ trunk/src/mainboard/intel/d810e2cb/chip.h Tue Jun 22 01:25:06 2010
(r5637)
@@ -0,0 +1,21 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Joseph Smith j...@settoplinux.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+extern struct chip_operations mainboard_ops;
+struct mainboard_config {};
Added: trunk/src/mainboard/intel/d810e2cb/devicetree.cb
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ trunk/src/mainboard/intel/d810e2cb/devicetree.cb
[coreboot] [commit] r5638 - trunk/src/mainboard/intel
Author: linux_junkie Date: Tue Jun 22 01:27:15 2010 New Revision: 5638 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5638 Log: This patch adds support for the Intel D810E2CB (i810e/ICH2) desktop board. Hurray, this is the first i810 board running CAR. Signed-off-by: Joseph Smith j...@settoplinux.org Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/src/mainboard/intel/Kconfig Modified: trunk/src/mainboard/intel/Kconfig == --- trunk/src/mainboard/intel/Kconfig Tue Jun 22 01:25:06 2010(r5637) +++ trunk/src/mainboard/intel/Kconfig Tue Jun 22 01:27:15 2010(r5638) @@ -2,6 +2,7 @@ prompt Mainboard model depends on VENDOR_INTEL +source src/mainboard/intel/d810e2cb/Kconfig source src/mainboard/intel/d945gclf/Kconfig source src/mainboard/intel/eagleheights/Kconfig source src/mainboard/intel/jarrell/Kconfig -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Support for Intel D810E2CB (i810e/ICH2)
On 06/20/2010 07:55 AM, Stefan Reinauer wrote: Hello, This patch adds support for the Intel D810E2CB desktop board. This patch has to go in after the other two patches I have submitted, it is dependent on them. Hurray, this is the first i810 board running CAR :-) Build and boot (bootlog attached) tested: Signed-off by: Joseph Smith j...@settoplinux.org Acked-by: Stefan Reinauer ste...@coresystems.de with some caveats: Index: src/mainboard/intel/d810e2cb/gpio.c === --- src/mainboard/intel/d810e2cb/gpio.c (revision 0) +++ src/mainboard/intel/d810e2cb/gpio.c (revision 0) @@ -0,0 +1,212 @@ +#define ICH_IO_BASE_ADDR 0x0500 /* GPIO base address register */ This is duplicated from i82801ax_lpc.c ... Can it go into i82801ax.h and be included here instead? (It's also called GPIO_BASE_ADDRESS elsewhere) + + /* Set the value for GPIO base address register and enable GPIO. */ + pci_write_config32(dev, 0x58, (ICH_IO_BASE_ADDR | 1)); + pci_write_config8(dev, 0x5c, 0x10); + 0x58 is GPIO_BASE_ICH0_5 in i82801ax.h (should be renamed to GPIO_BASE I guess) + udelay(10); Index: src/mainboard/intel/d810e2cb/Kconfig === --- src/mainboard/intel/d810e2cb/Kconfig(revision 0) +++ src/mainboard/intel/d810e2cb/Kconfig(revision 0) @@ -0,0 +1,65 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2010 Joseph Smithj...@settoplinux.org +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; version 2 of the License. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +config BOARD_INTEL_D810E2CB + bool D810E2CB + select ARCH_X86 + select CPU_INTEL_SOCKET_FC_PGA370 + select NORTHBRIDGE_INTEL_I82810 + select SOUTHBRIDGE_INTEL_I82801BX + select SUPERIO_SMSC_SMSCSUPERIO + select HAVE_PIRQ_TABLE + select UDELAY_TSC + select BOARD_ROMSIZE_KB_512 + select HAVE_MAINBOARD_RESOURCES + select USE_PRINTK_IN_CAR can this go into the CPU's Kconfig? + select GFXUMA + select USE_DCACHE_RAM And this, too? + select TINY_BOOTBLOCK And this? + +config MAINBOARD_DIR + string + default intel/d810e2cb + depends on BOARD_INTEL_D810E2CB + +config MAINBOARD_PART_NUMBER + string + default D810E2CB + depends on BOARD_INTEL_D810E2CB + +config HAVE_OPTION_TABLE + bool + default n + depends on BOARD_INTEL_D810E2CB + +config DCACHE_RAM_BASE + hex + default 0xffdf8000 + depends on BOARD_INTEL_D810E2CB And this. + +config DCACHE_RAM_SIZE + hex + default 0x8000 + depends on BOARD_INTEL_D810E2CB + And this. +config IRQ_SLOT_COUNT + int + default 7 + depends on BOARD_INTEL_D810E2CB + Stefan Done, thanks r5637 and r5638 -- 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] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 07:36:39AM -0600, Myles Watson wrote: On Mon, Jun 21, 2010 at 5:59 AM, Myles Watson myle...@gmail.com wrote: On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote: Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Thanks for testing. It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? The ADM1027 doesn't expect to have children, so it has no scan_bus method. I had thought that the ADM1027 was some kind of a controller for the ADT4763, but it looks like the same type of device. Is there really an ADM1027 on your board? I don't see it in your sensors output. So... the first two patches are the same as before. The third patch adds a scan_bus method to the ADM1027 so that the ADT4763 can be initialized, and the fourth patch replaces the ADM1027 with the ADT4763 in the device tree, and removes the third patch. I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4. See http://ward.vandewege.net/coreboot/s2881/20100621-myles/ The temperature differences (higher readouts in head + 1 + 2 + 3 + 4 seem to be the consequence of less than optimal cooling of the board - and the fact that it was entirely cooled off before the first boot (head + 1 + 2 + 3) only. 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] two pathes about libpayload
hi all,
the first one lib.patch make libpayload install itself into its own
directory which instead of /opt.
xcompile.patch which fix the libpayload xcompile script load the wrong path
of coreboot/util.
Signed-off by: Cai Bai Yin caibaiyin@gmail.com
Index: Makefile
===
--- Makefile (revision 5634)
+++ Makefile (working copy)
@@ -58,7 +58,7 @@
HOSTCFLAGS := -I$(srck) -I$(objk) -pipe
HOSTCXXFLAGS := -I$(srck) -I$(objk) -pipe
-DESTDIR = /opt
+DESTDIR = $(src)/install
DOXYGEN := doxygen
DOXYGEN_OUTPUT_DIR := doxygen
Index: util/xcompile/xcompile
===
--- util/xcompile/xcompile (revision 5634)
+++ util/xcompile/xcompile (working copy)
@@ -41,7 +41,7 @@
# This should be a loop over all supported architectures
TARCH=i386
TWIDTH=32
-for gccprefixes in `pwd`/util/crossgcc/xgcc/bin/${TARCH}-elf- ${TARCH}-elf- ; do
+for gccprefixes in `pwd`/../../util/crossgcc/xgcc/bin/${TARCH}-elf- ${TARCH}-elf- ; do
if ! which ${gccprefixes}as 2/dev/null /dev/null; then
continue
fi
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
