semarie reported problems with running arm64 on qemu which turned
out to be triggered by the psci version call.
[ using 979488 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org
OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
[email protected]:/usr/src/sys/arch/arm64/compile/GENERIC
real mem = 2105647104 (2008MB)
avail mem = 2017124352 (1923MB)
mainbus0 at root: unknown model
cpu0 at mainbus0: ARM Cortex-A57 r1p0
efi0 at mainbus0: UEFI 2.0.5
efi0: Das U-Boot rev 0x0
psci0 at mainbus0Stopped at psci_attach+0xf4:
ddb> tr
hvc_call() at psci_attach+0xf0
psci_attach() at mainbus_attach_node+0x244
mainbus_attach_node() at mainbus_attach+0x1ec
mainbus_attach() at config_attach+0x214
config_attach() at config_rootfound+0xc0
config_rootfound() at cpu_configure+0x34
cpu_configure() at main+0x348
main() at $x.2+0x70
ddb> sh reg
x0 0xffffffff84000000
x1 0
x2 0
x3 0
x4 0xffffff80008bf258 initstack+0x4a68
x5 0x1323
x6 0x861e4d1cb67f8248
x7 0x861e4d1cb67f8248
x8 0xffffff8000571978 hvc_call
x9 0x84000008
x10 0x84000009
x11 0
x12 0
x13 0
x14 0xffffff80073ad744 _end+0x6a5ac0c
x15 0xffffff8000671f20 ap_bits_user
x16 0xb64c1a07
x17 0xef56e85d
x18 0xffffff80008bf200 initstack+0x4a10
x19 0xffffff80073ac200 _end+0x6a596c8
x20 0xffffff80008bf310 initstack+0x4b20
x21 0xffffff8000800000 $d.5
x22 0
x23 0xffffff80073ac224 _end+0x6a596ec
x24 0xffffff8000813388 psci_cd
x25 0xffffff8000813360 psci_ca
x26 0xffffff8000950000 gf_log+0x1bc
x27 0x4085f000
x28 0x40200000
x29 0xffffff80008bf2b0 initstack+0x4ac0
x30 0
sp 0xffffff80008bf200 initstack+0x4a10
spsr 0x600003c5
elr 0xffffff8000571978 hvc_call
lr 0xffffff8000254d08 psci_attach+0xf4
psci_attach+0xf4:
Though it seems other calls had trouble before that, likely since the
psci changes made in december.
Attempting to power down...
Stopped at boot+0xd4:
ddb> tr
hvc_call() at boot+0xd0
boot() at sys_reboot+0x2c
reboot() at svc_handler+0x1bc
svc_handler() at do_el0_sync+0xbc
do_el0_sync() at handle_el0_sync+0x68
handle_el0_sync() at 0x4ca7b07a4
--- trap ---
ddb> sh reg
x0 0xffffffff84000008
x1 0
x2 0
x3 0
x4 0xffffff8000277918 hvc_call
x5 0
x6 0x33781a588ce87b4c
x7 0x33781a588ce87b4c
x8 0xffffff80072f7200 _end+0x69a49d8
x9 0x25bf00aba3ce1b98
x10 0x16707157c
x11 0x64
x12 0x1dcd662 __ALIGN_SIZE+0x1bcd662
x13 0xc
x14 0xffffff8007235184 _end+0x68e295c
x15 0
x16 0
x17 0x10
x18 0xffffff8018b00d90
x19 0x1008
x20 0xffffff8000805000 nv2tov_type+0x8
x21 0x37
x22 0x37
x23 0xffffff8018b00f00
x24 0xffffff8000800000 $d.5
x25 0xffffff8000856360 sysent
x26 0x37
x27 0xffffff80008566d2 sysent+0x372
x28 0x1
x29 0xffffff8018b00da0
x30 0x4f49c4fa00000000
sp 0xffffff8018b00d90
spsr 0x600003c5
elr 0xffffff8000277918 hvc_call
lr 0xffffff80002433f0 boot+0xd4
boot+0xd4:
qemu-system-aarch64 doesn't recognise the psci call when the high 32 bits
of x0 are not zero. The PSCI implemented by the ATF in the
overdrive 1000 only looks at the low 32 bits. And all the function ids
we use set bit 31. Bit 30 is used to indicate smc64/hvc64 calling
convention. The smc calling convention specification states that up to
six registers are used, but nothing we call needs that many yet.
Tested on overdrive 1000, and 32/64 bit qemu -M virt.
Index: psci.c
===================================================================
RCS file: /cvs/src/sys/dev/fdt/psci.c,v
retrieving revision 1.4
diff -u -p -r1.4 psci.c
--- psci.c 17 Jan 2018 10:17:33 -0000 1.4
+++ psci.c 28 Jan 2018 02:46:10 -0000
@@ -45,10 +45,10 @@ struct psci_softc {
struct device sc_dev;
register_t (*sc_callfn)(register_t, register_t, register_t,
register_t);
- int sc_psci_version;
- int sc_system_off;
- int sc_system_reset;
- int sc_cpu_on;
+ register_t sc_psci_version;
+ register_t sc_system_off;
+ register_t sc_system_reset;
+ register_t sc_cpu_on;
};
struct psci_softc *psci_sc;
