Marcin Juszkiewicz - linux

From the diary of AArch64 porter — ID registers

2025-11-12T09:19:00+01:00

People are used to looking at “Features” field in the /proc/cpuinfo file under Linux. But does it show everything about the CPU cores present in the system?

What ID registers?

AArch64 CPUs have a set of “identification registers” which are named “ID_AA64*_EL1”, where “*” can be:

AFR — Auxiliary Feature Registers
DFR — Debug Feature Registers
FPFR — Floating-Point Feature Registers
ISAR — Instruction Set Attribute Registers
MMFR — Memory Model Feature Registers
PFR — Processor Feature Registers
SMFR — SME Feature ID Registers
ZFR — SVE Feature ID Registers

They can be used to check which features are present in a given CPU core. Their presence depends on things like age, generation, revision, and the design of the SoC.

Introductions of registers

As the AArch64 architecture was progressing, more and more identification registers were needed to describe CPU core features.

From a quick look through Arm docs, I compiled a simple table of chronology:

ID register	Architecture version	Year	First Arm core
ID_AA64DFR0_EL1	v8.0-A	2011/2012	Cortex-A53, Cortex-A57
ID_AA64PFR0_EL1	v8.0-A	2011/2012	Cortex-A53, Cortex-A57
ID_AA64ISAR0_EL1	v8.0-A	2011/2012	Cortex-A53, Cortex-A57
ID_AA64MMFR0_EL1	v8.0-A	2011/2012	Cortex-A53, Cortex-A57
ID_AA64AFR0_EL1	v8.0-A	2013/2014	Cortex-A53, Cortex-A73
ID_AA64AFR1_EL1	v8.0-A	2013/2014	Cortex-A53, Cortex-A73
ID_AA64DFR1_EL1	v8.0-A	2013/2014	Cortex-A53, Cortex-A73
ID_AA64PFR1_EL1	v8.0-A	2013/2014	Cortex-A53, Cortex-A73
ID_AA64ISAR1_EL1	v8.0-A	2013/2014	Cortex-A53, Cortex-A73
ID_AA64MMFR1_EL1	v8.0-A	2013/2014	Cortex-A53, Cortex-A73
ID_AA64MMFR2_EL1	v8.2-A	2016	Cortex-A55, Cortex-A75
ID_AA64ZFR0_EL1	v8.2-A (SVE)	2017	Fujitsu A64FX, Cortex-A710
ID_AA64MMFR3_EL1	v8.3-A	2017	Cortex-X4
ID_AA64ISAR2_EL1	v8.5-A	2018	Cortex-A520
ID_AA64ISAR3_EL1	v8.5-A	2018	Cortex-A520
ID_AA64MMFR4_EL1	v8.7-A	2021	Cortex-A715
ID_AA64SMFR0_EL1	v9.0-A (SME)	2021	Neoverse V1
ID_AA64FPFR0_EL1	v9.5-A	2023
ID_AA64PFR2_EL1	v8.9-A/9.5-A	2023	C1

I am not 100% sure about years and architecture versions. Not every document has all versions available on the Arm developer website.

It also shows that the Cortex-A53 was a very popular core design — it had multiple revisions, which added several features.

How to read those?

In my opinion, the easiest way is to use my ArmCpuInfo tool. It runs on any EFI environment (EDK2, U-Boot, and so on), reads the ID registers and prints their meaning. I wrote about it some time ago.

Empty registers

A TRM document may list an ID register, explain all its fields, and it still can look like something to ignore because it only contains zeros. Like the ID_AA64MMFR3_EL1 register in the Neoverse-V3 TRM:

SpecFPACC
ADERR
SDERR
RPZ
ANERR
SNERR
D128_2
D128
MEC
AIE
S2POE
S1POE
S2PIE
S1PIE
SCTLRX
TCRX

All those fields have descriptions and they mean something. At the same time, they all have a 0b0000 value. I assume that the value of some fields may change when the SoC vendor pays more and begins designing its own version of a CPU core based on Arm’s design.

Strange cases

Cortex-A75 present in the MediaTek Helio G70 SoC reports SSBS (Speculative Store Bypass Safe) feature under Linux:

processor       : 6
BogoMIPS        : 26.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp
                  asimdhp cpuid asimdrdm lrcpc dcpop asimddp asimddp sha512 ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x3
CPU part        : 0xd0a
CPU revision    : 1

But to read it, you need the ID_AA64PRF1_EL1 register, which is not mentioned in the Cortex-A75 technical reference manual (TRM). It is present in the newer versions of the Cortex-A55 TRM, and both CPU core models are present in the Helio G70 SoC.

SSBS (and SSBS2) were introduced into Arm v8.5 and then added to v8.0 to allow every CPU core to have it implemented.

Let me list it for you

As you may know, I have a page about ARM CPU cores where I list some basic information. Last weekend I added showing of potential CPU features to it. Small example:

