dboot: MIDR Architecture is [19:16] not [18:15].

[jperkin]

While investigating other HVF issues I noticed that the architecture check does not match the manual and we are checking the wrong bits, presumably getting away with the high bit of PartNum happening to be set.

[richlowe]

is this something we could do with constants in cpuid.h, rather than naked values?

Did I get the equivalent macro in cpuid.h wrong? or is that ok?

[jperkin]

Yeh good idea, let me take a look. I don't see any similar use in cpuid.

[jperkin]

Just a note on the HVF issue here, if I run qemu with -accel hvf -cpu cortex-a53 or similar then the code in run_dboot matches the CPU but reading the CPUECTLR_EL1.SMPEN MSR (if my reading is correct) causes an abort:

Booting...                                                                                                            
"Synchronous Abort" handler, esr 0x02000000                                                                           
elr: fffffffff9a161e0 lr : fffffffff9a1604c (reloc)
elr: 00000001b90db1e0 lr : 00000001b90db04c
x0 : 00000000410fd083 x1 : 0000000000000d08
x2 : 00000000000003c5 x3 : 0000000000000002
x4 : 0000000000000007 x5 : 000000000000001d
x6 : 00000000020dcf30 x7 : 00000000ffffffc0
x8 : 0000000000000001 x9 : ffffffffe0000000
x10: 0000000000000002 x11: 0000000000000000
x12: 00000001bf7dc408 x13: 0000000000000018
x14: fffffffffffff000 x15: 00000001be6875a0
x16: 0000000020000000 x17: 0000000000000040
x18: 00000001bd426e48 x19: 00000001b90daea8
x20: 0000000000000000 x21: 00000001b90db000
x22: 00000001bd4722f8 x23: 00000001bb3790b0
x24: 00000001bd3d8434 x25: 0000000000000000
x26: 00000001ad01b000 x27: 0000000000000001
x28: 00000001b90db000 x29: 00000001bd470bb0

Code: 54000080 f1340c3f 54000040 14000007 (d539f220) 

d539f220 appears to match to mrs x0, s3_1_c15_c2_1 so my assumption about what's happening is that whilst the CPU is being reported as an A53 when qemu goes to read that MSR it does not exist on the host CPU.

Whether we want to try and handle that somehow or just mark it as user error is up for debate, but it's worth pointing out that I can't find any similar code to enable cache coherency for these CPUs on NetBSD or Linux, and I can boot NetBSD fine with the exact same qemu configuration.

[richlowe]

I don't know whether we should be skipping this, or conditionalizing it on guest-ness. Another one @r1mikey might have ideas about

[r1mikey]

I don't know whether we should be skipping this, or conditionalizing it on guest-ness. Another one @r1mikey might have ideas about

I'm not convinced we need this at all (anymore). Since we've moved to consistently using ATF and U-Boot everywhere this should not be necessary.

I'll test and confirm when I get a chance.

[r1mikey]

I don't know whether we should be skipping this, or conditionalizing it on guest-ness. Another one @r1mikey might have ideas about

I'm not convinced we need this at all (anymore). Since we've moved to consistently using ATF and U-Boot everywhere this should not be necessary.

I'll test and confirm when I get a chance.

Still need to do testing, but here are my preliminary findings:

• U-Boot can set this for us: https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/start.S#L149
• We don't set CONFIG_ARMV8_SET_SMPEN in our rpi4 U-Boot config, which would make that code active
• Qemu shouldn't need this, and seems to default to the behaviour where this is set (it does not advertise as set, but also doesn't seem to take any action when it is): https://github.com/qemu/qemu/blob/master/target/arm/cortex-regs.c#L53

I'll spin up some tests on both qemu and rpi4 in the next few days.