BMOS stack

[Tim M]

In the ap_clear label is this code:

; Set up the stack

shl rax, 21 ; Shift left 21 bits for a 2 MiB stack

add rax, [os_StackBase] ; The stack decrements when you "push", start at 2 MiB in

sub rax, 8

mov rsp, rax

If I comment it out, BMOS will make it to the cli and actually respond (running diskless and a dir gives me a green screen). If I don't comment it out, it goes to no mans land and crashes. I have narrowed the crash to the add rax, [os_StackBase]. If I just comment that line it will make it to cli, but it is unresponsive. So how do I increase the stack size to say 40MB? Or is there something else going on here?

Also, I am still getting incorrect core count on each boot, any insight to this?

-Tim

[Tim M]

also, using IDA Pro to disassemble the code to make sure all instructions are as they should be, here is the output:

ap_clear:                               ; CODE XREF: start+FF j

seg000:0000000000000130                 cli

seg000:0000000000000131                 mov     rsi, ds:110000h

seg000:0000000000000139                 xor     eax, eax

seg000:000000000000013B                 mov     [rsi+80h], eax

seg000:0000000000000141                 mov     eax, [rsi+20h]

seg000:0000000000000144                 shr     rax, 18h

seg000:0000000000000148                 mov     edi, 1FEF00h

seg000:000000000000014D                 add     rdi, rax

seg000:0000000000000150                 shl     rax, 15h

seg000:0000000000000154                 add     rax, ds:110028h ;THE line in qestion

seg000:000000000000015C                 sub     rax, 8

seg000:0000000000000160                 mov     rsp, rax

seg000:0000000000000163                 mov     al, 1

seg000:0000000000000165                 stosb

seg000:0000000000000166                 sti

[42Bastian]

Not setting up a stack is not wise.
But maybe you just start with a fixed number of cores?
Let's say 2?
Also maybe disable hyperthreading, so you first work with real cores.

--
42Bastian

[Tim M]

I know its not wise to not setup the stack, but that allowed it to boot and give me a cli. I have tried disabling all cores and hyper threading to no avail. I'll double check my test on that. It's a little confusing to me how the stack it setup at the moment.

[Tim M]

2 cores, no hyperthreading still results in a crash.

-Tim

[42Bastian]

Oh, WTF am I narrow-minded :(. Now I finally got what you mean with "cli".
I was confusing it with the assembler opcode "cli" (even not sure x64 has it).

--
42Bastian

[Tim M]

Sorry, cli == command line interface ;) I am grasping at straws now. BTW, why does it now show correct core count? As I said in another thread, this MOBO has an apci V5, seems that this might be related? It runs fine on an older dual core X64 machine without any code changes.

-Tim

[Tim M]

OK, I have traced it back to a bug in Pure64. Pure64 reports the wrong number of cores, thus the OS only allocates a stack for how ever many cores Pure64 says it found. I hard coded all places in the kernel that used os_NumCores and the kernel work as designed. Ian, do you have any ideas of where to start looking to find the bug in Pure64?

-Tim

[Tim M]

Debug show 12 cpu_activated and 12 cpu_detected but displays 7. Strange....

-Tim

[Ian Seyler]

Hi Tim,

What is the output for the following?:

debug 5012

I'm curious to see the detected/activated numbers.

Also,

debug 5100 256

I want to see the APIC ids.

-Ian

[Tim M]

[Tim M]

Ian,

What ever is causing the differences has to be MOBO or CPU related. Another thing that I have not mentioned yet is that if I do a dir, I get a solid green screen. Sounds to me like the stack is walking on the video buffer RAM.

Had a rough day reinstalling windows on my dev box and my server, so I will get back to debugging tomorrow.

-Tim

[Tim M]

Ian,

Did you see anything that might help narrow down the issue? Also, is there another forum that you and other BMOS users are more active on?

-Tim

On Friday, September 25, 2015 at 7:09:54 PM UTC-4, Ian Seyler wrote:

[Ian Seyler]

So I'm looking at the debug values you've posted.

The 16-bit value at 0x5012 is "cores active" and in this case is set to 9.

The 16-bit value at 0x5014 is "cores detected" and in this case is set to 12.

This means that Pure64 was able to start 9 of the 12 cores.

The 8-bit values at 0x5100 are the APIC IDs for all of the detected cores. This looks ok.

