unreal mode tutorial protected mode parts (in SMP)

[Geri]

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. 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 same goes with interrupts, those can end up on any cores, creating a large mess.

so you basically cant even control these. thats why a new interrupt system is introduced for SMP systems, becouse the standard will not work on them. 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.

[Brendan]

Hi,

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.

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.

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

[Geri]

well the 0th cpu is in unreal mode for sure, thats setuped by the smallerc runtime and the os itself operates its 512 mbyte sized payload properly.

(i guess this is an another meh situation, since it works on both emulator and both on real hardware. from this point i put this into my pocket of x86 misterys caused by the 2 billion transistors of obfuscated imperialism)

[alexfru]

Don't forget two things. APs execute some BIOS code and it may leave 4G segment limits. Also, the emulator may not honor segment limits in real mode as usually it doesn't cause any problems.

[Geri]

alexfru: maybe (but i will test first around) i should add some code on the cores to check if i can actually write some memory around 12 mbyte. and if not, then i try to call for the unreal mode. if unreal mode still not appears working, i halt the cores and continue as unicore.

[Icee]

How about uploading the binary image somewhere? I'm ready to spend a few minutes to find out what's actually going on.

[Geri]

icee: thankyou for the offer. depending on how my schedule goes, i will send you a link in private message with the disk image file

[Geri]

i did investigations. qemu comes up the ap cores in unreal mode. intel atom comes up the aps in unreal mode. amd athlon2 x4 comes up them in real mode, and needs to be switched.