CPU core name	features
Cortex-A53	AA32EL0, AA32EL1, AA32EL2, AA32EL3, AA64EL0, AA64EL1, AA64EL2, AA64EL3, AES, ASID16, AdvSIMD, CRC32, Debugv8, DoubleLock, FP, MixedEnd, MixedEndEL0, PMULL, PMUv3, SHA1, SHA256
Cortex-A520	AA64EL0, AA64EL1, AA64EL2, AA64EL3, AES, AFP, AMUv1, ASID16, AdvSIMD, BBM, BF16, BTI, CCIDX, CONSTPACFIELD, CRC32, CSV2_2, CSV3, DGH, DIT, DPB2, Debugv8p4, DotProd, E0PD, ECBHB, ECV_POFF, EVT, FCMA, FGT, FHM, FP, FP16, FRINTTS, FlagM2, HAFDBS, HCX, HPDS2, HPMN0, I8MM, IDST, IESB, JSCVT, LOR, LRCPC, LRCPC2, LSE, LSE2, MTE3, MixedEnd, MixedEndEL0, PACQARMA3, PAN3, PAuth2, PMULL, PMUv3p7, RASv1p1, RDM, S2FWB, SB, SHA1, SHA256, SHA3, SHA512, SM3, SM4, SPECRES, SSBS2, SVE, SVE2, SVE_AES, SVE_BitPerm, SVE_PMULL128, SVE_SHA3, SVE_SM4, TLBIOS, TLBIRANGE, TRBE, TRF, TTCNP, TTL, TTST, UAO, VHE, VMID16, XNX, XS, nTLBPA

CPU core name

features

Cortex-A53

AA32EL0, AA32EL1, AA32EL2, AA32EL3, AA64EL0, AA64EL1, AA64EL2, AA64EL3, AES, ASID16, AdvSIMD, CRC32, Debugv8, DoubleLock, FP, MixedEnd, MixedEndEL0, PMULL, PMUv3, SHA1, SHA256

Cortex-A520

AA64EL0, AA64EL1, AA64EL2, AA64EL3, AES, AFP, AMUv1, ASID16, AdvSIMD, BBM, BF16, BTI, CCIDX, CONSTPACFIELD, CRC32, CSV2_2, CSV3, DGH, DIT, DPB2, Debugv8p4, DotProd, E0PD, ECBHB, ECV_POFF, EVT, FCMA, FGT, FHM, FP, FP16, FRINTTS, FlagM2, HAFDBS, HCX, HPDS2, HPMN0, I8MM, IDST, IESB, JSCVT, LOR, LRCPC, LRCPC2, LSE, LSE2, MTE3, MixedEnd, MixedEndEL0, PACQARMA3, PAN3, PAuth2, PMULL, PMUv3p7, RASv1p1, RDM, S2FWB, SB, SHA1, SHA256, SHA3, SHA512, SM3, SM4, SPECRES, SSBS2, SVE, SVE2, SVE_AES, SVE_BitPerm, SVE_PMULL128, SVE_SHA3, SVE_SM4, TLBIOS, TLBIRANGE, TRBE, TRF, TTCNP, TTL, TTST, UAO, VHE, VMID16, XNX, XS, nTLBPA

There may be some mistakes in the table — I strongly advise checking Technical Reference Manuals (TRMs) to be sure. Please report any error — I will take a look at fixing them.

I built my first mechanical keyboard

2025-03-09T14:37:00+01:00

About a year ago I wrote a post about a need for a good keyboard. And that I am thinking of making mechanical one.

During last week I built one.

Repetitive strain injury

Twenty years ago I had a problem with repetitive strain injury (RSI in short). Typing on normal PC keyboard was quite impossible for me. Someone recommended buying one of those “fancy” ergonomic ones. And that’s how I ended with Microsoft Natural Keyboard Elite.

Microsoft Natural Keyboard

It was a great help. Got used to layout and my RSI problems were going away. Then bought second one to have one at home and one at work.

Time passed, keycaps were worn up so I got another keyboard — you can read the story in last year post about keyboards.

Let’s get mechanical

During last year I looked at several keyboards. Checked KMK, QMK, ZMK and other solutions of keyboard firmware. Watched countless videos on how to make keyboard and read many articles about it.

One layout caught my eye: TGR Alice as it was quite simple ergonomic one. Then found Arisu which added cursor keys and did some other changes. And finally Adelheid which added function keys.

My Adelheid

As those layouts are available on MIT license I took Adelheid and altered its layout a bit:

added Meta key
moved Backspace to were it is on PC105
moved Backslash to above Enter key

My version of Adelheid

Parts and costs

I had some parts already (ordered then to my MS4KMech project which I abandoned in meantime) and decided that my first keyboard will be as cheap as possible:

Redragon switches (11€ on Aliexpress)
cheap ABS keycaps (5€ oin Aliexpress)
Ultimate Pico RP2040 (2.7€ on Aliexpress)
hundred 1N4148 diodes (2€)

So cost of parts was about 20 EUR.

As a way to keep costs down I printed plate in two pieces (Ender 3 table size was a limit) and used some screws and plates to keep them together.

Soldering rows and columns