So for some reason Pure64 was not able to start some of the cores (or the cores started and did not execute the start_ap core). Hard to say at this point as usually it is an "all or nothing" thing.

And you mentioned that sometimes it activates a different amount of cores?

Sorry, this is the only forum. I was without internet for a couple of days but will try to be more active while this gets sorted out.

-Ian

[Ian Seyler]

Another odd thing is that BareMetal sees 12 active cores but the info table from Pure64 only says 9. :/

-Ian

[Tim M]

Ian,

This is the exact line that sends it in the weeds, from kernel64.asm. add rax, [os_StackBase] ; The stack decrements when you "push", start at 2 MiB in I understand what your saying about seeing 12 but only tuning on 9, even at that, why does the stack init blow it up it is only trying to allocate enough stack for what it is seeing? BTW, I have a VS2015 project that builds BMOS I can share, yea I am a windows guy. I had went through and hard coded all place that us the val at 0x5012 to 12 (num cores in this unit) and it still blows up.

-Tim

[Tim M]

Ian,

I have solve the issue with Pute64 not turning on all the cores. I read the spec from Intel on how to tun the core on and I found that they reccomended something like 20uS in one place and 200uS in another place. I found that in this pdf. file:http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html Section 8.4.4 I changed the code to allow a longer delay for the CPU core to settle and now every time it shows correct core count! YAY I have unlocked CPU's and I raised the CPU freq to 5200 mHZ and it still boots and shows correct amount every time. Although the CPU speed is still not right, but I do not plan to use that for anything. I don't run the CPU at 5200 all the time, just for testing, normally I keep it at about 4500 which is pretty stable for a 24/7 work load, and they are in a enclosure that is maintained at 20deg F always.

; Let things settle (Give the AP's some time to finish)

mov rax, [os_Counter_RTC]

add rax, 200 ;MORE TIME TO SETTLE

Now for the bad part, it still crashes when the kernel sets up the stack for each core. ;( I will spend some more time on that tonight. Do you have any ideas?

-Tim

[Ian Seyler]

Awesome! I'll take a further look at that doc and get to work on finding the source of the crash.

-Ian

[Tim M]

Ian,

Can support and the source for BareMetal node be purchased?

-Tim

[42Bastian]

Hi Tim

> Now for the bad part, it still crashes when the kernel sets up the stack
> for each core. ;( I will spend some more time on that tonight. Do you have
> any ideas?

Did you try to narrow the point of crash? After 4,8,10 stacks?

These line in 64.asm look suspicious to me:

add rax, 2097152
mov [os_StackBase], rax ; Store the Stack base address

Why adding 2MB on StackBase? Core 0?

Cheers

--
42Bastian

[42Bastian]

Am 29.09.2015 20:27, schrieb 42Bastian:

> These line in 64.asm look suspicious to me:
>
> add rax, 2097152 mov [os_StackBase], rax ; Store the Stack base
> address
>
> Why adding 2MB on StackBase? Core 0?

Ok, got it: To move rsp to the top of stack.

--
42Bastian

[Tim M]

I wonder if there is a change that an unhandled ISR is being triggered? If I jmp $ before the sti, it does not jump to the weeds and remains as the screen was last printed, but if I jmp$ after the sti its in the weeds, garbage flys across the screen then eventually a black screen; I am sure that it is something with this cpu cause it works fine on another older test pc and for many others.

-Tim

[Tim M]

Also found this, not sure if there is anything to it. http://forum.osdev.org/viewtopic.php?f=1&t=28057&start=0

-Tim

On Tuesday, September 29, 2015 at 2:31:27 PM UTC-4, 42Bastian wrote:

[Tim M]

I have a VMware machine that is giving strange results. Notice the dir cmd gives strings that are not even in the OS. Someone on OsDev sugessted that it is the memory map that is causing the issues. I at first assumed he was talking about the memory map between my 2 test cases, but later realized he was talking about BMOS internal mem map. I am still looking into how to fix the issue. I am sooo close, yet so far away. Anyone know how to single step the code so I can see the registers while excuting?

-Tim

[42Bastian]

Hi Tim

> Anyone know how to single step
> the code so I can see the registers while excuting?

It is possible with QEMU. It contains a GDB server. I tried it once or
twice with the ARM version but not with x64.

Cheers

--
42Bastian