collect/present extra data

[hrw]

Arnd Bergmann (@arndb) wrote on https://society.oftrolls.com/@arnd/109387464774037517:

How hard is it to extend your table with extra columns? I think it would be nice to list which cores support aarch32 state in EL0 and/or EL2, which ones support 16KB and 64KB pages, and what the supported virtual and physical address space sizes are.

I keep looking those up in the TRM and can provide the data for most cores if you want to add this.

[arndb]

Here is the data I know:

aarch32-el2 is supported by all early Cortex (A53, A57, A72, A35, A73, A75), but none of the later ones (A76+, Neoverse)
aarch32-el0 but not el2 is supported by A76/a77/a78, Neoverse N1/V1, A710 and second-generation A510, as well as X-Gene
No aarch32 support at all on A34, A65AE, R82, A715 and first-generation A510, Icestorm/Firestom, ThunderX, ThunderX2.
Not sure about the other ones

All cores except Apple's support 64K pages. Older apple cores had 64K but not 16K pages
Early Cortex cores (A53, A57, A72) did not support 16K pages, but later ones (A73+) do

Physical address size is totally weird, and I can't ever remember. Cortex-A72 and A75 had a fairly large 44-bit physical address space, while A53, A73, A76, A77, A78, A510, A710, A715 only use 40 bits and Apple M1 is even smaller with 36 bits. Neoverse N1/N2/V1 in turn all have 48 it physical addressing.

[hrw]

So something like this will be needed (example without checking are values are right):

0x41:
  cores:
    '0xd03':
      16k: false
      4k: true
      64k: true
      aarch32: true
      aarch32-el0: true
      aarch32-el2: true
      address_physical_bits: 40
      name: Cortex-A53
    '0xd0c':
      16k: true
      4k: true
      64k: true
      aarch32: true
      aarch32-el0: false
      aarch32-el2: true
      address_physical_bits: 48
      name: Neoverse-N1
    '0xd47':
      16k: true
      4k: true
      64k: true
      aarch32: false
      aarch32-el0: false
      aarch32-el2: false
      address_physical_bits: 40
      name: Cortex-A710

Question how much of that data will need to be set to "unknown" first.

[hrw]

issue #57 suggests adding PMU information

[hrw]

Or will it enough to have aarch32 support as "el0/el2/false" instead of 3 fields?

'0xc01':
      16k: true
      4k: true
      64k: true
      aarch32: "el0"
      address_physical_bits: 40
      name: SomeCore 1
'0xc03':
      16k: true
      4k: true
      64k: true
      aarch32: "el2"
      address_physical_bits: 40
      name: SomeCore 3
'0xc17':
      16k: true
      4k: true
      64k: true
      aarch32: false
      address_physical_bits: 40
      name: SomeCore Ultra 7

Would make table easier as those info needs to be present in SoC table as well (to not read same data each time).

- aarch32: el0
  cores:
  - implementer: 0x77
    part: 0xc03
    revision: 0x3
    variant: 0x0
  - implementer: 0x77
    part: 0xc01
    revision: 0x3
    variant: 0x0
  features:
  - fp
  - asimd
  - evtstrm
  - aes
  - pmull
  - sha1
  - sha2
  - crc32
  - cpuid
  name: Umba 7
  vendor: Exampel

[binarymaster]

Having just one field for it makes sense, as the values are mutually exclusive.

[hrw]

one flag then

[binarymaster]

Suggestion for the page sizes:

0x41:
  cores:
    '0xd03':
      page_kb: [4, 16, 64]

Or:

0x41:
  cores:
    '0xd03':
      pagesize:
      - 4k
      - 16k
      - 64k

[hrw]

I like second format. Converted locally but wonder which values to send by default.

[hrw]

#61 suggests another option to track

[hrw]

AArch32 has 4 options:

• EL0-EL3 (all exception levels)
• EL0 only
• false (no AArch32 support)
• to be set (no info for table yet)

[hrw]

Some more info added:

• URL to TRM
• implemented ISA level (v8.0/v8.2 etc)
• physical/virtual address space

[hrw]

Mark Brown suggested collecting data from /sys/devices/system/cpu/cpu*/regs/identification/* as well.

[hrw]

https://marcin.juszkiewicz.com.pl/download/tables/arm-cpu-cores.html lists some data for Arm Ltd cores.