[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexey Kardashevskiy
Subject: Re: [PATCH qemu v14] spapr: Implement Open Firmware client interface
Date: Tue, 9 Mar 2021 18:28:44 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.0

On 09/03/2021 16:29, David Gibson wrote:

+struct ClientArchitectureSupportClass {
+    InterfaceClass parent;
+    target_ulong (*cas)(CPUState *cs, target_ulong vec);
+    void (*quiesce)(void);

Is there actually any real connection of quiesce behaviour to cas
behaviour?  Basically, I'm wondering if this is not so much about
client-architecture-support fundamentally as just about
machine-specific parts of the VOF behaviour.  Which would be fine, but
suggests a different name for the interface.

The most canonical way would be having 2 interfaces.

Why?  I don't see any reason these shouldn't be a single interface, it
just has a bad name.

I renamed it to SpaprVofInterface for now.

+typedef int size_t;
+typedef void client(void);
+/* globals */
+extern void _prom_entry(void); /* OF CI entry point (i.e. this firmware) */
+void do_boot(unsigned long addr, unsigned long r3, unsigned long r4);
+/* libc */
+int strlen(const char *s);
+int strcmp(const char *s1, const char *s2);
+void *memcpy(void *dest, const void *src, size_t n);
+int memcmp(const void *ptr1, const void *ptr2, size_t n);
+void *memmove(void *dest, const void *src, size_t n);
+void *memset(void *dest, int c, size_t size);
+/* Prom */
+typedef unsigned long prom_arg_t;
+int call_prom(const char *service, int nargs, int nret, ...);

AIUI this isn't so much about calling the PROM, since this *is* the
PROM code, but rather about calling the parts that are implemented on
the qemu side.  Different names might clarify that.


Works for me.

call_ci() it is then.

About builtins such as memcmp() - turns out these are not really builtins as they are not inlined and gcc/ld still want to link against libc which is trickier for such firmware (not quite sure how to do this and keep it small and not pull other libc stuff in), gcc just knows about them a bit more. This is different from, for example, __builtin_ctz which is inlined. So I am keeping my libc.o for now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]