On Jan 29, 2008 12:00 AM, ron minnich [EMAIL PROTECTED] wrote:
And this is bad too.
in setup_realmode_idt -- both v2 and v3 ...
/* debug handler - useful to set a programmable delay between
instructions if the
TF bit is set upon call to real mode */
idts[1].cs =
boy, do I feel dumb!
OK, where do I want to put this page. I am thinking leave it where it
is and move coreboot text up to, e.g., 16K so we have room for this
type of thing in future?
thanks!
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ron minnich wrote:
The worst part is, I looked at that code about 50 times, and each
time, I thought oh yeah, i start that at idt at zero.
Sheesh!
ron
It didn't dawn on me right away either.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
ron minnich wrote:
On Jan 29, 2008 12:00 AM, ron minnich [EMAIL PROTECTED] wrote:
And this is bad too.
in setup_realmode_idt -- both v2 and v3 ...
/* debug handler - useful to set a programmable delay between
instructions if the
TF bit is set upon call to real mode */
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
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
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 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
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.
On 27/01/08 23:23 -0500, Tom Sylla wrote:
ron minnich wrote:
If I move the stage2 text address from 0x1000 to 0x2000 (see
arch/x86/Makefile: -T 0x1000), I get past the problem. It's dying
later but I think I know what that is.
But what piece of code is trashing memory at 0x1000? Could it be
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 Sat, Jan 26, 2008 at 09:07:23PM -0800, ron minnich wrote:
OK, VSA is running fine. BUT, after VSA runs, memory at 0x1000 is
ZERO'd. This is Bad, as this is where stage2 lives!
Can you confirm it is not zero before calling do_vsmbios() and zero
immediately after returning? That would indicate
20 matches
Mail list logo
