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.