Mounted switches and started soldering. Simple diode to diode to create rows. And it is visible that I watched some video after first 3 rows of one half ;D

Instead of forming diodes I soldered them and then use small pliers to form rows. Later started cutting legs before soldering.

Columns were easier. Spool of kynar and stripping isolation using nails did the job.

First half of keyboard

Added a bunch of colour wires to be able to test did my soldering resulted in something working. Grabbed Raspberry Pico from a drawer, flashed it with QMK firmware and testing bench was ready:

Testing bench

And it almost worked! One key was not working. Turned out that diode was soldered in wrong direction. Happens.

For second half I took a bit different strategy. Decided to solder columns first as they took me more time than rows. Whole half went much faster then first.

Second half of keyboard

Then all that left was finding a way to connect both halves (I did not wanted to make a split keyboard) and connect rows. I used pieces of old universal PCB and screws:

Both halves of keyboard

Connecting controller

I bought Ultimate Pico RP2040 especially for keyboard project months ago. Compared to Raspberry Pico this board had USB-C port and one line more (GP29). Also less GND pins so 17 GPIO lines are on one side. My keyboard has 16 columns so this allowed me to have all columns connected on one side of board and use second side connections for rows:

Final view of bottom side

I may do not look nice but it works :D

Powering up

I flashed QMK and started testing. Turned out that one column is not working. Soldered wire and it was fine.

3 other keys were not working. One needed soldering but other ones looked fine.

QMK has a solution for it: “Console debugging”. I added a bit of code to keymap.c file:

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
  // If console is enabled, it will print the matrix position and status
  // of each key pressed
#ifdef CONSOLE_ENABLE
    uprintf("KL: kc: 0x%04X, row: %2u, col: %2u, pressed: %u, "
            "time: %5u, int: %u, count: %u\n",
            keycode, record->event.key.col, record->event.key.row,
            record->event.pressed, record->event.time, record->tap.interrupted,
            record->tap.count);
#endif
  return true;
}

This allowed me to notice that both Enter and End keys are seen. Turned out that I wrote wrong row/column values for both of them.

Mistakes

I made some mistakes with this keyboard. They were expected as usual with first attempts.

First mistake: 2mm plate. Should had do 1.5mm to make switches keep better. Total thickness can be even 3-5 mm but with holes done in a way that switches hold properly. Also it may make keyboard less bendy.

Second ones - holes for stabilisers. I have a few 2u - 2.75u keys and they should get stabilisers. But I did holes in wrong way so the ones I have do not fit. Will see how it affects keyboard use.

Third one: soldering. I do not remember when last time I soldered so many points. So some of other are shitty. Just had to fix one more…

Tools

Community behind mechanical keyboards created many tools. Let me try to list ones I used.

First comes QMK firmware which allows to forget about programming microcontrollers as keyboard is done as simple JSON file and one C file with keymap definition.

Then Keyboard Layout Editor which allows to define layout of keys in any crazy way you want. Raw data from it is a base for several other tools.

Keyboard Firmware Builder is a simplest way to manage wiring of keyboard. You paste raw data from previous tool and start simplifying wiring. It can also generate ready to use QMK firmware images for several popular micro controllers (but no RP2040 I used).

Plate & Case Builder also takes layout data. And allows to choose switch/stabilizer types plus a bunch of other options. Then generates plate for your layout with option to download it in SVG, DXF, EPS file formats. I took SVG, extruded to 2mm and had a base plate for 3d printing.

Was it worth the time?

The question for the end: was it worth the time? I think that it was. Learnt new things, got something working. Something I did on my own. Sure, it is far from being perfect but gives me area for improvements.

I have two space keys and already see that for most of time I use right one. There are no layers defined yet and I have a key for it. Some keycaps may get replaced with other ones (like Calculator one next to left Space begs for lower one).

I have links to many interesting layouts so who knows, maybe I will make a new keyboard soon. Split, orthogonal one. With volume knob. Will see.

Arm cpu info EFI application

2023-05-03T15:38:00+02:00

As you may know one of my side projects is AArch64 SoC features table. It reports which features of AArch64 processor were recognized by Linux kernel and presented in /proc/cpuinfo file.

But there are moments when I do not want to boot Linux just to check what features cpu cores are capable of. So I wrote an EFI application for it and called it “ArmCpuInfo”.

How it works

AArch64 processors have set of system registers. All those ID_AA64DFR0_EL1 etc. All you have to do is read them, split into nibbles (4-bit long segments) and check armarm (Arm Architecture Reference Manual) for their meaning. Sometimes even single bits are used for marking feature support.

Turned out that writing application was quite easy. First version was just a bunch of “if” all over the place. Then I rewritten it to be more user friendly — now it uses “switch/case/default” schema so for each unknown nibble’s value simple “unknown” is printed. This allows to catch moments when either application needs updates due to architecture changes or when SoC does not follow the rules written in armarm.

Where is source code?

The ArmCpuInfo application ~~is part of EDK2. You can find it as a part of ArmPkg.~~ is hosted in edk2-armcpuinfo repository. I moved it there due to long review times in EDK2 project.

