(solved)memory address and e820

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Question: memory address and e820

Post by Combuster »

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.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Question: memory address and e820

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
neoe
Posts: 17
Joined: Wed Sep 24, 2014 10:03 am

Re: Question: memory address and e820

Post by neoe »

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)
User avatar
IanSeyler
Member
Member
Posts: 326
Joined: Mon Jul 28, 2008 9:46 am
Location: Ontario, Canada
Contact:

Re: Question: memory address and e820

Post by IanSeyler »

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?
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
neoe
Posts: 17
Joined: Wed Sep 24, 2014 10:03 am

Re: Question: memory address and e820

Post by neoe »

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 :
screenshot
screenshot
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.
neoe
Posts: 17
Joined: Wed Sep 24, 2014 10:03 am

Re: Question: memory address and e820

Post by neoe »

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
neoe
Posts: 17
Joined: Wed Sep 24, 2014 10:03 am

Re: Question: memory address and e820

Post by neoe »

Post Reply