3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <mark.rutland(a)arm.com>
commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.
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(a)google.com>
Cc: Ian Campbell <ijc(a)hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: cross-distro(a)lists.linaro.org
Cc: linux-api(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/cputype.h | 2
arch/arm64/kernel/setup.c | 99 ++++++++++++++++++++++++++++-----------
arch/arm64/kernel/smp.c | 5 +
3 files changed, 80 insertions(+), 26 deletions(-)
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -77,6 +77,8 @@ static inline u32 __attribute_const__ re
return read_cpuid(CTR_EL0);
}
+void cpuinfo_store_cpu(void);
+
#endif /* __ASSEMBLY__ */
#endif
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
+#include <linux/personality.h>
#include <asm/cputype.h>
#include <asm/elf.h>
@@ -73,7 +74,6 @@ unsigned int compat_elf_hwcap __read_mos
#endif
static const char *cpu_name;
-static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
/*
@@ -193,6 +193,19 @@ static void __init smp_build_mpidr_hash(
}
#endif
+struct cpuinfo_arm64 {
+ struct cpu cpu;
+ u32 reg_midr;
+};
+
+static DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
+
+void cpuinfo_store_cpu(void)
+{
+ struct cpuinfo_arm64 *info = this_cpu_ptr(&cpu_data);
+ info->reg_midr = read_cpuid_id();
+}
+
static void __init setup_processor(void)
{
struct cpu_info *cpu_info;
@@ -213,6 +226,8 @@ static void __init setup_processor(void)
sprintf(init_utsname()->machine, ELF_PLATFORM);
elf_hwcap = 0;
+ cpuinfo_store_cpu();
+
/*
* ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
* The blocks we test below represent incremental functionality
@@ -257,8 +272,6 @@ static void __init setup_machine_fdt(phy
while (true)
cpu_relax();
}
-
- machine_name = of_flat_dt_get_machine_name();
}
/*
@@ -363,14 +376,12 @@ static int __init arm64_device_init(void
}
arch_initcall(arm64_device_init);
-static DEFINE_PER_CPU(struct cpu, cpu_data);
-
static int __init topology_init(void)
{
int i;
for_each_possible_cpu(i) {
- struct cpu *cpu = &per_cpu(cpu_data, i);
+ struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
cpu->hotpluggable = 1;
register_cpu(cpu, i);
}
@@ -391,14 +402,41 @@ static const char *hwcap_str[] = {
NULL
};
+#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"
+};
+#endif /* CONFIG_COMPAT */
+
static int c_show(struct seq_file *m, void *v)
{
- int i;
-
- seq_printf(m, "Processor\t: %s rev %d (%s)\n",
- cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+ int i, j;
for_each_online_cpu(i) {
+ struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
+ u32 midr = cpuinfo->reg_midr;
+
/*
* glibc reads /proc/cpuinfo to determine the number of
* online processors, looking for lines beginning with
@@ -407,24 +445,33 @@ static int c_show(struct seq_file *m, vo
#ifdef CONFIG_SMP
seq_printf(m, "processor\t: %d\n", i);
#endif
- }
-
- /* dump out the processor features */
- seq_puts(m, "Features\t: ");
-
- for (i = 0; hwcap_str[i]; i++)
- if (elf_hwcap & (1 << i))
- seq_printf(m, "%s ", hwcap_str[i]);
-
- seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
- seq_printf(m, "CPU architecture: AArch64\n");
- seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15);
- seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff);
- seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
- seq_puts(m, "\n");
+ /*
+ * 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]);
+#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, "Hardware\t: %s\n", machine_name);
+ seq_printf(m, "CPU implementer\t: 0x%02x\n", (midr >> 24));
+ seq_printf(m, "CPU architecture: 8\n");
+ seq_printf(m, "CPU variant\t: 0x%x\n", ((midr >> 20) & 0xf));
+ seq_printf(m, "CPU part\t: 0x%03x\n", ((midr >> 4) & 0xfff));
+ seq_printf(m, "CPU revision\t: %d\n\n", (midr & 0xf));
+ }
return 0;
}
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -148,6 +148,11 @@ asmlinkage void secondary_start_kernel(v
cpu_ops[cpu]->cpu_postboot();
/*
+ * Log the CPU info before it is marked online and might get read.
+ */
+ cpuinfo_store_cpu();
+
+ /*
* Enable GIC and timers.
*/
notify_cpu_starting(cpu);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <mark.rutland(a)arm.com>
commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.
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(a)google.com>
Cc: Ian Campbell <ijc(a)hellion.org.uk>
Cc: Serban Constantinescu <serban.constantinescu(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: cross-distro(a)lists.linaro.org
Cc: linux-api(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas(a)arm.com>
[Mark: backport to v3.10.x]
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/cputype.h | 2
arch/arm64/kernel/setup.c | 100 +++++++++++++++++++++++++++++----------
arch/arm64/kernel/smp.c | 5 +
3 files changed, 82 insertions(+), 25 deletions(-)
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -74,6 +74,8 @@ static inline u32 __attribute_const__ re
return read_cpuid(ID_CTR_EL0);
}
+void cpuinfo_store_cpu(void);
+
#endif /* __ASSEMBLY__ */
#endif
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
+#include <linux/personality.h>
#include <asm/cputype.h>
#include <asm/elf.h>
@@ -97,6 +98,19 @@ void __init early_print(const char *str,
printk("%s", buf);
}
+struct cpuinfo_arm64 {
+ struct cpu cpu;
+ u32 reg_midr;
+};
+
+static DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
+
+void cpuinfo_store_cpu(void)
+{
+ struct cpuinfo_arm64 *info = this_cpu_ptr(&cpu_data);
+ info->reg_midr = read_cpuid_id();
+}
+
static void __init setup_processor(void)
{
struct cpu_info *cpu_info;
@@ -127,6 +141,8 @@ static void __init setup_machine_fdt(phy
struct boot_param_header *devtree;
unsigned long dt_root;
+ cpuinfo_store_cpu();
+
/* Check we have a non-NULL DT pointer */
if (!dt_phys) {
early_print("\n"
@@ -290,14 +306,12 @@ static int __init arm64_device_init(void
}
arch_initcall(arm64_device_init);
-static DEFINE_PER_CPU(struct cpu, cpu_data);
-
static int __init topology_init(void)
{
int i;
for_each_possible_cpu(i) {
- struct cpu *cpu = &per_cpu(cpu_data, i);
+ struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
cpu->hotpluggable = 1;
register_cpu(cpu, i);
}
@@ -312,14 +326,41 @@ static const char *hwcap_str[] = {
NULL
};
+#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"
+};
+#endif /* CONFIG_COMPAT */
+
static int c_show(struct seq_file *m, void *v)
{
- int i;
-
- seq_printf(m, "Processor\t: %s rev %d (%s)\n",
- cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+ int i, j;
for_each_online_cpu(i) {
+ struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
+ u32 midr = cpuinfo->reg_midr;
+
/*
* glibc reads /proc/cpuinfo to determine the number of
* online processors, looking for lines beginning with
@@ -328,27 +369,36 @@ static int c_show(struct seq_file *m, vo
#ifdef CONFIG_SMP
seq_printf(m, "processor\t: %d\n", i);
#endif
- seq_printf(m, "BogoMIPS\t: %lu.%02lu\n\n",
+ seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
loops_per_jiffy / (500000UL/HZ),
loops_per_jiffy / (5000UL/HZ) % 100);
- }
-
- /* dump out the processor features */
- seq_puts(m, "Features\t: ");
- for (i = 0; hwcap_str[i]; i++)
- if (elf_hwcap & (1 << i))
- seq_printf(m, "%s ", hwcap_str[i]);
-
- seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
- seq_printf(m, "CPU architecture: AArch64\n");
- seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15);
- seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff);
- seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
-
- seq_puts(m, "\n");
-
- seq_printf(m, "Hardware\t: %s\n", machine_name);
+ /*
+ * 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]);
+#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 >> 24));
+ seq_printf(m, "CPU architecture: 8\n");
+ seq_printf(m, "CPU variant\t: 0x%x\n", ((midr >> 20) & 0xf));
+ seq_printf(m, "CPU part\t: 0x%03x\n", ((midr >> 4) & 0xfff));
+ seq_printf(m, "CPU revision\t: %d\n\n", (midr & 0xf));
+ }
return 0;
}
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -200,6 +200,11 @@ asmlinkage void __cpuinit secondary_star
raw_spin_unlock(&boot_lock);
/*
+ * Log the CPU info before it is marked online and might get read.
+ */
+ cpuinfo_store_cpu();
+
+ /*
* OK, now it's safe to let the boot CPU continue. Wait for
* the CPU migration code to notice that the CPU is online
* before we continue.
Hi everyone,
Since cross-distribution meetings at Linaro Connect have been popular,
we are continuing the tradition and having a session[1] in Linaro Connect next
week.
https://hkg15.pathable.com/meetings/250818
The event is on Wednesday 11 February, 14.00 hong kong time (06.00 UTC).
We'll try to get session broadcasted on google hangouts for remote
participation, but I don't have the link at hand yet.
If you have anything specific in your mind, feel free to reply to this mail to
cross-distribution list, and I'll get it added to agenda.
Riku
Hi all,
Current snapshots of Debian Jessie installer snapshots, as well as the
kernel packages, support providing the system console information via
the chosen node 'stdout-path' property instead of on the command line.
This is enabled by two patches backported from 3.17 to Jessie's 3.16
kernel, together with three small patches currently in Linus's tree,
awaiting 3.19-rc1.
The first two are actually sufficient for models, but the additional
ones are required to be able to specify options (like baudrate).
The commits are:
>From 3.16
a208ffd251d08ed7ba6bdf3ae1e423373fb12d3d - of: Enable console on
serial ports specified by /chosen/stdout-path
3482f2c52b77bf6596e24aae82e204a0603eba66 - of: Create
of_console_check() for selecting a console specified in /chosen
>From current Linus
2a9d832cc9aae21ea827520fef635b6c49a06c6d - of: Add bindings for
chosen node, stdout-path
75c28c09af99a0db0ccd8b4395469761aa736543 - of: add optional options
parameter to of_find_node_by_path()
7914a7c5651a51617d952e8fa745000ed8c4f001 - of: support passing console
options with stdout-path
Linaro 2014.12 UEFI release sets this option for FVP/Foundation Base
models.
QEMU 2.2 does the same for all (?) arm64 platforms.
ACPI platforms will be able to do something similar with SPCR.
/
Leif
I am having difficulty figuring out the include and library paths to
compile hello.cpp with cross-toolchain arm-linux-gnueabihf installed via
'sudo apt-get install gcc-arm-linux-gnueabihf' on Ubuntu 14.04 PC
I can set up Eclipse (Luna) to build hello.c, but not hello.cpp
hello.c search paths:
Cross-tools path: /usr/bin
tools prefix: arm-linux-gnueabihf-
compilergcc
linker gcc
assembler as
include /usr/arm-linux-gnueabihf/include
libraries /usr/arm-linux-gnueabihf/lib
hello.cpp search paths:
Cross-tools path: /usr/bin
tools prefix: arm-linux-gnueabihf-
compilercpp
linker cpp
assembler as
include /usr/arm-linux-gnueabihf/include
libraries /usr/arm-linux-gnueabihf/lib
Build Output (-v):
21:14:27 **** Build of configuration Debug for project rockchip_hello ****
make all
Building file: ../src/rockchip_hello.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-cpp -I/usr/arm-linux-gnueabihf/include -O0 -g3 -Wall
-fmessage-length=0 -print-prog-name=cc1plus -v -MMD -MP
-MF"src/rockchip_hello.d" -MT"src/rockchip_hello.d" -o
"src/rockchip_hello.o" "../src/rockchip_hello.cpp"
Using built-in specs.
cc1plus
COLLECT_GCC=arm-linux-gnueabihf-cpp
Finished building: ../src/rockchip_hello.cpp
Building target: rockchip_hello
Invoking: Cross G++ Linker
arm-linux-gnueabihf-cpp -L/usr/arm-linux-gnueabihf/lib -o
"rockchip_hello" ./src/rockchip_hello.o
arm-linux-gnueabihf-cpp: error: ./src/rockchip_hello.o: No such file or
directory
arm-linux-gnueabihf-cpp: warning: ‘-x c’ after last input file has no effect
arm-linux-gnueabihf-cpp: fatal error: no input files
compilation terminated.
make: *** [rockchip_hello] Error 4
21:14:27 Build Finished (took 65ms)
Hi folks,
As a heads-up, there's a long standing bug in the way Firefox handles
register assignment in XPCOM for 32-bit ARM:
https://bugzilla.mozilla.org/show_bug.cgi?id=1050258
The symptoms are random data corruption and crashes.
(details of bug and fix in the link above).
Whilst upstream go through the motions of getting this fix merged, I
would encourage you to pull in the fix for now into your packages (or
at least keep an eye on this bug report).
Cheers,
--
Steve
Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a
manner which prevents some otherwise portable applications from
functioning as expected. Specifically, the "Features" line describes the
64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for
certain applications which attempt to parse /proc/cpuinfo to detect
features rather than directly using the hwcaps exposed via auxval.
Additionally, the arm64 /proc/cpuinfo format only provides identifying
information for a single CPU (unlike 32-bit), which is problematic for
systems with heterogeneous CPUs (i.e. big.LITTLE).
This patch attempts to solve both issues. I believe the contentious part
is what to do with the Features line, and for that there are a number of
possibilities:
[a] Only print the 64-bit hwcaps
This would match our current behaviour. However certain 32-bit
applications will not detect CPU features correctly, and could fail
to launch. The appropriate hwcaps are available in auxval, but this
will not be of help to existing binaries.
[b] Append the 64-bit and 32-bit hwcaps
This would allow for a consistent format. However, some
human-readable hwcap names have been reused for analogous
instruction set features (e.g. "aes") despite 32-bit and 64-bit
instruction set support being largely unrelated per the
architecture. This could lead to applications mis-detecting
instruction set support on some CPUs in future, and may be
misleading to a casual reader.
[c] Print different hwcaps for compat tasks
This would allow for 32-bit and 64-bit applications to function
correctly. Having the format differ depending on the instruction set
of the application reading /proc/cpuinfo may be misleading in some
cases (e.g. a human using a 32-bit cat to read /proc/cpuinfo on a
64-bit system).
[d] Print different hwcaps dependent on the personality.
This would allow for 32-bit and 64-bit applications to function
correctly, but for some 32-bit applications the personality would
need to be set explicitly by the user.
This patch takes approach d, aligning with what we do for
COMPART_UTS_NAME and COMPAT_ELF_PLATFORM function. Below are sample
output on a 32-bit platform and a 64-bit platform before and after this
patch (with and without LINUX32 personality).
Does it sound reasonable for the /proc/cpuinfo format to vary depending
on the task or personality?
Are there applications for which any of these strategies will not work?
Thanks,
Mark.
[1] arm, v3.17, Versatile Express A15x2 A7x3 coretile
---->8----
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc0f
CPU revision : 1
processor : 1
model name : ARMv7 Processor rev 1 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc0f
CPU revision : 1
processor : 2
model name : ARMv7 Processor rev 1 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 1
processor : 3
model name : ARMv7 Processor rev 1 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 1
processor : 4
model name : ARMv7 Processor rev 1 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 1
Hardware : ARM-Versatile Express
Revision : 0000
Serial : 0000000000000000
----8<----
[2] arm64, v3.17, Juno platform
---->8----
Processor : AArch64 Processor rev 0 (aarch64)
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: AArch64
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
Hardware : Juno
----8<----
[3] arm64, v3.17 + this patch, Juno platform
---->8----
processor : 0
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 1
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 2
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 3
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 4
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd07
CPU revision : 0
processor : 5
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd07
CPU revision : 0
----8<----
[4] arm64, v3.17 + this patch, Juno platform, LINUX32 personality
---->8----
processor : 0
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 1
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 2
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 3
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 0
processor : 4
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd07
CPU revision : 0
processor : 5
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd07
CPU revision : 0
----8<----
Mark Rutland (1):
arm64: Fix up /proc/cpuinfo
arch/arm64/kernel/setup.c | 96 +++++++++++++++++++++++++++++++++++------------
1 file changed, 72 insertions(+), 24 deletions(-)
--
1.9.1
So...
lshw (2.17) has the poor manners of scanning through /dev/mem looking
for SMBIOS tables, except for some architectures it excludes.
The correct behaviour would be to scan /dev/mem for i386/x86_64 only,
and otherwise get the SMBIOS entry point from the kernel's UEFI
information, if available.
I've submitted a patch to that effect upstream, but distros might want
to pick it up, since current upstream causes a kernel panic on certain
arm64 systems...:
http://www.ezix.org/project/ticket/666
/
Leif
> + seq_printf(m, "CPU implementer\t: 0x%02x\n",
> + MIDR_IMPLEMENTOR(midr));
Please can I request that MIDR_IMPLEMENTOR is renamed
MIDR_IMPLEMENTER.
I much prefer consistency - if I see "implementer" on screen I
expect a macro called MIDR_IMPLEMENTER to be invoked?
Bob
Hi All,
This is just a heads-up for anyone wanting to run btrfs with arm64.
When creating a new btrfs volume there is an option, sectorsize, which
is by default set to the current PAGE_SIZE. If one tries to mount
btrfs with a PAGE_SIZE != sectorsize, it will fail to mount and the
following will be found in dmesg:
BTRFS: Incompatible sector size
This should obviously be a cause for concern for those who intend to
create a btrfs volume running at one PAGE_SIZE (for instance an
installer kernel with 4K), and mounting it with a different PAGE_SIZE
(i.e. when running a server kernel with 64K).
There is some work being done by Chandan Rajendra at IBM to fix this:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/38808
I've not tried it yet, but will do soon.
Cheers,
--
Steve