Licensed under BSD-2-Clause-Patent license like EDK2 project. May relicense it to MIT (used by my other personal projects).

How to run

The ArmCpuInfo is simple EFI application therefore it can be run on any firmware which provides a way to run such. It can be closed EFI implementation, can be EDK2 one or it can also be U-Boot with EFI services enabled (which nowadays means basically any properly configured one).

download ArmCpuInfo from release page

Sample output

As most of my development time I spend with SBSA Reference Platform in QEMU I run ArmCpuInfo there (on “max” cpu core which has everything QEMU is capable of emulating):

Shell> fs0:armcpuinfo.efi
ArmCpuInfo v1.0.0

ID_AA64MMFR0_EL1 = 0x0100032310201126
ID_AA64MMFR1_EL1 = 0x0010011010312122
ID_AA64MMFR2_EL1 = 0x1221011110011011
ID_AA64PFR0_EL1  = 0x1201001121112222
ID_AA64PFR1_EL1  = 0x0000000001000121
ID_AA64ISAR0_EL1 = 0x1221111110212120
ID_AA64ISAR1_EL1 = 0x0011111101211052
ID_AA64ISAR2_EL1 = 0x0000000000110000
ID_AA64DFR0_EL1  = 0x0000000010305609
ID_AA64SMFR0_EL1 = 0x80F100FD00000000
ID_AA64ZFR0_EL1  = 0x0110110100110021

Reg   |  Bits | Value | Feature
------|-------|-------|----------------------------------------------
MMFR0 |  3:0  |  0110 | 52 Bits (4PB) of physical address range supported.
      |       |       | FEAT_LPA implemented.
MMFR0 |  7:4  |  0010 | ASID: 16 Bits
MMFR0 | 11:8  |  0001 | Mixed-endian support.
MMFR0 | 19:16 |  0000 | No mixed-endian support at EL0.
MMFR0 | 15:12 |  0001 | Supports a distinction between Secure and Non-Secure Memory.
MMFR0 | 31:28 |  0001 |  4KB granule supported for 52-bit address.
MMFR0 | 43:40 |  0011 |  4KB granule supported at stage 2 for 52-bit address.
MMFR0 | 23:20 |  0010 | 16KB granule supported for 52-bit address.
MMFR0 | 35:32 |  0011 | 16KB granule supported at stage 2 for 52-bit address.
MMFR0 | 27:24 |  0000 | 64KB granule supported.
MMFR0 | 39:36 |  0010 | 64KB granule supported at stage 2.
MMFR0 | 47:44 |  0000 | FEAT_ExS not implemented.
MMFR0 | 59:56 |  0001 | FEAT_FGT implemented.
MMFR0 | 63:60 |  0000 | FEAT_ECV not implemented.
------|-------|-------|----------------------------------------------
MMFR1 |  3:0  |  0010 | FEAT_HAFDBS implemented with dirty status support.
MMFR1 |  7:4  |  0010 | FEAT_VMID16 implemented.
MMFR1 | 11:8  |  0001 | FEAT_VHE implemented.
MMFR1 | 15:12 |  0010 | FEAT_HPDS2 implemented.
MMFR1 | 19:16 |  0001 | FEAT_LOR implemented.
MMFR1 | 23:20 |  0011 | FEAT_PAN3 implemented.
MMFR1 | 27:24 |  0000 | The PE never generates an SError interrupt due to
      |       |       | an External abort on a speculative read.
