[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: Wed, 10 Mar 2021 15:52:12 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.0

On 10/03/2021 13:40, David Gibson wrote:
On Wed, Mar 10, 2021 at 12:55:07PM +1100, Alexey Kardashevskiy wrote:

On 10/03/2021 01:00, BALATON Zoltan wrote:
On Tue, 9 Mar 2021, Alexey Kardashevskiy wrote:
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.

Do they really want libc or they are in libgcc for which there's
--static-libgcc I think to avoid needing it in runtime but not sure what
clang has for these.

I was getting "unresolved symbol `memcmp`" when I tried calling memcmp() or
__builtin_memcmp() and "-lc" did not help (installed some multilib packages,

Yeah, you'll need -lgcc rather than -lc, libgcc is the one with the
builtin helpers.

Tried that:
ld -nostdlib -e_start -Tl.lds -EB -lgcc -o vof.elf entry.o main.o ci.o bootmem.o
ld: cannot find -lgcc

I tried playing with the cmdline but to no avail.

I also looked at libgcc and it does not look like it has the libc implementations:

[fstn1-p1 qemu-killslof]$ find /lib -iname "libgcc*"

[fstn1-p1 qemu-killslof]$ objdump -D /lib/powerpc64le-linux-gnu/libgcc_s.so.1 | egrep '(memcmp|memcpy)'
0000000000010750 <memcpy@plt>:

[fstn1-p1 qemu-killslof]$

did not help either). I figured if I cannot get it compile in 3 minutes, I
should not probably be posting this and better off simply keeping the
existing small libc.

Fair point.



reply via email to

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