[Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Mark Cave-Ayland]

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.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
CC: Blue Swirl <blauwirbel@gmail.com>
CC: Bob Breuer <breuerr@mc.net>
CC: Artyom Tarasenko <atar4qemu@gmail.com>
---
 hw/display/tcx.c     |    7 +++++++
 hw/sparc/sun4m.c     |   32 +++++++++++++++++++++++++-------
 pc-bios/QEMU,tcx.bin |  Bin 0 -> 1242 bytes
 3 files changed, 32 insertions(+), 7 deletions(-)
 create mode 100644 pc-bios/QEMU,tcx.bin

diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 24876d3..7a18d3e 100644
--- a/hw/display/tcx.c
+++ b/hw/display/tcx.c
@@ -43,6 +43,7 @@ typedef struct TCXState {
     QemuConsole *con;
     uint8_t *vram;
     uint32_t *vram24, *cplane;
+    MemoryRegion rom;
     MemoryRegion vram_mem;
     MemoryRegion vram_8bit;
     MemoryRegion vram_24bit;
@@ -537,6 +538,12 @@ static int tcx_init1(SysBusDevice *dev)
     vmstate_register_ram_global(&s->vram_mem);
     vram_base = memory_region_get_ram_ptr(&s->vram_mem);
 
+    /* FCode ROM */
+    memory_region_init_ram(&s->rom, NULL, "tcx.prom", 0x10000);
+    vmstate_register_ram_global(&s->rom);
+    memory_region_set_readonly(&s->rom, true);
+    sysbus_init_mmio(dev, &s->rom);
+
     /* 8-bit plane */
     s->vram = vram_base;
     size = s->vram_size;
diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index 942ca37..9d7814b 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -75,6 +75,8 @@
 
 #define ESCC_CLOCK 4915200
 
+#define FCODE_MAX_ROM_SIZE 0x10000
+
 struct sun4m_hwdef {
     hwaddr iommu_base, iommu_pad_base, iommu_pad_len, slavio_base;
     hwaddr intctl_base, counter_base, nvram_base, ms_kb_base;
@@ -526,11 +528,15 @@ static void apc_init(hwaddr power_base, qemu_irq cpu_halt)
     sysbus_connect_irq(s, 0, cpu_halt);
 }
 
+#define TCX_ROM_FILE  "QEMU,tcx.bin"
+
 static void tcx_init(hwaddr addr, int vram_size, int width,
                      int height, int depth)
 {
     DeviceState *dev;
     SysBusDevice *s;
+    char *fcode_filename = NULL;
+    int ret = -1;
 
     dev = qdev_create(NULL, "SUNW,tcx");
     qdev_prop_set_uint32(dev, "vram_size", vram_size);
@@ -539,22 +545,34 @@ static void tcx_init(hwaddr addr, int vram_size, int width,
     qdev_prop_set_uint16(dev, "depth", depth);
     qdev_init_nofail(dev);
     s = SYS_BUS_DEVICE(dev);
+    /* FCode ROM */
+    sysbus_mmio_map(s, 0, addr);
     /* 8-bit plane */
-    sysbus_mmio_map(s, 0, addr + 0x00800000ULL);
+    sysbus_mmio_map(s, 1, addr + 0x00800000ULL);
     /* DAC */
-    sysbus_mmio_map(s, 1, addr + 0x00200000ULL);
+    sysbus_mmio_map(s, 2, addr + 0x00200000ULL);
     /* TEC (dummy) */
-    sysbus_mmio_map(s, 2, addr + 0x00700000ULL);
+    sysbus_mmio_map(s, 3, addr + 0x00700000ULL);
     /* THC 24 bit: NetBSD writes here even with 8-bit display: dummy */
-    sysbus_mmio_map(s, 3, addr + 0x00301000ULL);
+    sysbus_mmio_map(s, 4, addr + 0x00301000ULL);
     if (depth == 24) {
         /* 24-bit plane */
-        sysbus_mmio_map(s, 4, addr + 0x02000000ULL);
+        sysbus_mmio_map(s, 5, addr + 0x02000000ULL);
         /* Control plane */
-        sysbus_mmio_map(s, 5, addr + 0x0a000000ULL);
+        sysbus_mmio_map(s, 6, addr + 0x0a000000ULL);
     } else {
         /* THC 8 bit (dummy) */
-        sysbus_mmio_map(s, 4, addr + 0x00300000ULL);
+        sysbus_mmio_map(s, 5, addr + 0x00300000ULL);
+    }
+
+    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);
+    }
+
+    if (ret < 0 || ret > FCODE_MAX_ROM_SIZE) {
+        fprintf(stderr, "qemu: could not load prom '%s'\n", TCX_ROM_FILE);
+        exit(1);
     }
 }
 
