2012-03-05 18:49:27 +07:00
|
|
|
/*
|
|
|
|
* Based on arch/arm/kernel/setup.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1995-2001 Russell King
|
|
|
|
* Copyright (C) 2012 ARM Ltd.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
ARM64 / ACPI: Get RSDP and ACPI boot-time tables
As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other boot-time tables.
Introduce acpi.c and its related head file in this patch to provide
fundamental needs of extern variables and functions for ACPI core,
and then get boot-time tables as needed.
- asm/acenv.h for arch specific ACPICA environments and
implementation, It is needed unconditionally by ACPI core;
- asm/acpi.h for arch specific variables and functions needed by
ACPI driver core;
- acpi.c for ARM64 related ACPI implementation for ACPI driver
core;
acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
it will be called in setup_arch() before paging_init(), so we should
use eary_memremap() mechanism here to get the RSDP and all the table
pointers.
FADT Major.Minor version was introduced in ACPI 5.1, it is the same
as ACPI version.
In ACPI 5.1, some major gaps are fixed for ARM, such as updates in
MADT table for GIC and SMP init, without those updates, we can not
get the MPIDR for SMP init, and GICv2/3 related init information, so
we can't boot arm64 ACPI properly with table versions predating 5.1.
If firmware provides ACPI tables with ACPI version less than 5.1,
OS has no way to retrieve the configuration data that is necessary
to init SMP boot protocol and the GIC properly, so disable ACPI if
we get an FADT table with version less that 5.1 when acpi_boot_table_init()
called.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Yijing Wang <wangyijing@huawei.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Jon Masters <jcm@redhat.com>
Tested-by: Timur Tabi <timur@codeaurora.org>
Tested-by: Robert Richter <rrichter@cavium.com>
Acked-by: Robert Richter <rrichter@cavium.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-24 21:02:37 +07:00
|
|
|
#include <linux/acpi.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/stddef.h>
|
|
|
|
#include <linux/ioport.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/utsname.h>
|
|
|
|
#include <linux/initrd.h>
|
|
|
|
#include <linux/console.h>
|
2014-04-03 23:48:54 +07:00
|
|
|
#include <linux/cache.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <linux/bootmem.h>
|
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/screen_info.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/kexec.h>
|
|
|
|
#include <linux/crash_dump.h>
|
|
|
|
#include <linux/root_dev.h>
|
2013-02-08 19:18:15 +07:00
|
|
|
#include <linux/clk-provider.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/proc_fs.h>
|
|
|
|
#include <linux/memblock.h>
|
2015-01-13 03:48:54 +07:00
|
|
|
#include <linux/of_iommu.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <linux/of_fdt.h>
|
2012-12-08 00:47:17 +07:00
|
|
|
#include <linux/of_platform.h>
|
2014-04-16 08:59:30 +07:00
|
|
|
#include <linux/efi.h>
|
arm64: Fix up /proc/cpuinfo
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-10-24 20:56:40 +07:00
|
|
|
#include <linux/personality.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
|
ARM64 / ACPI: Get RSDP and ACPI boot-time tables
As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other boot-time tables.
Introduce acpi.c and its related head file in this patch to provide
fundamental needs of extern variables and functions for ACPI core,
and then get boot-time tables as needed.
- asm/acenv.h for arch specific ACPICA environments and
implementation, It is needed unconditionally by ACPI core;
- asm/acpi.h for arch specific variables and functions needed by
ACPI driver core;
- acpi.c for ARM64 related ACPI implementation for ACPI driver
core;
acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
it will be called in setup_arch() before paging_init(), so we should
use eary_memremap() mechanism here to get the RSDP and all the table
pointers.
FADT Major.Minor version was introduced in ACPI 5.1, it is the same
as ACPI version.
In ACPI 5.1, some major gaps are fixed for ARM, such as updates in
MADT table for GIC and SMP init, without those updates, we can not
get the MPIDR for SMP init, and GICv2/3 related init information, so
we can't boot arm64 ACPI properly with table versions predating 5.1.
If firmware provides ACPI tables with ACPI version less than 5.1,
OS has no way to retrieve the configuration data that is necessary
to init SMP boot protocol and the GIC properly, so disable ACPI if
we get an FADT table with version less that 5.1 when acpi_boot_table_init()
called.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Yijing Wang <wangyijing@huawei.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Jon Masters <jcm@redhat.com>
Tested-by: Timur Tabi <timur@codeaurora.org>
Tested-by: Robert Richter <rrichter@cavium.com>
Acked-by: Robert Richter <rrichter@cavium.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-24 21:02:37 +07:00
|
|
|
#include <asm/acpi.h>
|
2014-04-08 05:39:52 +07:00
|
|
|
#include <asm/fixmap.h>
|
2014-07-16 22:32:44 +07:00
|
|
|
#include <asm/cpu.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <asm/cputype.h>
|
|
|
|
#include <asm/elf.h>
|
2014-11-14 22:54:07 +07:00
|
|
|
#include <asm/cpufeature.h>
|
2013-10-25 02:30:17 +07:00
|
|
|
#include <asm/cpu_ops.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <asm/sections.h>
|
|
|
|
#include <asm/setup.h>
|
2012-08-29 15:47:19 +07:00
|
|
|
#include <asm/smp_plat.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
#include <asm/cacheflush.h>
|
|
|
|
#include <asm/tlbflush.h>
|
|
|
|
#include <asm/traps.h>
|
|
|
|
#include <asm/memblock.h>
|
2012-12-19 00:53:14 +07:00
|
|
|
#include <asm/psci.h>
|
2014-04-16 08:59:30 +07:00
|
|
|
#include <asm/efi.h>
|
2015-03-13 23:14:37 +07:00
|
|
|
#include <asm/virt.h>
|
2012-03-05 18:49:27 +07:00
|
|
|
|
2013-09-18 22:14:28 +07:00
|
|
|
unsigned long elf_hwcap __read_mostly;
|
2012-03-05 18:49:27 +07:00
|
|
|
EXPORT_SYMBOL_GPL(elf_hwcap);
|
|
|
|
|
2013-08-13 21:57:53 +07:00
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
#define COMPAT_ELF_HWCAP_DEFAULT \
|
|
|
|
(COMPAT_HWCAP_HALF|COMPAT_HWCAP_THUMB|\
|
|
|
|
COMPAT_HWCAP_FAST_MULT|COMPAT_HWCAP_EDSP|\
|
|
|
|
COMPAT_HWCAP_TLS|COMPAT_HWCAP_VFP|\
|
|
|
|
COMPAT_HWCAP_VFPv3|COMPAT_HWCAP_VFPv4|\
|
2014-11-17 17:37:40 +07:00
|
|
|
COMPAT_HWCAP_NEON|COMPAT_HWCAP_IDIV|\
|
|
|
|
COMPAT_HWCAP_LPAE)
|
2013-08-13 21:57:53 +07:00
|
|
|
unsigned int compat_elf_hwcap __read_mostly = COMPAT_ELF_HWCAP_DEFAULT;
|
2014-03-03 14:34:45 +07:00
|
|
|
unsigned int compat_elf_hwcap2 __read_mostly;
|
2013-08-13 21:57:53 +07:00
|
|
|
#endif
|
|
|
|
|
arm64: Provide a namespace to NCAPS
Building arm64.allmodconfig leads to the following warning:
usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined
#define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
^
In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0,
from /home/build/work/batch/include/linux/clocksource.h:19,
from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19,
from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27,
from /home/build/work/batch/arch/arm64/include/asm/timex.h:19,
from /home/build/work/batch/include/linux/timex.h:65,
from /home/build/work/batch/include/linux/sched.h:19,
from /home/build/work/batch/arch/arm64/include/asm/compat.h:25,
from /home/build/work/batch/arch/arm64/include/asm/stat.h:23,
from /home/build/work/batch/include/linux/stat.h:5,
from /home/build/work/batch/include/linux/module.h:10,
from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19:
arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition
#define NCAPS 2
So add a ARM64 prefix to avoid such problem.
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-04 08:17:01 +07:00
|
|
|
DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
|
2014-11-14 22:54:07 +07:00
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
phys_addr_t __fdt_pointer __initdata;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Standard memory resources
|
|
|
|
*/
|
|
|
|
static struct resource mem_res[] = {
|
|
|
|
{
|
|
|
|
.name = "Kernel code",
|
|
|
|
.start = 0,
|
|
|
|
.end = 0,
|
|
|
|
.flags = IORESOURCE_MEM
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "Kernel data",
|
|
|
|
.start = 0,
|
|
|
|
.end = 0,
|
|
|
|
.flags = IORESOURCE_MEM
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
#define kernel_code mem_res[0]
|
|
|
|
#define kernel_data mem_res[1]
|
|
|
|
|
|
|
|
void __init early_print(const char *str, ...)
|
|
|
|
{
|
|
|
|
char buf[256];
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
va_start(ap, str);
|
|
|
|
vsnprintf(buf, sizeof(buf), str, ap);
|
|
|
|
va_end(ap);
|
|
|
|
|
|
|
|
printk("%s", buf);
|
|
|
|
}
|
|
|
|
|
2015-03-17 16:55:12 +07:00
|
|
|
/*
|
|
|
|
* The recorded values of x0 .. x3 upon kernel entry.
|
|
|
|
*/
|
|
|
|
u64 __cacheline_aligned boot_args[4];
|
|
|
|
|
2013-11-06 01:10:47 +07:00
|
|
|
void __init smp_setup_processor_id(void)
|
|
|
|
{
|
2014-11-04 17:50:16 +07:00
|
|
|
u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
|
|
|
|
cpu_logical_map(0) = mpidr;
|
|
|
|
|
2013-11-06 01:10:47 +07:00
|
|
|
/*
|
|
|
|
* clear __my_cpu_offset on boot CPU to avoid hang caused by
|
|
|
|
* using percpu variable early, for example, lockdep will
|
|
|
|
* access percpu variable inside lock_release
|
|
|
|
*/
|
|
|
|
set_my_cpu_offset(0);
|
2014-11-04 17:50:16 +07:00
|
|
|
pr_info("Booting Linux on physical CPU 0x%lx\n", (unsigned long)mpidr);
|
2013-11-06 01:10:47 +07:00
|
|
|
}
|
|
|
|
|
2013-10-21 19:29:42 +07:00
|
|
|
bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
|
|
|
|
{
|
|
|
|
return phys_id == cpu_logical_map(cpu);
|
|
|
|
}
|
|
|
|
|
arm64: kernel: build MPIDR_EL1 hash function data structure
On ARM64 SMP systems, cores are identified by their MPIDR_EL1 register.
The MPIDR_EL1 guidelines in the ARM ARM do not provide strict enforcement of
MPIDR_EL1 layout, only recommendations that, if followed, split the MPIDR_EL1
on ARM 64 bit platforms in four affinity levels. In multi-cluster
systems like big.LITTLE, if the affinity guidelines are followed, the
MPIDR_EL1 can not be considered a linear index. This means that the
association between logical CPU in the kernel and the HW CPU identifier
becomes somewhat more complicated requiring methods like hashing to
associate a given MPIDR_EL1 to a CPU logical index, in order for the look-up
to be carried out in an efficient and scalable way.
This patch provides a function in the kernel that starting from the
cpu_logical_map, implement collision-free hashing of MPIDR_EL1 values by
checking all significative bits of MPIDR_EL1 affinity level bitfields.
The hashing can then be carried out through bits shifting and ORing; the
resulting hash algorithm is a collision-free though not minimal hash that can
be executed with few assembly instructions. The mpidr_el1 is filtered through a
mpidr mask that is built by checking all bits that toggle in the set of
MPIDR_EL1s corresponding to possible CPUs. Bits that do not toggle do not
carry information so they do not contribute to the resulting hash.
Pseudo code:
/* check all bits that toggle, so they are required */
for (i = 1, mpidr_el1_mask = 0; i < num_possible_cpus(); i++)
mpidr_el1_mask |= (cpu_logical_map(i) ^ cpu_logical_map(0));
/*
* Build shifts to be applied to aff0, aff1, aff2, aff3 values to hash the
* mpidr_el1
* fls() returns the last bit set in a word, 0 if none
* ffs() returns the first bit set in a word, 0 if none
*/
fs0 = mpidr_el1_mask[7:0] ? ffs(mpidr_el1_mask[7:0]) - 1 : 0;
fs1 = mpidr_el1_mask[15:8] ? ffs(mpidr_el1_mask[15:8]) - 1 : 0;
fs2 = mpidr_el1_mask[23:16] ? ffs(mpidr_el1_mask[23:16]) - 1 : 0;
fs3 = mpidr_el1_mask[39:32] ? ffs(mpidr_el1_mask[39:32]) - 1 : 0;
ls0 = fls(mpidr_el1_mask[7:0]);
ls1 = fls(mpidr_el1_mask[15:8]);
ls2 = fls(mpidr_el1_mask[23:16]);
ls3 = fls(mpidr_el1_mask[39:32]);
bits0 = ls0 - fs0;
bits1 = ls1 - fs1;
bits2 = ls2 - fs2;
bits3 = ls3 - fs3;
aff0_shift = fs0;
aff1_shift = 8 + fs1 - bits0;
aff2_shift = 16 + fs2 - (bits0 + bits1);
aff3_shift = 32 + fs3 - (bits0 + bits1 + bits2);
u32 hash(u64 mpidr_el1) {
u32 l[4];
u64 mpidr_el1_masked = mpidr_el1 & mpidr_el1_mask;
l[0] = mpidr_el1_masked & 0xff;
l[1] = mpidr_el1_masked & 0xff00;
l[2] = mpidr_el1_masked & 0xff0000;
l[3] = mpidr_el1_masked & 0xff00000000;
return (l[0] >> aff0_shift | l[1] >> aff1_shift | l[2] >> aff2_shift |
l[3] >> aff3_shift);
}
The hashing algorithm relies on the inherent properties set in the ARM ARM
recommendations for the MPIDR_EL1. Exotic configurations, where for instance
the MPIDR_EL1 values at a given affinity level have large holes, can end up
requiring big hash tables since the compression of values that can be achieved
through shifting is somewhat crippled when holes are present. Kernel warns if
the number of buckets of the resulting hash table exceeds the number of
possible CPUs by a factor of 4, which is a symptom of a very sparse HW
MPIDR_EL1 configuration.
The hash algorithm is quite simple and can easily be implemented in assembly
code, to be used in code paths where the kernel virtual address space is
not set-up (ie cpu_resume) and instruction and data fetches are strongly
ordered so code must be compact and must carry out few data accesses.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2013-05-16 16:32:09 +07:00
|
|
|
struct mpidr_hash mpidr_hash;
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/**
|
|
|
|
* smp_build_mpidr_hash - Pre-compute shifts required at each affinity
|
|
|
|
* level in order to build a linear index from an
|
|
|
|
* MPIDR value. Resulting algorithm is a collision
|
|
|
|
* free hash carried out through shifting and ORing
|
|
|
|
*/
|
|
|
|
static void __init smp_build_mpidr_hash(void)
|
|
|
|
{
|
|
|
|
u32 i, affinity, fs[4], bits[4], ls;
|
|
|
|
u64 mask = 0;
|
|
|
|
/*
|
|
|
|
* Pre-scan the list of MPIDRS and filter out bits that do
|
|
|
|
* not contribute to affinity levels, ie they never toggle.
|
|
|
|
*/
|
|
|
|
for_each_possible_cpu(i)
|
|
|
|
mask |= (cpu_logical_map(i) ^ cpu_logical_map(0));
|
|
|
|
pr_debug("mask of set bits %#llx\n", mask);
|
|
|
|
/*
|
|
|
|
* Find and stash the last and first bit set at all affinity levels to
|
|
|
|
* check how many bits are required to represent them.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
affinity = MPIDR_AFFINITY_LEVEL(mask, i);
|
|
|
|
/*
|
|
|
|
* Find the MSB bit and LSB bits position
|
|
|
|
* to determine how many bits are required
|
|
|
|
* to express the affinity level.
|
|
|
|
*/
|
|
|
|
ls = fls(affinity);
|
|
|
|
fs[i] = affinity ? ffs(affinity) - 1 : 0;
|
|
|
|
bits[i] = ls - fs[i];
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* An index can be created from the MPIDR_EL1 by isolating the
|
|
|
|
* significant bits at each affinity level and by shifting
|
|
|
|
* them in order to compress the 32 bits values space to a
|
|
|
|
* compressed set of values. This is equivalent to hashing
|
|
|
|
* the MPIDR_EL1 through shifting and ORing. It is a collision free
|
|
|
|
* hash though not minimal since some levels might contain a number
|
|
|
|
* of CPUs that is not an exact power of 2 and their bit
|
|
|
|
* representation might contain holes, eg MPIDR_EL1[7:0] = {0x2, 0x80}.
|
|
|
|
*/
|
|
|
|
mpidr_hash.shift_aff[0] = MPIDR_LEVEL_SHIFT(0) + fs[0];
|
|
|
|
mpidr_hash.shift_aff[1] = MPIDR_LEVEL_SHIFT(1) + fs[1] - bits[0];
|
|
|
|
mpidr_hash.shift_aff[2] = MPIDR_LEVEL_SHIFT(2) + fs[2] -
|
|
|
|
(bits[1] + bits[0]);
|
|
|
|
mpidr_hash.shift_aff[3] = MPIDR_LEVEL_SHIFT(3) +
|
|
|
|
fs[3] - (bits[2] + bits[1] + bits[0]);
|
|
|
|
mpidr_hash.mask = mask;
|
|
|
|
mpidr_hash.bits = bits[3] + bits[2] + bits[1] + bits[0];
|
|
|
|
pr_debug("MPIDR hash: aff0[%u] aff1[%u] aff2[%u] aff3[%u] mask[%#llx] bits[%u]\n",
|
|
|
|
mpidr_hash.shift_aff[0],
|
|
|
|
mpidr_hash.shift_aff[1],
|
|
|
|
mpidr_hash.shift_aff[2],
|
|
|
|
mpidr_hash.shift_aff[3],
|
|
|
|
mpidr_hash.mask,
|
|
|
|
mpidr_hash.bits);
|
|
|
|
/*
|
|
|
|
* 4x is an arbitrary value used to warn on a hash table much bigger
|
|
|
|
* than expected on most systems.
|
|
|
|
*/
|
|
|
|
if (mpidr_hash_size() > 4 * num_possible_cpus())
|
|
|
|
pr_warn("Large number of MPIDR hash buckets detected\n");
|
|
|
|
__flush_dcache_area(&mpidr_hash, sizeof(struct mpidr_hash));
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-03-13 23:14:37 +07:00
|
|
|
static void __init hyp_mode_check(void)
|
|
|
|
{
|
|
|
|
if (is_hyp_mode_available())
|
|
|
|
pr_info("CPU: All CPU(s) started at EL2\n");
|
|
|
|
else if (is_hyp_mode_mismatched())
|
|
|
|
WARN_TAINT(1, TAINT_CPU_OUT_OF_SPEC,
|
|
|
|
"CPU: CPUs started in inconsistent modes");
|
|
|
|
else
|
|
|
|
pr_info("CPU: All CPU(s) started at EL1\n");
|
|
|
|
}
|
|
|
|
|
2015-03-13 23:14:34 +07:00
|
|
|
void __init do_post_cpus_up_work(void)
|
|
|
|
{
|
2015-03-13 23:14:37 +07:00
|
|
|
hyp_mode_check();
|
2015-03-13 23:14:34 +07:00
|
|
|
apply_alternatives_all();
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_UP_LATE_INIT
|
|
|
|
void __init up_late_init(void)
|
|
|
|
{
|
|
|
|
do_post_cpus_up_work();
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_UP_LATE_INIT */
|
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
static void __init setup_processor(void)
|
|
|
|
{
|
2013-12-17 04:04:36 +07:00
|
|
|
u64 features, block;
|
2014-04-03 23:48:54 +07:00
|
|
|
u32 cwg;
|
|
|
|
int cls;
|
2012-03-05 18:49:27 +07:00
|
|
|
|
2015-03-18 21:55:20 +07:00
|
|
|
printk("CPU: AArch64 Processor [%08x] revision %d\n",
|
|
|
|
read_cpuid_id(), read_cpuid_id() & 15);
|
2012-03-05 18:49:27 +07:00
|
|
|
|
2013-10-11 20:52:11 +07:00
|
|
|
sprintf(init_utsname()->machine, ELF_PLATFORM);
|
2012-03-05 18:49:27 +07:00
|
|
|
elf_hwcap = 0;
|
2013-12-17 04:04:36 +07:00
|
|
|
|
2014-07-16 22:32:44 +07:00
|
|
|
cpuinfo_store_boot_cpu();
|
|
|
|
|
2014-04-03 23:48:54 +07:00
|
|
|
/*
|
|
|
|
* Check for sane CTR_EL0.CWG value.
|
|
|
|
*/
|
|
|
|
cwg = cache_type_cwg();
|
|
|
|
cls = cache_line_size();
|
|
|
|
if (!cwg)
|
|
|
|
pr_warn("No Cache Writeback Granule information, assuming cache line size %d\n",
|
|
|
|
cls);
|
|
|
|
if (L1_CACHE_BYTES < cls)
|
|
|
|
pr_warn("L1_CACHE_BYTES smaller than the Cache Writeback Granule (%d < %d)\n",
|
|
|
|
L1_CACHE_BYTES, cls);
|
|
|
|
|
2013-12-17 04:04:36 +07:00
|
|
|
/*
|
|
|
|
* ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
|
|
|
|
* The blocks we test below represent incremental functionality
|
|
|
|
* for non-negative values. Negative values are reserved.
|
|
|
|
*/
|
|
|
|
features = read_cpuid(ID_AA64ISAR0_EL1);
|
|
|
|
block = (features >> 4) & 0xf;
|
|
|
|
if (!(block & 0x8)) {
|
|
|
|
switch (block) {
|
|
|
|
default:
|
|
|
|
case 2:
|
|
|
|
elf_hwcap |= HWCAP_PMULL;
|
|
|
|
case 1:
|
|
|
|
elf_hwcap |= HWCAP_AES;
|
|
|
|
case 0:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
block = (features >> 8) & 0xf;
|
|
|
|
if (block && !(block & 0x8))
|
|
|
|
elf_hwcap |= HWCAP_SHA1;
|
|
|
|
|
|
|
|
block = (features >> 12) & 0xf;
|
|
|
|
if (block && !(block & 0x8))
|
|
|
|
elf_hwcap |= HWCAP_SHA2;
|
|
|
|
|
|
|
|
block = (features >> 16) & 0xf;
|
|
|
|
if (block && !(block & 0x8))
|
|
|
|
elf_hwcap |= HWCAP_CRC32;
|
2014-03-03 14:34:46 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
/*
|
|
|
|
* ID_ISAR5_EL1 carries similar information as above, but pertaining to
|
|
|
|
* the Aarch32 32-bit execution state.
|
|
|
|
*/
|
|
|
|
features = read_cpuid(ID_ISAR5_EL1);
|
|
|
|
block = (features >> 4) & 0xf;
|
|
|
|
if (!(block & 0x8)) {
|
|
|
|
switch (block) {
|
|
|
|
default:
|
|
|
|
case 2:
|
|
|
|
compat_elf_hwcap2 |= COMPAT_HWCAP2_PMULL;
|
|
|
|
case 1:
|
|
|
|
compat_elf_hwcap2 |= COMPAT_HWCAP2_AES;
|
|
|
|
case 0:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
block = (features >> 8) & 0xf;
|
|
|
|
if (block && !(block & 0x8))
|
|
|
|
compat_elf_hwcap2 |= COMPAT_HWCAP2_SHA1;
|
|
|
|
|
|
|
|
block = (features >> 12) & 0xf;
|
|
|
|
if (block && !(block & 0x8))
|
|
|
|
compat_elf_hwcap2 |= COMPAT_HWCAP2_SHA2;
|
|
|
|
|
|
|
|
block = (features >> 16) & 0xf;
|
|
|
|
if (block && !(block & 0x8))
|
|
|
|
compat_elf_hwcap2 |= COMPAT_HWCAP2_CRC32;
|
|
|
|
#endif
|
2012-03-05 18:49:27 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __init setup_machine_fdt(phys_addr_t dt_phys)
|
|
|
|
{
|
2013-08-26 22:14:32 +07:00
|
|
|
if (!dt_phys || !early_init_dt_scan(phys_to_virt(dt_phys))) {
|
2012-03-05 18:49:27 +07:00
|
|
|
early_print("\n"
|
|
|
|
"Error: invalid device tree blob at physical address 0x%p (virtual address 0x%p)\n"
|
2013-08-26 22:14:32 +07:00
|
|
|
"The dtb must be 8-byte aligned and passed in the first 512MB of memory\n"
|
2012-03-05 18:49:27 +07:00
|
|
|
"\nPlease check your bootloader.\n",
|
2013-08-26 22:14:32 +07:00
|
|
|
dt_phys, phys_to_virt(dt_phys));
|
2012-03-05 18:49:27 +07:00
|
|
|
|
|
|
|
while (true)
|
|
|
|
cpu_relax();
|
|
|
|
}
|
2014-09-01 21:47:19 +07:00
|
|
|
|
arm64: Fix up /proc/cpuinfo
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-10-24 20:56:40 +07:00
|
|
|
dump_stack_set_arch_desc("%s (DT)", of_flat_dt_get_machine_name());
|
2012-03-05 18:49:27 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __init request_standard_resources(void)
|
|
|
|
{
|
|
|
|
struct memblock_region *region;
|
|
|
|
struct resource *res;
|
|
|
|
|
|
|
|
kernel_code.start = virt_to_phys(_text);
|
|
|
|
kernel_code.end = virt_to_phys(_etext - 1);
|
|
|
|
kernel_data.start = virt_to_phys(_sdata);
|
|
|
|
kernel_data.end = virt_to_phys(_end - 1);
|
|
|
|
|
|
|
|
for_each_memblock(memory, region) {
|
|
|
|
res = alloc_bootmem_low(sizeof(*res));
|
|
|
|
res->name = "System RAM";
|
|
|
|
res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
|
|
|
|
res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
|
|
|
|
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
|
|
|
|
|
|
|
|
request_resource(&iomem_resource, res);
|
|
|
|
|
|
|
|
if (kernel_code.start >= res->start &&
|
|
|
|
kernel_code.end <= res->end)
|
|
|
|
request_resource(res, &kernel_code);
|
|
|
|
if (kernel_data.start >= res->start &&
|
|
|
|
kernel_data.end <= res->end)
|
|
|
|
request_resource(res, &kernel_data);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-29 15:47:19 +07:00
|
|
|
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
|
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
void __init setup_arch(char **cmdline_p)
|
|
|
|
{
|
|
|
|
setup_processor();
|
|
|
|
|
|
|
|
setup_machine_fdt(__fdt_pointer);
|
|
|
|
|
|
|
|
init_mm.start_code = (unsigned long) _text;
|
|
|
|
init_mm.end_code = (unsigned long) _etext;
|
|
|
|
init_mm.end_data = (unsigned long) _edata;
|
|
|
|
init_mm.brk = (unsigned long) _end;
|
|
|
|
|
|
|
|
*cmdline_p = boot_command_line;
|
|
|
|
|
2014-11-22 04:50:42 +07:00
|
|
|
early_fixmap_init();
|
2014-04-08 05:39:52 +07:00
|
|
|
early_ioremap_init();
|
2014-04-08 05:39:51 +07:00
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
parse_early_param();
|
|
|
|
|
2014-08-27 03:23:38 +07:00
|
|
|
/*
|
|
|
|
* Unmask asynchronous aborts after bringing up possible earlycon.
|
|
|
|
* (Report possible System Errors once we can report this occurred)
|
|
|
|
*/
|
|
|
|
local_async_enable();
|
|
|
|
|
2014-04-16 08:59:30 +07:00
|
|
|
efi_init();
|
2012-03-05 18:49:27 +07:00
|
|
|
arm64_memblock_init();
|
|
|
|
|
ARM64 / ACPI: Get RSDP and ACPI boot-time tables
As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other boot-time tables.
Introduce acpi.c and its related head file in this patch to provide
fundamental needs of extern variables and functions for ACPI core,
and then get boot-time tables as needed.
- asm/acenv.h for arch specific ACPICA environments and
implementation, It is needed unconditionally by ACPI core;
- asm/acpi.h for arch specific variables and functions needed by
ACPI driver core;
- acpi.c for ARM64 related ACPI implementation for ACPI driver
core;
acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
it will be called in setup_arch() before paging_init(), so we should
use eary_memremap() mechanism here to get the RSDP and all the table
pointers.
FADT Major.Minor version was introduced in ACPI 5.1, it is the same
as ACPI version.
In ACPI 5.1, some major gaps are fixed for ARM, such as updates in
MADT table for GIC and SMP init, without those updates, we can not
get the MPIDR for SMP init, and GICv2/3 related init information, so
we can't boot arm64 ACPI properly with table versions predating 5.1.
If firmware provides ACPI tables with ACPI version less than 5.1,
OS has no way to retrieve the configuration data that is necessary
to init SMP boot protocol and the GIC properly, so disable ACPI if
we get an FADT table with version less that 5.1 when acpi_boot_table_init()
called.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Yijing Wang <wangyijing@huawei.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Jon Masters <jcm@redhat.com>
Tested-by: Timur Tabi <timur@codeaurora.org>
Tested-by: Robert Richter <rrichter@cavium.com>
Acked-by: Robert Richter <rrichter@cavium.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-24 21:02:37 +07:00
|
|
|
/* Parse the ACPI tables for possible boot-time configuration */
|
|
|
|
acpi_boot_table_init();
|
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
paging_init();
|
|
|
|
request_standard_resources();
|
|
|
|
|
2015-01-08 16:54:58 +07:00
|
|
|
early_ioremap_reset();
|
2014-04-16 08:59:30 +07:00
|
|
|
|
2015-03-25 22:22:13 +07:00
|
|
|
if (acpi_disabled) {
|
2015-03-24 21:02:42 +07:00
|
|
|
unflatten_device_tree();
|
2015-03-24 21:02:43 +07:00
|
|
|
psci_dt_init();
|
2015-03-24 21:02:45 +07:00
|
|
|
cpu_read_bootcpu_ops();
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
of_smp_init_cpus();
|
|
|
|
#endif
|
2015-03-24 21:02:43 +07:00
|
|
|
} else {
|
|
|
|
psci_acpi_init();
|
2015-03-24 21:02:45 +07:00
|
|
|
acpi_init_cpus();
|
2015-03-24 21:02:43 +07:00
|
|
|
}
|
2012-12-19 00:53:14 +07:00
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
#ifdef CONFIG_SMP
|
arm64: kernel: build MPIDR_EL1 hash function data structure
On ARM64 SMP systems, cores are identified by their MPIDR_EL1 register.
The MPIDR_EL1 guidelines in the ARM ARM do not provide strict enforcement of
MPIDR_EL1 layout, only recommendations that, if followed, split the MPIDR_EL1
on ARM 64 bit platforms in four affinity levels. In multi-cluster
systems like big.LITTLE, if the affinity guidelines are followed, the
MPIDR_EL1 can not be considered a linear index. This means that the
association between logical CPU in the kernel and the HW CPU identifier
becomes somewhat more complicated requiring methods like hashing to
associate a given MPIDR_EL1 to a CPU logical index, in order for the look-up
to be carried out in an efficient and scalable way.
This patch provides a function in the kernel that starting from the
cpu_logical_map, implement collision-free hashing of MPIDR_EL1 values by
checking all significative bits of MPIDR_EL1 affinity level bitfields.
The hashing can then be carried out through bits shifting and ORing; the
resulting hash algorithm is a collision-free though not minimal hash that can
be executed with few assembly instructions. The mpidr_el1 is filtered through a
mpidr mask that is built by checking all bits that toggle in the set of
MPIDR_EL1s corresponding to possible CPUs. Bits that do not toggle do not
carry information so they do not contribute to the resulting hash.
Pseudo code:
/* check all bits that toggle, so they are required */
for (i = 1, mpidr_el1_mask = 0; i < num_possible_cpus(); i++)
mpidr_el1_mask |= (cpu_logical_map(i) ^ cpu_logical_map(0));
/*
* Build shifts to be applied to aff0, aff1, aff2, aff3 values to hash the
* mpidr_el1
* fls() returns the last bit set in a word, 0 if none
* ffs() returns the first bit set in a word, 0 if none
*/
fs0 = mpidr_el1_mask[7:0] ? ffs(mpidr_el1_mask[7:0]) - 1 : 0;
fs1 = mpidr_el1_mask[15:8] ? ffs(mpidr_el1_mask[15:8]) - 1 : 0;
fs2 = mpidr_el1_mask[23:16] ? ffs(mpidr_el1_mask[23:16]) - 1 : 0;
fs3 = mpidr_el1_mask[39:32] ? ffs(mpidr_el1_mask[39:32]) - 1 : 0;
ls0 = fls(mpidr_el1_mask[7:0]);
ls1 = fls(mpidr_el1_mask[15:8]);
ls2 = fls(mpidr_el1_mask[23:16]);
ls3 = fls(mpidr_el1_mask[39:32]);
bits0 = ls0 - fs0;
bits1 = ls1 - fs1;
bits2 = ls2 - fs2;
bits3 = ls3 - fs3;
aff0_shift = fs0;
aff1_shift = 8 + fs1 - bits0;
aff2_shift = 16 + fs2 - (bits0 + bits1);
aff3_shift = 32 + fs3 - (bits0 + bits1 + bits2);
u32 hash(u64 mpidr_el1) {
u32 l[4];
u64 mpidr_el1_masked = mpidr_el1 & mpidr_el1_mask;
l[0] = mpidr_el1_masked & 0xff;
l[1] = mpidr_el1_masked & 0xff00;
l[2] = mpidr_el1_masked & 0xff0000;
l[3] = mpidr_el1_masked & 0xff00000000;
return (l[0] >> aff0_shift | l[1] >> aff1_shift | l[2] >> aff2_shift |
l[3] >> aff3_shift);
}
The hashing algorithm relies on the inherent properties set in the ARM ARM
recommendations for the MPIDR_EL1. Exotic configurations, where for instance
the MPIDR_EL1 values at a given affinity level have large holes, can end up
requiring big hash tables since the compression of values that can be achieved
through shifting is somewhat crippled when holes are present. Kernel warns if
the number of buckets of the resulting hash table exceeds the number of
possible CPUs by a factor of 4, which is a symptom of a very sparse HW
MPIDR_EL1 configuration.
The hash algorithm is quite simple and can easily be implemented in assembly
code, to be used in code paths where the kernel virtual address space is
not set-up (ie cpu_resume) and instruction and data fetches are strongly
ordered so code must be compact and must carry out few data accesses.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2013-05-16 16:32:09 +07:00
|
|
|
smp_build_mpidr_hash();
|
2012-03-05 18:49:27 +07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_VT
|
|
|
|
#if defined(CONFIG_VGA_CONSOLE)
|
|
|
|
conswitchp = &vga_con;
|
|
|
|
#elif defined(CONFIG_DUMMY_CONSOLE)
|
|
|
|
conswitchp = &dummy_con;
|
|
|
|
#endif
|
|
|
|
#endif
|
2015-03-17 16:55:12 +07:00
|
|
|
if (boot_args[1] || boot_args[2] || boot_args[3]) {
|
|
|
|
pr_err("WARNING: x1-x3 nonzero in violation of boot protocol:\n"
|
|
|
|
"\tx1: %016llx\n\tx2: %016llx\n\tx3: %016llx\n"
|
|
|
|
"This indicates a broken bootloader or old kernel\n",
|
|
|
|
boot_args[1], boot_args[2], boot_args[3]);
|
|
|
|
}
|
2012-03-05 18:49:27 +07:00
|
|
|
}
|
|
|
|
|
2013-05-14 16:51:18 +07:00
|
|
|
static int __init arm64_device_init(void)
|
2013-02-08 19:18:15 +07:00
|
|
|
{
|
2015-01-13 03:48:54 +07:00
|
|
|
of_iommu_init();
|
2013-05-14 16:51:18 +07:00
|
|
|
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
|
2013-02-08 19:18:15 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2014-04-25 21:31:45 +07:00
|
|
|
arch_initcall_sync(arm64_device_init);
|
2013-02-08 19:18:15 +07:00
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
static int __init topology_init(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for_each_possible_cpu(i) {
|
2014-07-16 22:32:44 +07:00
|
|
|
struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
|
2012-03-05 18:49:27 +07:00
|
|
|
cpu->hotpluggable = 1;
|
|
|
|
register_cpu(cpu, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
subsys_initcall(topology_init);
|
|
|
|
|
|
|
|
static const char *hwcap_str[] = {
|
|
|
|
"fp",
|
|
|
|
"asimd",
|
2013-08-13 21:57:53 +07:00
|
|
|
"evtstrm",
|
2013-12-17 04:04:36 +07:00
|
|
|
"aes",
|
|
|
|
"pmull",
|
|
|
|
"sha1",
|
|
|
|
"sha2",
|
|
|
|
"crc32",
|
2012-03-05 18:49:27 +07:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
arm64: Fix up /proc/cpuinfo
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-10-24 20:56:40 +07:00
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
static const char *compat_hwcap_str[] = {
|
|
|
|
"swp",
|
|
|
|
"half",
|
|
|
|
"thumb",
|
|
|
|
"26bit",
|
|
|
|
"fastmult",
|
|
|
|
"fpa",
|
|
|
|
"vfp",
|
|
|
|
"edsp",
|
|
|
|
"java",
|
|
|
|
"iwmmxt",
|
|
|
|
"crunch",
|
|
|
|
"thumbee",
|
|
|
|
"neon",
|
|
|
|
"vfpv3",
|
|
|
|
"vfpv3d16",
|
|
|
|
"tls",
|
|
|
|
"vfpv4",
|
|
|
|
"idiva",
|
|
|
|
"idivt",
|
|
|
|
"vfpd32",
|
|
|
|
"lpae",
|
|
|
|
"evtstrm"
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char *compat_hwcap2_str[] = {
|
|
|
|
"aes",
|
|
|
|
"pmull",
|
|
|
|
"sha1",
|
|
|
|
"sha2",
|
|
|
|
"crc32",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
#endif /* CONFIG_COMPAT */
|
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
static int c_show(struct seq_file *m, void *v)
|
|
|
|
{
|
arm64: Fix up /proc/cpuinfo
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-10-24 20:56:40 +07:00
|
|
|
int i, j;
|
2012-03-05 18:49:27 +07:00
|
|
|
|
|
|
|
for_each_online_cpu(i) {
|
arm64: Fix up /proc/cpuinfo
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-10-24 20:56:40 +07:00
|
|
|
struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
|
|
|
|
u32 midr = cpuinfo->reg_midr;
|
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
/*
|
|
|
|
* glibc reads /proc/cpuinfo to determine the number of
|
|
|
|
* online processors, looking for lines beginning with
|
|
|
|
* "processor". Give glibc what it expects.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
seq_printf(m, "processor\t: %d\n", i);
|
|
|
|
#endif
|
2014-09-01 21:47:19 +07:00
|
|
|
|
arm64: Fix up /proc/cpuinfo
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-10-24 20:56:40 +07:00
|
|
|
/*
|
|
|
|
* Dump out the common processor features in a single line.
|
|
|
|
* Userspace should read the hwcaps with getauxval(AT_HWCAP)
|
|
|
|
* rather than attempting to parse this, but there's a body of
|
|
|
|
* software which does already (at least for 32-bit).
|
|
|
|
*/
|
|
|
|
seq_puts(m, "Features\t:");
|
|
|
|
if (personality(current->personality) == PER_LINUX32) {
|
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
for (j = 0; compat_hwcap_str[j]; j++)
|
|
|
|
if (compat_elf_hwcap & (1 << j))
|
|
|
|
seq_printf(m, " %s", compat_hwcap_str[j]);
|
|
|
|
|
|
|
|
for (j = 0; compat_hwcap2_str[j]; j++)
|
|
|
|
if (compat_elf_hwcap2 & (1 << j))
|
|
|
|
seq_printf(m, " %s", compat_hwcap2_str[j]);
|
|
|
|
#endif /* CONFIG_COMPAT */
|
|
|
|
} else {
|
|
|
|
for (j = 0; hwcap_str[j]; j++)
|
|
|
|
if (elf_hwcap & (1 << j))
|
|
|
|
seq_printf(m, " %s", hwcap_str[j]);
|
|
|
|
}
|
|
|
|
seq_puts(m, "\n");
|
|
|
|
|
|
|
|
seq_printf(m, "CPU implementer\t: 0x%02x\n",
|
|
|
|
MIDR_IMPLEMENTOR(midr));
|
|
|
|
seq_printf(m, "CPU architecture: 8\n");
|
|
|
|
seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
|
|
|
|
seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
|
|
|
|
seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
|
|
|
|
}
|
2014-09-01 21:47:19 +07:00
|
|
|
|
2012-03-05 18:49:27 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *c_start(struct seq_file *m, loff_t *pos)
|
|
|
|
{
|
|
|
|
return *pos < 1 ? (void *)1 : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
|
|
|
|
{
|
|
|
|
++*pos;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void c_stop(struct seq_file *m, void *v)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct seq_operations cpuinfo_op = {
|
|
|
|
.start = c_start,
|
|
|
|
.next = c_next,
|
|
|
|
.stop = c_stop,
|
|
|
|
.show = c_show
|
|
|
|
};
|