These sockets are good because their pins are hard to bend, so I used it on
the bottom of the "pie":
This ones pins are easier to bend, so I used them to bend Chip Enable pins.
If part is deselected (Chip Enable floating), Chip Enable pin should be
high, but my flash part doesn't have internal pull-ups, so sometimes during
flashing deselected chip was badly flashed. I soldered external 200 kilohm
resistors to pull-up both Chip Enable pins. Now it works for me :)
I hope someone will have time to update wiki :)
Date: Fri Sep 3 11:33:50 2010
New Revision: 5772
Add support for dumping RCBA registers for i7
Signed-off-by: Warren Turkal <wt(a)penguintechs.org>
Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
--- trunk/util/inteltool/rootcmplx.c Fri Sep 3 11:32:17 2010 (r5771)
+++ trunk/util/inteltool/rootcmplx.c Fri Sep 3 11:33:50 2010 (r5772)
@@ -36,14 +36,15 @@
+ case PCI_DEVICE_ID_INTEL_ICH8:
+ case PCI_DEVICE_ID_INTEL_ICH8M:
- case PCI_DEVICE_ID_INTEL_ICH8M:
- case PCI_DEVICE_ID_INTEL_ICH8:
+ case PCI_DEVICE_ID_INTEL_ICH10R:
rcba_phys = pci_read_long(sb, 0xf0) & 0xfffffffe;
Am Donnerstag, den 02.09.2010, 16:06 -0500 schrieb Scott:
> -----Original Message-----
> From: coreboot-bounces(a)coreboot.org [mailto:firstname.lastname@example.org] On Behalf Of Paul Menzel
> Sent: Thursday, September 02, 2010 04:11 AM
> To: coreboot(a)coreboot.org
> Subject: Re: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0'
> Am Donnerstag, den 02.09.2010, 10:59 +0200 schrieb Paul Menzel:
> > Am Donnerstag, den 02.09.2010, 00:40 -0500 schrieb Scott:
> > > The subversion comment for -r 5571 states:
> > >
> > > The AMD Fam10 code breaks with coreboot 4.5.0.
> > > Potentially caused by reordering. Going back to 4.4.4
> > > which is known working on Fam10 until gcc or the Fam10 code is fixed.
> > >
> > > Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de>
> > > Acked-by: Stefan Reinauer <stepan(a)coresystems.de>
> > >
> > >
> > > I encountered the same problem and debugged it. The AP code that disables
> > > cache as ram before the final halt has to be all inline. Function calls
> > > require a valid stack, and the stack is kept in the very cache as ram that
> > > the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache,
> > > and enable_cache and not getting inlined as intended. Function calls are
> > s/and/are/
> > > generated, and the first one after the AP clears msr 268 fails. The solution
> > > is to force these functions to generate inline code by adding
> > > __attribute__((always_inline)) to their declarations:
> > great find!!! Could you please send a patch according to the development
> > guidelines. Especially do not forget to add your Signed-off-by line.
> They are documented in the Wiki .
> > Just to leave no doubt, could you please add that you tested your fix
> > using GCC 4.5.0 with the used hardware.
> > [.]
> OK, I resubmitted it. Currently tested on simnow only. I will make a
> Tilapia binary and ask the AMD guys to test it. By the way, the patch
> file has Windows style line endings. I wonder if others can use it easily...
I guess next time this message should go to the list since it contains
information interesting to the others too.