Hi,
Geri wrote:
i executed the code on real hardware. also works (the write happens).
i am suspecting what is going on.
its in the name: AP. which means application processors. the cpu0 just *probably* clones all of the settings into then if you bring them up.
No, it doesn't "clone" anything from other CPUs.
Geri wrote:
i am not sure you even can tell to the keyboard controller to make babbies with the a20 gate, since it would be difficult to investigate which core was giving down the signal.
The A20 gate is a global thing, and is (logically) part of the chipset and not part of any CPU, and has nothing to do with real mode or unreal mode.
Geri wrote:
so this probably means the AP-s will not even able to come up in the so called real mode, becouse its not possible to support it properly. they probably always coming up in 32 bit modes.
No, the AP CPUs are in real mode, and the "register dump" you posted proves that the segment limits are all "64 KiB".
It's extremely likely that the problem is that you do get a general protection fault (which is "interrupt 0x0D"); but (for historical reasons) the BIOS uses "interrupt 0x0D" for "IRQ 0x05" so the BIOS does nothing useful (and it doesn't crash) and returns to the instruction that caused the general protection fault (which causes another general protection fault, leading to a "continually causing general protection faults" situation). This is why real OSs reprogram the PIC chips (so the same interrupt isn't used for both IRQs and exceptions) and why real OSs have exception handlers.
Cheers,
Brendan