[Letux-kernel] Merging/Reorganizing different variants of kernel packages/binaries

Andreas Kemnade andreas at kemnade.info
Tue Jan 15 18:07:07 CET 2019


here are the things which come to my mind about kernel organizing.

On Mon, 14 Jan 2019 18:40:34 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> Hi,
> Currently, I am upgrading all kernel variants and they have
> grown to a list of e.g.
> 	letux-4,19.15/
> 	letux-4.19-15-lpae/
> 	letux-4.19-15-udoo/
> 	letux-4.19-15-raspi/
> 	letux-4.19-15-l400/
> These share the same sources but have slightly different
> CONFIGs. So we create 5 packages of everything as you

They should share the same sources, but we should also be
prepared for the situation that
a patch might do something important for platform A but breaks platform B.
Examples: Tiler (sometimes breaks omap3)
  - clock stuff (fixes issues on gta04 and probably beagleboard)
       but in its earlier version broke beaglebone.


> can see here:
> 	http://download.goldelico.com/letux-kernel/?C=M;O=D
> All of them contain the same device trees and an uImage and
> a zImage. All our boot-loaders (u-Boot) are looking for
> this uImage (or zImage for RasPi) from the package that
> was installed..
> Now the new idea:
> Why don't we create
> 	uImage
> 	uImage-lpae
> 	uImage-udoo
> 	zImage-raspi (or kernel7.img)
> 	uImage-l400
> and adjust the boot-loaders to specifically pick
> one of them? And modify makesd to install all of them
> or the right one on the SD card?
The alternative would be to rename it after downloading.
Hmm, what about going to zImage on omap also?
We must find a way to transition. A bootargs.scr should
do the job. But I also want to try buster/beowulf(-backports)
armmp-kernels tomorrow which are afaik just zImages named vmlinuz-...

We could extend localversion a bit (letux vs. letux-lpae) and
modules could be sorted out. Or include the version number
in the name and create a symlink from uImage/zImage to the real file
like done on a lot of other systems.
I think nobody forces us to put a kernel on a fat partition.
At least on gta04 and pyra we can live totally without fat partitions.

And probably we could use the same kernel for raspi and
omap (only have to distinguish between lpae vs. non-lpae).

> This will clean up the above linked repository since
> there will be only one package for each kernel release.
> We already have different boot-loaders for each of the
> devices.
> E.g. Pyra 2GB uses a different U-Boot and could load
> the "uImage" while a Pyra 4GB could load the "uImage-lpae".
For the pyra we also have another interesting situation.
It has a keyboard, so almost everything is in place to
use an encrypted root partition. You can use the standard
debian way of creating an initramfs to mount that even on a
non-debian kernel. So loading an initramfs would be
an interesting thing.
There I would have an ext4 boot partition + encrypted
container (e.g. luks)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190115/ebe45129/attachment.asc>

More information about the Letux-kernel mailing list