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.
Regards,
BALATON Zoltan