Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 28.01.2008 04:14, Corey Osgood wrote:
Corey Osgood wrote:
Carl-Daniel Hailfinger wrote:
On 27.01.2008 01:53, Stefan Reinauer wrote:
* Carl-Daniel Hailfinger [EMAIL PROTECTED]
[080126 01:50]:
- causes lots of breakage when you try to go back to versions
before the
rename (try it
* Marc Jones [EMAIL PROTECTED] [080121 22:14]:
Signed-off-by: Marc Jones [EMAIL PROTECTED]
Acked-by: Stefan Reinauer [EMAIL PROTECTED]
Index: LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
===
---
Urbez Santana Roma wrote:
El lun, 28-01-2008 a las 10:41 +0100, Rudolf Marek escribió:
Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
Yes, i can try, but i have a ugly 'English', :
Must i complete the generated
El lun, 28-01-2008 a las 10:41 +0100, Rudolf Marek escribió:
Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
Yes, i can try, but i have a ugly 'English', :
Must i complete the generated *.c files with a line of the
-Original Message-
From: ron minnich [mailto:[EMAIL PROTECTED]
On Jan 22, 2008 10:20 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
I'd say we refuse to execute the ROM in v3. If the ROM is broken, we
have no way to determine how broken it is. Unconditional execution may
ron minnich wrote:
coreboot seems to by dying in VSM on some config access as well.
Carl-Daniel pointed out to me:
IIRC there is also a VSM stack which is located in a place differing
from the one clobbered between 0x1000 and 0x2000.
Notice how it blows up exactly at the time where the
Carl-Daniel Hailfinger wrote:
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse [EMAIL PROTECTED] wrote:
Hmm - probably the right move, but the changes in buildrom are not
trivial for v2. We would need to figure out what the ROM size is (by
greping
I said that SC-fam10 was the only failing platform, but I lied. Looks
like plain ol serengeti-cheetah had a flag problem too.Patch attached.
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
v2: Fix Serengeti-Cheetah flags too
Signed-off-by:
On 28/01/08 14:12 -0700, Jordan Crouse wrote:
Something is amiss here, and I need to put my head down with Stefan and
figure it out. But in the meantime, hiding the problem isn't going to help
anybody.
In that spirit, here are the sizes of the object files in my build for
comparision.
All,
I do not know if this is the same problem I faced with the .id
section. But it looks really familiar.
I had tracked this down to a bug in binutils that was already reported
and fixed in the cvs. Someone one the list haad found a newer binutils
(2.18) and had installed the rpm from it.
Carl-Daniel Hailfinger wrote:
On 28.01.2008 21:55, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse [EMAIL PROTECTED] wrote:
Hmm - probably the right move, but the changes in buildrom are not
trivial for
On 28.01.2008 21:55, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
On 25.01.2008 19:17, ron minnich wrote:
On Jan 25, 2008 10:15 AM, Jordan Crouse [EMAIL PROTECTED] wrote:
Hmm - probably the right move, but the changes in buildrom are not
trivial for v2. We would need to figure out
Here is my message about the .id bug in binutils
/***
After some more investigating I think I have found the core problem
with the id.lds file.
I think this is a bug in binutils. if you look at the link below you
will see an explanation. I
Hi,
On 28.01.2008 21:04, Brendan Trotter wrote:
On 1/27/08, Peter Stuge [EMAIL PROTECTED] wrote:
What, specifically, do you need?
For long-term viability, I need something (e.g. a formal
specification) that gives guarantees on the (past, present and future)
behaviour that a
Author: stepan
Date: 2008-01-28 18:50:56 +0100 (Mon, 28 Jan 2008)
New Revision: 565
Added:
coreboot-v3/arch/x86/coreboot_table.c
Removed:
coreboot-v3/arch/x86/linuxbios_table.c
Log:
rename linuxbios_table.c
Signed-off-by: Stefan Reinauer [EMAIL PROTECTED]
Acked-by: Stefan Reinauer [EMAIL
Hi,
On 1/27/08, Peter Stuge [EMAIL PROTECTED] wrote:
What, specifically, do you need?
For long-term viability, I need something (e.g. a formal
specification) that gives guarantees on the (past, present and future)
behaviour that a payload can expect from Coreboot, which includes
considerations
On 28.01.2008 20:38, ron minnich wrote:
coreboot seems to by dying in VSM on some config access as well.
Carl-Daniel pointed out to me:
IIRC there is also a VSM stack which is located in a place differing
from the one clobbered between 0x1000 and 0x2000.
Notice how it blows up exactly at
coreboot seems to by dying in VSM on some config access as well.
Carl-Daniel pointed out to me:
IIRC there is also a VSM stack which is located in a place differing
from the one clobbered between 0x1000 and 0x2000.
Notice how it blows up exactly at the time where the first virtual PCI
access
This patch needed because some chips (mostly north) can have more than
one function.
patch attached.
ron
In the current version of dtc, if one has the line:
/config/ = northbridge/amd/geodelx;
Then the file northbridge/amd/geodelx/dts is read in and processed.
Magic(TM) appends the name /dts
ron minnich wrote:
On Jan 27, 2008 8:23 PM, Tom Sylla [EMAIL PROTECTED] wrote:
Well, you might want to take a look at real_mode_switch_call_vsm. I see
the code telling it to use real mode address 0:0x1000 as the location
for the stack.
On Jan 28, 2008 11:18 AM, Jordan Crouse [EMAIL PROTECTED] wrote:
On 28/01/08 11:14 -0800, ron minnich wrote:
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
I don't know buildrom, but you did not need the DISTRO_CFLAGS?
Gah! That will teach me to read the other patches. Did we move to
On 28/01/08 11:14 -0800, ron minnich wrote:
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
I don't know buildrom, but you did not need the DISTRO_CFLAGS?
Gah! That will teach me to read the other patches. Did we move to
DISTRO_CFLAGS instead of CFLAGS?
Jordan
--
Jordan Crouse
Systems
On 28/01/08 19:56 +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 14:28, Stefan Reinauer wrote:
* Marc Jones [EMAIL PROTECTED] [080122 00:01]:
-/* smbus functions */
-int smbus_read_byte(unsigned device, unsigned address);
hmm. So where does the prototype live then?
I have write a new release of a tool that i named RemoteBIOS. This tool,
can help us, to test your Coreboot development for new mainboards. If
one is interesting on this tool, can download it in Sourceforge.
Is only in the first stage of a more complex project. I use for my
mainboards, and help me
On Mon, Jan 28, 2008 at 11:16:01AM +0100, Torsten Duwe wrote:
Without knowing exactly what you are trying to protect against ( I
know -- the user ) we cannot tell.
What I think Torsten is getting at is that it would be beneficial to
think about what user actions you want the system to be able
Author: jcrouse
Date: 2008-01-28 20:22:29 +0100 (Mon, 28 Jan 2008)
New Revision: 3085
Modified:
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/Config.lb
Log:
[V2]: Add CFLAGS to targets to suck in any passed in flags
Signed-off-by: Jordan Crouse [EMAIL PROTECTED]
Acked-by:
On 28.01.2008 22:32, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 28.01.2008 22:12, Jordan Crouse wrote:
On 28/01/08 21:38 +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 21:12, coreboot information wrote:
revision 3085
Build Log:
Compilation of
Author: jcrouse
Date: 2008-01-28 23:55:47 +0100 (Mon, 28 Jan 2008)
New Revision: 3086
Modified:
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Config.lb
Log:
v2: Fix Serengeti-Cheetah flags too
Signed-off-by: Jordan Crouse [EMAIL PROTECTED]
Acked-by: Ward Vandewege [EMAIL PROTECTED]
Hi again Brendan,
On Mon, Jan 28, 2008 at 08:04:28PM +, Brendan Trotter wrote:
On 1/27/08, Peter Stuge [EMAIL PROTECTED] wrote:
What, specifically, do you need?
For long-term viability, I need something (e.g. a formal
specification) that gives guarantees on the (past, present and
On 28/01/08 23:33 +0100, Carl-Daniel Hailfinger wrote:
Testing with other gcc versions and creating a size table like the one
at http://coreboot.org/~jcrouse/ubuntu_4_1_fam10_sizes would certainly
help us see where the whole size problem is most apparent.
Attached is the comparison of the
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer jcrouse checked in revision 3086 to
the coreboot source repository and caused the following
changes:
Change Log:
v2: Fix Serengeti-Cheetah flags too
Signed-off-by: Jordan Crouse [EMAIL PROTECTED]
On Jan 28, 2008 3:58 PM, Marc Jones [EMAIL PROTECTED] wrote:
I don't think so. It is coreboot that sets the stack for VSA
initialization. The more I think about it, the stack shouldn't be moved.
Just switch to real mode and VSA can use the same stack as LinuxBIOS
(maybe pad it a little if you
On 29.01.2008 00:53, ron minnich wrote:
On Jan 28, 2008 3:48 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Ron, can you provide us with logs of the last revision before VSA
support went in and of your current local codebase? I hope to pinpoint
the location of the explosion better.
Looking at one of your old logs, it looks like the VSA init code is
*running* in the 0x1000 segment:
http://www.coreboot.org/pipermail/coreboot/2008-January/029736.html
(cs 0x1000)
That is probably smashing the region. The int18s are certainly bad,
you should just have the normal two int15s,
putting vsa in v3 is very simple.
lar -a build/bios.bin your-vsa-file:blob/vsa
That last is a tad confusing, maybe. The part before the : is the unix
pathname. The part after the : is the lar pathname.
Make sure it is blob/vsa, NOT /blob/vsa
To see if it is there,
lar -l build/bios.bin
nice work and congrats. This is neat!
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Marc Jones wrote:
Tom is right, something funny is going on here. We see the VSA
decompressed to buf 0x0006 which is a good place for VSA. Then we
don't see an error that VSA isn't found. That means that it found the
first post code as expected.
Yep, I checked with FS2, things look
ron minnich wrote:
here's an interesting bug in
/home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c
/* Dump zeros in the other segment registers */
mov %ax, %es\n
mov %ax, %fs\n
mov
here's an interesting bug in
/home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c
/* Dump zeros in the other segment registers */
mov %ax, %es\n
mov %ax, %fs\n
mov %ax, %gs\n
On Jan 28, 2008 10:15 PM, Marc Jones [EMAIL PROTECTED] wrote:
Can you try using vsmsetup.c instead of vm86.c? Something looks strange
in the reporting. ebp 0x6000. Are the variables aligned on the stack
correctly? Is this debug info correct? Are we being mislead?
This looks suspicious in
Another data point.
From my log.
biosint: INT# 0x18
biosint: eax 0x84e53 ebx 0x38 ecx 0xff0 edx 0x87ed8
biosint: ebp 0x6000 esp 0x87f60 edi 0x15 esi 0x0
biosint: ip 0x28 cs 0x1000 flags 0x26
That's just bogus as far as I can tell. Note that edi is 15, kind of looks like
the interrupt.
42 matches
Mail list logo
