# Firmware loading.

## dE_logics

I've always been in problems with by graphs chip, ATI x1270 belonging to RS690M chipset. On enabling KMS, I used to get ~250 FPS on glxgears, but the desktop felt very sluggish (slow 2d acceleration?). On disabling KMS, the desktop was a lot more responsive.

Recently I tried out Debian, issue was the same as with Gentoo. Debian kernel does not come with KMS enabled so it was moderately responsive.

The I installed Linux-firmware and Linux-firmware-nonfree to get a very responsive desktop + the FPS of glxgears reached 900.

I peeped into the Debian kernel has not been configured to build the firmware, it has "Prevent firmware from being built" active in the device drivers options.

So, before I get back to Gentoo, I want to clarify a few things so that I don't have to waist time experimenting.

What have these Debian guys done? I think they build the firmware using the kernel itself, and the resultant firmware files got to linux-firmware (free) package where as the proprietary binary blobs (which are not included in the kernel) are in the Linux-firmware-nonfree package. Is it so? If it is, I think what I have to do in Gentoo is uncheck "Prevent firmware from being built" (and optionally build the firmware into the kernel), and then install linux-firmware package. 

Speaking of linux-firmware, will it contain only the non-free firmware (since the free ones are included in the kernel)?

----------

## mbar

 *dE_logics wrote:*   

> ... install linux-firmware package. 
> 
> 

 

Or maybe "radeon-ucode".

----------

## dE_logics

Yeah, they are included in that.

Actually when it comes to firmware portage appears to be a mess... tons of repetitive packages.

----------

## dE_logics

Dudes, it does NOT work. I'm still getting 150 FPS.  :Evil or Very Mad: 

The kernel doesn't appear to be loading the firmware. dmesg | grep firmware has no output.

On Debian it does acknowledge.

----------

## dE_logics

It appears to be a udev issue - 

```
monitor will print the received events for:

UDEV - the event which udev sends out after rule processing

KERNEL - the kernel uevent

KERNEL[1293033506.572817] add      /devices/platform/radeon_cp.0 (platform)

UDEV_LOG=3

ACTION=add

DEVPATH=/devices/platform/radeon_cp.0

SUBSYSTEM=platform

MODALIAS=platform:radeon_cp

SEQNUM=1057

KERNEL[1293033506.572891] add      /devices/platform/radeon_cp.0/firmware/radeon_cp.0 (firmware)

UDEV_LOG=3

ACTION=add

DEVPATH=/devices/platform/radeon_cp.0/firmware/radeon_cp.0

SUBSYSTEM=firmware

FIRMWARE=radeon/RS690_cp.bin

ASYNC=0

SEQNUM=1058

UDEV  [1293033506.582235] add      /devices/platform/radeon_cp.0 (platform)

UDEV_LOG=3

ACTION=add

DEVPATH=/devices/platform/radeon_cp.0

SUBSYSTEM=platform

MODALIAS=platform:radeon_cp

SEQNUM=1057

KERNEL[1293033506.620156] remove   /devices/platform/radeon_cp.0/firmware/radeon_cp.0 (firmware)

UDEV_LOG=3

ACTION=remove

DEVPATH=/devices/platform/radeon_cp.0/firmware/radeon_cp.0

SUBSYSTEM=firmware

FIRMWARE=radeon/RS690_cp.bin

ASYNC=0

SEQNUM=1059

UDEV  [1293033506.620202] add      /devices/platform/radeon_cp.0/firmware/radeon_cp.0 (firmware)

UDEV_LOG=3

ACTION=add

DEVPATH=/devices/platform/radeon_cp.0/firmware/radeon_cp.0

SUBSYSTEM=firmware

FIRMWARE=radeon/RS690_cp.bin

ASYNC=0

SEQNUM=1058

KERNEL[1293033506.620237] remove   /devices/platform/radeon_cp.0 (platform)

UDEV_LOG=3

ACTION=remove

DEVPATH=/devices/platform/radeon_cp.0

SUBSYSTEM=platform

MODALIAS=platform:radeon_cp

SEQNUM=1060

UDEV  [1293033506.620265] remove   /devices/platform/radeon_cp.0/firmware/radeon_cp.0 (firmware)

UDEV_LOG=3

ACTION=remove

DEVPATH=/devices/platform/radeon_cp.0/firmware/radeon_cp.0

SUBSYSTEM=firmware

FIRMWARE=radeon/RS690_cp.bin

ASYNC=0

SEQNUM=1059

UDEV  [1293033506.620294] remove   /devices/platform/radeon_cp.0 (platform)

UDEV_LOG=3

ACTION=remove

DEVPATH=/devices/platform/radeon_cp.0

SUBSYSTEM=platform

MODALIAS=platform:radeon_cp

SEQNUM=1060
```

