The template file has been moved, but POTFILES.in hasn't been updated
following that move. This way the po files can be updated using:
debconf-updatepo --podir=debian/templates/po
svn path=/dists/sid/linux/; revision=21518
Deal with the various ABI changes:
* Avoid the change in ALSA
* We can no longer avoid a change in sockdiag, and it doesn't seem to
have any OOT users so ignore it
* team driver probably doesn't have OOT users, so ignore the change
svn path=/dists/sid/linux/; revision=21476
This creates the debian/installer/ppc64el dir with the usual contents
(kernel-versions, packages-list, and modules/).
For commonality with the other powerpc-based ports, make the installer's
module lists '#include' those from the ppc64 port (which in turn '#includes'
some from the powerpc port).
The differences are 4 modules from ps3/cell/powermacs systems removed from
nic-modules and scsi-modules.
Changes from V2 [1]:
- Removed symlinks 'debian/installer/ppc64el/modules/{powerpc,ppc64}'.
- Updated #include paths in module lists accordingly (path of ppc64 port).
[2] https://lists.debian.org/debian-kernel/2014/06/msg00064.html
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
svn path=/dists/sid/linux/; revision=21437
Debian ppc64el will wait for the 'powerpc/boot: 64bit little endian wrapper'
(zImage) patches upstream rather than shipping 32-bit tools for zImage. The
patches are currently in Ben Herrenschmidt's linux-next tree [1].
The patches are not being carried over instead of this workaround because,
even without both, the build process does produces vmlinux, only failing for
zImage. So, it's ok to just work-around this for now, as we pick vmlinux.
The workaround patch just avoids this build error:
[...]
LD vmlinux
SYSMAP System.map
[...]
WRAP arch/powerpc/boot/zImage.pseries
ld: unrecognised emulation mode: elf32ppc
Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim
make[6]: *** [arch/powerpc/boot/zImage.pseries] Error 1
make[5]: *** [zImage] Error 2
[1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=powerpc%2Fboot
(15 commits with message prefix 'powerpc/boot:' dated of 2014-04-28)
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
svn path=/dists/sid/linux/; revision=21426
Create a more complete 'debian/config/ppc64el/defines' file.
The ppc64el (little endian) config has most options common with
the ppc64 (big endian) config.
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
svn path=/dists/sid/linux/; revision=21423
This config has options for little-endian PowerPC64 systems.
It shares most options with big-endian PowerPC64 systems.
The differences are:
- choice: Endianness selection
Build a little endian kernel.
- choice: Page size
64k pages have benefits (performance et al) over 4k pages on
IBM POWER processors.
The Debian ppc64el port primarily runs on this sort of hardware
and chances are it will also run on hardware based on it (i.e.,
OpenPOWER) [1] [2].
- Maximum number of CPUs
This was increased to 2048 (following pseries_le_defconfig).
For the currently announced systems, the number of CPUs range
between 80-192 (1 or 2 processor module(s) * 10 or 12 cores
per module * 8 threads per core) [3]. This is enough to have
to diverge from CONFIG_NR_CPUS=32 in the other powerpc ports.
For future systems, it's likely larger ones will be announced.
The rationale: consider the announced systems are classified
as 'scale-out' and 'entry-level', plus larger ones have been
historically made available for addressing other markets; and
notice the largest POWER7 server has 1024 CPUs (threads) [4],
and that the threads-per-core doubled from POWER7 to POWER8.
So, the 2048 value is a reasonable 'max' in that projection.
Certainly it is greater than what would be required for most
systems, but I belive 'max' makes sense in that case, if we
are not looking for kernel rebuild and/with different config
for the larger systems (although I would be ok with flavours).
- choice: Default CPUFreq governor
As other architectures, we would prefer the default cpufreq
governor to be 'ondemand'.
The currently available cpufreq driver is for the PowerNV
(non-virtualized) platform, where all processors are available.
In that scenario, statically running at the highest frequency
(specially on idle processors) is not very desireable for the
hardware around (servers), and it is not unlikely for future
hardware (possibly non-servers) to benefit too, considering
that energy savings have been increasingly important on most
environments.
(Note: the powernv-cpufreq driver was introduced only in 3.15;
so, this option has no effect in 3.14; it is harmless.
I can put in patches for enabling this on 3.14 soon.)
- Apple PowerMac based machines
This is being disabled temporarily, until a patch makes upstream
(restricting it to 'depends on !CPU_LITTLE_ENDIAN').
This hardware line has no (known) support for little endian
mode currently, and disabling it has the useful effect of also
disabling a lot of config options which 'depends on PPC_PMAC',
thus saving tens of lines from changing config files.
It indeed has to be disabled because it's enabled by default
('depends on BOOK3S', 'default y'), so even changing it from
config files would not be sufficient.
[1] 'OpenPOWER Foundation Unveils First Innovations and Roadmap'
http://openpowerfoundation.org/press-releases/openpower-foundation-unveils-first-innovations-and-roadmap/
[2] 'POWER8 Reference Board now available for Development!'
http://openpowerfoundation.org/technical/related-links/
[3] 'IBM Power System S812L and S822L'
http://www-03.ibm.com/systems/power/hardware/s812l-s822l/specs.html
[4] 'IBM Power 795 server'
http://www-03.ibm.com/systems/power/hardware/795/perfdata.html
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
svn path=/dists/sid/linux/; revision=21422
Instead of overriding the global default in kernelarch-arm disable virtio on
those armel flavours which do not want it (which is all but vexpress). This
allows the armmp flavours to pickup the global default.
No change to any of the eventual .config files.
svn path=/dists/sid/linux/; revision=21412
Ben Hutchings
Aurelien Jarno
Ian Campbell