From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH qemu v4] spapr: Kill SLOF
Date: Mon, 13 Jan 2020 17:05:00 +1000 [thread overview]
Message-ID: <20200113070500.GD19995@umbus> (raw)
In-Reply-To: <684e7d31-04d0-3176-5de2-c817ce1aedf3@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 3237 bytes --]
On Fri, Jan 10, 2020 at 11:51:32AM +1100, Alexey Kardashevskiy wrote:
>
>
> On 10/01/2020 10:32, Alexey Kardashevskiy wrote:
> >
> >
> > On 10/01/2020 10:05, Alexey Kardashevskiy wrote:
> >>
> >>
> >> On 08/01/2020 17:18, Alexey Kardashevskiy wrote:
> >>> The Petitboot bootloader is way more advanced than SLOF is ever going to
> >>> be as Petitboot comes with the full-featured Linux kernel with all
> >>> the drivers, and initramdisk with quite user friendly interface.
> >>> The problem with ditching SLOF is that an unmodified pseries kernel can
> >>> either start via:
> >>> 1. kexec, this requires presence of RTAS and skips
> >>> ibm,client-architecture-support entirely;
> >>> 2. normal boot, this heavily relies on the OF1275 client interface to
> >>> fetch the device tree and do early setup (claim memory).
> >>>
> >>> This adds a new bios-less mode to the pseries machine: "bios=on|off".
> >>> When enabled, QEMU does not load SLOF and jumps to the kernel from
> >>> "-kernel".
> >>>
> >>> The client interface is implemented exactly as RTAS - a 20 bytes blob,
> >>> right next after the RTAS blob. The entry point is passed to the kernel
> >>> via GPR5.
> >>>
> >>> This implements a handful of client interface methods just to get going.
> >>> In particular, this implements the device tree fetching,
> >>> ibm,client-architecture-support and instantiate-rtas.
> >>>
> >>> This implements changing FDT properties for RTAS (for vmlinux and zImage)
> >>> and initramdisk location (for zImage). To make this work, this skips
> >>> fdt_pack() when bios=off as not packing the blob leaves some room for
> >>> appending.
> >>>
> >>> This assigns "phandles" to device tree nodes as there is no more SLOF
> >>> and OF nodes addresses of which served as phandle values.
> >>> This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
> >>> phandles are regenerated at every FDT rebuild.
> >>>
> >>> This defines phandles for VIO devices to have phandle assigned to
> >>> the default stdout device at the point when we write "/chosen/stdout"
> >>> which an ihandle which the OS uses to write to the console.
> >>
> >>
> >> And I do not really need to preallocate phandles for stdout as it is a
> >> leftover from when I populated /chosen/stdout before populating VIO
> >> nodes, now /chosen/stdout is added at the very end. Thanks,
> >
> >
> > Ah noo, I do, to implement "write" to the selected stdout as I need to
> > trace ihandle back to Object* and object_resolve_path() does not know
> > about FDT path, it is /machine/peripheral/svty0 in QOM. The commit log
> > needs an update, or this needs a fix but I cannot think of a nicer one.
> > Thanks,
>
>
> I just might extend instances to do real instances, i.e. associate
> ihandle with phandle _and_ Object*, I just need a helper to find Object
> which matches what qdev_get_fw_dev_path() returns. Fun :)
If you only allow one instance per device, could you just make
ihandles == phandle | CONSTANT?
--
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:[~2020-01-13 7:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 6:18 [PATCH qemu v4] spapr: Kill SLOF Alexey Kardashevskiy
2020-01-08 22:35 ` Alexey Kardashevskiy
2020-01-09 23:05 ` Alexey Kardashevskiy
2020-01-09 23:32 ` Alexey Kardashevskiy
2020-01-10 0:51 ` Alexey Kardashevskiy
2020-01-13 7:05 ` David Gibson [this message]
2020-01-14 0:33 ` 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=20200113070500.GD19995@umbus \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--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.