> * There also appears to be a "cpu" section in chrome://system and that won't work.  I seem to remember everyone always yells right before ship about that being blank and then everyone panics, so maybe we should find something to put there ahead of time?

https://chromium.googlesource.com/chromiumos/platform2/+/04211c61ef8d1f9d680ee9db5b30ad0855f4b99e/debugd/src/log_tool.cc#91

That's just 'uname -p'.

If it helps, my gLinux (i.e., Debian testing) system also says "unknown" for this :) It's basically a nonstandard property:

https://www.gnu.org/software/coreutils/manual/html_node/uname-invocation.html

  ‘-p’
  ‘--processor’
  Print the processor type (sometimes called the instruction set architecture or ISA). Print ‘unknown’ if this information is not available. Note this is non-portable (even across GNU/Linux distributions).

@2: Ah, thanks for the pointer.  We should try to update the log_tool source to show _something_ since I think I've seen panics in at least 2 previous products because it said "unknown" here.

BTW: anyone want to grab ownership of this?

I've got one of those -- we should just drop those fields:

https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1232234

> I've seen panics in at least 2 previous products because it said "unknown" here.

RK3399 still says "unknown" for "hw_platform" (uname -i), so the panics can't have been *too* bad :)

lets drop the custom kernel patch

we still include /proc/cpuinfo which is a supserset of "cpu"

i'll reiterate that, if aarch64 has some path under /sys or /proc that we can get the current CPU name, i can change Gentoo's coreutils accordingly.  i don't have an aarch64 system on hand atm to check.

> RK3399 still says "unknown" for "hw_platform" (uname -i), so the panics can't have been *too* bad :)

Yeah, I think it was marketing folks who thought end users would be upset that they couldn't see their CPU name.  I can dig up history if it matters, but I don't think it really does.

===

> i'll reiterate that, if aarch64 has some path under /sys or /proc that we can get the current CPU name

On ARM64 we weren't really getting the cpu name anyway.  We were getting "ARMv8 Processor rev 13 (v8l)" which is much closer to the model.

I don't know that we have anywhere easy to get something closer to a marketing name for a CPU.  Let's see, I guess there's the device tree though.  That could give you something sorta interesting, but you'd have to figure out how to deal with it:

for path in /sys/devices/system/cpu/cpu*/of_node; do
  hexdump -C ${path}/compatible
done


 On cheza:

00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d
00000000  71 63 6f 6d 2c 6b 72 79  6f 33 38 35 00           |qcom,kryo385.|
0000000d

On kevin:

00000000  61 72 6d 2c 63 6f 72 74  65 78 2d 61 35 33 00 61  |arm,cortex-a53.a|
00000010  72 6d 2c 61 72 6d 76 38  00                       |rm,armv8.|
00000019
00000000  61 72 6d 2c 63 6f 72 74  65 78 2d 61 35 33 00 61  |arm,cortex-a53.a|
00000010  72 6d 2c 61 72 6d 76 38  00                       |rm,armv8.|
00000019
00000000  61 72 6d 2c 63 6f 72 74  65 78 2d 61 35 33 00 61  |arm,cortex-a53.a|
00000010  72 6d 2c 61 72 6d 76 38  00                       |rm,armv8.|
00000019
00000000  61 72 6d 2c 63 6f 72 74  65 78 2d 61 35 33 00 61  |arm,cortex-a53.a|
00000010  72 6d 2c 61 72 6d 76 38  00                       |rm,armv8.|
00000019
00000000  61 72 6d 2c 63 6f 72 74  65 78 2d 61 37 32 00 61  |arm,cortex-a72.a|
00000010  72 6d 2c 61 72 6d 76 38  00                       |rm,armv8.|
00000019
00000000  61 72 6d 2c 63 6f 72 74  65 78 2d 61 37 32 00 61  |arm,cortex-a72.a|
00000010  72 6d 2c 61 72 6d 76 38  00                       |rm,armv8.|
00000019

Upstream suggested parsing cpuinfo and having a lookup table:

https://patchwork.kernel.org/patch/9707263/#20418533
"""
This information can be derived from the MIDR fields exposed in
/proc/cpuninfo

e.g.

CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0xd07
CPU revision    : 2

... is a Cortex-A57.
"""

Which basically means: no one's going to do this :)

Would this theoretical lookup table exist in coreutils? Has anyone ever tried to send such a patch to coreutils?

> Has anyone ever tried to send such a patch to coreutils?

yes and they have no interest in it

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/bfc6bed1f0cc90fa93b376abf95bf179b56b418f

commit bfc6bed1f0cc90fa93b376abf95bf179b56b418f
Author: Brian Norris <briannorris@chromium.org>
Date: Wed Sep 19 15:59:30 2018

debugd: drop nonstandard uname fields from log_tool

Feedback reports, chrome://system, etc., don't really need these fields
split out -- they're already available implicitly in the 'uname' entry
(which includes `uname -a`) if they're available at all. But they are
non-standard fields anyway, and aren't supported by all architectures
(e.g., arm64):

  https://www.gnu.org/software/coreutils/manual/html_node/uname-invocation.html

  "Note this is non-portable (even across GNU/Linux distributions)."

BUG=chromium:885343
TEST=build; also check output of `generate_logs`, chrome://system, and
     similar

Change-Id: I094cce66298cb5c08eca41bdc96c0044ae620ed4
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1232234
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/bfc6bed1f0cc90fa93b376abf95bf179b56b418f/debugd/src/log_tool.cc

An autotest fix is at <https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1257578>.  It's kinda ugly but maybe OK?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/7978d02a2fc7b00d2f641918a07059b8451d50f4

commit 7978d02a2fc7b00d2f641918a07059b8451d50f4
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Oct 05 18:37:45 2018

utils: Update our house of cards arm detection to detect Qualcomm SoCs

There's a whole bunch of fragile logic in autotest to try to detect
which type of ARM device we're on.  Let's update this fragile logic to
properly detect Qualcomm boards now.

A few notes:
* I've totally revamped get_cpu_arch() to rely on 'uname -m' which is
  much more robust than trying to manually grok /proc/cpuinfo.
* Grepping through '/sys/firmware/devicetree/base/compatible' for an
  SoC name isn't really guaranteed to work.  We always include the SoC
  name there on our boards, but I don't think upstream has any
  guarantee.  Of course I'm not sure I know of anything better.

BUG=chromium:885343
TEST=graphics_Gralloc now complains about no "qualcomm" support on cheza
TEST=graphics_Gralloc still passes on kevin / veyron_jerry

Change-Id: I7726fdbfc92f981172bdc3cf5364fec12de3eab6
Reviewed-on: https://chromium-review.googlesource.com/1257578
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/7978d02a2fc7b00d2f641918a07059b8451d50f4/client/bin/utils.py