| Date | Tue, 24 Jul 2012 15:42:28 -0400 | From | Christopher Covington <> | Subject | Re: [08/36] AArch64: Kernel booting and initialisation |
| |
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
|