Hi,
On Wed, Jun 25, 2008 at 02:53:03PM +0800, Zhang Rui wrote:
- What is the address of post() in LegacyBIOS?
The address of post() is dynamic.
and then how can we call the post() function?
Well, that will require some work. :-) Take a look at how the build exports the assembler stub "post32" (in post.c) - which calls _start() (also in post.c).
[...]
How can I call post outside LegacyBIOS but just use the bios.bin file(copied to 0xf0000)? Can this function have a fixed address? or is there another approach?
The post() function should not be put at a fixed address. You should export any addresses you need during the build and then teach coreboot to import those addresses.
- How to modify the post() method in LegacyBIOS?
post() will auto boot the system at the end. But we want it return to coreboot. So what is the boot code at the end of the function? Is this?
init_boot_vectors(); dprintf(1, "Scan for option roms\n"); rom_scan(0xc8000, 0xe0000);
The post() function itself doesn't attempt to boot the system. It's the last few parts of the _start() function that does this. In particular the call to 'int 0x19' starts the boot phase.
May be we could write another funcion post_noboot() without the boot code and have a fixed address?
Yes, you probably want to introduce a "post32_noboot" in addition to the existing "post32" asm code. You should not introduce any additional fixed addresses.
- How to get the address of idt of LegacyBIOS?
The idt is internal to LegacyBIOS. Coreboot should not know about it. I recommend you have your "post32_noboot" set the idt on entry and restore it on exit.
There are bigger issues hiding here. In order to call out to LegacyBIOS and return from it, you'll need to ensure that LegacyBIOS does not overwrite coreboot's idt, gdt, stack, or any important memory areas. Further, later on coreboot will need to call back into 16 bit mode to actually make use of the SCSI option rom. In the time between returning to coreboot and coreboot calling back into 16bit mode, you must ensure coreboot does not overwrite any of the memory areas LegacyBIOS has initialized.
Making sure the two programs do not conflict with each other could be difficult. As such, I am not convinced that returning to coreboot is a good idea.
I noticed that OFFSET_pmode_IDT_info is defined in rom16.offset.auto.h. But this header file is generated in building process and I do not find the rule for it in the Makefile. So I want to know how can I get the value of OFFSET_pmode_IDT_info? So do OFFSET_rombios32_gdt_48 and BUILD_STACK_ADDR.
BUILD_STACK_ADDR is defined in config.h.
The rom16.offset.auto.h is generated by this rule in the Makefile:
$(OUT)%.offset.auto.h: $(OUT)%.o @echo " Generating symbol offset header $@" $(Q)nm $< | ./tools/defsyms.py $@
-Kevin