From: David Gibson <david@gibson.dropbear.id.au>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH qemu v20] spapr: Implement Open Firmware client interface
Date: Mon, 7 Jun 2021 13:05:29 +1000 [thread overview]
Message-ID: <YL2M+XP3Kw6w0UMr@yekko> (raw)
In-Reply-To: <537a6990-4f18-746e-a1da-5dfa51f23dbd@eik.bme.hu>
[-- Attachment #1: Type: text/plain, Size: 5417 bytes --]
On Fri, Jun 04, 2021 at 03:50:28PM +0200, BALATON Zoltan wrote:
> On Fri, 4 Jun 2021, David Gibson wrote:
> > On Sun, May 30, 2021 at 07:33:01PM +0200, BALATON Zoltan wrote:
[snip]
> > > MorphOS checks the name property of the root node ("/") to decide what
> > > platform it runs on so we may need to be able to set this property on /
> > > where it should return "bplan,Pegasos2", therefore the above maybe should do
> > > getprop first and only generate name property if it's not set (or at least
> > > check if we're on the root node and allow setting name property there). (On
> > > Macs the root node is named "device-tree" and this was before found to be
> > > needed for MorphOS.)
> >
> > Ah. Hrm. Have to think about what to do about that.
>
> This is easy to fix, this seems to allow setting a name property or return a
> default:
>
> > diff --git a/hw/ppc/vof.c b/hw/ppc/vof.c
> index b47bbd509d..746842593e 100644
> --- a/hw/ppc/vof.c
> +++ b/hw/ppc/vof.c
> @@ -163,14 +163,14 @@ static uint32_t vof_finddevice(const void *fdt,
> uint32_t nodeaddr)
> static const void *getprop(const void *fdt, int nodeoff, const char *propname,
> int *proplen, bool *write0)
> {
> - const char *unit, *prop;
> + const char *unit, *prop = fdt_getprop(fdt, nodeoff, propname, proplen);
>
> /*
> * The "name" property is not actually stored as a property in the FDT,
> * we emulate it by returning a pointer to the node's name and adjust
> * proplen to include only the name but not the unit.
> */
> - if (strcmp(propname, "name") == 0) {
> + if (!prop && strcmp(propname, "name") == 0) {
> prop = fdt_get_name(fdt, nodeoff, proplen);
> if (!prop) {
> *proplen = 0;
> @@ -196,7 +196,7 @@ static const void *getprop(const void *fdt, int nodeoff, const char *propname,
> if (write0) {
> *write0 = false;
> }
> - return fdt_getprop(fdt, nodeoff, propname, proplen);
> + return prop;
> }
Kind of a hack, but it'll do for now.
> This allows adding a name property to "/" different from the default but
> this does not yet fix MorphOS booting with VOF on pegasos2. I think it tries
> to query name on / and check if it's called "device-tree" in which case it
> assumes Mac hardware otherwise it goes with pegasos2 so even if we return
> nothing for name it would not matter in this case as we don't use VOF on
> Mac. If we wanted that then this would become a problem so it could be fixed
> now in advance just in case other guests may need it.
>
> > > Other than the above two problems, I've found that getting the device tree
> > > from vof returns it in reverse order compared to the board firmware if I add
> > > it the expected order. This may or may not be a problem but to avoid it I
> > > can build the tree in reverse order then it comes out right so unless
> > > there's an easy fix this should not cause a problem but may worth a comment
> > > somewhere.
> >
> > The order of things in the device tree *should* never matter. If it
> > does, that's definitely a client bug... but of course that doesn't
> > necessarily mean we won't have to work around it in practice.
>
> I don't know if it matters or not but having the device tree in the same
> order as the firmware ROM helps with comparing it for debugging but I've
> found I can solve this by building the tree in reverse order so no changes
> to VOF is needed for this, just thought adding a comment somewhere may
> clarify it but it's not really a problem.
>
> I still don't know what's MorphOS is missing, I've tried adding almost all
> misssing properties, checked what hardware is init by the firmware and tried
> to do the same in board reset code and even after that MorphOS still takes a
> different route with VOF and crashes but boots with the board firmware. I'm
> now thinking it may be either different memory organisation or the missing
> name properties that are not returned by nextprop in VOF so they are only
> appearing when explicitely queried whereas with the board firmware they are
> present as properties. With the above patch I could explicitely set it on
> nodes and test if that makes a difference.
>
> I got to this because adding more missing props or init more devices did not
> make a difference so I'm guessing it may be something else then and the only
> difference I can see compared to board firmware are the different memory
> ranges in claimed (VOF puts itself to 0 for example); and the missing name
> and additional phandle props in the device tree. MorphOS copies the whole
> device tree on startup then later it uses this copy of the device tree after
> shutting down OF with quiesce. I can imagine it may use some name props like
> that on the cpu node without checking assuming it's always there and if
> we're missing that it may cause a NULL dereference. I have no better idea
> what else could be missing so I'll test this next. If it helps I can try to
> come up with a patch to VOF to return these name props or allow setting them
> as above.
>
> Regards,
> BALATON Zoltan
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-06-07 3:56 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 9:05 [PATCH qemu v20] spapr: Implement Open Firmware client interface Alexey Kardashevskiy
2021-05-20 21:59 ` BALATON Zoltan
2021-05-21 0:25 ` Alexey Kardashevskiy
2021-05-21 9:05 ` BALATON Zoltan
2021-05-21 19:57 ` BALATON Zoltan
2021-05-22 6:39 ` Alexey Kardashevskiy
2021-05-22 13:08 ` BALATON Zoltan
2021-05-23 3:47 ` Alexey Kardashevskiy
2021-05-23 12:12 ` BALATON Zoltan
2021-05-22 6:22 ` Alexey Kardashevskiy
2021-05-22 13:01 ` BALATON Zoltan
2021-05-22 15:02 ` BALATON Zoltan
2021-05-22 16:46 ` BALATON Zoltan
2021-05-23 3:41 ` Alexey Kardashevskiy
2021-05-23 12:02 ` BALATON Zoltan
2021-05-23 3:31 ` Alexey Kardashevskiy
2021-05-23 11:24 ` BALATON Zoltan
2021-05-24 4:26 ` Alexey Kardashevskiy
2021-05-24 5:40 ` David Gibson
2021-05-24 11:56 ` BALATON Zoltan
2021-05-23 3:20 ` Alexey Kardashevskiy
2021-05-23 11:19 ` BALATON Zoltan
2021-05-23 17:09 ` BALATON Zoltan
2021-05-24 6:01 ` David Gibson
2021-05-24 10:55 ` BALATON Zoltan
2021-05-24 12:46 ` Alexey Kardashevskiy
2021-05-24 22:34 ` BALATON Zoltan
2021-05-25 5:24 ` David Gibson
2021-05-25 5:23 ` David Gibson
2021-05-25 10:08 ` BALATON Zoltan
2021-05-27 5:34 ` David Gibson
2021-05-27 12:42 ` BALATON Zoltan
2021-06-02 7:57 ` David Gibson
2021-06-02 12:29 ` BALATON Zoltan
2021-06-04 6:29 ` David Gibson
2021-06-04 13:59 ` BALATON Zoltan
2021-06-07 3:30 ` David Gibson
2021-06-07 22:54 ` BALATON Zoltan
2021-06-09 5:51 ` Alexey Kardashevskiy
2021-06-09 10:19 ` BALATON Zoltan
2021-06-06 22:21 ` BALATON Zoltan
2021-06-07 3:37 ` David Gibson
2021-06-07 22:20 ` BALATON Zoltan
2021-05-24 12:42 ` BALATON Zoltan
2021-05-25 5:29 ` David Gibson
2021-05-25 9:55 ` BALATON Zoltan
2021-05-27 5:31 ` David Gibson
2021-05-24 5:23 ` David Gibson
2021-05-24 9:57 ` BALATON Zoltan
2021-05-24 10:50 ` David Gibson
2021-05-29 18:10 ` BALATON Zoltan
2021-05-30 17:33 ` BALATON Zoltan
2021-05-31 13:07 ` BALATON Zoltan
2021-06-01 12:02 ` Alexey Kardashevskiy
2021-06-01 14:12 ` BALATON Zoltan
2021-06-04 6:21 ` David Gibson
2021-06-04 13:27 ` BALATON Zoltan
2021-06-07 3:02 ` David Gibson
2021-06-04 6:19 ` David Gibson
2021-06-04 13:50 ` BALATON Zoltan
2021-06-04 14:34 ` BALATON Zoltan
2021-06-07 3:05 ` David Gibson [this message]
2021-06-09 6:13 ` Alexey Kardashevskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YL2M+XP3Kw6w0UMr@yekko \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=balaton@eik.bme.hu \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.