This is already tracked internally at Google at b/314738464 but quoting the same info here:

Problem:
We display big/little/mid core information in the UI on cpu tracks
That information is often wrong

Root cause:
Today we infer core types by analyzing the max(cpufreq) for each core during the trace
That's incorrect because a core could be fully idle, or could be even at max frequency (but then we wouldn't record any freq change), or anything in between

Proposed solution:
We should instead scrape the list of available frequencies from cpufreq and report it into the trace, and use that information to inform the core type
We even have that code, but is behind an optional data source "linux.system_info" which is not enabled in AOT
We should consider always dump that data (as we do for UTSname and kernel version) instead