Re: [08/36] AArch64: Kernel booting and initialisation

[Christopher Covington <cov@codeaurora.org>]

Hi Catalin,

On 01/-10/-28163 02:59 PM, Catalin Marinas wrote:
> The patch adds the kernel booting and the initial setup code.
> Documentation/aarch64/booting.txt describes the booting protocol on the
> AArch64 Linux kernel. This is subject to change following the work on
> boot standardisation, ACPI.

[...]

> diff --git a/Documentation/aarch64/booting.txt b/Documentation/aarch64/booting.txt
> new file mode 100644
> index 0000000..5268280
> --- /dev/null
> +++ b/Documentation/aarch64/booting.txt
> @@ -0,0 +1,139 @@

[...]

> +- Architected timers
> +  CNTFRQ must be programmed with the timer frequency.
> +  If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
> +  set where available.

After Marc Zyngier's virtual timer patches come in, will the latter
requirement only be strictly necessary for kernels wanting to do
virtualization?

[...]

> diff --git a/arch/aarch64/kernel/setup.c b/arch/aarch64/kernel/setup.c
> new file mode 100644
> index 0000000..9da03d5
> --- /dev/null
> +++ b/arch/aarch64/kernel/setup.c

[...]

> +static void __init setup_processor(void)
> +{
> +	struct proc_info_list *list;
> +
> +	/*
> +	 * locate processor in the list of supported processor
> +	 * types.  The linker builds this table for us from the
> +	 * entries in arch/arm/mm/proc-*.S
> +	 */

It looks like there's only arch/arm64/mm/proc.S at the moment.

> +	list = lookup_processor_type(read_cpuid_id());
> +	if (!list) {
> +		printk("CPU configuration botched (ID %08x), unable to continue.\n",
> +		       read_cpuid_id());
> +		while (1);
> +	}
> +
> +	cpu_name = list->cpu_name;
> +
> +	printk("CPU: %s [%08x] revision %d\n",
> +	       cpu_name, read_cpuid_id(), read_cpuid_id() & 15);
> +
> +	sprintf(init_utsname()->machine, "aarch64");
> +	elf_hwcap = 0;
> +
> +	cpu_proc_init();
> +}
> +
> +/*
> + * cpu_init - initialise one CPU.
> + *
> + * cpu_init sets up the per-CPU stacks.
> + */
> +void cpu_init(void)
> +{
> +}

It looks like the comment above is a holdover from the 32-bit code and
no longer applies. Perhaps you could replace it with a comment on where
stack pointer initialization is actually handled. Searching briefly, it
looks like it's done in __mmap_switched and __secondary_switched.

[...]

> +
> +/*
> + * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
> + * is_kdump_kernel() to determine if we are booting after a panic. Hence
> + * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
> + */

This comment doesn't seem relevant to the current version of the code.

[...]

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum