Do we need to re-invent the wheel here? maybe we could leverage:
https://en.wikipedia.org/wiki/BareMetal https://github.com/ReturnInfinity/BareMetal-OS http://www.returninfinity.com/baremetal.html http://www.osnews.com/story/27566/BareMetal_OS_gets_TCP_IP On Fri, Jul 10, 2015 at 9:30 AM, Alexander Burger <[email protected]> wrote: > Hi Geo, > > thanks for the investigations! > > > I think i got some leads why some of us got stuck with "Checking long > mode" > > What i noticed is the that if i insert some message printing on most > > parts of the code between "Loading PilOS" and "Checking long mode", i > > will arrive on the real error which is "ERROR: CPU has no local APIC". > > Yes, that's interesting. So this means that message printing doesn't > work reliably? Did the messages you inserted appear? Or does it mean > that your CPU passed the tests for "Extended function available" and > "Check long mode" (Bit 29), but then finally failed in the "Check local > APIC"? > > > > I check my BIOS how to enable APIC but seems my BIOS does not have > > such option. So my plan is to enable APIC through assembly code but > > didn't work, any idea? > > I think this is not an option in the BIOS. The "Local APICs" are part of > the CPU. Each core in a multi-core CPU has its own private local APIC > (see http://wiki.osdev.org/APIC). > > The APIC *is* actually enabled at the end of "pilos/x86-64/beg.l", in > these lines: > > mov $0x0000001B, %ecx # APIC Base MSR > rdmsr > or $0x0800, %eax # Enable APIC (Bit 11) > wrmsr > and $0xFFFFF000, %eax # Get base address > or $0x93, %eax # 2 MiB + P | R/W | PCD > mov %eax, 8(%edi) # Map APICs to 0x200000 > movl $0xFEC00093, 16(%edi) # Map IO-APIC 0x400000 > movw $0x1FF, (0x2000F0) # Spurious IR vector + APIC enable > > But only after the above test succeeded, of course. > > > > But before that i want to resolve why the code will not work properly > > if without the newly inserted message printing.. is it about code > > Yes, this is a strange thing. It is not good if we can't even rely on > the debug messages ;) > > > misalignment? Maybe it differs per CPU model? > > Misalignment should not be an issue. We are still in 16-bit code (8086 > real mode) here. > > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe >
