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 <a...@software-lab.de>
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:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to