[PATCH 1/1] arm: qemu: support qfw

Simon Glass sjg at chromium.org
Sat Feb 20 12:54:41 CET 2021


Hi Asherah,

On Fri, 19 Feb 2021 at 18:14, Asherah Connor <ashe at kivikakk.ee> wrote:
>
> On 21/02/19 06:02:p, Heinrich Schuchardt wrote:
> > drivers/misc/qfw.c should be converted to the driver model instead of
> > initializing the driver in arch_early_init_r() on qemu-arm and
> > qemu_chipset_init() on qemu-x86.
> >
> > Cf. https://u-boot.readthedocs.io/en/latest/driver-model/index.html
> >
> > Please, coordinate the change with Simon.
>
> Understood.  I've played around a little bit with the DM and it
> shouldn't be too hard to convert.  Probably the biggest question in my
> mind is, should it be slotted into UCLASS_MISC?  Or do we create a qfw
> uclass?

Probably create a uclass. I expect there are operations and some
private data. We also need to think about testing, since all uclasses
need a sandbox test.

>
> I am also a little unsure on the division of responsibilities and
> configuration as we move this to DM.
>
> Right now, drivers/misc/qfw.c handles the QFW "protocol" entirely on its
> own, and it's the responsibility of arch/x86/cpu/qemu/qemu.c (and
> arch/arm/mach-qemu/qemu.c in this patch series) to mediate the
> communication between the QFW handler and the actual platform; i.e. on
> x86 we use PIO (and we simply must assume it is present if the config is
> enabled), and on Arm we use MMIO (and we use DT to detect and
> configure).
>
> In other words, on x86 including QFW means we need to just try PIO,
> whereas on Arm including QFW means we let the DM handle it if the node
> appears.  I'll try to make this work in code and hopefully someone can
> guide me a little on the Kconfig.

The cros_ec driver has different transports for the actual comms, so
it might be useful as an example.

>
>
> > Should cmd/qfw.c be enhanced to show if the ramfb device is present?
>
> Yes, once ramfb support is implemented, but I think that should come in
> a later patch series.  We will initialise ramfb if we detect an
> "etc/ramfb" entry in the qfw list, like here:
>
>     => qfw list
>     bios-geometry
>     bootorder
>     etc/acpi/rsdp
>     etc/acpi/tables
>     etc/boot-fail-wait
>     etc/ramfb
>     etc/smbios/smbios-anchor
>     etc/smbios/smbios-tables
>     etc/table-loader
>     etc/tpm/log
>     opt/test
>     vgaroms/vgabios-ramfb.bin
>     =>
>
> Including information on how much we allocated for the ramfb, where we
> placed it, etc. will be a job for a future "qfw ramfb" command.

What is a ramfb?

Regards,
Simon


More information about the U-Boot mailing list