Quoting "anders(a)jenbo.dk" <anders(a)jenbo.dk>:
> When a memory module Is larger the nb supports it can be run are the
> max supported size.
> The nb you have supports 512 MB per side, the 1 gb you have has 1
> side with 1gb so you nb can't handle the full size, the 2 gb has 2
> sides With 1gb, so the nb can use a total of 1 gb.
> I committed a patch to handle this type of stuff for 440bx.
> All you have to do is force the sides to the max supported, if any
> thing larger is detected.
Hmm, I did not know that about the different sides of RAM. Thank you. (And thanks Google for filling in the details about low/high density RAM...)
Okay, I'm comparing the raminit.c files for the cn700 and 440bx, I think I see what to do.
On Thu, Aug 5, 2010 at 5:03 AM, Alec Wright <alecjw(a)member.fsf.org> wrote:
> I have a spare flash chip, and I should be able to reflash using an
> external programmer if everything goes wrong. If I configure flashrom
> as a motherboard with the f71805f chip, should i at least get serial
The first step would be to test flashrom and your spare flash chip
with the factory BIOS. Read the original, swap it out, and write the
original to the spare. If it still boots, then there's no harm in
trying other things.
Your northbridge and southbridge may also need some configuration
before you can get serial debugging. If you look at SerialICE, it has
several examples of minimal configurations to get serial working.
When a memory module Is larger the nb supports it can be run are the max supported size.
The nb you have supports 512 MB per side, the 1 gb you have has 1 side with 1gb so you nb can't handle the full size, the 2 gb has 2 sides With 1gb, so the nb can use a total of 1 gb.
I committed a patch to handle this type of stuff for 440bx.
All you have to do is force the sides to the max supported, if any thing larger is detected.
----- Reply message -----
Fra: "ron minnich" <rminnich(a)gmail.com>
Dato: tir., aug. 3, 2010 19:41
Emne: [coreboot] Jetway J7F4K1G5S-LF acting weird, any suggestions?
Well, in the worst-case scenario, as a test, you can modify the
raminit and just force it to use only 512M. Just as a test. I do this
sometimes when I have ram issues.
coreboot mailing list: coreboot(a)coreboot.org
Date: Thu Aug 5 08:12:16 2010
New Revision: 5684
The number of cores is got by reading the bit 15,13,12 of [0,24,3,e8].
The bit 15 seems to be a new feature when CPU started to have more than 4
Yes, this was add for revD.
Signed-off-by: Zheng Bao <zheng.bao(a)amd.com>
Acked-by: Marc Jones <marcj303(a)gmail.com>
--- trunk/src/northbridge/amd/amdht/h3ncmn.c Wed Aug 4 21:29:11 2010 (r5683)
+++ trunk/src/northbridge/amd/amdht/h3ncmn.c Thu Aug 5 08:12:16 2010 (r5684)
@@ -555,16 +555,17 @@
ASSERT((node < nb->maxNodes));
- /* Read CmpCap */
+ /* Read CmpCap [1:0] */
- 13, 12, &temp);
+ 15, 12, &temp);
+ /* bits[15,13,12] specify the cores */
/* Support Downcoring */
- cores = temp + 1;
+ cores = ((temp & 8) >> 1) + (temp & 3) + 1;
Change the default path to libpayload since they are both in payloads/.
Change LAR support to default to no, since that is the default in libpayload.
With this change, the steps to build coreinfo are:
1. Build libpayload:
2. Build coreinfo
Signed-off-by: Myles Watson <mylesgw(a)gmail.com>
I've been looking through the datasheets for my superio (f71882f, not
officially supported in coreboot) and the .h and _early_serial.c files
for the f71805f (supported in coreboot). It looks like my superio
might be compatible. (same addresses/commands etc). Is it worth a try?
My COM1 port's fried and my COM2 port doesnt seem to work, although I
think the latter might be an issue with the BIOS disabling it. If
that's the case, how easy would it be to get a basic coreboot image on
my board with serial debugging? RAM etc can come later.
It looks like EHCI debug is possible on my motherboard, but at $90
each, I can't really afford a debugger - my motherboard cost half
On Tue, Aug 3, 2010 at 4:39 PM, <silversurfer.2010(a)gmx.de> wrote:
> I bought the “PLX NET20DC USB Debug Device”.
> Now I want to use this device for debug purpose. But I get with different
> mainboards the same build error messages.
> Can anybody help?
> cc1: warnings being treated as errors
We've made warnings errors since this code has been used much. You
can change the default value for WARNINGS_ARE_ERRORS in src/Kconfig to
n, make oldconfig, and try building again. It's a bonus if you fix
the warnings and submit a patch :)