OSDev.org

You can't use GRUB's code to set up the APs. If you want the APs to switch to protected mode, you need to write that code yourself.

NeonLightions wrote:As I found on documents, the APs will start on Real mode and begin excuting at given address. Like you said, it still excuting even there's nothing at [0100:0000].

This is correct.

I'm expecting that the APs will excuting GRUB's code (which I don't know how to do it) and enter the Protected mode.

Only the boot processor goes through the boot process, and Grub may not even be around anymore once it's booted your kernel the first time. You need to supply real mode code at the appropriate physical address for the APs to run. You'll need to get the APs into protected mode yourself.

klange wrote:

NeonLightions wrote:As I found on documents, the APs will start on Real mode and begin excuting at given address. Like you said, it still excuting even there's nothing at [0100:0000].

This is correct.

I'm expecting that the APs will excuting GRUB's code (which I don't know how to do it) and enter the Protected mode.

Only the boot processor goes through the boot process, and Grub may not even be around anymore once it's booted your kernel the first time. You need to supply real mode code at the appropriate physical address for the APs to run. You'll need to get the APs into protected mode yourself.

How to send the code address (0xDEADBEEF, for example) to other APs to excute the code?

NeonLightions wrote:How to send the code address (0xDEADBEEF, for example) to other APs to excute the code?

You don't get that sort of granularity from the SIPI interface, and real mode code can not run at an address like that anyway.

The 1 in this value is what is setting the address the AP will start at: https://github.com/NeonLightions/Amore- ... /smp.c#L27

As you already saw, that will start executing at 0100:0000 which is equivalent to a linear address of 0x1000. Remember that this is a physical address - if you enabled the MMU previously that will only apply to the boot processor, and you'll need to "bootstrap" the AP into the same environment.

As i saw in the document, do i have to do a warm-reset? And what to put in warm reset vector [40:67]? And in MultiProcessor spec, Appendix B, section 4, why we need to send double Startup IPI?

NeonLightions wrote:As i saw in the document, do i have to do a warm-reset? And what to put in warm reset vector [40:67]?

You don't need it. The warm reset stuff only applies to the 82489DX (in 486 or socket 4 Pentium systems) because it doesn't support SIPI. All modern systems use SIPI to control where APs begin executing.

NeonLightions wrote:And in MultiProcessor spec, Appendix B, section 4, why we need to send double Startup IPI?

I've heard it's because some very old CPUs ignore the first SIPI. It doesn't seem to be necessary on any modern CPUs, but you should still do it just in case.