Royce Mitchell III schrieb:
I was in a strange mood and decided to try to implement something Alex wanted.
I've done the leg-work on this, but need someone familiar with boot-up and particularly smp to review this patch. I do not have access to smp, and do not wish to break it.
This patch implements the /3G switch from within multiboot.S, which is necessary in order to configure the page tables correctly.
I noticed some code in _main() that was processing a 3G switch on the command-line, and I can't understand how it could possibly work because it's not readjusting the page tables, nor does it transition to the 0xC0000000 address space that I can see, so I don't think that code actually works. If it does, I'm glad to be proved wrong.
The patch I've written makes an assumption that lowmem is available when application processors execute the code. I can't seem to figure out how or where the application processor(s) actually get told to start executing, so I don't know if this assumption is true. However, if it's not true, if someone could point me to the code that inits the application processors, I can configure them to pass the needed info via %ebp or something.
Finally, I haven't actually tried booting this code. I wanted someone to review it first for obvious blunders, or to tell me, if necessary, that I've wasted my time ;) If I'm on the right track then, when I'm feeling motivated enough again, I will actually try booting it.
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hi,
I think your patch will never work. There are used some offsets which based on the '/3GB' switch and other ones are hard coded by KERNEL_BASE. IMHO, the boot code should not search for the '/3GB' option. The kernel base address must be send by freeldr. The boot code must not contain any KERNEL_BASE value. I've add your patch to my source tree. On the smp machine, ros reboots in the very early boot phase. It is before the call to _main.
- Hartmut