[sf-lug] /firmware/radeon

Rick Moen rick at linuxmafia.com
Sun Dec 20 20:43:07 PST 2015


Maestro, forgive me, but I found that difficult to follow, and it might
be impossible to help, given the data provided.  (However, read on.  I 
did some detective work anyway based on tiny clues late in your post.)

Quoting maestro (maestro415 at gmail.com):

> the box]
> toshiba satellite 32 bit laptop

Er, shouldn't you have at the _very_ minimum have posted the exact model
designation?  I'm sorry, but when I saw this bit, I had a sinking
feeling about the rest.

In the rest, it appeared as if the required firmware BLOB for some ATI
Radeon chipset was unable to load, but _what_ Radeon chipset?  If you'd
bothered to post the Toshiba model designation, it might have been
possible to figure out the video chipset, but since your description
went off the rails right at the beginning, the rest of us cannot
research your video chipset.

If you wanted to be truly helpful in helping others help you, you could
have posted the results of getting your video chip data from lspci, like
maybe...

$ lspci | grep VGA

I mean, c'mon, really.  You have the information about what hardware
this is, right in front of you.  It should have been obvious that that's 
critical information, but you didn't include it.  So, what, we're
supposed to guess?  You honestly think that's how getting 'an assist'
works?  By magic?  Midichlorians?

Knowing what video chipset you have should permit a sufficiently
determined helper to look up what firmware BLUB file it needs, and then
what Debian package contains it.

As Daniel suggested, package firmware-linux-nonfree is a very strong
possibility -- and installing it can't hurt.  ISTR that 'firmware-linux'
is a metapackage that brings in both firmware-linux-free and
firmware-linux-nonfree -- though I'm not sure about that.  What would 
_definitely_ eliminate some sources of trouble would be to install both
the firmware-linux-free and firmware-linux-nonfree packages.

Tip:  If you need to provide debugging data but aren't completely sure
which is the relevant portion of (say) logfile data, you can put it on
pastebin.com , and provide the URL.  In this case, the contents of
/var/log/dmesg and (if available) 


> #dmesg
> gives...
> 
> [   11.298320] [drm:r100_cp_init] *ERROR* Failed to load firmware!
> [   11.298386] radeon 0000:01:05.0: failed initializing CP (-12).
> [   11.298436] radeon 0000:01:05.0: Disabling GPU acceleration

It may be of interest that the 'DRM' here does not stand for Digital
Restrictions Management (what Our Lords in Hollywood call 'Digital
Rights Management') but rather Direct Rendering Manager.  (I am way out
of date on this stuff, but just now looked that up.)

'R100' is one of the major generational categories (families) of ATI
Radeon chipsets, and there are also 'R200' and 'R300' families of video
chips -- among others.

Here are some background docs about the 'drm' driver code, its pieces,
and how it all works together:  http://www.botchco.com/agd5f/?p=50

> [   11.298489] [drm] radeon: cp finalized

'cp' here is not the command /bin/cp, but rather Command Processor, a
hardware component name, part of the Radeon Graphics Processor Unit
(GPU).  (Again, I've just now looked that up, and am passing it along
for the interested.)

> #dmesg | grep firmware
> gives...
> [   10.405558] radeon 0000:01:05.0: firmware: failed to load radeon/R300_cp.bin (-2)
> [   10.405726] radeon 0000:01:05.0: Direct firmware load failed with error -2
> [   11.298320] [drm:r100_cp_init] *ERROR* Failed to load firmware!

(By the way, please don't line-wrap pasted lines of code.  That makes them
painful and difficult to read.  I've unwrapped the above.)

Ah.  Some searching on '0000:01:05.0' suggests that this is the PCI ID
of an ATI RS482 [Radeon Xpress 200M].

I'll bet that, if you were to post the super-obvious data from lspci,
you'd have posted:

$ lspci | grep VGA
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M]
$

That's a pretty old Radeon chip.  FYI, sometimes old chips cease to 
be supported by ongoing driver sets.  Rare, but it happens.
This Ubuntu page says that the 'RS482 [Radeon Xpress 200M]' is is a
'RS400/RS480' Radeon engineering name.
https://help.ubuntu.com/community/RadeonDriver
This X.org Project page says 'RS400/RS480' engineering names 
belong to the _R300_ family (ta-da!), your specific chip having 
marketing name '200M'.  Anyway, R300 -- so we're getting somewhere.

I'm betting that the correct firmware BLOB file for the Xpress 200M 
file is going to be /lib/firmware/radeon/R300_cp.bin, and that Debian
supplies that BLOB in package firmware-linux-nonfree .  So, install that
package.  It will be (obviously) in the 'non-free' package collection,
for which you might need to enable the package source in aptitude or
whatever you're using as a package tool.  (Personally, I've never cared
for aptitude, and use apt-get.)

If you eventually cannot get the open-source 'radeon' driver to work,
don't forget, as a last resort, you _can_ switch to ATI's proprietary,
binary-only 'fglrx' aka AMD Catalyst driver.






More information about the sf-lug mailing list