[coreboot] r929 - in coreboot-v3: arch/x86 include include/device superio/winbond/w83627hf

2008-10-14 Thread svn
Author: cozzie Date: 2008-10-15 08:41:16 +0200 (Wed, 15 Oct 2008) New Revision: 929 Modified: coreboot-v3/arch/x86/pci_ops_conf1.c coreboot-v3/include/device/pci_ids.h coreboot-v3/include/spd.h coreboot-v3/superio/winbond/w83627hf/stage1.c Log: Commit a few things I forgot with the vt8

Re: [coreboot] [PATCH] v3: CN700 initram support

2008-10-14 Thread Corey Osgood
I'm reposting the patch with the changes, just to make sure I got everything, and I've made a few more little changes. It once again builds without warning and passes a ram_check(). Thanks, Corey Add ram init support for the Via CN700 to v3. Note that this isn't based on current v2 support, but ra

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread Peter Stuge
ron minnich wrote: > > Which voltage do you have on pin 7 and 8 of the flash chip? Can you check this? > > And doesn't this guy have block lock registers? > > (It's using the sst_fwhub driver, which doesn't know about lock > > registers.) > > what's odd is it won't for either the lpc or fwhub v

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 8:14 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > ron minnich wrote: >> Found chipset "ATI(AMD) SB600", enabling flash write... OK. >> Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. >> Flash image seems to be a legacy BIOS. Disabling checks. >> ERASE

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread Peter Stuge
ron minnich wrote: > Found chipset "ATI(AMD) SB600", enabling flash write... OK. > Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. > Flash image seems to be a legacy BIOS. Disabling checks. > ERASE FAILED! .. > Marc, you had no trouble right? This is odd. Identical hardware

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread ron minnich
[EMAIL PROTECTED] flashrom]# ./flashrom -w /tmp/bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "ATI(AMD) SB600", enabling flash write... OK. Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. Flash image seems to be a legacy BIOS. Disabling checks

Re: [coreboot] [PATCH] v3: determine global variable location

2008-10-14 Thread ron minnich
return (void *) CONFIG_RAM_STACK_LOCATION; not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 7:47 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > I was expecting that my 64-bit values would lose their upper bits, but I > wasn't expecting what I got. > just cast them to u32 in the call to printk (u32) whatever, (u32) whatever, etc. ron -- coreboot mailing list: co

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread Myles Watson
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2008 3:29 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: Extra pairs of eyes > > On Tue, Oct 14, 2008 at 2:13 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > I'm tired of staring at this

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread Myles Watson
> -Original Message- > From: Stefan Reinauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2008 5:18 PM > To: Myles Watson > Cc: Coreboot; ron minnich > Subject: Re: [coreboot] Extra pairs of eyes > > Myles Watson wrote: > > I'm tired of staring at this piece of code wondering w

Re: [coreboot] Patch: New board: Bcom WinNET P680

2008-10-14 Thread Corey Osgood
On Tue, Oct 14, 2008 at 7:41 PM, ron minnich <[EMAIL PROTECTED]> wrote: > sweet. > Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> > > but let's see if there are other comments. I've got no problems with it, even the coding style looks clean to me. Acked-by: Corey Osgood <[EMAIL PROTECTED]> -C

[coreboot] [PATCH] v3: determine global variable location

