Re: [PATCH qemu v19] spapr: Implement Open Firmware client interface

[Alexey Kardashevskiy]

On 5/16/21 01:04, BALATON Zoltan wrote:
> On Thu, 22 Apr 2021, Alexey Kardashevskiy wrote:

[snip]

> > +/* Defined as Big Endian */
> > +struct prom_args {
> > +    uint32_t service;
> > +    uint32_t nargs;
> > +    uint32_t nret;
> > +    uint32_t args[10];
> > +} QEMU_PACKED;
>
> This #define and struct definition should probably be moved to 
> include/hw/ppc/vof.h as I had to copy these when trying to get VOF 
> running with pegasos2 and these seem to be VOF specific not spapr.

Correct, I'll fix it - there are 2 copies already.


> I was trying to wire up VOF on pegasos2 as proof of concept but I did 
> not get very far as it crashed at the first move due to using mtmsrd 
> which does not exist on the 32 bit CPUs (G4 or G3) used by pegasos2:
>
> 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
> invalid/unsupported opcode: 1f - 12 - 05 - 00 (7fe00164) fff00108 0
> ----------------
> IN:
> 0xfff00100:  3fe00000  lis      r31, 0
> 0xfff00104:  63ff0000  ori      r31, r31, 0
> 0xfff00108:  7fe00164  mtmsrd   r31
>
> ----------------
> IN:
> 0xfff00700:  807e8020  lwz      r3, -0x7fe0(r30)
> 0xfff00704:  4cc63182  crclr    6
> 0xfff00708:  4bfffd1d  bl       0xfff00424
>
> Invalid access at addr 0xFFFF8020, size 4, region '(null)', reason: 
> rejected
>
> Is this mtmsrd really needed? Do 64-bit Power CPUs start in 64 bit mode?

Yup:
https://git.qemu.org/?p=qemu.git;a=blob;f=target/ppc/translate_init.c.inc;h=66e6a4a746f46148e0006081af09391b32c125cd;hb=HEAD#l10085

I cannot find the exact reason for that, probably PAPR or some PPC-OF 
binding says so.


> I'd expect them to be in compatibility mode unless 64 bit is enabled but 
> I did not check the docs. If it's needed maybe a dummy handler has to be 
> at 0x700 to ignore this exception if it's running on a 32-bit CPU.

I wanted MSR and the code to be in sync explicitly.

> By the way does vof need to be loaded at addr 0 or it could work at the 
> default ROM address as well? That would simplify usage if it could run 
> position independent.

What do you call the default ROM address? SLOF loads at 0 and starts at 
0x100, VOF does the same.

Making it run position independend is going to make it more complex and 
I really (really) want it to be tiny.

I think what you really want is another vof-pegasos2.bin linked at the 
address you like and not calling mtmsrd, could be an #ifdef in the 
existing vof firmware. It is rather expected to have a firmware per a 
machine type.


--
Alexey