From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot@lists.denx.de, Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>,
Anatolij Gustschin <agust@denx.de>, Tom Rini <trini@konsulko.com>,
Bin Meng <bmeng.cn@gmail.com>, Asherah Connor <ashe@kivikakk.ee>,
Alexander Graf <agraf@csgraf.de>,
Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default
Date: Mon, 28 Aug 2023 21:28:58 +0300 [thread overview]
Message-ID: <3ff5dcb5-27f6-4529-a186-b16130d4249e@gmail.com> (raw)
In-Reply-To: <CAPnjgZ33DwdxrW7ys9n8DRMnbpKdzqunEozOFf-5LKpnhh3bZA@mail.gmail.com>
On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> Hi Alper,
> On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>
>> On 2023-08-22 21:56 +03:00, Simon Glass wrote:
>>> Hi Alper,
>>>
>>> On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>>>
>>>> From: Alexander Graf <agraf@csgraf.de>
>>>>
>>>> Now that we have everything in place to support ramfb, let's wire it up
>>>> by default in the ARM QEMU targets. That way, you can easily use a
>>>> graphical console by just passing -device ramfb to the QEMU command line.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@csgraf.de>
>>>> [Alper: Rebase on bochs changes, add pre-reloc init, error handling]
>>>> Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
>>>> Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
>>>> - Drop env changes from ARM (necessary but in prerequisite series)
>>>> - Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
>>>> - Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
>>>> - Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU
>>>>
>>>> arch/arm/Kconfig | 3 +++
>>>> board/emulation/qemu-arm/qemu-arm.c | 41 +++++++++++++++++++++++++++++
>>>> 2 files changed, 44 insertions(+)
>>>>
>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>> index 1fd3ccd1607f..7afe26ac804f 100644
>>>> --- a/arch/arm/Kconfig
>>>> +++ b/arch/arm/Kconfig
>>>> @@ -1046,6 +1046,9 @@ config ARCH_QEMU
>>>> imply USB_XHCI_PCI
>>>> imply USB_KEYBOARD
>>>> imply CMD_USB
>>>> + imply VIDEO_RAMFB
>>>> + imply BOARD_EARLY_INIT_F
>>>> + imply BOARD_EARLY_INIT_R
>>>>
>>>> config ARCH_RMOBILE
>>>> bool "Renesas ARM SoCs"
>>>> diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c
>>>> index 942f1fff5717..23ef31cb7feb 100644
>>>> --- a/board/emulation/qemu-arm/qemu-arm.c
>>>> +++ b/board/emulation/qemu-arm/qemu-arm.c
>>>> @@ -11,6 +11,7 @@
>>>> #include <fdtdec.h>
>>>> #include <init.h>
>>>> #include <log.h>
>>>> +#include <qfw.h>
>>>> #include <usb.h>
>>>> #include <virtio_types.h>
>>>> #include <virtio.h>
>>>> @@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
>>>> struct mm_region *mem_map = qemu_arm64_mem_map;
>>>> #endif
>>>>
>>>> +int board_early_init_f(void)
>>>> +{
>>>> + struct udevice *dev;
>>>> + int ret;
>>>> +
>>>> + /*
>>>> + * Make sure we enumerate the QEMU Firmware device to bind ramfb
>>>> + * so video_reserve() can reserve memory for it.
>>>> + */
>>>> + if (IS_ENABLED(CONFIG_QFW)) {
>>>> + ret = qfw_get_dev(&dev);
>>>> + if (ret) {
>>>> + log_err("Failed to get QEMU FW device: %d\n", ret);
>>>
>>> We should only present an error if the device is present but
>>> failed...so if the user doesn't provide the flag, all should be well.
>>
>> I don't understand what you mean by "user doesn't provide the flag". But
>> I assume this should ignore the error (unless what?) so that we can
>> continue to boot. Would that apply for board_early_init_r below as well?
>
> I thought you said there was a qemu flag to enable ramfb? So add it to
> the DT and then the device can (in its bind routine) decide not to be
> bound by returning -ENODEV
Ah. I'm not used to calling them flags, especially those that have
values as in "-device ramfb". My mind jumped to DM_FLAG_PRE_RELOC /
bootph-some-ram.
But note that what this code tries to probe here is not the ramfb
device, it's the bus/parent of that. If this fails, we can't know if the
user specified "-device ramfb" or not.
Is the parent node's device probed by the time .bind() is called? Or,
can I have it probed by calling qfw_get_dev() (which is just
uclass_first_device_err(UCLASS_QFW, ...))?
next prev parent reply other threads:[~2023-08-28 18:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 12:10 [PATCH v2 0/7] Add support for QEMU's ramfb display Alper Nebi Yasak
2023-08-22 12:10 ` [PATCH v2 1/7] qfw: Add WRITE definition Alper Nebi Yasak
2023-08-22 12:10 ` [PATCH v2 2/7] ramfb: Add driver for ramfb display Alper Nebi Yasak
2023-08-22 18:56 ` Simon Glass
2023-08-22 12:10 ` [PATCH v2 3/7] qfw: Spawn ramfb device if its file is present Alper Nebi Yasak
2023-08-22 18:56 ` Simon Glass
2023-08-28 10:33 ` Alper Nebi Yasak
2023-08-22 12:10 ` [PATCH v2 4/7] qfw: Add flag to allow probing before relocation Alper Nebi Yasak
2023-08-22 18:56 ` Simon Glass
2023-08-28 15:22 ` Alper Nebi Yasak
2023-08-28 15:27 ` Tom Rini
2023-08-22 12:10 ` [PATCH v2 5/7] arm: qemu: Enable ramfb by default Alper Nebi Yasak
2023-08-22 18:56 ` Simon Glass
2023-08-28 15:46 ` Alper Nebi Yasak
2023-08-28 17:54 ` Simon Glass
2023-08-28 18:28 ` Alper Nebi Yasak [this message]
2023-08-28 20:32 ` Alexander Graf
2023-08-28 20:38 ` Simon Glass
2023-08-28 20:56 ` Alexander Graf
2023-08-22 12:10 ` [PATCH v2 6/7] riscv: " Alper Nebi Yasak
2023-08-22 18:56 ` Simon Glass
2023-08-22 12:10 ` [PATCH v2 7/7] x86: " Alper Nebi Yasak
2023-08-22 18:56 ` Simon Glass
2023-08-28 15:40 ` Alper Nebi Yasak
2023-08-28 15:47 ` Tom Rini
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=3ff5dcb5-27f6-4529-a186-b16130d4249e@gmail.com \
--to=alpernebiyasak@gmail.com \
--cc=agraf@csgraf.de \
--cc=agust@denx.de \
--cc=ashe@kivikakk.ee \
--cc=bmeng.cn@gmail.com \
--cc=mark.kettenis@xs4all.nl \
--cc=rayagonda.kokatanur@broadcom.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=tuomas.tynkkynen@iki.fi \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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.