Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus

> Date: Fri, 12 Feb 2010 16:54:43 -0700 > From: marcj...@gmail.com > To: zheng@amd.com > CC: coreboot@coreboot.org > Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus > > On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones wrote: > > On Thu, Feb 11, 2010 at 6:54 PM, B

Re: [coreboot] Patch to add MSI MS-9652 support to CoreBoot

This looks fine to me, with a few nits which you might want to consider. ms9652_fam10/cache_as_ram_auto.c I would love to see that "cache_as_ram_auto.c" name go away. It has no meaning. A common new name is romstage.c If you could consider this it would be better. You might want to look at the

[coreboot] [patch] ms7135 fixes, updates

Adjust msi/ms7135 DCACHE_RAM_* config to previous 32KiB values, 4KiB is not enough to work. Additionally, modify the device tree so that the undocumented LDN 6 is ignored by the resource allocator, and while here, assign the parallel port DRQ, hardware monitor IRQ and drop NIC MAC address on SMBus

Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus

On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones wrote: > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng wrote: >> I kept on finding the problem. Now it is narrowed down to the line 108, >> src/arch/i386/coreboot_ram.ld. It is very, very, very, very confused. >> My CONFIG_RAMBASE should be 0x20, whic

Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus

On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng wrote: > I kept on finding the problem. Now it is narrowed down to the line 108, > src/arch/i386/coreboot_ram.ld. It is very, very, very, very confused. > My CONFIG_RAMBASE should be 0x20, which is more than 0x10, but > the location counter "." i

Re: [coreboot] [patch] coreboot romcc build issue

Marc Jones wrote: > I was having problems building a working romcc with the -O2 > optimization flag on ubuntu hardy. It was causing this error building > the bootblock: > bootblock.c:49.0: > Internal compiler error: low: next != prev? > > Signed-off-by: Marc Jones Acked-by: Peter Stuge -- cor

[coreboot] [patch] coreboot romcc build issue

I was having problems building a working romcc with the -O2 optimization flag on ubuntu hardy. It was causing this error building the bootblock: bootblock.c:49.0: Internal compiler error: low: next != prev? Signed-off-by: Marc Jones -- http://se-eng.com romcc-O2fix.patch Description: Binary

[coreboot] [commit] r5123 - trunk/util/romcc

Author: stuge Date: Fri Feb 12 22:28:15 2010 New Revision: 5123 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5123 Log: romcc: Fix a few (harmless) warnings Signed-off-by: Peter Stuge Acked-by: Peter Stuge Modified: trunk/util/romcc/romcc.c Modified: trunk/util/romcc/romcc.c ===

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On Fri, Feb 12, 2010 at 1:36 PM, Joseph Smith wrote: > On 02/12/2010 01:33 PM, Peter Stuge wrote: >> >> Joseph Smith wrote: Is there no way to auto-detect it? >>> >>> Nope, The onboard memory does not have SPD, hence the spd array. >> >> First configure 128, then test if 65MB can store d

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

Joseph Smith wrote: >>> So basically raminit would take twice as long.. >> >> Right. Do you know how long that would be? > > It takes about 2 seconds to get through raminit. so that would > make it about 4 seconds. That's really long. I completely agree that's not very nice. > I just thi

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On 02/12/2010 02:16 PM, Peter Stuge wrote: Joseph Smith wrote: So basically raminit would take twice as long.. Right. Do you know how long that would be? It takes about 2 seconds to get through raminit. so that would make it about 4 seconds. Anyways, in this situation I think it w

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

Joseph Smith wrote: > So basically raminit would take twice as long.. Right. Do you know how long that would be? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On 02/12/2010 01:50 PM, Peter Stuge wrote: Joseph Smith wrote: Is there no way to auto-detect it? Nope, The onboard memory does not have SPD, hence the spd array. First configure 128, then test if 65MB can store data, if not then fall back to 64. I guess, but that seems like alot of wasted

Re: [coreboot] printk question

Gregg Levine wrote: > would one of you please define the term "printk"? It is a function name, taken from the Linux kernel. It behaves like the C function printf() in that it accepts a format string and a list of parameters. It is used in coreboot to print debug messages. Source code here: http

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

Joseph Smith wrote: Is there no way to auto-detect it? >>> >>> Nope, The onboard memory does not have SPD, hence the spd array. >> >> First configure 128, then test if 65MB can store data, if not then >> fall back to 64. > > I guess, but that seems like alot of wasted boot time. What are

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On 02/12/2010 01:33 PM, Peter Stuge wrote: Joseph Smith wrote: Is there no way to auto-detect it? Nope, The onboard memory does not have SPD, hence the spd array. First configure 128, then test if 65MB can store data, if not then fall back to 64. I guess, but that seems like alot of wasted

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

Joseph Smith wrote: >> Is there no way to auto-detect it? > > Nope, The onboard memory does not have SPD, hence the spd array. First configure 128, then test if 65MB can store data, if not then fall back to 64. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/ma

[coreboot] printk question

