Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
The code does not really support more than one CPU type at a time.
CAR code for K8/Fam10 autodetects the CPU and issues the right
commands based on autodetection.
That's fine, but it's not worth much without actually
Paweł Stawicki wrote:
I was able run my VIA c3 processor :-)
changing the line:
chip cpu/intel/socket_PGA370# CPU
to:
chip cpu/via/model_c3
in Config.lb
but how to turn on intel processors AND via C3 processors ?
Instead of the above, you should add the VIA cpu to the
Peter Stuge wrote:
but how to turn on intel processors AND via C3 processors ?
This is the first time it has been done.
Supporting several CPUs on one socket is not so new though.
The code does not really support more than one CPU type at a time.
Not exactly. All required
Myles Watson wrote:
The attached patch fixes booting for arima/hdama.
How should we really fix it? In v3 didn't we just scrap type 2
accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes absolutely no sense.
I sent a patch for this some days
Myles Watson wrote:
Right now I'd like to match newconfig and kill it as
quickly as possible.
Sure, same here. I don't think this patch interferes with this effort
though.
As long as all of the code that gets enabled/disabled is only print
statements, that's probably true. I
Uwe Hermann wrote:
See patch.
I'm happy for any comments. Also, I'm not sure how all this
hard_reset() stuff is meant to work. Many southbridges have _two_
implementations of hard_reset(). Why? Some only have one.
Some have none, but I guess that's OK, as their RAM init or other
coreboot
Hi all,
I did a fresh svn co the other day and tried building and
running a Tyan S2912_fam10 system. With older sources
(rev 4729) everything worked just fine, with the newest checkout
the booting process stops at setting MTRR registers or a little
later (depending on the compiler used: 3.4.6
On 21/10/09 18:27, Mark Marshall wrote:
Hi.
I've been lurking here for some time, and am slowly trying to get a ASUS
P2B board to run with coreboot. This is mainly so that I can get to
grips with how coreboot works - the P2B seemed to be an easy starting
point (well documented and cheap,
2009/10/22 Stefan Reinauer ste...@coresystems.de
Instead of the above, you should add the VIA cpu to the PGA370 socket.
right now the Config.lb of that socket looks like this:
config chip.h
object socket_PGA370.o
dir /cpu/intel/model_6xx
You should add another line there:
dir
As long as all of the code that gets enabled/disabled is only print
statements, that's probably true. I was worried that some of these
boards
may depend on the correct setting of those debug flags to be functional.
Which boards are that?
There are lots of boards affected by this patch,
Myles Watson wrote:
How should we really fix it? In v3 didn't we just scrap type 2
accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes absolutely no sense.
I sent a patch for this some days ago, but I think Carl-Daniel didn't
have
It froze again. Here is some of the output:
SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0010 kB
Lower RAM end at 0x0010 kB
Ram2.01
Myles Watson wrote:
How should we really fix it? In v3 didn't we just scrap type 2
accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes absolutely no sense.
I sent a patch for this some days ago, but I think Carl-Daniel didn't
have
Myles Watson wrote:
The attached patch fixes booting for arima/hdama.
How should we really fix it? In v3 didn't we just scrap type 2
accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes absolutely no sense.
The auto detection code is the
On Thu, Oct 22, 2009 at 09:16:14AM -0600, Myles Watson wrote:
RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3
Before starting clocks: Before memreset: cpu is pre_c0
after first udelay
OK. So the timer worked for the first udelay...
Does it only freeze when you have
I did a fresh svn co the other day and tried building and
running a Tyan S2912_fam10 system. With older sources
(rev 4729) everything worked just fine, with the newest checkout
the booting process stops at setting MTRR registers or a little
later (depending on the compiler used: 3.4.6 builds
On Thu, Oct 22, 2009 at 9:36 AM, Stefan Reinauer ste...@coresystems.dewrote:
Myles Watson wrote:
I thought enable was run at the very beginning, before scan, while init
was
run at the end.
Yes.
That seems like a hard conversion to make.
Why?
I thought that some of the PCI
dir /cpu/via/model_c3
Since this worked for him, is there a reason not to commit the change?
This will enable CPU support code for all model 6xx intel CPUs as well
as VIA C3 CPUs
As a side discussion to all developers: We could move the sockets from
intel/ and amd/ to src/cpu/sockets or
On 22.10.2009 09:57, Stefan Reinauer wrote:
Myles Watson wrote:
The attached patch fixes booting for arima/hdama.
How should we really fix it? In v3 didn't we just scrap type 2
accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes
On Thu, Oct 22, 2009 at 9:45 AM, Carl-Daniel Hailfinger
c-d.hailfinger.devel.2...@gmx.net wrote:
On 22.10.2009 09:57, Stefan Reinauer wrote:
Myles Watson wrote:
The attached patch fixes booting for arima/hdama.
How should we really fix it? In v3 didn't we just scrap type 2
accesses
Myles Watson wrote:
dir /cpu/via/model_c3
Since this worked for him, is there a reason not to commit the change?
No.
As a side discussion to all developers: We could move the sockets from
intel/ and amd/ to src/cpu/sockets or some such for those few CPUs
that
have a
SMM support hasn't been added yet. Should we disable SMI for Kontron, or
does someone who understands it want to add the code to the Makefiles?
It doesn't look that bad, but it will be a lot easier for someone who is
already familiar with it.
Thanks,
Myles
--
coreboot mailing list:
Author: stepan
Date: 2009-10-22 18:59:33 +0200 (Thu, 22 Oct 2009)
New Revision: 4823
Modified:
trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c
Log:
trivial: add note that VSA blob belongs into CBFS.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer
Author: stepan
Date: 2009-10-22 19:02:44 +0200 (Thu, 22 Oct 2009)
New Revision: 4824
Modified:
trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c
Log:
minimal whitespace fix (trivial)
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
On Thu, Oct 22, 2009 at 07:29:14AM +0200, Peter Stuge wrote:
Mick Reed wrote:
Procedure 2:
check out coreboot-v2 source
cd into coreboot-v2 directory
make menuconfig
make
Note that this is still in alpha stage for most if not all listed
boards.
Yep.
Where is kconfig looking for
Hello,
I am working on booting up VIA VX800 board with coreboot.
I have coreboot (r4824) stuck on POST code 0x80 (sequence was 00 - 10 -
80) with this board.
Could somebody please let me know where (in which source file in coreboot) this
code is outputted in port 0x80?
Thank you,
Konstantin
On Thu, Oct 22, 2009 at 6:29 PM, Konstantin Lazarev
klaza...@sbcglobal.netwrote:
Hello,
I am working on booting up VIA VX800 board with coreboot.
I have coreboot (r4824) stuck on POST code 0x80 (sequence was 00 - 10
- 80) with this board.
Could somebody please let me know where (in which
PCI: 00:02.0 init
Starting Graphics Initialization
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
CBFS: follow chain: fff0 + 38 + 8073 + align - fff080c0
Check
CBFS: follow chain: fff080c0 + 28 + e7ef8 + align -
CBFS: Could
Have you added the vga rom into image by running
./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom optionrom
: vendor id
: device id
And Please provide the output of
sh cbfstool coreboot.rom print
Zheng
Date: Thu, 22 Oct 2009 23:42:19 -0400
From:
Konstantin Lazarev wrote:
I am working on booting up VIA VX800 board with coreboot.
Which board are you using?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 10/23/2009 12:07 AM, Zheng Bao wrote:
Have you added the vga rom into image by running
./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom
optionrom
: vendor id
: device id
And Please provide the output of
sh cbfstool coreboot.rom
Joseph Smith wrote:
On 10/23/2009 12:07 AM, Zheng Bao wrote:
Have you added the vga rom into image by running
./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom
optionrom
: vendor id
: device id
And Please provide the output of
On 10/23/2009 12:33 AM, Peter Stuge wrote:
Joseph Smith wrote:
On 10/23/2009 12:07 AM, Zheng Bao wrote:
Have you added the vga rom into image by running
./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom
optionrom
: vendor id
: device id
Joseph Smith wrote:
Look under VGA BIOS in the top level menu.
from my config.h
#define CONFIG_VGA_BIOS 1
#define CONFIG_FALLBACK_VGA_BIOS_ID 8086,3577
#define CONFIG_FALLBACK_VGA_BIOS_FILE pci8086,3577.rom
Still no go...
_BIOS_FILE should be the name of the VGA BIOS as it exists in the
On 10/23/2009 12:45 AM, Peter Stuge wrote:
Joseph Smith wrote:
Look under VGA BIOS in the top level menu.
from my config.h
#define CONFIG_VGA_BIOS 1
#define CONFIG_FALLBACK_VGA_BIOS_ID 8086,3577
#define CONFIG_FALLBACK_VGA_BIOS_FILE pci8086,3577.rom
Still no go...
_BIOS_FILE should be the
35 matches
Mail list logo