2008-10-14 Thread Carl-Daniel Hailfinger
We need a way to find out where our stack and our global variables are at any given moment. This is a first generic try, but doing this in a processor-specific way would be more appropriate. Please note that this needs a new #define or Kconfig variable somewhere: CONFIG_RAM_STACK_LOCATION. As an a

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread Peter Stuge
ron minnich wrote: > no workaround in the bios setup? coreboot would be the workaround.. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread Peter Stuge
Marc Jones wrote: > SB600 has four write once LPC ROM protect areas. It is not possible to write > enable that area once the register is set so print a warning. > > Signed-off-by: Marc Jones <[EMAIL PROTECTED]> Clean up the whitespace before committing please. Acked-by: Peter Stuge <[EMAIL PROT

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread Carl-Daniel Hailfinger
On 15.10.2008 02:22, Marc Jones wrote: > More could be done to open up a larger ROM area etc but this will > inform you of a major problem. > > SB600 has four write once LPC ROM protect areas. It is not possible to > write enable that area once the register is set so print a warning. > > Signed-off

Re: [coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 5:22 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > More could be done to open up a larger ROM area etc but this will inform you > of a major problem. bummer! Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> no workaround in the bios setup? I guess I will see. ron -- corebo

[coreboot] [patch][flashrom] sb600 flashrom

2008-10-14 Thread Marc Jones
More could be done to open up a larger ROM area etc but this will inform you of a major problem. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors SB600 has four write once LPC ROM protect areas. It is not possible t

Re: [coreboot] Patch: New board: Bcom WinNET P680

2008-10-14 Thread ron minnich
sweet. Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> but let's see if there are other comments. ron On Tue, Oct 14, 2008 at 1:27 PM, Alex Mauer <[EMAIL PROTECTED]> wrote: > Attached please find a patch which adds support for the Bcom P680 mainboard. > This board is a thin client system, used

Re: [coreboot] flashrom and the dbm690t

2008-10-14 Thread Marc Jones
ron minnich wrote: [EMAIL PROTECTED] qemu]# /usr/local/bin/flashrom -w /tmp/bios.bin Calibrating delay loop... OK. No coreboot table found. WARNING: No chipset found. Flash detection will most likely fail. Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. Flash image seems t

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread Stefan Reinauer
Myles Watson wrote: > I'm tired of staring at this piece of code wondering why printk isn't > working as I expected. Can someone point out what I've obviously missed? > > code (inserted in pci_device.c in pci_get_resource() right before the > limit mask and return): > if (resource->flags) >

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 23:35, Marc Jones wrote: > ron minnich wrote: >> On Tue, Oct 14, 2008 at 2:16 PM, Carl-Daniel Hailfinger >>> Calling anything after disable_car() returns can only be done reliably >>> if the stack has not moved. You see, gcc is free to reorder stuff as it >>> sees fit and it could ins

Re: [coreboot] [PATCH] v3: CN700 initram support

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 21:40, Corey Osgood wrote: > On Tue, Oct 14, 2008 at 6:32 AM, Carl-Daniel Hailfinger < > [EMAIL PROTECTED]> wrote: > > >> On 14.10.2008 06:21, Corey Osgood wrote: >> >> > > > >>> +/* Is this correct? */ >>> +static void read32(u32 addr) >>> +{ >>> + u32 val; >>> +

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Marc Jones
ron minnich wrote: On Tue, Oct 14, 2008 at 2:16 PM, Carl-Daniel Hailfinger Calling anything after disable_car() returns can only be done reliably if the stack has not moved. You see, gcc is free to reorder stuff as it sees fit and it could insert almost anything between disable_car() and the cal

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 2:16 PM, Carl-Daniel Hailfinger > Calling anything after disable_car() returns can only be done reliably > if the stack has not moved. You see, gcc is free to reorder stuff as it > sees fit and it could insert almost anything between disable_car() and > the call to stage1.

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 2:13 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > I'm tired of staring at this piece of code wondering why printk isn't > working as I expected. Can someone point out what I've obviously missed? > > code (inserted in pci_device.c in pci_get_resource() right before the limi

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread Myles Watson
On Tue, Oct 14, 2008 at 3:23 PM, Carl-Daniel Hailfinger < [EMAIL PROTECTED]> wrote: > On 14.10.2008 23:13, Myles Watson wrote: > > I'm tired of staring at this piece of code wondering why printk isn't > > working as I expected. Can someone point out what I've obviously missed? > > > > code (inser

Re: [coreboot] Extra pairs of eyes

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 23:13, Myles Watson wrote: > I'm tired of staring at this piece of code wondering why printk isn't > working as I expected. Can someone point out what I've obviously missed? > > code (inserted in pci_device.c in pci_get_resource() right before the limit > mask and return): > if (

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 22:21, ron minnich wrote: > On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <[EMAIL PROTECTED]> wrote: > >> Why not ret and do a call (or ljmp) from stage0_main to main(). It would >> make the code easier to follow and it would be easy to add code if anything >> were required between d

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 21:10, Marc Jones wrote: > ron minnich wrote: >> On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <[EMAIL PROTECTED]> wrote: >> >>> Why not ret and do a call (or ljmp) from stage0_main to main(). It >>> would >>> make the code easier to follow and it would be easy to add code if >>> anythi

[coreboot] Extra pairs of eyes

2008-10-14 Thread Myles Watson
I'm tired of staring at this piece of code wondering why printk isn't working as I expected. Can someone point out what I've obviously missed? code (inserted in pci_device.c in pci_get_resource() right before the limit mask and return): if (resource->flags) { printk(BIOS_DEBUG, "%s re

[coreboot] Patch: New board: Bcom WinNET P680

2008-10-14 Thread Alex Mauer
Attached please find a patch which adds support for the Bcom P680 mainboard. This board is a thin client system, used in (at least) the Neoware e140 thin client. It's essentially the same as the epia-cn, but with a Winbond W83697HG Super-IO. Signed-off-by: Alex Mauer <[EMAIL PROTECTED]> Thi

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <[EMAIL PROTECTED]> wrote: > Why not ret and do a call (or ljmp) from stage0_main to main(). It would > make the code easier to follow and it would be easy to add code if anything > were required between disable car and the jmp. > OK Marc is right again

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 12:15 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > That should be specific to the CPU or platform but it would be good to be > below 1MB. 0x1000 is a normal location. This will allow the stack to be > shared if/when coreboot goes to real mode (SeaBIOS integration discussion)

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 12:15 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > Carl-Daniel Hailfinger wrote: >> >> I believe the stage0_main name is misleading. After all, stage0 >> >> is pure asm and lives in its own .S file. >> > >> > let's call it stage1 then and main() >> >> Works for me. > > I'm a

Re: [coreboot] [PATCH] v3: CN700 initram support

2008-10-14 Thread Corey Osgood
On Tue, Oct 14, 2008 at 6:32 AM, Carl-Daniel Hailfinger < [EMAIL PROTECTED]> wrote: > On 14.10.2008 06:21, Corey Osgood wrote: > > > +/* Is this correct? */ > > +static void read32(u32 addr) > > +{ > > + u32 val; > > + volatile unsigned long *x; > > + x = (void *)addr; > > + val

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Marc Jones
Carl-Daniel Hailfinger wrote: If the stack is > CARBASE, then it is the CARBASE + CARSIZE - 4. If < carbase, it is the RAMBASE + RAMSIZE - 4. Done. But let's make it flexible. Hm yes, something along these lines. Which leads to an interesting question: Where do we want the stack if we have

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Peter Stuge
Carl-Daniel Hailfinger wrote: > >> I believe the stage0_main name is misleading. After all, stage0 > >> is pure asm and lives in its own .S file. > > > > let's call it stage1 then and main() > > Works for me. I'm afraid I don't like that. Please suggest something that makes the timeline obvious.

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Marc Jones
ron minnich wrote: On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <[EMAIL PROTECTED]> wrote: Why not ret and do a call (or ljmp) from stage0_main to main(). It would make the code easier to follow and it would be easy to add code if anything were required between disable car and the jmp. it's j

Re: [coreboot] [PATCH] v3: vt8237 stage1 support

2008-10-14 Thread Corey Osgood
On Tue, Oct 14, 2008 at 6:46 AM, Carl-Daniel Hailfinger < [EMAIL PROTECTED]> wrote: > On 14.10.2008 05:33, Corey Osgood wrote: > > See attached. Stage2 has to wait until CAR can be disabled on C7. > > > > Add stage1 support for vt8237[RS] to v3. > > > > Signed-off-by: Corey Osgood <[EMAIL PROTECTE

[coreboot] r928 - in coreboot-v3/southbridge: . via via/vt8237

2008-10-14 Thread svn
Author: cozzie Date: 2008-10-14 20:26:09 +0200 (Tue, 14 Oct 2008) New Revision: 928 Added: coreboot-v3/southbridge/via/ coreboot-v3/southbridge/via/vt8237/ coreboot-v3/southbridge/via/vt8237/Makefile coreboot-v3/southbridge/via/vt8237/stage1.c coreboot-v3/southbridge/via/vt8237/vt82

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 10:57 AM, Carl-Daniel Hailfinger > I can mail a new version to the list in ~2 hours. If that's OK for you, > I'll go ahead. perfect. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 18:55, ron minnich wrote: > On Tue, Oct 14, 2008 at 9:38 AM, Carl-Daniel Hailfinger > >> I believe the stage0_main name is misleading. After all, stage0 is pure >> asm and lives in its own .S file. >> > > let's call it stage1 then and main() > Works for me. >>> I don't s

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 9:38 AM, Carl-Daniel Hailfinger > I believe the stage0_main name is misleading. After all, stage0 is pure > asm and lives in its own .S file. let's call it stage1 then and main() >> I don't see a need for swtich_stack, since disable_car pretty much >> does that now -- it

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <[EMAIL PROTECTED]> wrote: > Why not ret and do a call (or ljmp) from stage0_main to main(). It would > make the code easier to follow and it would be easy to add code if anything > were required between disable car and the jmp. > it's just not doable o

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 18:31, Marc Jones wrote: > ron minnich wrote: >> Here is a version I put together yesterday as a straw main. >> >> summary: >> >> stage1_main is now split into stage0_main and main(). stage0_main runs >> up to and including initram. It then calls disable_car. >> >> disable_car does wh

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 17:43, ron minnich wrote: > Here is a version I put together yesterday as a straw main. > Nice. I'll comment inline. > summary: > > stage1_main is now split into stage0_main and main(). stage0_main runs > up to and including initram. It then calls disable_car. > I believe the

Re: [coreboot] AMD K8 define fix

2008-10-14 Thread Myles Watson
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2008 10:31 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: AMD K8 define fix > > On Tue, Oct 14, 2008 at 9:13 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > This patch fixes an ifdef that

[coreboot] r3658 - trunk/util/superiotool

2008-10-14 Thread svn
Author: uwe Date: 2008-10-14 18:34:38 +0200 (Tue, 14 Oct 2008) New Revision: 3658 Modified: trunk/util/superiotool/ali.c trunk/util/superiotool/fintek.c trunk/util/superiotool/ite.c trunk/util/superiotool/smsc.c trunk/util/superiotool/winbond.c Log: Drop global register 0x07 for all

Re: [coreboot] AMD K8 define fix

2008-10-14 Thread Myles Watson
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Peter Stuge > Sent: Tuesday, October 14, 2008 10:24 AM > To: Coreboot > Subject: Re: [coreboot] AMD K8 define fix > > Myles Watson wrote: > > This patch fixes an ifdef that should have been an ifndef.

[coreboot] r927 - coreboot-v3/northbridge/amd/k8

2008-10-14 Thread svn
Author: myles Date: 2008-10-14 18:31:57 +0200 (Tue, 14 Oct 2008) New Revision: 927 Modified: coreboot-v3/northbridge/amd/k8/domain.c Log: Change an ifdef to an ifndef so it matches the logic of v2. Clean up some white space. Signed-off-by: Myles Watson <[EMAIL PROTECTED]> Acked-by: Peter Stug

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Marc Jones
ron minnich wrote: Here is a version I put together yesterday as a straw main. summary: stage1_main is now split into stage0_main and main(). stage0_main runs up to and including initram. It then calls disable_car. disable_car does what it does now: copy CAR stack to ram stack, disable car, BU

Re: [coreboot] [PATCH] superiotool: Add dump support for it8726f

2008-10-14 Thread Uwe Hermann
On Mon, Oct 13, 2008 at 05:51:06AM -0400, Josh wrote: > I used the it8718f dump code as a reference for how to do this. > There was one value that I wasn't sure about. > > > 0x72 Watch Dog Timer Configuration Register > ldn idx def > 0x7 0x720x20it8718f superiotool cod

Re: [coreboot] AMD K8 define fix

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 9:13 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > This patch fixes an ifdef that should have been an ifndef. It also changes > white space so that it was obvious what the difference from v2 to v3 was. > nice find. I am glad to see that you are going through this code. It

[coreboot] r3657 - trunk/util/superiotool

2008-10-14 Thread svn
Author: uwe Date: 2008-10-14 18:28:50 +0200 (Tue, 14 Oct 2008) New Revision: 3657 Modified: trunk/util/superiotool/README trunk/util/superiotool/ite.c Log: Add dump support to ITE IT8726F, and add comments and a missing GPIO register to ITE IT8718F. Signed-off-by: Josh Profitt <[EMAIL PROTE

Re: [coreboot] AMD K8 define fix

2008-10-14 Thread Peter Stuge
Myles Watson wrote: > This patch fixes an ifdef that should have been an ifndef. It also changes > white space so that it was obvious what the difference from v2 to v3 was. > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> Acked-by: Peter Stuge <[EMAIL PROTECTED]> -- coreboot mailing list: co

[coreboot] AMD K8 define fix

2008-10-14 Thread Myles Watson
This patch fixes an ifdef that should have been an ifndef. It also changes white space so that it was obvious what the difference from v2 to v3 was. Signed-off-by: Myles Watson <[EMAIL PROTECTED]> Thanks, Myles Index: northbridge/amd/k8/domain.c ==

[coreboot] flashrom and the dbm690t

2008-10-14 Thread ron minnich
[EMAIL PROTECTED] qemu]# /usr/local/bin/flashrom -w /tmp/bios.bin Calibrating delay loop... OK. No coreboot table found. WARNING: No chipset found. Flash detection will most likely fail. Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff8. Flash image seems to be a legacy BIOS. D

Re: [coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread ron minnich
Here is a version I put together yesterday as a straw main. summary: stage1_main is now split into stage0_main and main(). stage0_main runs up to and including initram. It then calls disable_car. disable_car does what it does now: copy CAR stack to ram stack, disable car, BUT: instead of a ret,

Re: [coreboot] : v2: Move AMD RS690/SB600 PCI IDs to pci_ids.h

2008-10-14 Thread ron minnich
On Tue, Oct 14, 2008 at 7:35 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote: > I disagree - the vendor ID is still 0x1002 which is technically assigned > to ATI - the kernel has always had the policy of matching the vendor ID > to the assignee of the number, not the current owner of the IP. As an >

[coreboot] r926 - coreboot-v3/device

2008-10-14 Thread svn
Author: myles Date: 2008-10-14 14:27:23 +0200 (Tue, 14 Oct 2008) New Revision: 926 Modified: coreboot-v3/device/pci_rom.c Log: Because the enable bit was masked off, checking for 0x didn't work. This patch changes the place where the bit is masked. The other way to fix it would be t

[coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

2008-10-14 Thread Carl-Daniel Hailfinger
Right now we face the problem that we can't support processors which have a CAR area outside the usual RAM area. For those processors, we have to implement a stack copying and switching mechanism. Since gcc can't be told that the stack just moved, split stage1_main() into stage1_main() and stage1_l

Re: [coreboot] : v2: Move AMD RS690/SB600 PCI IDs to pci_ids.h

2008-10-14 Thread Jordan Crouse
On 13/10/08 16:07 -0600, Marc Jones wrote: > Uwe Hermann wrote: > > On Mon, Oct 13, 2008 at 02:50:05PM -0600, Marc Jones wrote: > >>> Move AMD RS690 and SB600 PCI IDs to pci_ids.h where they should be. > >>> > >>> Build-tested with the AMD dbm690t board. > >>> > >>> Signed-off-by: Uwe Hermann <[EMA

[coreboot] test for mailserver

2008-10-14 Thread Patrick Georgi
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v3: vt8237 stage1 support

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 05:33, Corey Osgood wrote: > See attached. Stage2 has to wait until CAR can be disabled on C7. > > Add stage1 support for vt8237[RS] to v3. > > Signed-off-by: Corey Osgood <[EMAIL PROTECTED]> > Looks good. I didn't understand one part of the code and would appreciate clarification

Re: [coreboot] [PATCH] v3: CN700 initram support

2008-10-14 Thread Carl-Daniel Hailfinger
On 14.10.2008 06:21, Corey Osgood wrote: > See attached. Thanks Carl-Daniel for the explanation on floats in CAR, hope > you don't mind that I've quoted you ;) > Sure, no problem. I feel honored. > Add ram init support for the Via CN700 to v3. Note that this isn't based on > current v2 support

[coreboot] r924 - coreboot-v3/superio/ite/it8712f

2008-10-14 Thread svn
Author: uwe Date: 2008-10-14 12:13:24 +0200 (Tue, 14 Oct 2008) New Revision: 924 Modified: coreboot-v3/superio/ite/it8712f/dts coreboot-v3/superio/ite/it8712f/it8712f.h coreboot-v3/superio/ite/it8712f/stage1.c coreboot-v3/superio/ite/it8712f/superio.c Log: Make the ITE IT8712F support

Re: [coreboot] [PATCH] v3: Fixup Fintek F71805F dts

2008-10-14 Thread Uwe Hermann
On Mon, Oct 13, 2008 at 09:08:25PM -0400, Corey Osgood wrote: > Acked-by: Corey Osgood <[EMAIL PROTECTED]> Thanks, r925. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@

Re: [coreboot] [PATCH] v3: Improve ITE IT8712F support

2008-10-14 Thread Uwe Hermann
On Mon, Oct 13, 2008 at 08:57:44PM -0400, Corey Osgood wrote: > Acked-by: Corey Osgood <[EMAIL PROTECTED]> Thanks, r924. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@

[coreboot] r925 - coreboot-v3/superio/fintek/f71805f

2008-10-14 Thread svn
Author: uwe Date: 2008-10-14 12:14:06 +0200 (Tue, 14 Oct 2008) New Revision: 925 Modified: coreboot-v3/superio/fintek/f71805f/dts Log: Fix incorrect and incomplete Fintek F71805F dts. Some LDNs got mixed up in the dts, some LDNs were missing. Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]> Acke