MMFR1 | 31:28 |  0001 | FEAT_XNX implemented.
MMFR1 | 35:32 |  0000 | FEAT_TWED not implemented.
MMFR1 | 39:36 |  0001 | FEAT_ETS implemented.
MMFR1 | 43:40 |  0001 | FEAT_HCX implemented.
MMFR1 | 47:44 |  0000 | FEAT_AFP not implemented.
MMFR1 | 51:48 |  0000 | FEAT_nTLBPA not implemented.
MMFR1 | 55:52 |  0001 | FEAT_TIDCP1 implemented
MMFR1 | 59:56 |  0000 | FEAT_CMOW not implemented.
------|-------|-------|----------------------------------------------
MMFR2 |  3:0  |  0001 | FEAT_TTCNP implemented.
MMFR2 |  7:4  |  0001 | FEAT_UAO implemented.
MMFR2 | 11:8  |  0000 | FEAT_LSMAOC not implemented.
MMFR2 | 15:12 |  0001 | FEAT_IESB implemented.
MMFR2 | 19:16 |  0001 | FEAT_LVA implemented.
MMFR2 | 23:20 |  0000 | FEAT_CCIDX not implemented.
MMFR2 | 27:24 |  0000 | FEAT_NV not implemented.
MMFR2 | 31:28 |  0001 | FEAT_TTST implemented.
MMFR2 | 35:32 |  0001 | FEAT_LSE2 implemented.
MMFR2 | 39:36 |  0001 | FEAT_IDST implemented.
MMFR2 | 43:40 |  0001 | FEAT_S2FWB implemented.
MMFR2 | 51:48 |  0001 | FEAT_TTL implemented.
MMFR2 | 55:52 |  0010 | FEAT_BBM: Level 2 support for changing block size is supported.
MMFR2 | 59:56 |  0010 | FEAT_EVT: HCR_EL2.{TTLBOS, TTLSBIS, TOCU, TICAB, TID4} traps are supported.
MMFR2 | 63:60 |  0001 | FEAT_E0PD implemented.
------|-------|-------|----------------------------------------------
PFR0  |  3:0  |  0010 | EL0 in AArch64 and AArch32
PFR0  |  7:4  |  0010 | EL1 in AArch64 and AArch32
PFR0  | 11:8  |  0010 | EL2 in AArch64 and AArch32
PFR0  | 15:12 |  0010 | EL3 in AArch64 and AArch32
PFR0  | 19:16 |  0001 | Floating-point with half-precision support (FEAT_FP16).
PFR0  | 23:20 |  0001 | Advanced SIMD with half precision support (FEAT_FP16).
PFR0  | 27:24 |  0001 | System registers to versions 3.0/4.0 of GIC CPU implemented.
PFR0  | 31:28 |  0010 | FEAT_RASv1p1 implemented. FEAT_DoubleFault implemented.
PFR0  | 35:32 |  0001 | FEAT_SVE implemented.
PFR0  | 39:36 |  0001 | Secure EL2 implemented.
PFR0  | 43:40 |  0000 | FEAT_MPAM not implemented.
PFR0  | 47:44 |  0000 | FEAT_AMU not implemented.
PFR0  | 51:48 |  0001 | FEAT_DIT implemented.
PFR0  | 55:52 |  0000 | FEAT_RME not implemented
PFR0  | 59:56 |  0010 | FEAT_CSV2_2 implemented.
PFR0  | 63:60 |  0001 | FEAT_CSV3 implemented.
------|-------|-------|----------------------------------------------
PFR1  |  3:0  |  0001 | FEAT_BTI implemented.
PFR1  |  7:4  |  0010 | FEAT_SSBS2 implemented.
PFR1  | 11:8  |  0001 | FEAT_MTE implemented.
PFR1  | 27:24 |  0001 | FEAT_SME implemented.
PFR1  | 31:28 |  0000 | FEAT_RNG_TRAP not implemented.
PFR1  | 39:36 |  0000 | FEAT_NMI not implemented.
------|-------|-------|----------------------------------------------
ISAR0 |  7:4  |  0010 | FEAT_AES and FEAT_PMULL implemented.
ISAR0 | 11:8  |  0001 | FEAT_SHA1 implemented.
ISAR0 | 15:12 |  0010 | FEAT_SHA512 implemented.
ISAR0 | 19:16 |  0001 | CRC32 instructions implemented.
ISAR0 | 23:20 |  0010 | FEAT_LSE implemented.
ISAR0 | 27:24 |  0000 | TME instructions not implemented.
ISAR0 | 31:28 |  0001 | FEAT_RDM implemented.
ISAR0 | 35:32 |  0001 | FEAT_SHA3 implemented.
ISAR0 | 39:36 |  0001 | FEAT_SM3 implemented.
ISAR0 | 43:40 |  0001 | FEAT_SM4 implemented.
ISAR0 | 47:44 |  0001 | FEAT_DotProd implemented.
ISAR0 | 51:48 |  0001 | FEAT_FHM implemented.
ISAR0 | 55:52 |  0010 | FEAT_FlagM2 implemented.
ISAR0 | 59:56 |  0010 | FEAT_TLBIRANGE implemented.
ISAR0 | 63:60 |  0001 | FEAT_RNG implemented.
------|-------|-------|----------------------------------------------
ISAR1 |  3:0  |  0010 | FEAT_DPB2 implemented.
ISAR1 |  7:4  |  0101 | FEAT_FPACCOMBINE implemented.
      |       |       | FEAT_PACQARMA5 implemented.
