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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).