Thank you Dick
Oops, I use a wrong subject, what I want to ask is how the pg0 be initialized
in head.S,
395 .org 0x2000
396 ENTRY(pg0)
so $pg0-__PAGE_OFFSET = 0x2000 - 0xC0000000 = 40002000, how comes bff00000 ?
>84 movl $pg0-_PAGE_OFFSET,%edi
%edi = bff00000 (or 40002000) ?
>87 2: stosl
that's move %eax to %es:%edi, __KERNEL_DS = 0x18, so %es is 0x18, according the gdt_table, 0x00cf92000000ffff, the base linear address is 0x00000000, that means
%es:%edi = bff00000 (or 40002000), how can the %eax be moved into an nonexist ram,
cause at that time, no page directory and and page table yet.
Anyway, thank you for your help.
Regards,
Jason
>> 48 cld
>> 49 movl $(__KERNEL_DS),eax
>> 50 movl eax,ds
>> 51 movl eax,es
>> 52 movl eax,fs
>> 53 movl eax,gs
>> 81 /*
>> 82 * Initialize page tables
>> 83 */
>> 84 movl $pg0-__PAGE_OFFSET,edi /* initialize page tables */
>> 85 movl $007,eax /* "007" doesn't mean with right to kill, but
>> 86 PRESENT+RW+USER */
>> 87 2: stosl
>> 88 add $0x1000,eax
>> 89 cmp $empty_zero_page-__PAGE_OFFSET,edi
>> 90 jne 2b
>>
>> I remove the SMP code. According the setup.S, gdt_table is setup as
>> gdt_table:
>> #.quad 0x0000000000000000; // null
>> #.quad 0x0000000000000000; // not used
>> #.quad 0x00cf9a000000ffff; // 0x10 kernel 4GB code at 0x00000000
>> #.quad 0x00cf92000000ffff; // 0x18 kernel 4GB data at 0x00000000
>>
>> 1) So, what's in eax after line 49 ? 0x0 ?
>> 2) Isn't __PAGE_OFFSET 0xC0000000 ? what's the result of $pg0-__PAGE_OFFSET ?
>>
>> Thanks,
>>
>> Jason
>
On Wed, 20 Feb 2002, Jason Yan wrote:
> Thank you Dick
>
> Oops, I use a wrong subject, what I want to ask is how the pg0 be initialized
>
> in head.S,
>
> 395 .org 0x2000
> 396 ENTRY(pg0)
Last I checked the page-table was 1 megabyte + that origin. Anyways,
it doesn't matter. It is all referenced by labels which are fixed up
by the linker.
>
> so $pg0-__PAGE_OFFSET = 0x2000 - 0xC0000000 = 40002000, how comes bff00000 ?
>
> >84 movl $pg0-_PAGE_OFFSET,%edi
>
> %edi = bff00000 (or 40002000) ?
>
> >87 2: stosl
>
> that's move %eax to %es:%edi, __KERNEL_DS = 0x18, so %es is 0x18,
> according the gdt_table, 0x00cf92000000ffff, the base linear address
> is 0x00000000, that means
> %es:%edi = bff00000 (or 40002000), how can the %eax be moved into an
EAX contents ^^^
> nonexist ram, cause at that time, no page directory and and page table
> yet.
The RAM exists and is addressed as linear address space because the
paging bit in CR0 isn't set yet. This is the reason why all the
operations that change or modify paging have to be done in a region
where there is a 1:1 physical/virtual address translation. If the
correct PTEs are present, once the paging bit is set, the stuff
being executed doesn't change, but now exists at the (unchanged)
virtual address.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
111,111,111 * 111,111,111 = 12,345,678,987,654,321
Jason Yan wrote:
>
> Thank you Dick
>
> Oops, I use a wrong subject, what I want to ask is how the pg0 be initialized
>
> in head.S,
>
> 395 .org 0x2000
> 396 ENTRY(pg0)
>
> so $pg0-__PAGE_OFFSET = 0x2000 - 0xC0000000 = 40002000, how comes bff00000 ?
That's offset 0x2000 from the beginning of head.o, which is at virtual
address 0xc0100000, meaning the final value of pg0 is 0xc0102000.
Subtract __PAGE_OFFSET and you get physical address 0x00102000.
--
Brian Gerst
Thank you all.
OK. I got it. and,
Is the linker who set the beginning virtual address as 0xc0100000 ? Is it a must? When and where? at the time "make bzImage" ? If it's not a BIG kernel, is the magic number still 0xc0100000 ?
Thanks,
Jason
Jason Yan wrote:
>
> Thank you all.
>
> OK. I got it. and,
>
> Is the linker who set the beginning virtual address as 0xc0100000 ? Is it a must? When and where? at the time "make bzImage" ? If it's not a BIG kernel, is the magic number still 0xc0100000 ?
It's set in vmlinux.lds, and is the same for all kernels unless patched
to change the user:kernel vm split.
--
Brian Gerst
>It's set in vmlinux.lds, and is the same for all kernels unless patched
>to change the user:kernel vm split.
> Brian Gerst
Brian,
Thank you so much, now I totally understand. I'm a real newbie, :-) I've been tortured for almost 2 weeks until I find this list.
And thank you all,
Jason