Hi Adrian,
Thank you very much for your explain. I might have some misunderstanding about
the source code. First may I ask what the kernel window means? Does it means
the virtual memory space kernel can access (through pptr_t)?
I can see the dev_p_regs[] (kernel/src/plat/tk1/machine/hardware.c) has
multiple parts: the first is the RAM part, VM_HOST_PA_START - VM_HOST_PA_START
+ VM_HOST_PA_SIZE (0xb0000000 — 0xf0000000), the rest are real device region
from 0x01000000 - 0x7c000000 approximately. I guess my question is why put the
second half as a “device” instead of putting it together in avail_p_regs[]? Is
it somehow due to the support of virtualization?
Here is the booting procedure according to my understanding, could you take a
look and see if I got it right?
1. the code start at the ELF-loader main()
(tools/elfloader/src/arch-arm/boot.c) which is loaded in physical memory
0x82000000 for TK1 (tools/elfloader/gen_boot_image.sh)
2. the boot code unpack the ELF and find the kernel image and the user-land
image, the kernel is loaded at 0x80000000 the user land image is loaded at
0x80037000 approximately
3. MMU is enabled and a “boot" page directory is created that maps physical
0x80000000 to (0xe0000000 - 0xf0000000)
4. enter the kernel code _start, which setup up vector table and kernel stack;
then init_kernel(); then try_init_kernel() calls map_kernel_window()
I’m not sure why map_kernel_windows() remap the virtual address kernelBase
(start from 0xe0000000) to physical address physBase (0x80000000) again or did
I miss anything?
Also I’m not sure what those armHSGlobalPGD[], armHSGlobalPD[] for, I assume it
is for context switch?
(deleted diagram due to size limit)
Thanks
-Dan
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
