OSDev.org

0000000 0000000f 000000008 0000000010283 (What is mean?)

Considering you don't know, what will you do to find out what the error code is exactly?

In addition, you fail your homework in part for being unable to type things over. Please post exactly what you see, possibly together with a description of how you got this information.

Hi,

neoe wrote:Would you please have a look at the implementation:
https://github.com/ReturnInfinity/Pure6 ... pure64.asm

Some of the comments in that code are misleading. It creates enough PDPTs for 64 GiB of the virtual address space, but only actually maps 4 GiB of the physical address space (2048 pages at 2 MiB each) into that 64 GiB area.

Of course this is only boot code and I'd assume whatever it does is only temporary (and replaced or modified later during boot by kernel or something else).


Cheers,

Brendan

Brendan wrote:Hi,

neoe wrote:Would you please have a look at the implementation:
https://github.com/ReturnInfinity/Pure6 ... pure64.asm

Some of the comments in that code are misleading. It creates enough PDPTs for 64 GiB of the virtual address space, but only actually maps 4 GiB of the physical address space (2048 pages at 2 MiB each) into that 64 GiB area.

Of course this is only boot code and I'd assume whatever it does is only temporary (and replaced or modified later during boot by kernel or something else).


Cheers,

Brendan

Maybe Not. It seem that other 60GB is mapped later. see code with comment "Another 60 GiB (We already mapped 4 GiB)"

---------------------

There is still problem, but
I made progress by making it clear that 4GB memory is not must be [0 to 0x100000000-1],
if e820 shows address like [0x100000000 - 0x12F000000] is usable it is valid. (I just tested on another PC)

Author of Pure64 and BareMetal checking in..

Pure64 initially maps the first 4GiB while in 32-bit mode (https://github.com/ReturnInfinity/Pure6 ... 4.asm#L209) and then maps 60GiB more while in 64-bit mode (https://github.com/ReturnInfinity/Pure6 ... 4.asm#L314).

As mentioned in the BareMetal OS group you need to make sure that your memory addressing starts at 0x0.

Can you post the entire output of E820 map?

IanSeyler wrote:Author of Pure64 and BareMetal checking in..

Pure64 initially maps the first 4GiB while in 32-bit mode (https://github.com/ReturnInfinity/Pure6 ... 4.asm#L209) and then maps 60GiB more while in 64-bit mode (https://github.com/ReturnInfinity/Pure6 ... 4.asm#L314).

As mentioned in the BareMetal OS group you need to make sure that your memory addressing starts at 0x0.

Can you post the entire output of E820 map?

Hi, nice to see you!
--------------------------e820-------------
0000000 0000000000000009FC00 usable
more to see : I don't test memory below 2MB, so as you can see I tested 2 part of memory
0000200000 len:BFDA000
0000100000000 len: 140000000
when testing the 2nd part at 78%, page-fault error.
Any hint?
Thanks.

Well, I found some clue.

baremetal-os use "os_mem_allocate" to alloc 2MB memory for each CPU as stack.
I'm afraid my memtest overwritten the allocated stacks.

By the way, there should be a fatal bug in "os_mem_allocate" ,
because it not alloc memory according to e820 map,
means
(1) will alloc memory in some reserverd memory holes.
(2) the memory limit is not [os_MemAmount]/2 MB, but some value higher shown in e820 map.

Neoe

I made a temp fix on smp cpu stack.
and the memtest works like magic!

https://github.com/neoedmund/Pure64/com ... 15eff65e47
https://github.com/neoedmund/BareMetal- ... 8d3b7c2c0e