diff --git a/pc-bios/QEMU,tcx.bin b/pc-bios/QEMU,tcx.bin
new file mode 100644
index 0000000000000000000000000000000000000000..a8ddd70ef35355c30d7cffd2e1b57f877572a3ca
GIT binary patch
literal 1242
zcmZ8hxl-Fu6xFkZeQXTK&j!qn**AgB64rt)Bt;q~lNw`zm4NNY!htH3naNM2fFJOT
zMvP0-C0(jantVh4Aoo6xa1s^oY*+VceZQe4G)@2MLG!<*wdh7l>uTIJS~6X!TIGUW
zshM@VXjRM)cF`?Cvpk3g+5cZyvh4GctJ2Vej2Eq{TQUo_TT@n;tP8trnS~qIYFqk)
zhb|xDvgIM-Bg7c>5oUxB{jz0fba;q04NWkK6PaYvO+-5+l3=3g9(st(aMT+_eL-Xp
zS>Pzi&MgtCBH<xLBxjJ5X2Lc79I-RN1fw1XiBvht1kn(YTXu$tP?d*~rV&z?I!ewV
zJ7Zj|(TMS;p{r;jh$e$5+cY97nj+_x&zf!;aplYe#j`>2T+^VJL^bn4@j?(SHjQ2t
zEd|kX5Un&ln11eFgno#yNaaORNP4`hK87&@6QdZ1DI_M4RXBxdg)^8_IFChzOIT5u
z!H~jk^eF7dpu!m93VUHFOd`c7!;W<>44SysnK-5@CNQb6GjUewc`PVg!m`57#Dvmm
z3@GeO>{B`k$=I2g^K&Acmyyeps%e))F}jGnFQY6gS1##059<%KZ1A#4ALEvvdw%>e
zkM;3d>ucn+a#3-zc;??@>%~icn>x1s1!}qNqZ=E@Jz|~I4&9}}KNB09WbFFb#!gG(
z`1PwdEAHuaNXTf>u2nBiZp5&MJs<0L2Wf2?yV!gb1@TtAqctg`C&i*;)oQ{(7a~XE
zGJ7O0vf^`tn(q6E@`Zp-oWd%49<d>H*SWGpTE=LIxx+u6Fj88kfi)y3SM>-x)J=C9
ztj2gsy-=+<rzK&q^M#$#-%f;_u6pgJeA=$~#JbecVb$a8uO1oI<H-sC`hLhx)xJJ+
ztoQ9M2i&FJ*5DD5_TItw%8}Y;NPt9)Hx0FCw9lo2d;W-}ZkJu>$&+!Cmg8JiU3z3m
K?1|A9_O(BcTLJ$7

literal 0
HcmV?d00001

-- 
1.7.10.4

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Peter Maydell]

On 20 August 2013 23:25, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> 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

[Mark Cave-Ayland]

On 20/08/13 23:41, Peter Maydell wrote:

> On 20 August 2013 23:25, Mark Cave-Ayland<mark.cave-ayland@ilande.co.uk>  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?

Unfortunately the OpenBIOS repository is still based in SVN :(  There is 
a git-svn mirror on git.qemu.org, but currently it needs to be manually 
updated and so is generally not particularly helpful. For the 1.6 
release I got Anthony to manually update the repository on git.qemu.org 
so that the git submodule reference was updated as part of the pull request.

The main reason for not updating the git submodule in this particular 
commit is because this is actually a precursor to another larger sun4m 
framebuffer patch, and once both these patches are hopefully accepted 
then my plan is to send a single pull request to update all 3 of the 
OpenBIOS images at the same time rather than to split architectures 
across different OpenBIOS versions.

As the existing OpenBIOS image won't bother to check for the new FCode 
ROMs then in the short term it will use the existing hardwired device 
nodes and so remain bisectable.

>> --- 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?

Good point - that does make more sense. I'll rework the patch with the 
ROM load moved into the device itself.

> (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.)

Indeed - I suspect a lot of the sparc-softmmu code is still based upon 
legacy APIs :/


ATB,

Mark.

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Peter Maydell]

On 21 August 2013 15:44, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
> On 20/08/13 23:41, Peter Maydell wrote:
>> 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?