Why does it remove the firmware? udev rules?

----------

## ssteinberg

 *dE_logics wrote:*   

> Dudes, it does NOT work. I'm still getting 150 FPS. 
> 
> The kernel doesn't appear to be loading the firmware. dmesg | grep firmware has no output.
> 
> On Debian it does acknowledge.

 

Post the relevant .config. Firmware blobs and path must be correctly set.

----------

## Logicien

Hi,

if I can ask, is there an advantage to load a firmware from the kernel instead of loading it from an initrd or from the real root filesystem? Does it change something if the driver is compile in the kernel or in module? I have more FPS too with KMS disabled with a Radeon RS780M/RS780MN chipset. With Debian Sid, the radeon module is in the initrd with the firmware.

----------

## Gusar

 *Logicien wrote:*   

> I have more FPS too with KMS disabled with a Radeon RS780M/RS780MN chipset.

 

That's normal. And it's not because of KMS, but because of DRI2. Why are people still using glxgears numbers??

----------

## dE_logics

 *Gusar wrote:*   

>  *Logicien wrote:*   I have more FPS too with KMS disabled with a Radeon RS780M/RS780MN chipset. 
> 
> That's normal. And it's not because of KMS, but because of DRI2. Why are people still using glxgears numbers??

 

What else do we have (specially when the best FPS it ever gave is 900).

It shouldn't matter if the kernel loads the firmware from the initrd.. speaking of which Debain has it in it's initrd?... I don't think so, I needed to install firmware-linux package to get it working which didn't modify the initrd.

----------

## Ant P.

 *Logicien wrote:*   

> is there an advantage to load a firmware from the kernel instead of loading it from an initrd or from the real root filesystem?

 

In radeon's case it means you can compile the fbcon code in and have it working right away, instead of after init starts.

----------

## dE_logics

 *ssteinberg wrote:*   

>  *dE_logics wrote:*   Dudes, it does NOT work. I'm still getting 150 FPS. 
> 
> The kernel doesn't appear to be loading the firmware. dmesg | grep firmware has no output.
> 
> On Debian it does acknowledge. 
> ...

 

I think you're referring to this - 

 *Quote:*   

> CONFIG_EXTRA_FIRMWARE=""

 

Which's clearly empty. It has to do only with the kernel built in firmware right?

----------

## dE_logics

This is a kernel issue. That Debian kernel is loading the firmware on the Gentoo system.

This time I specified which firmware to include in CONFIG_EXTRA_FIRMWARE, but after booting off the new kernel there was no difference in FPS.

----------

## Logicien

 *dE_logics wrote:*   

> 
> 
> It shouldn't matter if the kernel loads the firmware from the initrd.. speaking of which Debain has it in it's initrd?... I don't think so, I needed to install firmware-linux package to get it working which didn't modify the initrd.

 

You need to install any firmware package your kernel need. On Debian, firmware-linux-nonfree is the package name who contain the firmwares the kernel radeon module ask for when it load. With Debian, you can configure what the initrd will contain in terms of modules, parameters and more. So I added the line radeon in /etc/initramfs-tools/modules file. When mkinitramfs build the initrd, the radeon module is include in the initrd, plus the dependencys of  the radeon module and the directory /lib/firmware/radeon. More again, the directory /etc/modprobe.d is also include with the parameter I wrote in one of the files, 

```
options radeon modeset=1
```

This way, I do not have to specify it as kernel boot parameter. This parameter is really needed in Debian kernels because it is not activate by default. The first time you make the changes, you have to remake the initrd or reinstall the kernel what will rebuild the initrd. KMS then start early at boottime. 

I do not think put the radeon firmware in the kernel will make KMS start a lot earlier and give better performances, as you say I think. The radeon firmware is nonfree as the package name say. Because I never include any firmwares in my customs kernels, I can not say if licenses matters.

----------

## dE_logics

Yup, that is right. I'll try that modeset parameter.

The only option left now is to discuss in the Linux mailing list. I hope I wont be bashed.

--update--

Unfortunately there doesn't appear to be a mailing list for the 'users', so I think i'll try the Gentoo mailing list.

----------

## dE_logics

It was loading the firmware... just didn't have a firmware string, it stated 'microcode' instead.

However, new problem. Now I'm using gallium and setting r300 to gallium (using eselect) results in segmentation fault in X.

----------

