All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Date: Sun, 26 Sep 2021 12:55:32 -0600	[thread overview]
Message-ID: <CAPnjgZ2NCRVxKULWR1JjZU+D9saJ7fbZ=yHmWTSr3ufHxLYg-g@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8S2=7rOKxeqcW+kw0BVPO3PUJGSUH-ioN7=c=U7zQxvg@mail.gmail.com>

Hi Peter,

On Sun, 26 Sept 2021 at 12:47, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Sun, 26 Sept 2021 at 19:34, Simon Glass <sjg@chromium.org> wrote:
> >
> > At present qemu creates a device tree automatically with the 'virt' generic
> > virtual platform. This is very convenient in most cases but there is not
> > much control over what is generated.
> >
> > Add a way to provide a device tree binary file with additional properties
> > to add before booting. This provides flexibility for situations where
> > Linux needs some tweak to operate correctly. It also allows configuration
> > information to be passed to U-Boot, supporting verified boot, for example.
>
> So, I'm strongly inclined to say "nope" here. The device
> tree virt generates is supposed to entirely describe the
> virtual hardware we pass to the guest. If a guest doesn't
> work with that, then either we're generating bogus dtb info
> or the guest is not handling the dtb we pass it, and one
> or the other should be fixed.

Thanks for the response.

In the case of U-Boot at least, it uses the devicetree for
configuration (it is a boot loader, so there is no user space to
provide configuration). So the current setup is not sufficient to boot
it correctly in all cases. On the other hand, the 'virt' feature is
very useful for testing U-Boot, so it would be great to be able to
support this.

I also forgot to ask about testing, but am happy to add a test if you
can give me some pointers.

Regards,
Simon


  reply	other threads:[~2021-09-26 18:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-26 18:34 [PATCH] hw/arm/virt: Allow additions to the generated device tree Simon Glass
2021-09-26 18:46 ` Peter Maydell
2021-09-26 18:55   ` Simon Glass [this message]
2021-09-27  8:48     ` Peter Maydell
2021-09-27 15:17       ` Simon Glass
2021-09-27 15:45         ` Peter Maydell
2021-09-27 16:04           ` Simon Glass
2021-09-27 16:49             ` Peter Maydell
2021-09-27 20:12               ` Simon Glass
2021-09-28  9:20                 ` Peter Maydell
2021-09-29  3:01                   ` Simon Glass
2021-09-29  9:09                     ` Peter Maydell
2021-09-29 15:09                       ` Simon Glass
2021-09-29 19:44                         ` Andrew Jones
2021-11-03 11:39           ` Alex Bennée
2021-11-03 13:17             ` François Ozog
2021-11-05 15:50               ` François Ozog
2023-02-07 18:39                 ` Simon Glass

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='CAPnjgZ2NCRVxKULWR1JjZU+D9saJ7fbZ=yHmWTSr3ufHxLYg-g@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@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.