Create sysctl hw.model on ARM

[hyun_caffeinated.codes]

Summary

This patch adds 'hw.model' sysctl OID for ARM builds; this will report the generic chip name (e.g. ARM Cortex-A7).

[imp]

You need to do runtime CPU detection, and do it for all the other SoC families.

sys/arm/arm/identcpu-v6.c

59 ↗

(On Diff #39594)

just have this be a char *.

sys/arm/broadcom/bcm2835/bcm2835_machdep.c

76 ↗

(On Diff #39594)

extern char *

98 ↗

(On Diff #39594)

You have to do run time detections, this won't work.

[hyun_caffeinated.codes]

Pardon my naive questions; this is my first time handling non-userland code.

sys/arm/arm/identcpu-v6.c

59 ↗

(On Diff #39594)

I have referenced this from existing codes: sys/x86/x86/identcpu.c:156, sys/mips/mips/machdep.c:107, etc.
Changing to just char * means that I have to prepare the space for this string later. Wouldn't it be a safer choice to refrain from using malloc at the very beginning of the kernel? It looks like many other similar files are not using malloc that often.

sys/arm/broadcom/bcm2835/bcm2835_machdep.c

98 ↗

(On Diff #39594)

The sys/arm/arm/identcpu-v6.c file does contain runtime detection of the SoC, so I think the OID can be populated inside that very file using existing codes; then this hunk can be removed.
My intention was to show the specific SoC model (BCM2836) itself without showing generic core name like 'ARM Cortex-A7', but according to my further digging so far it is not possible to detect that in portable manner at this moment (or I did not study deeper).

By your opinion, do you think just showing generic ARM core name as hw.model would be suffice?

[andrew]

Why aren't you using the model property from the device tree?

[• ian]

I agree with Andrew... the approach here for FDT-based systems should be to use the model string from the FDT data. Note that that usually doesn't tell you anything about the CPU at all, it tells you about the overall board/system. I don't think that's a problem, it's just a bit different than the info available on x86 systems.

[• ian]

Replying to myself here... now I think I've changed my mind. Looking at all the other arches that support a hw.model sysctl (everything except arm and riscv), they all provide the specific CPU model, not an overall machine/system model; it's just a historical poor choice of name that we're stuck with.

So all in all, I agree with the originator's idea that the sysctl could be implemented in identcpu-v6.c using the existing code that prints the cpu info. That would give us a string like "ARM Cortex-A9 r2p10 (ECO: 0x00000000)".

It would actually be nice to export the board/system model string from FDT data as well, but we'd have to make a new hw.<something> oid name for it since the obvious name was already taken to mean "cpu type".

[imp]

In D14465#304163, @ian wrote:

It would actually be nice to export the board/system model string from FDT data as well, but we'd have to make a new hw.<something> oid name for it since the obvious name was already taken to mean "cpu type".

I once had a hw.board that I filled in from the FDT data. I thought I'd committed it, but it's not in the tree... I wonder which would be easier to do: find it on what might even be disks at Ian's employer and update it, or just redo from scratch... :)

[hyun_caffeinated.codes]

I am trying to reuse the existing core detection in sys/arm/arm/identcpu-v6.c:288 for filling out the OID.

@imp, does that 'changing to char *' still stands? Should I use malloc when filling that OID, or just leave it as is (char cpu_model[64])?

[hyun_caffeinated.codes]

Also, as @andrew and @ian suggested, I am thinking about this: first set the OID with what identify_arm_cpu() gives us, then later when FDT is available (inside initarm()?) add the board specific core name to the OID.

The only question is: is this an acceptable, legitimate approach?

[• ian]

All the existing arches use a static string array of either 64, 80, or 128 bytes. All the current arm models in the table, if formatted just like they print out now in dmesg, will fit in 44 bytes. My vote would be for the simplicity of static char cpu_model[64] and use snprintf() to format it for use in both printing in dmesg and for the sysctl.

[• ian]

I think we should handle the fdt-provided info with new OIDs. Hopefully we can do so in the common platform code somewhere.

On irc, imp suggested "hw.board" for the info from fdt's root-node model= property. But that's going to give a marketing name for the whole board, like Raspberry Pi or Wandboard, not the SoC name. I can't find any documentation about a standard property that gives the SoC name. It looks like it's often present as one of the strings in the compatible= property of the root node, but even that may not be universal.

[hyun_caffeinated.codes]

Use existing CPU detection in sys/arm/arm/identcpu-v6.c.

[hyun_caffeinated.codes]

Forgot to make cpu_model as static.

[• ian]

sys/arm/arm/identcpu-v6.c

292 ↗

(On Diff #39772)

this has to be sizeof(cpu_model), not a hard-coded 64.

[hyun_caffeinated.codes]

Refrain from using hard-coded length value; per the advice from @ian.

[hyun_caffeinated.codes]

Refrain from using hard-coded length value, part 2.

[• ian]

This looks good. Also, tested on a wandboard, works pefectly.

[imp]

my only concern is with 64-bytes being long enough.

[imp]

In D14465#304593, @imp wrote:

my only concern is with 64-bytes being long enough.

Ian reports on IRC that 44 bytes is enough for everything, so 64 should give us a good buffer.