> Unfortunately the OpenBIOS repository is still based in SVN :(  There is a
> git-svn mirror on git.qemu.org, but currently it needs to be manually
> updated and so is generally not particularly helpful. For the 1.6 release I
> got Anthony to manually update the repository on git.qemu.org so that the
> git submodule reference was updated as part of the pull request.
>
> The main reason for not updating the git submodule in this particular commit
> is because this is actually a precursor to another larger sun4m framebuffer
> patch, and once both these patches are hopefully accepted then my plan is to
> send a single pull request to update all 3 of the OpenBIOS images at the
> same time rather than to split architectures across different OpenBIOS
> versions.

In that case we should defer adding this fcode rom blob until then.
I really don't like the idea of having random binary blobs in our git
repo (and thus in our release tarballs) which aren't tied exactly to
the sources you need to rebuild them.

(It's the pain of managing this which is why I don't like binary blobs
at all, in fact. But they're a fact of life given that mostly we don't have
easy cross-compilation setups  :-( )

-- PMM

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Mark Cave-Ayland]

On 21/08/13 16:34, Peter Maydell wrote:

>> Unfortunately the OpenBIOS repository is still based in SVN :(  There is a
>> git-svn mirror on git.qemu.org, but currently it needs to be manually
>> updated and so is generally not particularly helpful. For the 1.6 release I
>> got Anthony to manually update the repository on git.qemu.org so that the
>> git submodule reference was updated as part of the pull request.
>>
>> The main reason for not updating the git submodule in this particular commit
>> is because this is actually a precursor to another larger sun4m framebuffer
>> patch, and once both these patches are hopefully accepted then my plan is to
>> send a single pull request to update all 3 of the OpenBIOS images at the
>> same time rather than to split architectures across different OpenBIOS
>> versions.
>
> In that case we should defer adding this fcode rom blob until then.
> I really don't like the idea of having random binary blobs in our git
> repo (and thus in our release tarballs) which aren't tied exactly to
> the sources you need to rebuild them.
>
> (It's the pain of managing this which is why I don't like binary blobs
> at all, in fact. But they're a fact of life given that mostly we don't have
> easy cross-compilation setups  :-( )

Okay so in that case what is the best way to manage to process? If both 
this and the follow-up patchset are committed first without the 
associated FCode ROM images then qemu-system-sparc will be broken until 
the main OpenBIOS images are updated because (quite rightly) the TCX 
driver will attempt to load the ROM at startup and fail because they 
aren't present...?

Is the best way to send a pull request for the update OpenBIOS images 
plus associated FCode ROMs first and then work on getting the QEMU 
patches applied? This isn't strictly correct, but the display code 
currently has a "panic" fallback in place where it should try and load 
an inbuilt TCX driver if it doesn't find a valid display ROM during probe.


ATB,

Mark.

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Peter Maydell]

On 21 August 2013 17:29, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
> On 21/08/13 16:34, Peter Maydell wrote:
>
>>> Unfortunately the OpenBIOS repository is still based in SVN :(  There is
>>> a
>>> git-svn mirror on git.qemu.org, but currently it needs to be manually
>>> updated and so is generally not particularly helpful. For the 1.6 release
>>> I
>>> got Anthony to manually update the repository on git.qemu.org so that the
>>> git submodule reference was updated as part of the pull request.
>>>
>>> The main reason for not updating the git submodule in this particular
>>> commit
>>> is because this is actually a precursor to another larger sun4m
>>> framebuffer
>>> patch, and once both these patches are hopefully accepted then my plan is
>>> to
>>> send a single pull request to update all 3 of the OpenBIOS images at the
>>> same time rather than to split architectures across different OpenBIOS
>>> versions.
>>
>>
>> In that case we should defer adding this fcode rom blob until then.
>> I really don't like the idea of having random binary blobs in our git
>> repo (and thus in our release tarballs) which aren't tied exactly to
>> the sources you need to rebuild them.
>>
>> (It's the pain of managing this which is why I don't like binary blobs
>> at all, in fact. But they're a fact of life given that mostly we don't
>> have
>> easy cross-compilation setups  :-( )
>
>
> Okay so in that case what is the best way to manage to process? If both this
> and the follow-up patchset are committed first without the associated FCode
> ROM images then qemu-system-sparc will be broken until the main OpenBIOS
> images are updated because (quite rightly) the TCX driver will attempt to
> load the ROM at startup and fail because they aren't present...?
>
> Is the best way to send a pull request for the update OpenBIOS images plus
> associated FCode ROMs first and then work on getting the QEMU patches
> applied? This isn't strictly correct, but the display code currently has a
> "panic" fallback in place where it should try and load an inbuilt TCX driver
> if it doesn't find a valid display ROM during probe.

I guess Anthony gets to make the call on what we should do here,
but my opinion is that if the problem is effectively "these QEMU
changes must be in sync with these updated OpenBIOS images" then
(a) something's wrong because having QEMU that closely coupled
to firmware is rather dubious and (b) there should be a single patch
[and thus a single git commit] which both updates QEMU and updates
the blobs in our repo and updates the gitmodule to point at the
sources we used to build those blobs].

-- PMM

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Mark Cave-Ayland]

On 21/08/13 18:06, Peter Maydell wrote:

>> Okay so in that case what is the best way to manage to process? If both this
>> and the follow-up patchset are committed first without the associated FCode
>> ROM images then qemu-system-sparc will be broken until the main OpenBIOS
>> images are updated because (quite rightly) the TCX driver will attempt to
>> load the ROM at startup and fail because they aren't present...?
>>
>> Is the best way to send a pull request for the update OpenBIOS images plus
>> associated FCode ROMs first and then work on getting the QEMU patches
>> applied? This isn't strictly correct, but the display code currently has a
>> "panic" fallback in place where it should try and load an inbuilt TCX driver
>> if it doesn't find a valid display ROM during probe.
>
> I guess Anthony gets to make the call on what we should do here,
> but my opinion is that if the problem is effectively "these QEMU
> changes must be in sync with these updated OpenBIOS images" then
> (a) something's wrong because having QEMU that closely coupled
> to firmware is rather dubious and (b) there should be a single patch
> [and thus a single git commit] which both updates QEMU and updates
> the blobs in our repo and updates the gitmodule to point at the
> sources we used to build those blobs].

Just to clarify that all of the changes don't have to go in one commit, 
since the current OpenBIOS has a (temporary) fallback to use an internal 
copy of the old hard-wired TCX FCode blob if it can't locate a suitable 
display ROM. While this may be removed longer term, I think it's a 
reasonable compromise in order to maintain bisectability of the QEMU 
tree at the moment.

Based upon this thread, my preferred method would be this:

1) Get Anthony to update the OpenBIOS git repository on git.qemu.org

