Bug#908161: Please enable building a riscv64 kernel image
Control: tags 908161 + patch On Tue, Sep 18, 2018 at 08:57:01PM +0200, Karsten Merker wrote: > On Sat, Sep 08, 2018 at 11:15:36PM +0100, Ben Hutchings wrote: > > [Building a linux-image-*-riscv64 binary package] > > > The addition of riscv will have to wait until it has support > > for an initramfs. > > > > Is this commit sufficient to make booting with an initramfs work: > > > > commit cdc7274029ca5984350a057a2399aaa340d3be2d > > Author: Guenter Roeck > > Date: Tue Aug 28 17:33:46 2018 -0700 > > > > riscv: Do not overwrite initrd_start and initrd_end > > > > or are more changes needed? > > Hello, > > just a short status update: the aforementioned patch has been > included in the upstream 4.19-rc4 release and I can confirm > that the initramfs support for riscv64 works with 4.19-rc4. > > The other major issue in this bug (unversioned symbols breaking > the package build) is still unresolved; I'll report back as soon > as I have received feedback from the upstream RISC-V architecture > maintainer. Hello, all previously mentioned issues have been addressed in the meantime: - The broken initrd support has been fixed upstream in kernel 4.19-rc4. - The symbol version issue has been fixed upstream in kernel 4.19-rc6. - The riscv64 kernel config has been modularized as far as possible and all redundant entries have been removed. - Headings have been added to the kernel config. Attached is a new patch, alternatively it is available as a merge request on salsa as suggested earlier in the discussion: https://salsa.debian.org/kernel-team/linux/merge_requests/66 The resulting kernel has been successfully tested on a qemu "virt" board: [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 [0.00] Linux version 4.19.0-rc7-riscv64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-7)) #1 SMP Debian 4.19~rc7-1~exp2 (2018-10-08) [0.00] bootconsole [early0] enabled [0.00] Initial ramdisk at: 0x(ptrval) (43521258 bytes) [0.00] Zone ranges: [0.00] DMA32[mem 0x8020-0x] [0.00] Normal [mem 0x0001-0x2fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8020-0x0002] [0.00] Initmem setup node 0 [mem 0x8020-0x0002] [0.00] On node 0 totalpages: 2620928 [0.00] DMA32 zone: 8184 pages used for memmap [0.00] DMA32 zone: 0 pages reserved [0.00] DMA32 zone: 523776 pages, LIFO batch:63 [0.00] Normal zone: 32768 pages used for memmap [0.00] Normal zone: 2097152 pages, LIFO batch:63 [0.00] software IO TLB: mapped [mem 0xfbfff000-0xf000] (64MB) [0.00] elf_hwcap is 0x112d [0.00] percpu: Embedded 19 pages/cpu @(ptrval) s39384 r8192 d30248 u77824 [0.00] pcpu-alloc: s39384 r8192 d30248 u77824 alloc=19*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2579976 [0.00] Kernel command line: console=ttyS0 ro root=/dev/vda [0.00] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [0.00] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 10178016K/10483712K available (4955K kernel code, 504K rwdata, 1633K rodata, 446K init, 934K bss, 305696K reserved, 0K cma-reserved) [0.00] random: get_random_u64 called from __kmem_cache_create+0x46/0x55c with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 21055 entries in 83 pages [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0 [0.00] plic: mapped 10 interrupts to 4 (out of 8) handlers. [0.00] clocksource: riscv_clocksource: mask: 0x max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns [0.004000] Console: colour dummy device 80x25 [0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 20.00 BogoMIPS (lpj=4) [0.012000] pid_max: default: 32768 minimum: 301 [0.016000] Security Framework initialized [0.016000] Yama: disabled by default; enable with sysctl kernel.yama.* [0.02] AppArmor: AppArmor initialized [0.024000] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.028000] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.072000] rcu: Hierarchical SRCU implementation. [0.092000] smp: Bringing up secondary CPUs ... [0.112000] smp: Brought up 1 node, 4 CPUs [0.16]
Bug#908161: Please enable building a riscv64 kernel image
Control: tag -1 moreinfo On Sat, 2018-09-08 at 20:07 +0200, Karsten Merker wrote: > 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. [...] This is not OK for distribution kernel packages. The addition of riscv will have to wait until it has support for an initramfs. Is this commit sufficient to make booting with an initramfs work: commit cdc7274029ca5984350a057a2399aaa340d3be2d Author: Guenter Roeck Date: Tue Aug 28 17:33:46 2018 -0700 riscv: Do not overwrite initrd_start and initrd_end or are more changes needed? Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, on joining IRC signature.asc Description: This is a digitally signed message part
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 > > '<>/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: > > 0x, export: EXPORT_SYMBOL > > return_to_handlermodule: vmlinux, version: > > 0x, 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 > , so should just be: > > /* SPDX-License-Identifier: GPL-2.0 */ > #include 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.
Bug#908161: Please enable building a riscv64 kernel image
On Thu, 2018-09-06 at 22:59 +0100, James Cowgill wrote: > Hi! > > On 06/09/2018 21:06, Karsten Merker wrote: > > 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 > > '<>/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: > > 0x, export: EXPORT_SYMBOL > > return_to_handlermodule: vmlinux, version: > > 0x, 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 :). > > I sent this upstream patch for this: > http://lists.infradead.org/pipermail/linux-riscv/2018-September/001372.html Why not remove the export of return_to_handler? Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Bug#908161: Please enable building a riscv64 kernel image
Hi! On 06/09/2018 21:06, Karsten Merker wrote: > 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 > '<>/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: > 0x, export: EXPORT_SYMBOL > return_to_handlermodule: vmlinux, version: > 0x, 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 :). I sent this upstream patch for this: http://lists.infradead.org/pipermail/linux-riscv/2018-September/001372.html James signature.asc Description: OpenPGP digital signature
Bug#908161: Please enable building a riscv64 kernel image
Some minor clarifications: On Thu, 2018-09-06 at 22:28 +0100, Ben Hutchings wrote: [...] > 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 "... include (or directly add) ..." > arch/riscv/include/asm/asm-prototypes.h. > > I don't think that return_to_handler should be exported at all. No > other architecture does. "No other architecture exports it." [...] > I'm removing the patch tag as this patch isn't usable. Please add it > again when you send another patch. Also, you are welcome to send a > merge request on Gitlab instead of a patch; I find easier to discuss > changes that way. By "Gitlab" I mean salsa.debian.org. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Bug#908161: Please enable building a riscv64 kernel image
Control: tag -1 - patch On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote: > Source: linux > Version: 4.19~rc2-1~exp1 > Severity: wishlist > Tags: patch > X-Debbugs-CC: debian-ri...@lists.debian.org > User: debian-ri...@lists.debian.org > Usertags: riscv64 > > Hello, > > 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). 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. 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 . > 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 > '<>/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: > 0x, export: EXPORT_SYMBOL > return_to_handlermodule: vmlinux, version: > 0x, 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 , so should just be: /* SPDX-License-Identifier: GPL-2.0 */ #include -- 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. -- I'm removing the patch tag as this patch isn't usable. Please add it again when you send another patch. Also, you are welcome to send a merge request on Gitlab instead of a patch; I find easier to discuss changes that way. Ben. > Regards, > Karsten -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Bug#908161: Please enable building a riscv64 kernel image
Source: linux Version: 4.19~rc2-1~exp1 Severity: wishlist Tags: patch X-Debbugs-CC: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, 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. 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 '<>/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: 0x, export: EXPORT_SYMBOL return_to_handlermodule: vmlinux, version: 0x, 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 :). 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. >From d1d47c22d5c41bb3b1924d2534aa06e86a16c10d Mon Sep 17 00:00:00 2001 From: Karsten Merker Date: Sat, 1 Sep 2018 23:02:11 +0200 Subject: [PATCH] Build a kernel image for riscv64 --- debian/config/riscv64/config | 79 +++ debian/config/riscv64/defines | 6 +- debian/config/riscv64/none/defines| 3 + debian/installer/modules/riscv64/ata-modules | 1 + .../installer/modules/riscv64/btrfs-modules | 1 + .../modules/riscv64/compress-modules | 1 + debian/installer/modules/riscv64/crc-modules | 1 + .../modules/riscv64/crypto-dm-modules | 1 + .../installer/modules/riscv64/crypto-modules | 1 + .../installer/modules/riscv64/event-modules | 1 + debian/installer/modules/riscv64/ext4-modules | 1 + debian/installer/modules/riscv64/fat-modules | 1 + debian/installer/modules/riscv64/fuse-modules | 1 + debian/installer/modules/riscv64/i2c-modules | 1 + .../installer/modules/riscv64/input-modules | 1 + .../installer/modules/riscv64/isofs-modules | 1 + debian/installer/modules/riscv64/jfs-modules | 1 + debian/installer/modules/riscv64/kernel-image | 1 + debian/installer/modules/riscv64/leds-modules | 1 + debian/installer/modules/riscv64/loop-modules | 1 + debian/installer/modules/riscv64/md-modules | 1 + debian/installer/modules/riscv64/mmc-modules | 1 + debian/installer/modules/riscv64/mtd-modules | 1 + .../modules/riscv64/multipath-modules | 1 + debian/installer/modules/riscv64/nbd-modules | 1 + debian/installer/modules/riscv64/nic-modules | 1 + .../modules/riscv64/nic-shared-modules| 1 + .../installer/modules/riscv64/nic-usb-modules | 1 + .../modules/riscv64/nic-wireless-modules | 1 + debian/installer/modules/riscv64/pata-modules | 1 + debian/installer/modules/riscv64/ppp-modules | 1 + debian/installer/modules/riscv64/sata-modules | 1 + .../modules/riscv64/scsi-core-modules | 1 + debian/installer/modules/riscv64/scsi-modules | 2 + .../modules/riscv64/squashfs-modules | 1 + debian/installer/modules/riscv64/udf-modules | 1 + .../installer/modules/riscv64/uinput-modules | 1 + debian/installer/modules/riscv64/usb-modules | 1 + .../modules/riscv64/usb-storage-modules | 1 + .../installer/modules/riscv64/virtio-modules | 1 + debian/installer/modules/riscv64/zlib-modules | 1 + 41 files changed, 126 insertions(+), 1 deletion(-) create mode 100644 debian/config/riscv64/config create mode 100644 debian/config/riscv64/none/defines create mode 100644 debian/installer/modules/riscv64/ata-modules create mode 100644 debian/installer/modules/riscv64/btrfs-modules create mode 100644 debian/installer/modules/riscv64/compress-modules create mode 100644 debian/installer/modules/riscv64/crc-modules create mode 100644 debian/installer/modules/riscv64/crypto-dm-modules create mode 100644 debian/installer/modules/riscv64/crypto-modules create mode 100644 debian/installer/modules/riscv64/event-modules create mode 100644 debian/installer/modules/riscv64/ext4-modules create mode 100644 debian/installer/modules/riscv64/fat-modules create mode 100644 debian/installer/modules/riscv64/fuse-modules create mode 100644 debian/installer/modules/riscv64/i2c-modules create mode
