Re: framebuffer console on old ATI

["John D. Baker" <jdbaker%consolidated.net@localhost>]

On Tue, 7 May 2024, Riccardo Mottola wrote:

> John D. Baker wrote:
> > As you have seen, the "radeon*" and "radeondrmkmsfb*" drivers do not
> > attach on "r100" class devices.  They have been explicitly excluded
> > because early in the DRMKMS integration in NetBSD, they exhibited the
> > "(almost) black-on-black" video problem described in:
> 
> I remember seeing that issue.. long time ago, but don't remember on
> which OS and hardware combination.
> 
> However, i checked a little better.
>  ATI Technologies Radeon
> Mobility M7 LW (rev. 0x00)
> 
> would be an RS250 chip, so a little bit newer. Does the same issue
> apply? or is it "blacklisted" for any other reason?

That looks like the same description of the radeon device in my T42
ThinkPad:

  $ grep Radeon /r0/diskless/slate/var/run/dmesg.boot
  vga0 at pci1 dev 0 function 0: ATI Technologies Radeon Mobility M7 LW (rev. 0x00)
  radeondrm0 at vga0: ATI Radeon LW RV200 Mobility 7500 M7

(radeondrm0 is the legacy UMS "radeondrm* at drm?" device)

As an R*200 device, it is not matched by the DRM2 code in NetBSD.

> Since I am endeavouring in compiling a kernel, I might try enabling it,
> if you tell me how. Just as a test, maybe magic happens.

The following patch (against -current from about 4 years ago) will
enable matching R100/R200 devices:


+Index: sys/external/bsd/drm2/radeon/radeon_pci.c
+===================================================================
+RCS file: /cvsroot/src/sys/external/bsd/drm2/radeon/radeon_pci.c,v
+retrieving revision 1.14
+diff -u -p -r1.14 radeon_pci.c
+--- sys/external/bsd/drm2/radeon/radeon_pci.c	24 Jan 2020 11:44:27 -0000	1.14
++++ sys/external/bsd/drm2/radeon/radeon_pci.c	28 May 2020 23:49:44 -0000
+@@ -126,7 +126,7 @@ extern const struct pci_device_id *const
+ extern const size_t radeon_n_device_ids;
+ 
+ /* Set this to false if you want to match R100/R200 */
+-bool radeon_pci_ignore_r100_r200 = true;
++bool radeon_pci_ignore_r100_r200 = false;
+ 
+ static bool
+ radeon_pci_lookup(const struct pci_attach_args *pa, unsigned long *flags)

> I also tried to compare with OpenBSD on another Laptop where
> framebwuffer runs wonderfully. It uses radeondrm0. I don't know how this
> in OpenBSD speak this compares to NetBSD.

I really don't know.  My understanding is that on OpenBSD and various
Penguin-OSes, these older ATI devices work fine.

I saw your message about trying "radeonfb* at pci?" in your kernel config.

I did the same for amd64 systems with ATI ES1000, which also exhibits
the "(almost) black-on-black" video problem if radeon*/radeondrmkmsfb* is
allowed to match it:

  vga0 at pci6 dev 3 function 0: ATI Technologies ES1000 (rev. 0x02)
  wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
  wsmux1: connecting to wsdisplay0
  radeondrm0 at vga0: ATI ES1000 RN50
  radeondrm0: Initialized radeon 1.29.0 20080613

but "radeonfb*" didn't attach and I got plain VGA instead.  "radeondrm0"
is the legacy UMS "radeondrm* at drm?".

I did remember to re-enable "wsdisplay* at wsemuldisplaydev?", but maybe
it failed because I forgot to re-enable the framebuffer font(s).

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645