Date: Mon, 30 Mar 2009 19:03:15 -0400 From: Miles Nordin <carton@Ivy.NET> To: freebsd-sparc64@freebsd.org Subject: Re: kernel panic with firewire PCI card Message-ID: <oqzlf2txzg.fsf@castrovalva.Ivy.NET> In-Reply-To: <20090330194350.GA2097@alchemy.franken.de> (Marius Strobl's message of "Mon, 30 Mar 2009 21:43:51 %2B0200") References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> <oqmyb4uxek.fsf@castrovalva.Ivy.NET> <20090330194350.GA2097@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1
Content-Type: text/plain; charset=US-ASCII
>>>>> "ms" == Marius Strobl <marius@alchemy.franken.de> writes:
ms> getting non-FCode/Sun graphics cards to work would be lots of
ms> work IMO better spent on improving the support for the
ms> "native" cards.
native cards are silly/doomed. Their 3D is too slow to be worth
supporting, there is no documentation for setting custom timings, they
have no panel-friendly digital output, and even in analog they cannot
push the resolutions attainable on relatively inexpensive modern
monitors. creator3D is probably among the best and maxes at 1080p
which is now the cheapest monitor you can buy within reason. You will
struggle to find any new monitor that can be driven by a native card
without pixel-scaling.
unfortunately there is not much point supporting modern cards either
since all but the most exotic are PCIe, and AIUI we don't run well on
any PCIe sparc64 equipment, and secondly the Linux folk have caved in
and failed to negotiate quality open-source drivers for any modern
card so even if you could bring up the card on the bus you would have
no Xorg .so to work with it---it's a miracle for them just to get
amd64 blobs with all the compliant groveling they do.
the approach is uniquely useful for video cards since it means you can
rely on VESA and leave the timing configuration job in proprietary
software instead of getting documentatino for it, just as you do with
the FCode cards, which seems to be what motivated uvesafb (they do not
just initialize the card but keep their VM around constantly).
HOWEVER, a genericized uvesafb that worked with more than just
framebuffers would be extremely useful for all sorts of things, even
on native i386. It is not only a way to solve an immediate problem
but a puzzle-piece for new device architectures. For example if we
had something like Linux's PCI hotplug, we could hot-unplug a RAID
card shackled with proprietary firmware, run the RAID configurator
built into its BIOS, and then hot-plugin the card and reprobe its
LUN's from freebsd. all over ssh.
the peecee platform will always dominate the market for PCI cards, yet
PCI busses will always be available on all kinds of notPeeCee
equipment. Until EFI takes over on $cheapCPU, a way to safely run
crappy proprietary BIOS addon ROMs inside a virtual machine with 1 VM
per card, will remain useful all over the place not just in X11. As
you said yourself it's already a de-facto requirement for full PCI
support.
EFI is also AIUI a native-code platform, so much of the VM would be
needed even after such a migration, the same way a ppc VM is needed to
really run the FCode on these speculated crappy Mac cards you mention
that just use F bytecode to jump to ppc machinecode.
--pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
iQCVAwUASdFPs4nCBbTaW/4dAQKo/wP/T4TwifbIFamVkofI3wbcxLFUN5hulyiV
mNVEfiXLLIg/uVFsZ23SFc4kexVR+sG+ZEUbbxLTKpEOgtEV5mtGJZdbiUNemCZ+
LQS5e+AtLzjfpYBrc1WmmKqHXa7wdlcXPovtLdTIc5WnfR4TyUE7bfJsxNyoqlir
p2CsHvf31xs=
=0eEh
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?oqzlf2txzg.fsf>