Re: [OpenBIOS] [RFC 3/3] ppc: RTAS WIP

[Andreas Färber]

Am 15.10.2010 um 00:38 schrieb Alexander Graf:
> Am 15.10.2010 um 00:17 schrieb Andreas Färber  
> :
> > diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
> > index 2b0b891..6d72386 100644
> > --- a/arch/ppc/qemu/init.c
> > +++ b/arch/ppc/qemu/init.c
> > @@ -745,10 +749,11 @@ arch_of_init( void )
> >       printk("Warning: No /rtas node\n");
> >   else {
> >       unsigned long size = 0x1000;
> >    while( size < (unsigned long)of_rtas_end - (unsigned  
> >
> > long)of_rtas_start )
> >    while ( size < rtas_size )
> >     size *= 2;
> > set_property( ph, "rtas-size", (char*)&size, sizeof(size) );
> > set_int_property(ph, "rtas-version", 1);
>
> Didn't you just set this to 0x41?

No. My Mac has it as 0x41 (or 41?). The JS20 tree and the spec has it  
as 1.

Locally I'm using ARCH_CHRP_U3 for differentiation, setting up the / 
rtas node for chrp only, for instance. The machine enum needs to the  
sync'ed with QEMU though. Would a patch adding just the enum member  
(i.e., reserving the value 4) have anything chance of being applied  
without accompanying fully-complete-and-reviewed machine? My chrp  
machine is just a stripped-down version of mac99 for now, some memory  
locations would need to change once we have OpenBIOS/ppc64 compiling  
and some devices like mac-io would need to be exchanged. Blue?
> > diff --git a/arch/ppc/qemu/rtas-tokens.c b/arch/ppc/qemu/rtas- 
> > tokens.c
> > new file mode 100644
> > index 0000000..f251716
> > --- /dev/null
> > +++ b/arch/ppc/qemu/rtas-tokens.c
> > @@ -0,0 +1,63 @@
> > +/*
> > Copyright (c) 2010 Andreas Färber
> > */
>
> This is missing a copyleft license.

Yeah, and an SoB. Not yet ready for committing.
> > +#define RTAS_MAX_ARGS    10
> >
> > +typedef struct rtas_args {
> > unsigned long    token;
> > long            nargs;
> > long            nret;
> > unsigned long    args[RTAS_MAX_ARGS];
> >
> > +} rtas_args_t;
> >
> > +void rtas_interface(rtas_args_t*, void*);
> >
> > +/* drivers/escc.h */
> > +#define IO_ESCC_OFFSET  0x00013000
> > +/* drivers/escc.c */
> > +#define CTRL(addr) (*(volatile unsigned char *)(addr))
> > +#define DATA(addr) (*(volatile unsigned char *)(addr + 16))
> > +#define Tx_BUF_EMP      0x4     /* Tx Buffer empty */
> >
> > +/*static void uart_putchar(int port, unsigned char c)
> > +{
> > while (!(CTRL(port) & Tx_BUF_EMP))
> >    ;
> > DATA(port) = c;
> >
> > +}*/
> >
> > +/*void serial_putchar(char);*/
> >
> > +static void serial_putchar(char c)
> > +{
> > unsigned long addr = 0x80800000;
>
> Phew - how is this done for the normal escc case?

In OpenBIOS, the address is passed in from PCI code.

In /rtas, there's a "display-device" property that specifies the  
phandle to be used for display-character. We would have to read this  
and pass any addresses to RTAS as part of instantiate-rtas.
> We should at least share the constants here.

As documented above, most #defines were in the source file and would  
need to be moved to a header file for sharing.

Here, I just wanted a quick way to trace whether my code was being  
called. OpenBIOS' escc code is very OF-specific, and the JS20 doesn't  
have a mac-io/cuda/escc device anyway. We might be able to split some  
core I/O functions like these off.
> > +GLOBL(_entry):
> > /*
> > * r3 = arguments
> > * r4 = private memory
> > */
> > stw r1, 0(r4)
> > stw r2, 4(r4)
> > stwu r1, -12(r1)
>
> Is the os guaranteed to give you r4 and r1 for free scribbling over?

r4 is a pointer to the memory it claimed for us. My reservation of  
0x1000 initial bytes in rtas_initialize() leaves some space for saving  
state and passing in the shared struct you suggested.
> > stw r4, 8(r1)
> > mflr r0
> > stw r0, 4(r1)
>
> /* saving non-volatile registers */
> > stw r13,  8(r4)
>
> I would recommend multiplying here:
>
> stw r13, (3 * 4)(r4)
>
> That makes it more readable.

I actually adapted this from start.S for the client interface.

stwu x, 4(y) on a volatile register would be ever better imo. It was a  
nightly proof of concept! ;)

Question: The CIF does irritating things with r1 and r4 and  
saved_stack - why? Would it be better to save everything on the stack  
here?
> > bl rtas_interface
>
> So rtas_interface gets the os given r3 as first parameter. Please  
> make sure that struct is packed then.

Good catch.
> > lwz r0, 4(r1)
> > mtlr r0
> > lwz    r4, 8(r1)
> >
> > +//    lwz    r1, 0(r1)
> > lwz r2, 84(r4)
> > mtcr r2
>
> If the abi is similar to the normal C one, cr is volatile.

It definitely isn't. I believe the CIF preserves it, too.

Andreas