Hello! Before I completely make a fool of myself, here, (don't ask!), would one of you please define the term "printk"? It sound as if this is one I should know, but again I can't be expected to know everything. (Even if the company mascots insist on it.) - Gregg C Levine gregg.drw...@gmail.c

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On 02/12/2010 12:54 PM, Myles Watson wrote: Acked-by: Myles Watson mailto:myle...@gmail.com>> Thanks r5122 -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5122 - in trunk/src/mainboard/thomson: . ip1000

Author: linux_junkie Date: Fri Feb 12 18:58:53 2010 New Revision: 5122 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5122 Log: This patch allows a Kconfig option to choose between 64MB (IP1000) and 128MB (IP1000T) of onboard memory. Signed-off-by: Joseph Smith Acked-by: Myles Watson

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On Fri, Feb 12, 2010 at 10:37 AM, Joseph Smith wrote: > On 02/12/2010 12:34 PM, Myles Watson wrote: > >> >> >> On Fri, Feb 12, 2010 at 10:15 AM, Joseph Smith > > wrote: >> >>We have found variations of the Thomson IP1000 (IP1000T) that have >>128MB onboard mem

Re: [coreboot] MP table multicore patch

On Fri, February 12, 2010 10:52 am, Myles Watson wrote: >> > Is this romcc code? If not, maybe it could even be recursive.. >> Not sure, but I know it is very sensitive. Running printk here reliably >> crashed coreboot, so the stack may be limited; > > > Have you tried increasing the stack size?

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On 02/12/2010 12:37 PM, Joseph Smith wrote: On 02/12/2010 12:34 PM, Myles Watson wrote: On Fri, Feb 12, 2010 at 10:15 AM, Joseph Smith mailto:j...@settoplinux.org>> wrote: We have found variations of the Thomson IP1000 (IP1000T) that have 128MB onboard memory instead of 64MB. This patch allow

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On 02/12/2010 12:34 PM, Myles Watson wrote: On Fri, Feb 12, 2010 at 10:15 AM, Joseph Smith mailto:j...@settoplinux.org>> wrote: We have found variations of the Thomson IP1000 (IP1000T) that have 128MB onboard memory instead of 64MB. This patch allows a Kconfig option to choose betw

Re: [coreboot] [PATCH] Thomson IP1000 onboard memory selection

On Fri, Feb 12, 2010 at 10:15 AM, Joseph Smith wrote: > We have found variations of the Thomson IP1000 (IP1000T) that have 128MB > onboard memory instead of 64MB. This patch allows a Kconfig option to choose > between the two. > Does it have to be chosen at compile time? Is there no way to auto

[coreboot] [PATCH] Thomson IP1000 onboard memory selection

We have found variations of the Thomson IP1000 (IP1000T) that have 128MB onboard memory instead of 64MB. This patch allows a Kconfig option to choose between the two. Signed-off-by: Joseph Smith -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org Index: src/mainboard/thomson/Kconfig ===

Re: [coreboot] MP table multicore patch

> > Is this romcc code? If not, maybe it could even be recursive.. > Not sure, but I know it is very sensitive. Running printk here reliably > crashed coreboot, so the stack may be limited; Have you tried increasing the stack size? It's too bad not to be able to use printk. Thanks, Myles -- c

Re: [coreboot] MP table multicore patch

> tpearson at raptorengineeringinc.com wrote: > > I have patched src/arch/i386/smp/mpspec.c to write a correct, multi-core > > MP table under amdfam10. > > I think this is very desirable and a great functionality improvement! > Thanks! > > But this code is not nice at all. You're right, it is quit

Re: [coreboot] MP table multicore patch

tpear...@raptorengineeringinc.com wrote: > I have patched src/arch/i386/smp/mpspec.c to write a correct, multi-core > MP table under amdfam10. I think this is very desirable and a great functionality improvement! > + // First, scan the root node for APIC clusters and APICs > + > for(roo

[coreboot] [commit] r5120 - trunk/src/devices

Author: stepan Date: Fri Feb 12 10:32:17 2010 New Revision: 5120 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5120 Log: Add two YABEL options to Kconfig Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/src/devices/Kconfig Modified: trunk/src/devices/Kcon

[coreboot] Patch to add MSI MS-9652 support to CoreBoot

Attached is a patch to add support for the MSI MS-9652 board to CoreBoot. The PCI routing tables and ACPI implementation are incomplete; I have all the functionality I need at this time so I will probably not be fixing them. The board boots and the following items work under the newconfig build s

[coreboot] MP table multicore patch

I have patched src/arch/i386/smp/mpspec.c to write a correct, multi-core MP table under amdfam10. The change is mainly to add APIC cluster scanning support, as the amdfam10 processors place all auxiliary APICs under one APIC cluster device. Before this patch on my MSI 9652 board an MP table was w

Re: [coreboot] resubmit - patch for Win Enterprises PL-6064/65 support

Patch looks good (excluding comments already made), with one side thought: Looks like the UARTS are on the SuperIo device, a-la db800, but there no call to disable_internal_uarts? It may be a nicety, but it stops any potential issues with early debug? Cheers, Edwin -Original Message- From

Re: [coreboot] resubmit - patch for Win Enterprises PL-6064/65 support

Am 12.02.2010 00:25, schrieb ron minnich: > I thought we were trying to get away from this kind of thing. Why is > it still there? Not quite there yet. I'll handle all boards that are in the tree when I get to removing that. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.cor