Nowadays, Raspberry Pi 2 and Rasberry Pi 3 works perfectly fine with
Debian (including the official kernel package or the userland). RPi 1
and RPi Zero have an SoC that contains an armv6-based CPU, this means
that it cannot work with an hardfloat ABI, that is armv7 based. So we
have to use the Debian armel userland for this reason. Both boards are
supported in the mainline linux kernel and not being supported in the
debian-kernel package is the only blocking point that prevent RPI 1 and
RPI Zero from being well supported in an official Debian distribution.
This commit add a new kernel flavour for enabling support for the both
platforms.
- Drop patches already in 4.16
- Overwrite changes on master to debian/installer, which were also
applied on sid and then changed
- [x86] Fix up dell_smbios configuration; now it's a single driver
selected by DELL_SMBIOS, with DELL_SMBIOS_{SMM,WMI} being boolean
options
- Clean up configuration with kconfigeditor2
Reduce armel image size by:
- Set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
- Change MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION from
built-in to module.
- Disable VT, ZSWAP, RD_BZIP2, and RD_LZMA.
So qnap support is back.
Thanks to Leigh Brown <leigh@solinno.co.uk> for his idea to disable VT.
(cherry picked from commit a4fdfa09ce)
Reduce armel image size by:
- Set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
- Change MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION from
built-in to module.
- Disable VT, ZSWAP, RD_BZIP2, and RD_LZMA.
So qnap support is back.
Thanks to Leigh Brown <leigh@solinno.co.uk> for his idea to disable VT.
Extend the size limit for kernel image, from 2097080 to 2729712.
This will break a few qnap devices, but keep other armel devices
running.
Also revert two commits that disabled armel previously:
- [2ed70eb] "Add empty featuresets for armel to help abiupdate script"
- [5f62872] "(Temporarily) disable armel kernel image build"
(cherry picked from commit b0a94d07b4)
Extend the size limit for kernel image, from 2097080 to 2729712.
This will break a few qnap devices, but keep other armel devices
running.
Also revert two commits that disabled armel previously:
- [2ed70eb] "Add empty featuresets for armel to help abiupdate script"
- [5f62872] "(Temporarily) disable armel kernel image build"
The abiupdate script bails out currently (since we disabled armel image
builds at least temporarily) with
Retrieve config
Traceback (most recent call last):
File "debian/bin/abiupdate.py", line 224, in <module>
Main(url, url_config, **kw)()
File "debian/bin/abiupdate.py", line 95, in __call__
self.update_arch(config, arch)
File "debian/bin/abiupdate.py", line 149, in update_arch
featuresets = config[('base', arch)]['featuresets']
KeyError: 'featuresets'
Possibly this should be handled more gracefully in abiupdate itself, but
workaround the situation first by adding an empty featuressets and
explaining in the comment why we do not build images.
In the long run armel will disapear completely.
Gbp-Dch: Ignore
The armel/marvell kernel size is growing to large and the compressed
image is over the limit.
Given the armel architecture will most likely not be part of Buster,
disable the image build.
Cf. https://lists.debian.org/debian-kernel/2018/01/msg00278.html
BLK_DEV_FD has *never* been enabled on any of these architectures!
The old arm/footbridge configuration did enable it and this suggestion
seems to be have been thoughtlessly copied over to these other
architectures.
- Enable it by default
- Disable it for armel/marvell since signature verification is not enabled.
- Disable it for mips and mipsel so linux-signed can be uploaded without
waiting for them to build
- Disable it for all architectures not in the main archive, as linux-signed
won't support them (at least, not initially).
We don't need a variable to control signing of the image, because
we should do that for all flavours that have CONFIG_EFI_STUB=y.
Image doesn't fit, old hardware, no one cares.
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: maximilian attems <maks@debian.org>
svn path=/dists/trunk/linux/; revision=21875
The filename of the kernel image to be installed, and the stem of the
installed name, varies between architectures, so we define several
different rules to install it for different sets of architectures.
However the basic fact that we need to install this file in /boot does
not.
We also duplicate this name information in gencontrol.py and in
debian/config/{armel,armhf,sh4}/defines (used by buildcheck.py).
To address this:
* Define [image]install-stem and [build]image-file for each architecture
* Copy these settings to make-flags in gencontrol.py
* Copy [image]install-stem to the image-stem template variable in
gencontrol.py
* Replace the per-architecture rules with a single rule using those
make-flags
The per-architecture rules for ARM and PowerPC also installed DTB
and DTS files, respectively. Include those commands in the single
rule with appropriate conditions around them.
svn path=/dists/trunk/linux/; revision=21253
The image-file path could potentially vary between flavours but
currently doesn't. buildcheck.py works either way.
svn path=/dists/trunk/linux/; revision=21251
These were disabled for armel in 3.2.1-1 due to size concerns, but
the armel config (now in kernelarch-arm) is shared by armhf. Move
the overrides into a new armel-specific config.
svn path=/dists/trunk/linux/; revision=21231
It is inconsistent and potentially surprising that armhf uses
armel/config as well as armhf/config. Move the common config into a
new kernelarch-arm directory.
While we're at it, remove some redundant lines from both files.
svn path=/dists/trunk/linux/; revision=21221
All that config cleanup has brought them back under the size limit again
... for now ... with gcc-4.7. (I don't have a gcc-4.8 cross-compiler
to check with.)
svn path=/dists/trunk/linux/; revision=20588