ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
justache has joined #armlinux
Pali has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 252 seconds]
heat has quit [Ping timeout: 252 seconds]
amitk has joined #armlinux
prabhakarlad has quit [Ping timeout: 260 seconds]
iivanov has joined #armlinux
hanetzer has quit [Ping timeout: 248 seconds]
hanetzer has joined #armlinux
Nact has joined #armlinux
cleger has joined #armlinux
guillaume_g has joined #armlinux
hanetzer has quit [Ping timeout: 260 seconds]
Pali has joined #armlinux
hanetzer has joined #armlinux
amitk has quit [Ping timeout: 248 seconds]
amitk has joined #armlinux
amitk has quit [Ping timeout: 260 seconds]
Pali has quit [Ping timeout: 252 seconds]
amitk has joined #armlinux
frieder has joined #armlinux
mcoquelin has joined #armlinux
prabhakarlad has joined #armlinux
headless has joined #armlinux
apritzel has joined #armlinux
tomeu has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
<tomeu>
abelloni: do you happen to know what ISA uses the Cadence Tensilica VP6 in the mediatek SoCs?
apritzel has joined #armlinux
<maz>
tomeu: probably Xtensa.
<tomeu>
yeah, it's looking like that
<tomeu>
anybody knows how much knowledge is out there about its ISA? I see that Cadence sells a botched GCC with the backend being a separate blob
headless_ has joined #armlinux
headless has quit [Ping timeout: 246 seconds]
headless_ is now known as headless
iivanov has quit [Quit: Leaving...]
iivanov has joined #armlinux
sszy has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
iivanov has quit [Client Quit]
iivanov has joined #armlinux
ccaione has quit [Ping timeout: 246 seconds]
dianders has quit [Ping timeout: 246 seconds]
qyousef has quit [Ping timeout: 260 seconds]
sboyd has quit [Ping timeout: 246 seconds]
robher has quit [Ping timeout: 246 seconds]
pjw has quit [Ping timeout: 246 seconds]
broonie has quit [Ping timeout: 255 seconds]
Peng_Fan has quit [Ping timeout: 255 seconds]
sjg1 has quit [Read error: Connection reset by peer]
nathanchance has quit [Read error: Connection reset by peer]
robclark has quit [Read error: Connection reset by peer]
khilman has quit [Read error: Connection reset by peer]
NishanthMenon has quit [Read error: Connection reset by peer]
jlinton has quit [Read error: Connection reset by peer]
_alice has quit [Read error: Connection reset by peer]
khilman has joined #armlinux
dianders has joined #armlinux
Peng_Fan has joined #armlinux
robher has joined #armlinux
pjw has joined #armlinux
nathanchance has joined #armlinux
sjg1 has joined #armlinux
qyousef has joined #armlinux
NishanthMenon has joined #armlinux
_alice has joined #armlinux
ccaione has joined #armlinux
jlinton has joined #armlinux
sboyd has joined #armlinux
robclark has joined #armlinux
broonie has joined #armlinux
<arnd>
tomeu: I think the way that Xtensa works in general (unlike other gcc targets) is that you build a custom gcc that targets the specific set of instructions that are implemented in a particular design, since there are too many variations to express using compiler flags.
<arnd>
What I don't know if whether the Vision/Fusion/HiFi DSPs each are a specific instance that always use a particular ISA flavor or if 'VP6' only refers to a general design that could still require soc specific compiler backends to match the specific feature set.
wens has quit [Read error: Connection reset by peer]
bjdooks has quit [Ping timeout: 260 seconds]
bjdooks has joined #armlinux
wens has joined #armlinux
alpernebbi has quit [Remote host closed the connection]
<tomeu>
arnd: that's good info, thanks!
headless has quit [Ping timeout: 260 seconds]
headless has joined #armlinux
headless has quit [Quit: Konversation terminated!]
alpernebbi has joined #armlinux
ccaione has quit [Ping timeout: 260 seconds]
ccaione has joined #armlinux
robclark has quit [Ping timeout: 260 seconds]
sboyd has quit [Ping timeout: 260 seconds]
sboyd has joined #armlinux
robclark has joined #armlinux
alpernebbi has quit [Quit: alpernebbi]
hanetzer has quit [Ping timeout: 252 seconds]
hanetzer has joined #armlinux
viorel_suman has joined #armlinux
torez has joined #armlinux
wens has quit [Ping timeout: 260 seconds]
wens has joined #armlinux
alpernebbi has joined #armlinux
prabhakarlad has quit [Ping timeout: 260 seconds]
<robher>
marcan: you can put whatever you want into 'model'. For CPUs, DT is already more specific than the kernel. I don't see why we need something other than 'compatible' (which is already unused).
<marcan>
robher: What I'm looking for is a place for (separately) listing the 3 bits of information system info apps want to show separately: what machine you have, what SoC it has, and what CPU cores that SoC has.
<marcan>
in human-readable form
<marcan>
sticking all that into "model" in the root node is... not ideal
<marcan>
"compatible" is not a marketing formatted name, so then you end up still needing a table...
<robher>
there's the soc info stuff in the kernel. My main issue with it is that it is random whether SoCs use it.
<marcan>
consider how x86 CPUs literally have the marketing name in CPUID but ARM CPUs don't
<marcan>
is there?
<broonie>
There's no strings in the arm64 hardware, no.
<robher>
'model' wasn't really supposed to be that either, but still a compatible like string. Somehow when we started Arm DT support that got abandoned.
<geertu>
marcan: Machine and SoC are in the top level compatible and model
<geertu>
CPU cores in the compatible values of the cpu nodes under /cpus
<geertu>
On some systems, you also have /sys/devices/soc0/{machine,family,soc_id,revision}
viorel_suman has quit [Quit: WeeChat 3.5]
<robmur01>
marcan: x86 CPUs embed the SoC name; the CPU microarchitecture is reported as opaque family/stepping numbers just like Arm's MIDR, nothing has ever spelled out "Skylake", "Broadwell", etc.
<robmur01>
the difference is that Arm CPUs don't offer an architectural way to identify the SoC because Arm don't architect the SoC
<robmur01>
(and even there I'm not exactly helping with the broad ambiguity of what different people think "CPU" means)
apritzel_ has joined #armlinux
hanetzer has quit [Ping timeout: 260 seconds]
tlwoerner_ has quit [Quit: Leaving]
Tokamak_ has joined #armlinux
tlwoerner has joined #armlinux
hanetzer has joined #armlinux
Tokamak has quit [Ping timeout: 255 seconds]
apritzel_ has quit [Ping timeout: 260 seconds]
wens has quit [Ping timeout: 260 seconds]
wens has joined #armlinux
Misotauros has quit [Ping timeout: 252 seconds]
alpernebbi has quit [Ping timeout: 260 seconds]
alpernebbi has joined #armlinux
prabhakarlad has joined #armlinux
torez has quit [Quit: torez]
torez has joined #armlinux
frieder has quit [Remote host closed the connection]
<arnd>
marcan: many socs have a drivers in drivers/soc/ that reads some SoC specific ID registers to provide the information about the SoC in a format that is meant to be both human- and machine-readable through sysfs, grep for soc_device_attribute. The SoC usually doesn't know about the machine, so some drivers fill in that information from /model.
<arnd>
On Armv5/XScale (Intel PXA/IXP/IOP) there was usually a 1:1 relation between CPU ID and SoC, but on modern chips these two are usually kept separate
<arnd>
I'd be in favor of having the same type of human-readable model names that Intel/AMD have, but everyone else seems opposed to that
<arnd>
there was a recent article somewhere about AMDs model registers are writable and actually written by boot firmware
cleger has quit [Remote host closed the connection]
heat has joined #armlinux
<robmur01>
that was certainly true of some of the old VIA Centaurs
<HdkR>
I do love the 48 bytes of human readable description that x86 CPUID gives you these days
Misotauros has joined #armlinux
<EricCurtin[m]>
Upstream arm64/Linux seems to really be an exception here as regards Human Readable strings. A lot of downstream Linux implementations will have it available as "Hardware" in /proc/cpuinfo, like the Qualcomm implementation of Linux on Android. I think it is useful, like in the Asahi case, otherwise you are left with core types like "icestorm" and "firestorm", and that doesn't mean anything to most people.
<EricCurtin[m]>
sysinfo tools like "neofetch" or Gnome's "About" screen just print nothing as regards CPU model without this info. I know some software like to use this info as part of a kind of fingerprint to help detect hardware changes.
heat has quit [Remote host closed the connection]
heat has joined #armlinux
Tokamak_ has quit [Remote host closed the connection]
Tokamak has joined #armlinux
Tokamak has quit [Quit: Tokamak]
prabhakarlad has quit [Ping timeout: 260 seconds]
<arnd>
EricCurtin[m]: having "firestorm" as a string would be much more helpful than the hexadecimal number we have today
Tokamak has joined #armlinux
Pali has joined #armlinux
wens has quit [Ping timeout: 260 seconds]
wens has joined #armlinux
<robmur01>
Helpful for what though, really? ifunc resolvers and "-mcpu=native" don't need strings, and we have lscpu for satisfying human curiosity :P
Tokamak has quit [Quit: Tokamak]
prabhakarlad has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
<Xogium>
to be fair, lscpu doesn't tell you the human readable names of most things
<Xogium>
all I know about this cpu here is, its using cortex a7 cores
<Xogium>
and yeah its probably worse on arm64, last time I checked, lscpu listed stuff in hexadecimal
<robmur01>
they keep a pretty up-to-date list of Arm-based microarchitecture names, so users can conclude that e.g. their tiny BCM2711 is somehow comparable to their honking dual-socket HiSilicon hip07
<jn>
Xogium: but the Cortex-A7 *is* the CPU
<jn>
Xogium: unless you say "CPU" to mean "SoC"
<Xogium>
jn: oh yeah, sorry. I'm a bit tired ;)
<jn>
happens to the best :)
<Xogium>
but I'm thinking SoC, like. Wouldn't it make sense to expose SoC name somewhere ?
<jn>
possibly
<Xogium>
I thought maybe hostnamectl for systemd would have a way to show this but nop
plappermaul has joined #armlinux
<robmur01>
right, the problem is mostly that terms like "CPU" and "processor" often refer to a physical chip since too many of us date from the days when those were synonymous
<jn>
true, the historic angle does make it confusing
<robmur01>
the SoC name is often more useful for identifying the system, but even then do I really care that my oscilloscope "is" a Xilinx Zynq-something, or am I more interested that it's an oscilloscope? ;)
<jn>
well… depends on the situation. *i* would want to know both the system name (tektronics foo bar) and SoC name (Xilinx Zync whatever)
<jn>
there are useful for answering different questions