ISAR1 | 11:8  |  0000 | Address Authentication (API) not implemented.
ISAR1 | 15:12 |  0001 | FEAT_JSCVT implemented.
ISAR1 | 19:16 |  0001 | FEAT_FCMA implemented.
ISAR1 | 23:20 |  0010 | FEAT_LRCPC2 implemented.
ISAR1 | 27:24 |  0001 | FEAT_PACQARMA5 implemented.
ISAR1 | 31:28 |  0000 | FEAT_PACIMP not implemented.
ISAR1 | 35:32 |  0001 | FEAT_FRINTTS implemented.
ISAR1 | 39:36 |  0001 | FEAT_SB implemented.
ISAR1 | 43:40 |  0001 | FEAT_SPECRES implemented.
ISAR1 | 47:44 |  0001 | FEAT_BF16 implemented.
ISAR1 | 51:48 |  0001 | FEAT_DGH implemented.
ISAR1 | 55:52 |  0001 | FEAT_I8MM implemented.
ISAR1 | 59:56 |  0000 | FEAT_XS not implemented.
ISAR1 | 63:60 |  0000 | FEAT_LS64 not implemented.
------|-------|-------|----------------------------------------------
ISAR2 |  3:0  |  0000 | FEAT_WFxT not implemented.
ISAR2 |  7:4  |  0000 | FEAT_RPRES not implemented.
ISAR2 | 11:8  |  0000 | FEAT_PACQARMA3 not implemented.
ISAR2 | 15:12 |  0000 | Address Authentication (APA3) not implemented.
ISAR2 | 19:16 |  0001 | FEAT_MOPS implemented.
ISAR2 | 23:20 |  0001 | FEAT_HBC implemented.
ISAR2 | 27:24 |  0000 | FEAT_CONSTPACFIELD not implemented.
------|-------|-------|----------------------------------------------
DFR0  |  3:0  |  1001 | FEAT_Debugv8p4 implemented.
DFR0  |  7:4  |  0000 | Trace unit System registers not implemented.
DFR0  | 11:8  |  0110 | FEAT_PMUv3p5 implemented.
DFR0  | 15:12 |  0101 | Number of breakpoints, minus 1.
DFR0  | 23:20 |  0011 | Number of watchpoints, minus 1.
DFR0  | 31:28 |  0001 | Number of breakpoints that are context-aware, minus 1.
DFR0  | 35:32 |  0000 | FEAT_SPE not implemented.
DFR0  | 39:36 |  0000 | FEAT_DoubleLock implemented.
DFR0  | 43:40 |  0000 | FEAT_TRF not implemented.
DFR0  | 47:44 |  0000 | FEAT_TRBE not implemented.
DFR0  | 51:48 |  0000 | FEAT_MTPMU not implemented.
DFR0  | 55:52 |  0000 | FEAT_BRBE not implemented.
DFR0  | 63:60 |  0000 | Setting MDCR_EL2.HPMN to zero has CONSTRAINED UNPREDICTABLE behavior.
------|-------|-------|----------------------------------------------
SMFR0 |    32 |  0001 | SME F32F32 implemented.
SMFR0 |    34 |  0001 | SME B16F32 implemented.
SMFR0 |    35 |  0001 | SME F16F32 implemented.
SMFR0 | 39:36 |  1111 | SME I8I32 implemented.
SMFR0 |    48 |  0001 | SME F64F64 implemented.
SMFR0 | 55:52 |  1111 | SME I16I64 implemented
SMFR0 | 59:56 |  0000 | Mandatory SME instructions are implemented.
SMFR0 |    63 |  0001 | SME_FA64 implemented.
------|-------|-------|----------------------------------------------
ZFR0  |  3:0  |  0001 | FEAT_SVE2 implemented.
ZFR0  |  7:4  |  0010 | FEAT_SVE_AES and FEAT_SVE_PMULL128 implemented.
ZFR0  | 19:16 |  0001 | FEAT_SVE_BitPerm implemented.
ZFR0  | 23:20 |  0001 | FEAT_BF16 SVE implemented.
ZFR0  | 35:32 |  0001 | FEAT_SVE_SHA3 implemented.
ZFR0  | 43:40 |  0001 | FEAT_SVE_SM4 implemented.
ZFR0  | 47:44 |  0001 | FEAT_I8MM SVE implemented.
ZFR0  | 55:52 |  0001 | FEAT_F32MM SVE implemented
ZFR0  | 59:56 |  0001 | FEAT_F64MM SVE implemented
------|-------|-------|----------------------------------------------

That’s a lot of feature flags :D

New toy arrived — RockPro64

2020-05-14T10:53:00+02:00

AArch64 world has toys on cheap side, servers on expensive and some attempts in a middle.

Me.

I started working on AArch64 in 2012 year. Before hardware was available. Even before toolchain bits were available. Then first prototype server arrived at Red Hat, then it got replaced with Applied Micro Mustang. Then more servers, Mustang under desk. Joined Linaro (as Red Hat assignee) and started using their server lab.

And during all those years I never played with AArch64 SBC.

If it lacks proper storage and 16+GB ram then I am not interested.

Some months ago I decided to change it.

What to choose?

There are many AArch64 boards to choose from. Some are better, some are not. Popular ones and those with features. Like usual.

So I asked Peter Robinson and few other folks about their proposal and most of them agreed that Rockchip RK3399 looks most interesting. Has PCI Express slot on several boards, uses Mali T860 so can play with Panfrost driver, USB 3 ports are present etc.

RockPro64

After some market research I decided on RockPro64 from Pine64. Board has USB 3 in both A and C type, PCIe x4 slot is present and I can reuse acrylic case from Pine A64 board I bought few years ago. And it has “the most expensive chip in ARM world” present (16MB SPI flash for boot firmware).

Ordered in March, board arrived two days ago.

Setup

I digged in my boxes and found 12V/5A power supply (3A is recommended minimum), used some Ethernet cable flying under desk, old 64GB usb3 thumb drive for storage and my lovely IOGEAR GKM561R keyboard/trackpoint which I use for all boards bring-up.

Mounted board into acrylic case and started wiring extra stuff.