2) Update the existing OpenBIOS images for all architectures on my
    github account and send a pull request

3) Rework the patch based upon yours/Andreas' suggestions and resubmit
    to the qemu-devel list, including the new TCX FCode ROM

4) Get TCX driver patch applied

Any future updates to OpenBIOS will also update the TCX ROM image, 
although I'm fairly sure that changes in the ROM aren't likely to occur 
often if at all. Does that sound reasonable to everyone?


ATB,

Mark.

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Andreas Färber]

Am 21.08.2013 00:41, schrieb Peter Maydell:
> On 20 August 2013 23:25, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> 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?

I concur. Independent of how to order the .gitmodules update, this patch
is missing Makefile support to actually copy the new binary from
OpenBIOS build to the location it is being added to as binary here.

>> --- 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.)

I vaguely recall Mark telling me that SBus is not really
qdev'ified/QOM'ified, right?

PCI devices have support for ROM files, too, and I think they just set
the file name and generic PCI code takes care of the actual loading.
Maybe we would want to do the same for SBus? We're not in a rush yet so
getting this designed right probably only takes a week or so...

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Mark Cave-Ayland]

On 21/08/13 18:54, Andreas Färber wrote:

>> 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?
>
> I concur. Independent of how to order the .gitmodules update, this patch
> is missing Makefile support to actually copy the new binary from
> OpenBIOS build to the location it is being added to as binary here.

Okay that's something else to add to the v2 :)

>>> --- 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.)
>
> I vaguely recall Mark telling me that SBus is not really
> qdev'ified/QOM'ified, right?
>
> PCI devices have support for ROM files, too, and I think they just set
> the file name and generic PCI code takes care of the actual loading.
> Maybe we would want to do the same for SBus? We're not in a rush yet so
> getting this designed right probably only takes a week or so...

Currently there is no concept of an SBus in QEMU, since the bus address 
lines are effectively mapped to the processor bus (and so the standard 
sysbus calls work just fine). I know this isn't the complete truth with 
respect to real hardware, though I suspect Blue/Bob could expand further 
on this if required.


ATB,

Mark.

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Andreas Färber]

