| Message ID | 1377037501-18498-1-git-send-email-mark.cave-ayland@ilande.co.uk |
|---|---|
| State | New |
| Headers | show |
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
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.
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
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.
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
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
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.
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.
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
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.
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); } }
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/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