Hi,
Here's quickly cleaned notes from etherpad:
People affiliated with at least Debian, Fedora, OpenEmbedded,
OpenSUSE, Redhat, Ubuntu and Yocto were present and voiced opinions.
Kernel:
- Good: most Interesting platforms mainline now
- Qualcomm IFC (in progress), raspi2, hikey probably mostly wanted?
- Bad: sometimes mainline kernels features limited "it boots to serial console"
- OEMs still put their own kernels on everything they ship
Kernel testing:
- http://kernelci.org is gaining traction by kernel devs, but so far
tests mostly defconfigs (which are rather minimal)
- all options needed by the new pid 1 and other hard requirements to
boot a modern distro should be in the arm64 defconfig and multi_v*
configs
- if not, kernel developers present think adding them is definetly OK
- make allmodconfig testing at kernelci.orghttp://kernelci.org/build/mainline/kernel/v3.19-rc7-200-gda2d96d3aa18/defco…
- TODO: make allmodconfig boot!
- ACTION Koen volunteered to put some distro-style config fragments
into the kernel
Kernel command line options
- Now firmware can tell where console= is instead of defining in command
- https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
- Similar setting exists for ACPI (SPCR)
- Userspace support needs to be done
- ACTION device tree files need to get chosen/stdout-path added
- Systemd should magically use that as serial console if
CONFIG_FHANDLE is enabled
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
- 32bit binaries compiled with latest binutils work with 64k pages
(trunk, so not in 2.25)
- 20-30 packages already fixed.
- probably more things making assumptions (BTRFS was glaring example)
Kernel trapping for old instructions not supported on v8. (mostly
android). SWP, SETEND, cp15 barriers.
- Some current packages have SWP due to embedded libatomicops. being fixed.
- need to make the personality do the right thing for chroots. linux32
says armv8l Would be nice to have a armv8l for building (or just fix
things)
- coreutils repeats uname name (aarch64 x3 - could be improved) Riku
will look into
32bit kernels on 64bit machines?
- Works with QEMU, but you don't get KVM acceleration.
- has worked on XEN - should still be working. IJC will fix if not.
Graphics
- framebuffer/drm/hdmi/panel drivers often half-done
- should DRM be built as modules or builtin?
- graphics developers prefer built-in, server people want them as modules...
- libdrm: enable tegra, exynos, freedreno, omap
- conclusion: nobody in the session was confident enough to take lead
on graphics issues
Applications still needing porting?
- golang in progress. Should arrive in 1.5 (release in August)
- gccgo also works for docker (esp gcc5)
- ocaml already fixed upstream
- mogodb, libv8, nodejs is tangled. (only new libv8 has arm64
support, mongodb forked the old one - big job to update). nodejs .12
needs to be released. ubuntu still maintains external libv8. suse gave
up. some pressure to stabilise ABI would help (and stop everyone
embedding copies)
- mono is done/built, still needs upstreaming ("some legal
issues"). $someone should build Microsofts code?
- GHCi - give some people a board, and wait longer
- freepascal, etc have bugs - time to tell upstreams that hardware exist
maybe hand out some boards to people to get stuff done.
Is booting solved problem?
- Document requirements/recommendations for OEMS
- Common requirements:
- boot into EL2 / Hyp mode!
- SPCR is serial port console redirection. No problem to
implement.(MS promise)
- there are two sets of EFIvars. You need to mount the newer
psedofilesystem (efivarfs). This is kernel build option.
ILP32 (some network people want it). Distros don't want to support
it!. Demo OE in a container and tell them to use that. (ssh broken on
ILP32) has different syscalls. Are they turned on?
Post-meeting discussion:
- Monthly Cross-Distro Google hangout planned (ACTION Riku)
Hi; this email is intended mainly to raise awareness of an
issue which some people here might care about but be currently
unaware of, and to see if anybody already has a plan to deal with it.
The VM System Specification for ARM Processors:
http://www.linaro.org/docs/vm-system-specification-arm-processors/
defines the contract between a VM implementaton (like KVM/QEMU or
Xen) and an image to run on it (like a distro's ISO installer image).
This specification mandates that we boot by treating the image as
a UEFI ISO image with a FAT32 filesystem. So the VM (and QEMU in
particular) needs to have a custom UEFI firmware image if it wants to
support booting these images, and that UEFI needs to understand FAT32.
Unfortunately the Tianocore UEFI implementation, though mostly BSD
licensed, has a critical piece which is not. The FAT filesystem driver
license is "BSD plus may only be used as part of EFI"; full license
text on this web page:
http://tianocore.sourceforge.net/wiki/Edk2-fat-driver
This is redistributable, but obviously not Free by either the OSI or
Debian Free Software Guidelines definitions. Accordingly it would have
to go in Debian "non-free" and other distro equivalents. (This is
exactly where the x86 Tianocore-derived UEFI implementation, OVMF,
is currently distributed.)
So the default place we're likely to end up if nobody takes any
action is that to use typically distributed ISO images with QEMU
the end-user will need to install the UEFI blob on their host system
from non-free or other distro equivalent (or download it themselves
from the upstream Tianocore website, perhaps).
The question then is: is this outcome unacceptable or undesirable
to anybody? Is anybody planning some other approach?
Some notes:
(1) The VM spec doesn't require that the VM supports *only* the UEFI
ISO image format, so it's not the case that QEMU is useless
without the UEFI firmware. For instance, you could have a Free UEFI
variant which omitted the FAT driver, and pick one of the other
filesystem types that Tianocore supports for your distro's CD images.
(Obviously those images would then probably not be able to boot on h/w,
and conversely "standard" images wouldn't boot on the Free-UEFI.)
(2) When describing or proposing a solution to this it's important
to be clear about the distinction between copyright licensing issues
and patent issues. The problem with the tianocore FAT driver is its
copyright license. Anybody proposing a reimplementation with a different
license needs to consider whether they run into patent problems.
(I'm not going to state an opinion either way about whether such
a reimplementation would potentially intersect any FAT related
patents or whether the MS license for purposes of implementing EFI
would avoid problems or not.)
(3) I imagine that a lot of this ground has already been covered
when considering x86 and OVMF; the only difference for ARM is that
there's no standard Free-licensed alternative firmware, so the problem
is a little more acute. If anybody has a pointer to previous
discussion or conclusions that might save us some argument.
(4) If the "default outcome" is actually at least not unacceptable
to anybody then we can of course simply do nothing...
thanks
-- PMM
Hi All,
This is just a heads-up that we've run into quite a horrible crash +
data corruption issue with MariaDB when running sysbench with a large
number of threads on a couple of AArch64 platforms.
I believe the problem can be attributed to the code used to release
the custom mutexes used by the storage engine.
I have logged a ticket (and attached an emergency fix) here:
https://mariadb.atlassian.net/browse/MDEV-6615
Cheers,
--
Steve Capper
I am trying to set up an Eclipse/CDT development environment on an
Ubuntu 14.04 (64 bit) PC to cross-compile and debug software for a
RK3188 Arm platform.
To this end, I downloaded
https://releases.linaro.org/12.10/components/toolchain/binaries/gcc-linaro-…,
expanded and rearranged the distribution to simplify the path to the
tools to /home/bob/Development/platforms/arm-linux-gnueabihf/bin.
With this arrangement I was able to compile a HelloWorld program without
any difficulty and the executable ran on the RK3188 Arm platform and
performed as intended.
I also copied gdbserver
(/home/bob/Development/platforms/arm-linux-gnueabihf/arm-linux-gnueabihf/debug-root/usr/bin/gdbserver)
to the RK3188 Arm platform and it could then be started remotely through
Eclipse. At least, gdbserver was assigned a pid and output "Listening on
port 2345". So far so good.
However, Eclipse was unable to launch arm-linux-gnueabihf-gdb;
outputting an error, instead:
"Could not determine GDB version using command:
/home/bob/Development/platforms/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb
--version
/home/bob/Development/platforms/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb:
error while loading shared libraries: libncurses.so.5: cannot open
shared object file: No such file or directory"
I tried running arm-linux-gnueabihf-gdb from the UpuntuPC's command line
and got a similar error:
bob@myUbuntuPC:~$ sudo
Development/platforms/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb --version
Development/platforms/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb:
error while loading shared libraries: libncurses.so.5: cannot open
shared object file: No such file or directory
Can anyone point me in the right direction?
BobF
3.18-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/kernel/setup.c | 94 ++++++++++++++++++++++++++++++++++------------
1 file changed, 71 insertions(+), 23 deletions(-)
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <linux/efi.h>
+#include <linux/personality.h>
#include <asm/fixmap.h>
#include <asm/cpu.h>
@@ -79,7 +80,6 @@ unsigned int compat_elf_hwcap2 __read_mo
#endif
static const char *cpu_name;
-static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
/*
@@ -311,8 +311,6 @@ static void __init setup_machine_fdt(phy
while (true)
cpu_relax();
}
-
- machine_name = of_flat_dt_get_machine_name();
}
/*
@@ -449,14 +447,50 @@ 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"
+};
+
+static const char *compat_hwcap2_str[] = {
+ "aes",
+ "pmull",
+ "sha1",
+ "sha2",
+ "crc32",
+ NULL
+};
+#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
@@ -465,24 +499,38 @@ 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]);
+
+ 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, "Hardware\t: %s\n", machine_name);
+ 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));
+ }
return 0;
}
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
