Bug#908161: Please enable building a riscv64 kernel image
On Thu, Sep 06, 2018 at 10:28:19PM +0100, Ben Hutchings wrote:
> On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote:
> > Source: linux
> > Version: 4.19~rc2-1~exp1
> > Severity: wishlist
[...]
> > starting with version 4.19rc2, the mainline Linux kernel includes
> > all drivers necessary for running a riscv64 system in qemu, so it
> > would be great if the "linux" source package could be extended to
> > build a linux-image-*-riscv64 binary package.
> >
> > Attached is a patch that tries to add the necessary bits.
>
> This config sets a whole lot of things to be built-in, but our policy
> is to build everything as modules if it works properly work as a
> module. This will also cause the building of installer udebs to fail
> (empty packages are treated as a fatal error).
Hello,
the reason for using a static config was that using an initrd
isn't possible on riscv64 with kernel 4.19rc2. This will
hopefully change sometime before the final 4.19 release so that
we can move to a fully modularized config, but for now everyting
required to mount the rootfs and bring up init has to be
built-in. I can probably trim down the current static config a
bit more, but e.g. filesystem drivers need to be built-in for
now, otherwise mounting the rootfs isn't possible.
> It also seems to have some redundant settings. debian/config/config is
> always used first (see README.source), so don't repeat anything that's
> in there.
Many thanks for the pointer, I'll take that into account for the
next version of the patch.
> Finally you should use kconfigeditor2 to add headings to the config
> file. You need to check out the kernel-team.git repository, and then
> in the linux repository run something like:
>
> ../kernel-team/utils/kconfigeditor2/process.py .
Ok, will do.
> > Unfortunately, with the patch applied the kernel itself builds
> > successfully, but the package build process then fails with
> >
> > -----8<----------8<----------8<----------8<----------8<-----
> >
> > make[3]: Leaving directory '<<builddir>>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> > debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none riscv64
> > ABI is not completely versioned! Refusing to continue.
> >
> > Unversioned symbols:
> > _mcount module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> > return_to_handler module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> > Can't read ABI reference. ABI not checked!
> > make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] Fehler 1
> >
> > -----8<----------8<----------8<----------8<----------8<-----
> >
> > I'm somewhat stuck here - is this an upstream issue or
> > have I overlooked something on the packaging side? Pointers
> > welcome :).
>
> It's an upstream issue, but not a fatal error there. For Debian it is
> a fatal error becasue unversioned symbols potentially undermine code
> signing.
>
> Any symbol exported from an assembly-language file won't automatically
> get a symbol version, since there's no type information there. The way
> to fix this is to include (or directly) add the function prototypes in
> arch/riscv/include/asm/asm-prototypes.h.
>
> I don't think that return_to_handler should be exported at all. No
> other architecture does. As for _mcount, that is declared in
> <asm/ftrace.h>, so <asm/asm-prototypes.h> should just be:
>
> /* SPDX-License-Identifier: GPL-2.0 */
> #include <asm/ftrace.h>
Thanks for the explanation, I'll contact the upstream RISC-V
kernel maintainer regarding this.
> Finally, you have added module lists for installer udebs, but this
> won't have any effect unless you also add the new architecture and
> flavour to debian/installer/kernel-versions.
Again thanks for the pointer, I'll look into it.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: