[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH qemu v19] spapr: Implement Open Firmware client interface
|
From: |
BALATON Zoltan |
|
Subject: |
Re: [PATCH qemu v19] spapr: Implement Open Firmware client interface |
|
Date: |
Mon, 17 May 2021 20:44:24 +0200 (CEST) |
On Mon, 17 May 2021, BALATON Zoltan wrote:
On Mon, 17 May 2021, Alexey Kardashevskiy wrote:
On 5/17/21 09:34, BALATON Zoltan wrote:
On Sat, 15 May 2021, BALATON Zoltan wrote:
On Sat, 15 May 2021, BALATON Zoltan wrote:
On Thu, 22 Apr 2021, Alexey Kardashevskiy wrote:
[snip]
vof_claim virt=0x0 size=0xc38 align=0x0 => 0x0
vof_claim virt=0x0 size=0x8000 align=0x8000 => 0x8000
vof_claim virt=0xc00000 size=0x18fd62 align=0x0 => 0xc00000
vof_claimed 0x0..0xc38 size=0xc38
vof_claimed 0x8000..0x10000 size=0x8000
vof_claimed 0xc00000..0xd8fd62 size=0x18fd62
vof_avail 0xc38..0x8000 size=0x73c8
vof_avail 0x10000..0xc00000 size=0xbf0000
vof_avail 0xd8fd62..0x20000000 size=0x1f27029e
via_superio_cfg: unimplemented register 0xf2
via_superio_cfg: unimplemented register 0xf4
via_superio_cfg: unimplemented register 0xf6
via_superio_cfg: unimplemented register 0xf7
[...]
OK, I've found that vof.bin needs to be at address 0 then hypercalls work
and it tries to query /chosen/qemu.boot-kernel but I get len = -1 for some
reason. I'm adding the kernel address and size like this:
uint64_t cells[2];
cells[0] = cpu_to_be64(pm->kernel_addr);
cells[1] = cpu_to_be64(pm->kernel_size);
qemu_fdt_setprop(fdt, "/chosen", "qemu,boot-kernel",
cells, sizeof(cells));
which is very much like what spapr does but when vof tries to query it I
get:
spapr_vof_reset() also claims the kernel/initrd/VOF memory and allocates
the stack, vof_claim() barfs if there are overlaps.
I've also copied spapr_vof_reset and I don't see an error due to overlap, it
seems to get past this as seen above. With the latest changes to load it to
address 0 I see a bit different output:
$ .qemu-system-ppc -M pegasos2 -device ati-vga,romfile="" -cdrom
morphos-3.15.iso -kernel boot.img -serial stdio -trace enable="vof*" -d
unimp,guest_errors,int,in_asm
vof_claim virt=0x0 size=0x55f1 align=0x0 => 0x0
vof_claim virt=0x0 size=0x8000 align=0x8000 => 0x8000
vof_claim virt=0xc00000 size=0x18fd62 align=0x0 => 0xc00000
vof_claimed 0x0..0x55f1 size=0x55f1
vof_claimed 0x8000..0x10000 size=0x8000
vof_claimed 0xc00000..0xd8fd62 size=0x18fd62
vof_avail 0x55f1..0x8000 size=0x2a0f
vof_avail 0x10000..0xc00000 size=0xbf0000
vof_avail 0xd8fd62..0x20000000 size=0x1f27029e
The size of the vof area changed for some reason that I don't understand but
it starts to run anyway and I get some hypercalls:
Raise exception at 00000150 => 00000008 (01)
hypercall r3=000000000000f005 r4=000000000000fe7c r5=0000000000000001
r6=0000000000000be8 r7=0000000000000000 r8=000000000000fe78
r9=000000000000fe7c r10=0000000000000001 r11=0000000000000000
r12=0000000000000000 nip=00000150
vof_finddevice "/chosen" => ph=0x5
Raise exception at 00000150 => 00000008 (01)
hypercall r3=000000000000f005 r4=000000000000fe6c r5=0000000000000001
r6=0000000000000005 r7=0000000000000bf0 r8=000000000000fe68
r9=000000000000fe6c r10=0000000000000001 r11=000000000000ff60
r12=0000000000000000 nip=00000150
vof_getprop ph=0x5 "qemu,boot-kernel" => len=-1 []
Then it panics here when I think it would jump to the guest code at this
point if this was successful. I'm probably missing something that VOF expects
which may cause problems. At the moment I don't have an initrd loaded and the
stdout path set becuase I did not figure out how the latter works. Are those
or anything else needed?
Raise exception at 00000150 => 00000008 (01)
hypercall r3=000000000000f005 r4=000000000000fe6c r5=0000000000000001
r6=0000000000000005 r7=0000000000000bf0 r8=000000000000fe68
r9=000000000000fe6c r10=0000000000000001 r11=000000000000ff60
r12=0000000000000000 nip=00000150
vof_getprop ph=0x5 "qemu,boot-kernel" => len=-1 []
then it calls exit and the VM stops. Any idea what could be wrong with the
above or what to check?
Memory allocation. Another thing I saw was clang/llvm incorrectly
initializing bss start/end for prom (very early boot) so the prim init code
in the kernel would memset(0) wrong page and break things. Dunno.
I don't get errors about memory allocation, why do you think that would be a
problem and where to look for such errors? I'm using your vof.bin, haven't
recompiled it and using gcc anyway so I don't think I have a compiler
problem.
I've uploaded my current changes I'm testing with here:
https://osdn.net/projects/qmiga/scm/git/qemu/blobs/pegasos2/hw/ppc/pegasos2.c
and these are the changes
https://osdn.net/projects/qmiga/scm/git/qemu/commits/80c3187758dccffbf167974de98f472ec5c5d03a
in case you can have a look and may spot something obviously wrong. I'm
running it as above with MorphOS for now as I know that only reads the device
tree at start up and should not use any other OF services. I'll eventually
test with Linux too but this seemed simpler for first try and should probably
work with minimal CI functionality but I hope to find that out when it
starts.
Sorry, my mistake, I was trying to set qemu.boot-kernel property in the
build_fdt function that's called before kernel_size is set so that part
did not run and the property was missing. I've updated the above osdn.net
repo with a fixed version. With this guest code now starts but does not
get to calling back into vof yet as it crashes somewhere short after
starting. I'm getting:
IN:
0x00c00084: 9421fbd0 stwu r1, -0x430(r1)
0x00c00088: 7c0802a6 mflr r0
0x00c0008c: 7ca32b78 mr r3, r5
0x00c00090: 3881040c addi r4, r1, 0x40c
0x00c00094: 90010434 stw r0, 0x434(r1)
0x00c00098: 93a10424 stw r29, 0x424(r1)
0x00c0009c: 93e1042c stw r31, 0x42c(r1)
0x00c000a0: 7cbf2b78 mr r31, r5
0x00c000a4: 48000d21 bl 0xc00dc4
----------------
IN:
0x00c00dc4: 9421ffe0 stwu r1, -0x20(r1)
0x00c00dc8: 3d2000d9 lis r9, 0xd9
0x00c00dcc: 7c0802a6 mflr r0
0x00c00dd0: 93810010 stw r28, 0x10(r1)
0x00c00dd4: 7c9c2378 mr r28, r4
0x00c00dd8: 3889fd44 addi r4, r9, 0xfd44
0x00c00ddc: 93c10018 stw r30, 0x18(r1)
0x00c00de0: 7c7e1b78 mr r30, r3
0x00c00de4: 90010024 stw r0, 0x24(r1)
0x00c00de8: 4bfff42d bl 0xc00214
----------------
IN:
0x00c00214: 9421ffd0 stwu r1, -0x30(r1)
0x00c00218: 7c691b78 mr r9, r3
0x00c0021c: 7c0802a6 mflr r0
0x00c00220: 7d2903a6 mtctr r9
0x00c00224: 3d2000d9 lis r9, 0xd9
0x00c00228: 39400001 li r10, 1
0x00c0022c: 3929fc58 addi r9, r9, 0xfc58
0x00c00230: 90010034 stw r0, 0x34(r1)
0x00c00234: 38610008 addi r3, r1, 8
0x00c00238: 39000000 li r8, 0
0x00c0023c: 90810014 stw r4, 0x14(r1)
0x00c00240: 91210008 stw r9, 8(r1)
0x00c00244: 9141000c stw r10, 0xc(r1)
0x00c00248: 91410010 stw r10, 0x10(r1)
0x00c0024c: 91010018 stw r8, 0x18(r1)
0x00c00250: 4e800421 bctrl
invalid/unsupported opcode: 3e - 08 - 1e - 01 (f821ff91) 00000120 0
----------------
IN:
0x00000118: 3c400000 lis r2, 0
0x0000011c: 60428b00 ori r2, r2, 0x8b00
0x00000120: f821ff91 stdu r1, -0x70(r1)
Raise exception at 00000120 => 00000060 (21)
invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) fff00700 0
----------------
IN:
0xfff00700: 00000000 .byte 0x00, 0x00, 0x00, 0x00
Raise exception at fff00700 => 00000060 (21)
The last part jumping to program exception vector is because we don't have
any handler installed at that address yet but the first exception is the
real problem which looks like vof has another opcode not supported on a G4
CPU. Could it be compiled with some options to only use PPC 32 opcodes or
where does this stdu come from?
Regards,
BALATON Zoltan