lkml.org 
[lkml]   [2017]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Firmware files removal for 4.14-rc1
On 2017.09.16 at 09:55 -0700, Greg KH wrote:
> On Sat, Sep 16, 2017 at 08:25:03AM +0200, Markus Trippelsdorf wrote:
> > On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote:
> > > On 2017.09.15 at 11:56 -0700, Greg KH wrote:
> > > > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261:
> > > >
> > > > Linux 4.13 (2017-09-03 13:56:17 -0700)
> > > >
> > > > are available in the git repository at:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/firmware_removal-4.14-rc1
> > > >
> > > > for you to fetch changes up to 5620a0d1aacd554ebebcff373e31107bb1ef7769:
> > > >
> > > > firmware: delete in-kernel firmware (2017-09-14 14:49:41 -0700)
> > > >
> > > > ----------------------------------------------------------------
> > > > Firmware removal patch for 4.14-rc1
> > > >
> > > > Many many years ago (at the kernel summit in Boston), we all came to the
> > > > agreement that the firmware/ tree should be dropped from the kernel, and
> > > > everyone use the linux-firmware package instead. For some minor reason,
> > > > David Woodhouse didn't send the pull request at that point in time, and
> > > > everyone forgot about this.
> > > >
> > > > The topic came up in the hallway track at the Plumbers conference this
> > > > week, so here's a single patch that drops the whole firmware tree. The
> > > > last firmware update was back in 2013, and all distros have been using
> > > > linux-firmware instead since at least that year, if not before. The
> > > > only commits to that directory since 2013 was some kbuild fixups for
> > > > various build tool issues.
> > > >
> > > > So lets finally drop this, we don't need to lug them around in the
> > > > kernel source tree anymore, especially as no one wants or uses them.
> > >
> > > Well, it is one thing to drop the redundant binary blobs. But is another
> > > to break perfectly fine setups that worked for years, e.g.:
> > >
> > > CONFIG_FW_LOADER=y
> > > CONFIG_FIRMWARE_IN_KERNEL=y
> > > CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin"
> > > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> > >
> > > Please restore the support for built-in firmware.
>
> How did that break anything? You are still using external firmware,
> right?
>
> That just adds an empty Makefile that doesn't actually build anything
> into the kernel. What error is this fixing? I did a bunch of build
> tests with the patch that I submitted, and nothing failed.

The external firmware has to be packaged before it can be included into
the kernel. And this is what the Makefile in firmware/ does. It
generates a *.gen.S for every firmware file in the CONFIG_EXTRA_FIRMWARE
list. For example:

markus@x4 linux % cat firmware/amd-ucode/microcode_amd.bin.gen.S
/* Generated by firmware/Makefile */
.section .rodata
.p2align 3
_fw_amd_ucode_microcode_amd_bin_bin:
.incbin "/lib/firmware/amd-ucode/microcode_amd.bin"
_fw_end:
.section .rodata.str,"aMS",@progbits,1
.p2align 3
_fw_amd_ucode_microcode_amd_bin_name:
.string "amd-ucode/microcode_amd.bin"
.section .builtin_fw,"a",@progbits
.p2align 3
.quad _fw_amd_ucode_microcode_amd_bin_name
.quad _fw_amd_ucode_microcode_amd_bin_bin
.quad _fw_end - _fw_amd_ucode_microcode_amd_bin_bin

This is then used to assemble *.bin.gen.o object files and finally
firmware/built-in.o, that includes all firmware blobs.

Without the firmware/Makefile nothing gets build and therefore no
firmware gets included into the kernel. This may lead for example to a
failure to start X11, because the firmware for the graphic card doesn't
get loaded.

--
Markus

\
 
 \ /
  Last update: 2017-09-16 19:21    [W:0.077 / U:7.104 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site