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
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
Hi,
I read the paper below some years ago, but it is still valid and being
aware of the contents can help avoid some totally non-obvious mistakes.
http://www.fefe.de/intof.html
Especially for former ROMCC code which uses unsigned types heavily this
is a must read.
Please keep in mind that
if (a -
Hi,
I have try to build rom file but I have incountered several difficulties.
There insn't a simple howto step by step?
I follow the AMD_Geode_Porting_Guide but after download the buildrom
and coreboot.. for example where I must do the command make menuconfig
and make?
I would want put into the
Hi,
I have try to build rom file but I have incountered several difficulties.
There insn't a simple howto step by step?
I follow the AMD_Geode_Porting_Guide but after download the buildrom
and coreboot.. for example where I must do the command make menuconfig
and make?
from
On Wed, Oct 15, 2008 at 6:06 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 15.10.2008 08:36, Corey Osgood wrote:
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
Author: cozzie
Date: 2008-10-15 17:06:18 +0200 (Wed, 15 Oct 2008)
New Revision: 930
Added:
coreboot-v3/northbridge/via/
coreboot-v3/northbridge/via/cn700/
coreboot-v3/northbridge/via/cn700/Makefile
coreboot-v3/northbridge/via/cn700/cn700.h
On Wed, Oct 15, 2008 at 4:46 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 14.10.2008 21:15, Peter Stuge 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
On Wed, Oct 15, 2008 at 8:34 AM, ron minnich [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2008 at 3:09 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; +
On Wed, Oct 15, 2008 at 3:09 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
Actually, that was intentional. You see, we haven't
ron minnich wrote:
[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
On Wed, Oct 15, 2008 at 8:58 AM, Marc Jones [EMAIL PROTECTED] wrote:
This is with my patch?
yes
Please send lspci.
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00: 02 10 8d 43 0f 00 20 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
not quite right? CONFIG_RAM_STACK_LOCATION; + CONFIG_RAM_STACK_SIZE -4?
Actually, that was intentional. You see, we haven't decided on the
meaning of the RAM_STACK_LOCATION constant/variable yet. We could
ron minnich wrote:
On Wed, Oct 15, 2008 at 8:58 AM, Marc Jones [EMAIL PROTECTED] wrote:
This is with my patch?
yes
Please send lspci.
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00: 02 10 8d 43 0f 00 20 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00
Change statictree emit function to emit path correctly for cpus.
Signed-off-by: Myles Watson [EMAIL PROTECTED]
Thanks,
Myles
Index: util/dtc/flattree.c
===
--- util/dtc/flattree.c (revision 929)
+++ util/dtc/flattree.c (working
On Tue, Oct 14, 2008 at 03:27:04PM -0500, Alex Mauer wrote:
Index: src/mainboard/bcom/winnetp680/Config.lb
===
--- src/mainboard/bcom/winnetp680/Config.lb (revision 3654)
+++ src/mainboard/bcom/winnetp680/Config.lb (working
On 14.10.2008 21:15, Peter Stuge 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 afraid I don't like that.
On 15.10.2008 17:34, ron minnich wrote:
On Wed, Oct 15, 2008 at 8:34 AM, ron minnich [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2008 at 3:09 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 15.10.2008 04:54, ron minnich wrote:
return (void *) CONFIG_RAM_STACK_LOCATION;
On Wed, Oct 15, 2008 at 10:02 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
While I do agree, it may be confusing for some people to have
RAM_STACK_BASE denote the upper (as in memory location) end of the stack
and CARBASE denote the lower end of the stack.
Suggested fix: Introduce the
On 15.10.2008 17:31, ron minnich wrote:
On Wed, Oct 15, 2008 at 4:46 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 14.10.2008 21:15, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
I believe the stage0_main name is misleading. After all, stage0
is pure asm and
On Wed, Oct 15, 2008 at 10:04 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
I'll be back in ~3 hours. If you have acked this in the meanwhile, I
will commit, otherwise I'll rework.
let's get a complete patch set, then I will test on geode and simnow
tonight. This all looks fine, but it
On Wed, Oct 15, 2008 at 9:14 AM, Myles Watson [EMAIL PROTECTED] wrote:
Here's the latest log. It hangs in the emulator. I've tried both
emulators, but to no avail.
Stick with the non emulator. This is incredible progress!
can you stop it and get us a register dump and tell us where eip is.
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
On Wed, Oct 15, 2008 at 9:12 AM, Myles Watson [EMAIL PROTECTED] wrote:
Change statictree emit function to emit path correctly for cpus.
Signed-off-by: Myles Watson [EMAIL PROTECTED]
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
-Original Message-
From: ron minnich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 11:05 AM
To: Myles Watson
Cc: Coreboot
Subject: Re: Serengeti vga hang
On Wed, Oct 15, 2008 at 9:14 AM, Myles Watson [EMAIL PROTECTED] wrote:
Here's the latest log. It hangs in
On Wed, Oct 15, 2008 at 10:22 AM, Myles Watson [EMAIL PROTECTED] wrote:
Stick with the non emulator.
I'm sorry I didn't get what you meant here. vm86 and x86emu are the two
choices to run the ROM and I'm using x86emu.
stick with vm86
can you stop it and get us a register dump and tell
Myles Watson wrote:
Here's the latest log. It hangs in the emulator. I've tried both
emulators, but to no avail.
Nothing jumped out at me why you might be having a problem with VGA.
These are some general v3 comments. I have a good feel for the new
dts/device scanning so some questions may
Author: myles
Date: 2008-10-15 19:46:52 +0200 (Wed, 15 Oct 2008)
New Revision: 931
Modified:
coreboot-v3/util/dtc/flattree.c
Log:
Change statictree emit function to emit path correctly for cpus.
Signed-off-by: Myles Watson [EMAIL PROTECTED]
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
Rev 931.
Thanks,
Myles
On Wed, Oct 15, 2008 at 9:12 AM, Myles Watson [EMAIL PROTECTED] wrote:
Change statictree emit function to emit path correctly for cpus.
Signed-off-by: Myles Watson [EMAIL PROTECTED]
Thanks,
Myles
--
coreboot
Author: mjones
Date: 2008-10-15 19:50:29 +0200 (Wed, 15 Oct 2008)
New Revision: 3659
Modified:
trunk/util/flashrom/chipset_enable.c
Log:
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:
Peter Stuge wrote:
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.
done
Acked-by:
On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones [EMAIL PROTECTED] wrote:
setting up resource map ex offset
(0+0,18+0,1+0,44) f8f8 | +
(0+0,18+0,1+0,4c) f8f8 | 0001+
...
done.
I don't think that resource setup needs to be done this early. There are
There is some 8111/8132 setup that might be causing the VGA issue?
Most of your questions I don't have answers for, but right now I'm trying to
figure out why the VGA_ENABLE bit in the 8111 gets cleared after it's set.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
ron minnich wrote:
On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones [EMAIL PROTECTED] wrote:
...
Where is phase4_enable_disable? Shouldn't it happen before Phase 4: Reading
resources ?
It does, for each device, if it is set up for that device.
phase4_enable_disable was in v2 in a different
Uwe Hermann wrote:
At least the Super I/O parts are incorrect for the w83697hf, I talked
with Alex on IRC about this, he'll post an updated patch today.
The logical devices which are present are actually correct, but there
are some missing.
Attached is the updated patch. In addition to the
On Wed, Oct 15, 2008 at 11:02 AM, Marc Jones [EMAIL PROTECTED] wrote:
ron minnich wrote:
Sorry but I don't see any phase4_enable_disable in the output. It is not
being called in device.c dev_phase4(). I think that is a problem.
see pci_probe_dev.
And, hey, if I could get you all to use
On Mon, Oct 13, 2008 at 09:14:14PM -0700, ron minnich wrote:
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
r926.
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:
That's right Ron, it would be a lot appreciated.
A simple howto that show step by step the operations for compile from
svn and ...etc
I think that would be a beautiful idea.
Thanks however for the help that I have received.
ron minnich ha scritto:
we have people on this list who don't
I was wrong about the bridge bit. Here's the output from the SimNOW windows
when it dies:
EAX=B102 EBX=002E ECX=000C2067 EDX=000C1022
ESI=0001 EDI=000D ESP=63D0 EBP=000CF11C
CS= DS=C000 ES= FS= GS= SS= EFLAGS=oditsZaPc
GIF=1 ASID=
On Wed, Oct 15, 2008 at 1:03 PM, Myles Watson [EMAIL PROTECTED] wrote:
I was wrong about the bridge bit. Here's the output from the SimNOW
windows when it dies:
EAX=B102 EBX=002E ECX=000C2067 EDX=000C1022
ESI=0001 EDI=000D ESP=63D0 EBP=000CF11C
CS= DS=C000 ES=
ron minnich wrote:
On Wed, Oct 15, 2008 at 11:02 AM, Marc Jones [EMAIL PROTECTED] wrote:
ron minnich wrote:
Sorry but I don't see any phase4_enable_disable in the output. It is not
being called in device.c dev_phase4(). I think that is a problem.
see pci_probe_dev.
And, hey, if I could
SimNOW goes off into the weeds when int 1a is called. Here's the trace of
execution:
C000:0003 E9E200 jmp loc_00e8
C000:00E8 60 pusha
C000:00E9 E84331 call loc_322f
C000:322F B800C0 mov ax,c000
C000:3232 8ED8 mov ds,ax
C000:3234 BE
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson [EMAIL PROTECTED] wrote:
C000:3241 B802B1 mov ax,b102
C000:3244 CD1A int 1a
: FF
Yep, b102 is not a common signature.
I'm looking for the place where the interrupt vector was supposed to have
been set.
I am
-Original Message-
From: Tom Sylla [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 2:04 PM
To: Myles Watson
Cc: Coreboot; ron minnich
Subject: Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson [EMAIL PROTECTED] wrote:
C000:3241 B802B1
Myles Watson wrote:
-Original Message-
From: Tom Sylla [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 2:04 PM
To: Myles Watson
Cc: Coreboot; ron minnich
Subject: Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson [EMAIL PROTECTED] wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt
(I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes
BREAK HERE run_bios = 0x944a
biosint: INT# 0x18
biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c
Is int1a pci bios calls supported in the emulators?
It seems to work in v2. I've never looked at them before today.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Myles Watson wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt
(I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes
BREAK HERE run_bios = 0x944a
biosint: INT# 0x18
biosint: eax 0x2e ebx 0x1
-Original Message-
From: Marc Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 2:45 PM
To: Myles Watson
Cc: Tom Sylla; ron minnich; Coreboot
Subject: Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote:
Here's the next part of the log now that I've enabled
Myles Watson wrote:
-Original Message-
From: Marc Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 2:45 PM
To: Myles Watson
Cc: Tom Sylla; ron minnich; Coreboot
Subject: Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote:
Here's the next part of the log now that
On Mon, Oct 13, 2008 at 11:27 AM, Roman Yeryomin [EMAIL PROTECTED] wrote:
on system with native bios (tinybios):
cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:03F8 irq:4 tx:945 rx:15 RTS|CTS|DTR|DSR|CD
1: uart:16550A port:02F8 irq:3 tx:0 rx:0
On Wed, Oct 15, 2008 at 1:26 PM, Marc Jones [EMAIL PROTECTED] wrote:
Is int1a pci bios calls supported in the emulators?
yes they are.
I'm not sure what is going wrong here.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Oct 15, 2008 at 1:27 PM, Myles Watson [EMAIL PROTECTED] wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt
(I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes
BREAK HERE run_bios =
there is a phase 3 enable that enables a device (if needed) to appear
or disappear in config space. There is a phase 4 enable disable to
enable a device's resources to be read. Both of these usages appeared
in v2.
Sorry, I'm worn out (long day) if this makes no sense let me know.
ron
--
ron minnich wrote:
there is a phase 3 enable that enables a device (if needed) to appear
or disappear in config space. There is a phase 4 enable disable to
enable a device's resources to be read. Both of these usages appeared
in v2.
Sorry, I'm worn out (long day) if this makes no sense let me
ron minnich wrote:
Myles, try setting -mregparm=0 and see if life is better.
Good find.
I vote we get rid of this type of Cleverness. It's just not
performance critical in a bios. We're not an OS and we should keep
it simple. I don't think we'll live or die on 3 on-stack variables.
If it
let's look around:
gdb build/util/x86emu/vm86.o
Dump of assembler code for function biosint:
0x04f3 biosint+0: push %esi
0x04f4 biosint+1: mov%eax,%esi
0x04f6 biosint+3: push %ebx
0x04f7 biosint+4: sub$0x4,%esp
0x04fa biosint+7:
On Wed, Oct 15, 2008 at 4:27 PM, Myles Watson [EMAIL PROTECTED] wrote:
I'll be interested to see how much faster v3 is when it's not set to SPEW.
Right now it seems a lot slower than v2dsr on SimNOW.
v3 is far faster than romcc v2 of course. Is it faster than CAR v2?
that's not clear yet. My
On Wed, Oct 15, 2008 at 4:10 PM, Marc Jones [EMAIL PROTECTED] wrote:
Your explanation of what it is makes sense. What doesn't make sense is that
it is never called during phase4. It is no better than v2 if name doesn't
tell you when it is used. The only time it is used is in pci device scan
Myles Watson wrote:
I'll be interested to see how much faster v3 is when it's not set
to SPEW.
Quite a lot on geodelx.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 15.10.2008 17:04, Corey Osgood wrote:
On Wed, Oct 15, 2008 at 6:06 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
+ {
+ reg8 = 0x0f;
+ reg8 |= ((spd_data -10) 4);
+ }
+
+ /* CAS Latency */
+ spd_data =
Author: hailfinger
Date: 2008-10-16 05:00:28 +0200 (Thu, 16 Oct 2008)
New Revision: 932
Added:
coreboot-v3/include/arch/x86/stage1.h
Modified:
coreboot-v3/arch/x86/amd/k8/stage1.c
coreboot-v3/arch/x86/amd/stage0.S
coreboot-v3/arch/x86/geodelx/stage0.S
Hi, list
I have a HP Pavilion dv1000 laptop with Debian sid installed,
and I'd like to try coreboot. Is it supported? Thanks!
The detailed HW spec I know is from lspci and /proc/cpuinfo.
lspci output:
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express
62 matches
Mail list logo
