[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer |
Date: |
Tue, 20 Aug 2013 23:41:45 +0100 |
On 20 August 2013 23:25, Mark Cave-Ayland <address@hidden> wrote:
> Upstream OpenBIOS now implements SBus probing in order to determine the
> contents of a physical bus slot, which is required to allow OpenBIOS to
> identify the framebuffer without help from the fw_cfg interface.
>
> SBus probing works by detecting the presence of an FCode program
> (effectively tokenised Forth) at the base address of each slot, and if
> present executes it so that it creates its own device node in the
> OpenBIOS device tree.
>
> The FCode ROM is generated as part of the OpenBIOS build and should
> generally be updated at the same time.
> hw/display/tcx.c | 7 +++++++
> hw/sparc/sun4m.c | 32 +++++++++++++++++++++++++-------
> pc-bios/QEMU,tcx.bin | Bin 0 -> 1242 bytes
Shouldn't this blob come in the same patch as an update to some
git module, so that we keep track of the sources used to build
the blob?
> --- a/hw/sparc/sun4m.c
> +++ b/hw/sparc/sun4m.c
> + fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, TCX_ROM_FILE);
> + if (fcode_filename) {
> + ret = load_image_targphys(fcode_filename, addr, FCODE_MAX_ROM_SIZE);
> + }
This looks like the wrong place for this -- surely the tcx device
should load its own fcode blob, not defer to the board code
to do it?
(For that matter, presumably if this is an SBus device then
the offsets of the ROM, DAC, etc etc are all fixed relative to
the base address of the SBus slot, and the tcx device itself
should be creating a container with all its component parts
at the right offset. But that's not an issue for this patch.)
thanks
-- PMM
Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer, Andreas Färber, 2013/08/21