Disable SPI button

As boot firmware can be stored in onboard SPI chip there has to be a way to ignore it on boot. According to disable SPI note on vendor website it is a matter of crossing SPI_CLK with GND during boot.

So small breadboard, two wires, button and I am ready.

Serial console

As usual serial console is on pins. So breadboard got one of my cheap USB-Serial dongles plugged and then wires started.

Serial console setup post on forum says that 6/8/10 pins are all I need. Did them, connected USB cable and started picocom at 1.5Mbps speed:

Terminal ready
��tU�����UU���˕�U���TU J���UU���Q�UR�)���Q�
*�R��uT��*��U�
      �VQ��Y��ս+UJ.���I��zT����UQ])

Lovely! Turned out that CP2102 dongles are only “expected” to work at that speed. Digged deeper in drawers and found SPI Hook device from TinCanTools. It uses FT2232HL so should be fine with up to 12Mbps speed.

And worked without problems:

U-Boot TPL 2020.04 (Apr 20 2020 - 00:00:00)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2020.04 (Apr 20 2020 - 00:00:00 +0000)
Trying to boot from MMC1

U-Boot 2020.04 (Apr 20 2020 - 00:00:00 +0000)

SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64
DRAM:  3.9 GiB
PMIC:  RK808 
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No block device, using default environment

So I was ready to play!

Mali

So when Arm will open source Mali drivers?

This question is present on each “Ask Arm Anything” sessions during Linaro Connect (ARM partners only session, badges are checked on room entry). And answer always is more or less “never”.

But there is Panfrost now. Fully open source driver for Mali family used in RK3399 SoC.

Booted board and it got stuck:

[   29.043106] panfrost ff9a0000.gpu: clock rate = 500000000
[   29.053073] rockchip-vop ff8f0000.vop: Adding to iommu group 1
[   29.058099] panfrost ff9a0000.gpu: mali-t860 id 0x860 major 0x2 minor 0x0 status 0x0
[   29.058948] panfrost ff9a0000.gpu: features: 00000000,100e77bf, issues: 00000000,24040400
[   29.059820] panfrost ff9a0000.gpu: Features: L2:0x07120206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
[   29.061053] panfrost ff9a0000.gpu: shader_present=0xf l2_present=0x1
[   29.063559] rockchip-vop ff900000.vop: Adding to iommu group 2
[   29.147966] panfrost ff9a0000.gpu: devfreq_add_device: Unable to find governor for the device
[   29.151244] panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq
[   29.173499] panfrost ff9a0000.gpu: Fatal error during devfreq init

Discussed issue with people on #panfrost IRC channel and they pointed me at “governor_simpleondemand” kernel module being missing. So I rebuilt initramfs with “dracut -v —force-drivers governor_simpleondemand —force” command and it booted to FullHD framebuffer.

Some work is needed here as monitor has 3440x1440 resolution so at least 2560x1440 or 2560x1080 should be used. But that can wait for now. I plan to move this board somewhere else on desk and connect to 24” full hd monitor.

Plans?

I do not plan to use that board for any serious stuff. More as a device to learn how EBBR world looks. Boot sequence with U-Boot loading Grub from EFI system partition looks good.

There are some things which need work. I want to have boot firmware stored in SPI flash as now I have 1GB microsd card in slot just to have U-Boot loaded.

There are some changes in U-Boot waiting for someone to test, USB-C port is not enabled at all (it should work as USB 3 and DisplayPort).

So who knows :D

Red Hat Platform Enablement meeting week

2018-11-20T12:54:00+01:00

Last week I was in Vancouver, Canada again. At the time when Linux Plumbers conference took place. But it was not the main reason as I went there to meet people from Platform Enablement team at Red Hat.

Linux Plumbers

The idea was simple — gather everyone in one place at same time and let them talk. Conference was selected to give something else to do at same time. And we were visible — for 473 attendees about 60 was from Red Hat.

Red Hat team before going for team dinner

I was talking with most of RH people to find out who they are, what they are working on etc. It ended in a lot of interesting discussions. Also many talks with non-RH people. The ‘so you are IBM now’ phrase happened just a few times.

There were funny moments too. Like one when Dave Airlie responded with “ah, you are the ‘arm64 + radeon guy’” ;D

Vancouver

As there was no breakfast option in ‘The Burrard’ hotel I went for a walk to find some. Davie street is full of bars, diners, restaurants (but most of them open at 11:00). Interesting graffiti, cannabis stores (as it is now legal in Canada) and lot of LGBT rainbows everywhere.

Band graffiti

Some “Safe space” monument

Tanning salon

Cannabis Store

Fountain

Shore

A-maze-ing Laughter

Toronto

Due to one of my flights being cancelled I had to choose: weekend in Vancouver, weekend in Toronto or rebooking whole trip. So I decided to go to Toronto and meet friend there.

On Saturday I meet Karol and we had long walk. It was good to not discuss about ARM or OpenStack — we went for visual effects instead as this is Karol’s area of expertise. Maya, Houdini, Renderman, Mr. X, ILM, Pixar and other names were going over. I was told “they work on Houdini in that building” and later “here Maya is developed” ;D

