[coreboot] alix1c and v3

Marc Jones marc.jones at amd.com
Tue Jan 29 20:34:32 CET 2008



ron minnich wrote:
> On Jan 29, 2008 12:00 AM, ron minnich <rminnich at gmail.com> 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 = 0;
>>         idts[1].offset = 16384;
>>         memcpy((void *)16384, &debughandle, &end_debughandle - &debughandle);
>>
>>
> 

Is the debug handler even used? I don't see how it is used....

> And that certainly made things better, taking out that blind memcpy.
> 
> We're still getting the weird error on biosint but ...
> 

I think that there is a calling convention problem. Look at the code 
generated by v2 and by v3 for biosint(). callbiosint() expects biosint() 
will get the interrupt number off the stack
		// - put the INT # on the stack as a parameter
		// - provides us with a temp for the %cr0 mods.
		"	pushl	%eax	\n"

with fs2 I step into biosint and get the following (note: intel asm)
   push esi
   mov esi, eax
   push ebx
   .... then there is a bunch of stack manipulation creating local 
    variables (that I wouldn't expect).....

eax contains 0x18 from the mode change. esi is later used to report the 
int #.

We get lucky in that 0x18 doesn't have a function. If biosint() were to 
modify variables to return it would probably be catastrophic. 
Fortunately, nothing is changed and callbiosint() restores everything as 
expected and we continue on.

We don't need the int15 handling with the new VSA but this needs to be 
fixed to properly identify interrupt calls when they happen from VGA or 
other ROMs.

Another observation:
		/* Dump zeros in the other segregs */
		"	mov	%ax, %es	\n"
		"	mov	%ax, %fs	\n"
		"	mov	%ax, %gs	\n"
		"	mov	$0x40, %ax	\n"
		"	mov	%ax, %ds	\n"

Isn't needed because the registers are popped off the stack in imedeatly 
following.

		/* pop the INT # that you pushed earlier */
		"	popl	%eax		\n"
		"	pop	%gs		\n"
		"	pop	%fs		\n"
		"	pop	%es		\n"
		"	pop	%ds		\n"
		"	popal			\n"



  At this point I am convinced that VSA is setup and working and is not 
using other memory areas.

You were talking about doing a memory map. On thing to consider is that 
I think VSA/ROMs can use the same stack location as the coreboot stack 
(as long as it is below 1MB). Change the following:
	
	/* put the stack at the end of page zero.
	 * that way we can easily share it between real and protected,
	 * since the 16-bit ESP at segment 0 will work for any case. */
	/* Setup a stack */
	"	mov	$0x0, %ax	\n"
	"	mov	%ax, %ss	\n"
	"	movl	$0x1000, %eax	\n"
	"	movl	%eax, %esp	\n"

To (off the top of my head so it may need a tweak)
	/* figure the seg:offset of the coreboot stack */
	"	mov	$esp, %eax	\n"
	"	andl	$0x000F0000, %eax \n"
	"	shrl	$4, %eax	\n"
	"	movl	%ax, %ss	\n"
	"	mov	$esp, %eax	\n"
	"	andl	$0x0000FFFF, %eax \n"
	"	movl	%eax, %esp	\n"

Maybe subtract a few bytes off if you are worried about corruption.
Hmmm that does mean you need to re-figure this on the way back in 
interrupt handler.... but you save a segment. Maybe the old way is still 
better. Maybe the stack should always be at 0x1000... (and yes this gets 
into the stack moving stuff.....)

OK, enough rambling.

Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors






More information about the coreboot mailing list