Am 21.08.2013 20:52, schrieb Mark Cave-Ayland:
> On 21/08/13 18:54, Andreas Färber wrote:
> 
>>> 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?
>>
>> I concur. Independent of how to order the .gitmodules update, this patch
>> is missing Makefile support to actually copy the new binary from
>> OpenBIOS build to the location it is being added to as binary here.
> 
> Okay that's something else to add to the v2 :)

On second thoughts, more important than Makefile changes (which would
depend on the OpenBIOS gitmodule update) would be to document textually
in the README wherever the openbios-sparc origin is tracked that this
file comes from OpenBIOS rXXXX, too.

>>>> --- 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.)
>>
>> I vaguely recall Mark telling me that SBus is not really
>> qdev'ified/QOM'ified, right?
>>
>> PCI devices have support for ROM files, too, and I think they just set
>> the file name and generic PCI code takes care of the actual loading.
>> Maybe we would want to do the same for SBus? We're not in a rush yet so
>> getting this designed right probably only takes a week or so...
> 
> Currently there is no concept of an SBus in QEMU, since the bus address
> lines are effectively mapped to the processor bus (and so the standard
> sysbus calls work just fine). I know this isn't the complete truth with
> respect to real hardware, though I suspect Blue/Bob could expand further
> on this if required.

Seems I mixed that up with CBus then. ;)

So, TCX is a SysBusDevice. How do I recognize which devices are SBus
devices? Do you have a list of files/types or some recipe to find out?

With QOM it would be easily possible to derive a TYPE_SBUS_DEVICE from
TYPE_SYS_BUS_DEVICE and have TYPE_TCX be derived from it. Then
SBusDeviceClass could supply a rom_file field, which generic SBus code
loads in its realizefn while still being able to use sysbus_*() API.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Mark Cave-Ayland]

On 24/08/13 18:46, Andreas Färber wrote:

> Am 21.08.2013 20:52, schrieb Mark Cave-Ayland:
>> On 21/08/13 18:54, Andreas Färber wrote:
>>
>>>> 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?
>>>
>>> I concur. Independent of how to order the .gitmodules update, this patch
>>> is missing Makefile support to actually copy the new binary from
>>> OpenBIOS build to the location it is being added to as binary here.
>>
>> Okay that's something else to add to the v2 :)
>
> On second thoughts, more important than Makefile changes (which would
> depend on the OpenBIOS gitmodule update) would be to document textually
> in the README wherever the openbios-sparc origin is tracked that this
> file comes from OpenBIOS rXXXX, too.

Sure - we already do this for OpenBIOS updates anyhow, so all that is 
required here is to add the FCode ROM to the list of filenames given in 
the README.

Given that the fallback seems to be working fine, I'll send Anthony a 
pull request to update the main OpenBIOS images so at least any 
subsequent patches can be rebased from that.

(cut)

>>> I vaguely recall Mark telling me that SBus is not really
>>> qdev'ified/QOM'ified, right?
>>>
>>> PCI devices have support for ROM files, too, and I think they just set
>>> the file name and generic PCI code takes care of the actual loading.
>>> Maybe we would want to do the same for SBus? We're not in a rush yet so
>>> getting this designed right probably only takes a week or so...
>>
>> Currently there is no concept of an SBus in QEMU, since the bus address
>> lines are effectively mapped to the processor bus (and so the standard
>> sysbus calls work just fine). I know this isn't the complete truth with
>> respect to real hardware, though I suspect Blue/Bob could expand further
>> on this if required.
>
> Seems I mixed that up with CBus then. ;)
>
> So, TCX is a SysBusDevice. How do I recognize which devices are SBus
> devices? Do you have a list of files/types or some recipe to find out?

I don't have any official documentation, but it is possible to see where 
each device belongs by launching qemu-system-sparc with each machine 
type and issuing "show-devs". Anything under /iommu/sbus is located on 
the SBus, and using drivers/sbus.c in the OpenBIOS source it's possible 
to map the SBus physical slot number to its equivalent sysbus address.

> With QOM it would be easily possible to derive a TYPE_SBUS_DEVICE from
> TYPE_SYS_BUS_DEVICE and have TYPE_TCX be derived from it. Then
> SBusDeviceClass could supply a rom_file field, which generic SBus code
> loads in its realizefn while still being able to use sysbus_*() API.

I suspect that the hard bit is working out the slot<->address mappings 
for all of the devices above for each machine; once that is done then I 
think you should be able to model SBus using just a MemoryRegion and 
some generic FCode ROM loader code.


HTH,

Mark.