On 13/06/2019 10:30, BALATON Zoltan wrote:
On Wed, 12 Jun 2019, Mark Cave-Ayland wrote:
OpenBIOS SPARC32 has always maintained a fallback option of an internal TCX driver if an FCode driver cannot be located on the TCX card itself.
Since QEMU's TCX adapter has supported FCode payloads for a long time then we only require this logic for non-QEMU builds. Otherwise we unintentionally install the fallback driver and device node even if the framebuffer card hasn't been installed into the machine.
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk
arch/sparc32/init.fs | 7 +++++-- drivers/sbus.c | 11 +++++++++++ 2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/sparc32/init.fs b/arch/sparc32/init.fs index 814c720..5e8805b 100644 --- a/arch/sparc32/init.fs +++ b/arch/sparc32/init.fs @@ -78,6 +78,9 @@ defer ignore-dfault
\ Load TCX FCode driver blob [IFDEF] CONFIG_DRIVER_SBUS - -1 value tcx-driver-fcode - " QEMU,tcx.bin" $encode-file to tcx-driver-fcode + [IFDEF] CONFIG_QEMU + [ELSE] + -1 value tcx-driver-fcode + " QEMU,tcx.bin" $encode-file to tcx-driver-fcode + [THEN] [THEN]
It looks strange that the driver is called QEMU,tcx but is not used on QEMU. Does it make sense to use it when not in QEMU at all? Should it be completely removed instead or maybe renamed to some other name when it's not related to QEMU any more?
The driver is still used in QEMU, it's just that the image is memory-mapped into the TCX card address space by QEMU where it is located and executed during SBus probe (QEMU contains its own copy of QEMU,tcx.bin in the pc-bios directory).
Also the commit message says that the problem is that driver should not be installed when TCX hardware is not present so maybe you should test for hardware presence instead of QEMU or not which may be the wrong conditional to decide if the driver is needed or not if I got this correctly.
(But it's possible I haven't understood something in which case just disregard my comment.)
The problem here is that the fallback works by "executing" an in-built copy of the FCode if a valid ROM can't be located during the SBus probe. But with -vga none this causes issues because it is the FCode that generates the TCX device node, and so you end up with the case where the DT node exists yet the underlying hardware isn't there and so things rapidly start to go downhill...
ATB,
Mark.