arm minix boot

[Pu Yongming]

Hi,

I want to know the sequnece of minix booting on arm platform.

Is the bootloader uboot? 

Is there any docs about this question?

when and where minix setup the exception vector table?

in the source code excerpt blow, why assign sp a new value after switching to user mode? 

ENTRY(restore_user_context)

/* sp holds the proc ptr */

mov sp, r0

/* Set SPSR and LR for return */

ldr r0, [sp, #PSREG]

msr spsr_fsxc, r0

ldr lr, [sp, #PCREG]

/* Restore user-mode registers from proc struct */

ldm sp, {r0-r14}^

ldr sp, =_C_LABEL(svc_stack)

ldr sp, [sp]

/* To user mode! */

movs pc, lr

BR,

Hunter

[keesj]

Hi,

On Thursday, January 16, 2014 12:33:22 PM UTC+1, Pu Yongming wrote:

Hi,

I want to know the sequnece of minix booting on arm platform.

Is the bootloader uboot? 

Documenting the boot sequence is on my todo list. I don't thing anybody else wrote documentation about this yet but the x86 procedure is pretty much followed

-u-boot is indeed used and is itself loaded by the boot ROM and the stripped u-boot (MLO)

 

Is there any docs about this question?

There is  http://wiki.minix3.org/DevelopersGuide/EarlyBoot  for x86 that pretty much also applies to ARM.

when and where minix setup the exception vector table?

 

prot_init in protect.c sets the vector base address. this is done one the code is running "high"

 

in the source code excerpt blow, why assign sp a new value after switching to user mode? 

ENTRY(restore_user_context)

/* sp holds the proc ptr */

mov sp, r0

/* Set SPSR and LR for return */

ldr r0, [sp, #PSREG]

msr spsr_fsxc, r0

ldr lr, [sp, #PCREG]

/* Restore user-mode registers from proc struct */

ldm sp, {r0-r14}^

ldr sp, =_C_LABEL(svc_stack)

ldr sp, [sp]

 arch_finish_switch_to_user already sets the svc_stack to point to the correct stack. I don't know why.

[Pu Yongming]

Thank you very very much.

Can u tell me when and where Minix boot system processes?

And where Minix setup every system processes' stackframe_s and every user processes' stackframe_s? because my understanding is that before running any process, its registers must be set correctly in somewhere, for minix it is proc's stackframe_s, when need to context switch, sp point to the stackframe_s then call instruction like ldm sp, {r0-r14}^ to switch to user mode and fill cpu registers the values in stackframe_s at the same time. is my understanding correct?

When context switch, switch_to_user will be called. This function actually does two things, firstly switch address space, secondly register context switch. is my understanding right?

And my another question is after address space switch, how can minix work correctly in supervisor mode?

[Antoine LECA]

Pu Yongming wrote:
> Can u tell me when and where Minix boot system processes?

Define "boot". Loading? Setting up? Made running?

System processes can be divided in two classes, those which are part of
the boot image and those which do not. I assume the latter are
irrelevant here.
The former are loaded in memory as part of the boot process, obviously,
and are started in two steps called from kernel/main.c: first they are
initialized but mostly prevented to run (only VM is allowed), then when
VM has initialized itself, they are unblocked (bsp_finish_booting).

Nothing here is ARM specific, which makes me changing the subject.
And while the process had to be adjusted because of VM (particularly the
blocking), the explanations of this process in the OSDI book are still
largely relevant. Including the setting up of the stack.


Antoine

[Pu Yongming]

Thanks, by reading the code, I found kmain call arch_boot_proc(ip, rp). in arch_boot_proc, why only when rp->p_nr == VM_PROC_NR, then call arch_proc_init to initialize vm's proc structure?

how about other servers' procs?

[keesj]

Hello,

On Friday, January 17, 2014 1:54:42 PM UTC+1, Pu Yongming wrote:

Thanks, by reading the code, I found kmain call arch_boot_proc(ip, rp). in arch_boot_proc, why only when rp->p_nr == VM_PROC_NR, then call arch_proc_init to initialize vm's proc structure?

how about other servers' procs?

As you can read in  http://wiki.minix3.org/DevelopersGuide/EarlyBoot

VM is needed first(if even gets mapped into the initial pagetable). The other processes are initiated later on (by vm calling do_exec) when VM has it's own pagetable. this is to keep the minimum of logic in the kernel.

[Pu Yongming]

It really helps, but I am not sure the meaning of sentence bellow

"The kernel, however, must logically execute at the top of virtual address space, i.e. at a high address. This is because the kernel shares the virtual address space with the currently running process, and constraining user processes to be linked (i.e. execute) at a certain minimal address, also bounding kernel size and kernel virtual address space usage, is unacceptable."

does it mean like linux, kernel runs in 3G-4G address space, processes run in 0G ~ 3G address space?

[Antoine LECA]

Pu Yongming wrote:
> "The kernel, however, must logically execute at the *top* of virtual

> address space, i.e. at a high address. This is because the kernel shares
> the virtual address space with the currently running process, and
> constraining user processes to be linked (i.e. execute) at a certain
> minimal address, also bounding kernel size and kernel virtual address space
> usage, is unacceptable."
>
> does it mean like linux, kernel runs in 3G-4G address space, processes run
> in 0G ~ 3G address space?

For i386 Minix 3.2.1 and up, yes this is correct, besides the small
difference that only 256MiB is reserved to the kernel, so the upper
limit for processes is 3.75GiB.
Also, unlike the standard System V ELF-based memory layout, in MINIX the
stack is not in the 128Ki below the 0x08040800 address, but rather above
the end of bss segment of the main image.

For ARM, a quick inspection of kernel.lds is blurred by misleading
comments (0x80200000 is *NOT* 4M-aligned :-) )
_kern_phys_base = 0x80200000;
/* phys 4MB aligned for convenient remapping */
but the same basic scheme seems to apply.


Antoine