So I asked about photo realistic movies — are they possible now? Turns out that yes, they are. But it is too expensive to make.

During weekend I did over 20 kilometers by just walking through the city. Some random photos below:

Thimble monument

Pink Panther graffiti

Dog graffiti

Rabbits graffiti

Leslieville graffiti

Together sidewalk graffiti

Halloween decorations

Small house between bigger ones

TORONTO city sign with buildings

TORONTO city sign

Me and TORONTO city sign

It was great week. Despite sleep deprivation ;D

Ctrl-Q issue or “are Firefox developers using Linux at all?”

2018-08-02T16:54:00+02:00

When I started using Linux on my desktop there was only Mozilla based browsers which were usable. They had different names: Galeon, Firebird, Phoenix, Mozilla Suite and finally Firefox.

It worked better or worse but did. There were moments when on 2GB ram machine browser was using 6 gigabytes (which resulted in killing it). Then were moments when it started to be slower and slower so I moved to Google Chrome instead.

But still — Firefox had all those extensions which could do insane amount of things with how browser looks, how it works etc. But then Quantum came and changed that. Good bye all nice addons. Hope we meet in other life.

But what it has with question from post title? Simple, little, annoying thing: “Ctrl-Q” shortcut. Lovely one which everyone is using to close application they work with. Not that it does not work — it does. Perfectly. And this is a problem…

Imagine you have few browser windows opened. On different virtual desktops. With several tabs per window. Some open notes there, somewhere some not-finished wiki edit etc. Normal day. And then you want to close ‘funny kitten’ tab and instead you close all those windows/tabs, drop not finished notes/edits etc. Just because your finger slipped to “Ctrl-Q”.

For years most of users I know used one of those “disable ctrl-q shortcut” addons to NOT close all browser windows when your finger slips a bit when you wanted to close a tab (with “Ctrl-W”) or switch a tab (with “Ctrl-Tab”). Since Quantum it is not possible at all as there is no way how addon can alter shortcuts. Or how user can alter shortcut. No Way At All.

And then it appears that “Ctrl-Q” problem exists only under Linux. Under Microsoft Windows developers of Mozilla Firefox decided that “Ctrl-Shift-Q” will be a good workaround for the problem. Something similar under MacOS. But Linux still on “Ctrl-Q”.

There is a bug report opened for it but there were 4 major releases of Firefox without any change I highly doubt that anything will change in this regard.

Slowly thinking of making COPR repo where I would provide Mozilla Firefox builds with one patch: removing that “Ctrl-Q” shortcut…

2021 UPDATE

Firefox 87+ has “browser.quitShortcut.disabled” option to get rid of shortcut from menu. And even without it used it now warns user after shortcut is used:

Firefox warning about closing 5 windows after Ctrl-Q use

25 years of Red Hat

2018-03-26T20:35:00+02:00

Years ago I bought Polish translation of “Under the radar” book about how Red Hat was started. Was a good read and went to bookshelf.

Years passed. In meantime I got hired by Red Hat. To work on Red Hat Enterprise Linux. For AArch64 architecture.

Then one day I was talking with my wife about books and I looked at shelf. And found that book again. Took it and said:

You know, when I bought that book I did not even dreamt that one day I will be working at Red Hat.

Today company turned 25. Amount of time longer than my career. I remember how surprised I was when realised that some of my friends work at company for 20 years already.

This is the oldest company I worked for. Directly at least as some of the customers of companies I worked in past were probably older. And hope that one day my work title will be “Retired Software Engineer” as my wife once said. And that will be at this company.

Twenty five years of Linux

2016-08-29T13:53:00+02:00

As I came back from PTO I had to dig into work mails. One of threads was about 25 years of Linux and there was a question “which was your first kernel” and I thought that it may be not an easy question to answer.

For me first was 2.0.2[6-8] (do not remember) on some Uni server where I got my first Linux account (normally used SunOS and text terminal). I remember that there was simple root exploit we used.

Then 2.0.36 on my Amiga 1200 (Debian ‘slink’) was first I run on my hardware.

2.2.10 was first I used for longer as it was Debian ‘potato’ m68k one.

2.3.47 was first I cross compiled (on i686/linux for m68k/linux). And it worked!

2.4.0-test5 was first I built for my x86 desktop once I moved from Amiga/AmigaOS to PC/Debian. I had Duron/600 desktop and old 386 desktop both running same version. Duron got newer ones later, 386 stayed with this one for about year when I returned it.

When I bought Sharp Zaurus SL-5500 PDA 2.4.18-rmk7-pxa3-embeddix was running on it. So this is my first Linux version on mobile device. Next jump was 2.6.11 on Zaurus c760 as first 2.6 one on mobile.

During OpenZaurus maintaince I started upstreaming kernel patches. 2.6.17 was first with my patches in.

When I had that strange ProGear webpad I wrote backlight for it (based on someone’s code) and 2.6.21 was first with my driver in (and I removed it in 3.7).