Bug#933603: linux 5.2.1-1~exp1: riscv64 updates, including a FTBFS fix
Source: linux Severity: important Tags: patch Hello, current git master for src:linux FTBFS on riscv64. Recently CONFIG_LOAD_UEFI_KEYS has been enabled in the top-level kernel config fragment (debian/config/config), but this option depends on EFI support which is not yet available on riscv64. Therefore CONFIG_LOAD_UEFI_KEYS must be disabled in the architecture-specific config, otherwise the package fails to build on riscv64 due to undefined symbols. I have created a merge request on salsa that addresses this issue and also provides some other riscv64-related updates: [riscv64] Backport kernel image header support from kernel 5.3 [riscv64] Enable clock drivers for the SiFive FU540 [riscv64] Enable SiFive UART and UART console support [riscv64] Disable CONFIG_LOAD_UEFI_KEYS for riscv64 (fixes FTBFS) https://salsa.debian.org/kernel-team/linux/merge_requests/161/commits Regards, Karsten -- Ich widerspreche hiermit ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#928451: linux: riscv64 updates (change kernel image type to flat image and enable vdso)
ting OpenNTPd Network Time Protocol...
[ OK ] Started OpenNTPd Network Time Protocol.
[ OK ] Started Raise network interfaces.
Starting Online ext4 Metad…a Check for All Filesystems...
Starting Rotate log files...
Starting Daily man-db regeneration...
[ OK ] Reached target Network.
Starting Permit User Sessions...
Starting OpenBSD Secure Shell server...
[ OK ] Reached target Network is Online.
Starting LSB: exim Mail Transport Agent...
Starting Daily apt download activities...
[ OK ] Started Permit User Sessions.
[ OK ] Started Serial Getty on ttyS0.
[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
[ OK ] Started OpenBSD Secure Shell server.
[ OK ] Started Online ext4 Metadata Check for All Filesystems.
[ OK ] Started Rotate log files.
[ OK ] Started Recover schroot sessions.
Debian GNU/Linux 10 riscv64 ttyS0
riscv64 login:
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
>From de70ae43563da85568562e49c6f3bc1f27741dfc Mon Sep 17 00:00:00 2001
From: Karsten Merker
Date: Sat, 4 May 2019 19:41:45 +0200
Subject: [PATCH 1/2] [riscv64] Change the kernel image format from ELF to flat
Image.
The riscv64 architecture is changing its standard kernel image
format from ELF to a flat kernel image with a PE/COFF-compatible
header (similar to arm64) to make EFI stub support possible.
Ship arch/riscv/boot/Image instead of an ELF vmlinux in
accordance with this change.
---
debian/config/riscv64/defines | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/config/riscv64/defines b/debian/config/riscv64/defines
index 2ea6d75977f1..e83b750ea74a 100644
--- a/debian/config/riscv64/defines
+++ b/debian/config/riscv64/defines
@@ -4,7 +4,7 @@ featuresets:
none
[build]
-image-file: vmlinux
+image-file: arch/riscv/boot/Image
[image]
install-stem: vmlinux
--
2.20.1
>From 5fda00263bfe81d8a62dd4162c66527b51ea1755 Mon Sep 17 00:00:00 2001
From: Karsten Merker
Date: Sat, 4 May 2019 19:51:14 +0200
Subject: [PATCH 2/2] [riscv64] Enable vdso
When riscv64 support was originally added to the Debian Linux
kernel package, the mainline kernel lacked a vdso_install target
for riscv64. This has in the meantime been added with upstream
commit f157d411a9eb170d2ee6b766da7a381962017cc9 ("riscv: add
missing vdso_install target"), so we can now enable the
corresponding option in the kernel package.
---
debian/config/riscv64/defines | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/config/riscv64/defines b/debian/config/riscv64/defines
index e83b750ea74a..1d5a58b7313a 100644
--- a/debian/config/riscv64/defines
+++ b/debian/config/riscv64/defines
@@ -5,6 +5,7 @@ featuresets:
[build]
image-file: arch/riscv/boot/Image
+vdso: true
[image]
install-stem: vmlinux
--
2.20.1
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-kernel@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
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
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/i
Bug#864562: u-boot: broken ethernet support on Olimex A20-Olinuxino-Micro Rev. J
control: reassign 864562 u-boot-sunxi control: retitle 864562 u-boot: broken ethernet support on Olimex A20-Olinuxino-Micro Rev. J control: tags 864562 patch On Mon, Oct 16, 2017 at 10:45:57PM +0200, Karsten Merker wrote: > On Mon, Oct 16, 2017 at 09:39:36PM +0200, Jean-Louis Mounier wrote: [Ethernet not working on Olimex A20-Olinuxino Micro Rev. J] > > I discovered a new installer release but the bug is still > > present. > > > > Now the test : > > > > => gpio clear PA17 > > gpio: pin PA17 (gpio 17) value is 0 > > =>run bootcmd > > > > after that, the installer got IPV4 and IPV6 addresses wwith DHCP and then > > ran fine. > > > > Hope it helps > > Yes, that helps as it confirms that a change in u-boot alone is > enough to work around the issue in Linux as well (although it is > debateable whether the kernel should rely on the bootloader in > this case or not). There has recently been an attempt to address > the issue in mainline u-boot, but that didn't work out as planned > and the patch got rejected: > > https://lists.denx.de/pipermail/u-boot/2017-September/307778.html Hello, a patch to address this issue has finally been accepted today by the upstream u-boot custodian for the sunxi platform, targeting u-boot v2018.01: https://patchwork.ozlabs.org/patch/833763/ Vagrant, could you include the patch in the next u-boot package upload? 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#866521: [PATCH] initramfs-tools: rootfs on USB mass storage broken for a number of armhf systems
Package: initramfs-tools Severity: important Tags: patch Hello, with newer kernels (including kernel 4.9 as used in stretch), initializing the USB host controllers on a number of armhf systems is not possible without having the "axp20x_usb_power" power supply driver module available. To be able to have the rootfs on a USB mass storage device on such systems it is therefore necessary to include this module in the initramfs, which currently isn't the case. Attached is a patch that adds the "axp20x_usb_power" module to the "base" module list for the "MODULES=most" setting. JFTR: The patch doesn't address the "MODULES=dep" case; rootfs on USB mass storage currently doesn't work at all with "MODULES=dep" as the necessary USB controller drivers don't get included. An Example (Allwinner A20) with MODULES=dep: lib/modules/4.9.0-3-armmp-lpae/kernel/drivers lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/common lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/common/usb-common.ko lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/phy lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/usb/phy/phy-generic.ko lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/scsi lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/scsi/sd_mod.ko lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/scsi/scsi_mod.ko lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/i2c lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/i2c/busses lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/i2c/busses/i2c-mv64xxx.ko lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/phy lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/phy/phy-sun4i-usb.ko lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/extcon lib/modules/4.9.0-3-armmp-lpae/kernel/drivers/extcon/extcon-core.ko Missing are at least ehci_platform, ehci_hcd, ohci_platform, ohci_hcd and usbcore (when using the OTG controller also musb_hdrc and udc_core) plus the axp20x_regulator regulator driver and the axp20x_usb_power power supply driver. 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 7358533bcf35c7237ad8ab57dd2fe0b7db5f553c Mon Sep 17 00:00:00 2001 From: Karsten Merker <mer...@debian.org> Date: Thu, 29 Jun 2017 20:51:03 +0200 Subject: [PATCH] Include the axp20x_usb_power module in the base modules list for MODULES=most With newer kernels (including kernel 4.9 as used in stretch), initializing the USB host controllers on a number of armhf systems is not possible without having the "axp20x_usb_power" power supply driver module available. To be able to have the rootfs on a USB mass storage device on such systems it is therefore necessary to include this module in the initramfs. --- hook-functions | 4 1 file changed, 4 insertions(+) diff --git a/hook-functions b/hook-functions index 679e11d..4c68c90 100644 --- a/hook-functions +++ b/hook-functions @@ -513,6 +513,10 @@ auto_add_modules() copy_modules_dir kernel/drivers/usb/renesas_usbhs # and any extcon drivers for USB modules="$modules extcon-usb-gpio" + # Add the axp20x_usb_power power supply driver, + # required to initialize the USB host controllers + # on a number of armhf systems + modules="$modules axp20x_usb_power" # Include all HID drivers unless we're sure they # don't support keyboards. hid-*ff covers various -- 2.13.2
Re: Bug#864457: [d-i daily hd-media 20170608] kernel doesn't initialize USB ports inside d-i on a sunxi-based system
On Thu, Jun 08, 2017 at 10:50:57PM +0200, Karsten Merker wrote: > Package: installation-reports > > Boot method: hd-media tarball from USB stick > Image version: > https://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz > Date: 2017-06-08 > > Machine: LeMaker Banana Pi > Processor: Allwinner A20 (2x Cortex A7) > Memory: 1GB [...] > Comments/Problems: > Installation method is a d-i hd-media tarball and a Debian CD/DVD > ISO image on a USB stick. Booting d-i from the stick works fine, > but inside the installer the USB ports are dead and no USB > devices get recognized by the kernel. > > In an installed system on the same hardware (installed with the > netboot image), the USB ports work normally. In the d-i > environment, the ehci platform driver gets loaded, but for some > reason doesn't initialize the actual host controller. All > relevant USB host driver modules appear to be there: > > Module Size Used by > usb_storage45835 0 > phy_generic 4686 1 sunxi > musb_hdrc 113325 1 sunxi > udc_core 26444 1 musb_hdrc > ohci_platform 4786 0 > ohci_hcd 37898 1 ohci_platform > ehci_platform 5462 0 > ehci_hcd 64996 1 ehci_platform > phy_sun4i_usb 8637 1 sunxi > extcon_core13223 2 sunxi,phy_sun4i_usb > usbcore 196310 6 > usb_storage,ehci_hcd,musb_hdrc,ohci_hcd,ehci_platform,ohci_platform > usb_common 3659 5 udc_core,sunxi,musb_hdrc,phy_sun4i_usb,usbcore > > In the d-i environment: > [2.694030] usbcore: registered new interface driver usbfs > [2.699958] usbcore: registered new interface driver hub > [2.703305] SCSI subsystem initialized > [2.716192] usbcore: registered new device driver usb > [2.724836] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.736947] sunxi-mmc 1c0f000.mmc: base:0xf08f4000 irq:28 > [2.750665] ehci-platform: EHCI generic platform driver > [2.751130] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > [2.752551] ohci-platform: OHCI generic platform driver > > While on the installed system: > [2.162185] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.168314] ehci-platform: EHCI generic platform driver > [6.187194] ehci-platform 1c14000.usb: EHCI Host Controller > [6.187256] ehci-platform 1c14000.usb: new USB bus registered, assigned > bus number 2 > [6.192414] ehci-platform 1c14000.usb: irq 30, io mem 0x01c14000 > [6.205562] ehci-platform 1c14000.usb: USB 2.0 started, EHCI 1.00 > [6.206170] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 > [6.206184] usb usb2: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [6.206191] usb usb2: Product: EHCI Host Controller > [6.206198] usb usb2: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd > [6.206204] usb usb2: SerialNumber: 1c14000.usb > [6.207443] hub 2-0:1.0: USB hub found > [6.207557] hub 2-0:1.0: 1 port detected > [6.209230] ehci-platform 1c1c000.usb: EHCI Host Controller > [6.209289] ehci-platform 1c1c000.usb: new USB bus registered, assigned > bus number 3 > [6.216403] ehci-platform 1c1c000.usb: irq 34, io mem 0x01c1c000 > [6.230524] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 > [6.231044] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 > [6.231058] usb usb3: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [6.231066] usb usb3: Product: EHCI Host Controller > [6.231072] usb usb3: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd > [6.231079] usb usb3: SerialNumber: 1c1c000.usb > > We might have a problem with the USB port power supply here. > Comparing the available modules between the installed system and > the d-i environment (full list below) and looking for possibly > related modules shows that the "axp20x_regulator" and > "axp20x_usb_power" modules are available in the installed system, > but not in the d-i environment. I am not sure whether > axp20x_usb_power is really responsible for providing power _to_ > the USB hosts ports, though. It could be that it is responsible > for powering the system _from_ a USB-OTG port, so it might be > unrelated to the problem at hand. "axp20x_regulator" would > possibly be a candidate for a power-supply problem. I have also > tried using a powered USB hub between the USB stick and the host > port, but even then no USB device gets recognized, which kind of > speaks against the theory of only a missing 5V-supply on the USB > port as the sole source of the problem. Possibly
Bug#774067: linux 3.16.7-ckt: [patch] please add a dts for the LinkSprite pcDuino V3
Source: linux
Version: 3.16.7-ckt2-1
Severity: wishlist
Tags: patch
On the debian-arm mailinglist, a user has asked for support for
the LinkSprite pcDuino V3 board (see the thread starting at
https://lists.debian.org/debian-arm/2014/12/msg00052.html).
Driver-wise all core components of the board (serial console,
MMC, SATA, USB, wired ethernet) are supported by kernel 3.16, it
just lacks an appropriate device-tree file, which was added
upstream in kernel 3.17. Attached is a patch to backport the
device-tree file. As this is a completely self-contained
addition and does not bring any code changes, I believe this to
be suitable for inclusion into Jessie despite the freeze.
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.
Index: debian/patches/features/arm/dts-sun7i-Add-board-support-for-LinkSprite-pcDuino-V3.patch
===
--- debian/patches/features/arm/dts-sun7i-Add-board-support-for-LinkSprite-pcDuino-V3.patch (revision 0)
+++ debian/patches/features/arm/dts-sun7i-Add-board-support-for-LinkSprite-pcDuino-V3.patch (working copy)
@@ -0,0 +1,206 @@
+From 04089927981f295b42cd695485383b2d11283d59 Mon Sep 17 00:00:00 2001
+From: Zoltan HERPAI wigy...@uid0.hu
+Date: Mon, 30 Jun 2014 23:57:56 +0200
+Subject: ARM: dts: sun7i: Add board support for LinkSprite pcDuino V3
+Origin: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=04089927981f295b42cd695485383b2d11283d59
+
+The LinkSprite pcDuino V3 is an A20 based development board featuring
+arduino compatible io headers, 1G RAM, 4G nand, sata, rtl8188cus usb wifi
+and 100 Mbit ethernet using an ip101a phy:
+
+http://www.pcduino.com/pcduino-v3/
+
+Signed-off-by: Zoltan HERPAI wigy...@uid0.hu
+[hdego...@redhat.com: Various cleanups, correct led pins]
+[hdego...@redhat.com: Add axp209, ir and gpio-keys nodes]
+Signed-off-by: Hans de Goede hdego...@redhat.com
+Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
+
+--- a/arch/arm/boot/dts/Makefile
b/arch/arm/boot/dts/Makefile
+@@ -381,7 +381,8 @@
+ sun7i-a20-cubietruck.dtb \
+ sun7i-a20-i12-tvbox.dtb \
+ sun7i-a20-olinuxino-lime.dtb \
+- sun7i-a20-olinuxino-micro.dtb
++ sun7i-a20-olinuxino-micro.dtb \
++ sun7i-a20-pcduino3.dtb
+ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
+ tegra20-iris-512.dtb \
+ tegra20-medcom-wide.dtb \
+--- /dev/null
b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
+@@ -0,0 +1,173 @@
++/*
++ * Copyright 2014 Zoltan HERPAI
++ * Zoltan HERPAI wigy...@uid0.hu
++ *
++ * The code contained herein is licensed under the GNU General Public
++ * License. You may obtain a copy of the GNU General Public License
++ * Version 2 or later at the following locations:
++ *
++ * http://www.opensource.org/licenses/gpl-license.html
++ * http://www.gnu.org/copyleft/gpl.html
++ */
++
++/dts-v1/;
++/include/ sun7i-a20.dtsi
++/include/ sunxi-common-regulators.dtsi
++#include dt-bindings/gpio/gpio.h
++#include dt-bindings/input/input.h
++
++/ {
++ model = LinkSprite pcDuino3;
++ compatible = linksprite,pcduino3, allwinner,sun7i-a20;
++
++ soc@01c0 {
++ mmc0: mmc@01c0f000 {
++ pinctrl-names = default;
++ pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_reference_design;
++ vmmc-supply = reg_vcc3v3;
++ bus-width = 4;
++ cd-gpios = pio 7 1 0; /* PH1 */
++ cd-inverted;
++ status = okay;
++ };
++
++ usbphy: phy@01c13400 {
++ usb1_vbus-supply = reg_usb1_vbus;
++ usb2_vbus-supply = reg_usb2_vbus;
++ status = okay;
++ };
++
++ ehci0: usb@01c14000 {
++ status = okay;
++ };
++
++ ohci0: usb@01c14400 {
++ status = okay;
++ };
++
++ ahci: sata@01c18000 {
++ target-supply = reg_ahci_5v;
++ status = okay;
++ };
++
++ ehci1: usb@01c1c000 {
++ status = okay;
++ };
++
++ ohci1: usb@01c1c400 {
++ status = okay;
++ };
++
++ pinctrl@01c20800 {
++ ahci_pwr_pin_a: ahci_pwr_pin@0 {
++allwinner,pins = PH2;
++ };
++
++ led_pins_pcduino3: led_pins@0 {
++allwinner,pins = PH15, PH16;
++allwinner,function = gpio_out;
++allwinner,drive = 0;
++allwinner,pull = 0;
++ };
++
++ key_pins_pcduino3: key_pins@0 {
++allwinner,pins = PH17, PH18, PH19;
++allwinner,function = gpio_in;
++allwinner,drive = 0;
++allwinner,pull = 0;
++ };
++ };
++
++ ir0: ir@01c21800 {
++ pinctrl-names = default;
++ pinctrl-0 = ir0_pins_a;
++ status = okay;
++ };
++
++ uart0: serial@01c28000 {
++ pinctrl-names = default;
++ pinctrl-0 = uart0_pins_a;
++ status = okay;
++ };
++
++ i2c0: i2c@01c2ac00 {
++ pinctrl-names = default;
++ pinctrl-0 = i2c0_pins_a;
++ status = okay;
++
++ axp209: pmic@34 {
++compatible = x-powers,axp209;
++reg = 0x34;
++interrupt-parent = nmi_intc;
++interrupts = 0 8;
++
++interrupt-controller;
++#interrupt-cells = 1;
++ };
++ };
++
++ gmac:
Next kernel package upload?
Hello, I would like to kindly ask what the current plans are regarding the next kernel package upload and getting a freeze exception for it. Is there already some agreement with the release team? I ask because I would really like to see the fix for bug #767042 (which is in current SVN) going into Jessie, as this bug breaks the installer on the Banana Pi board. On Saturday the next phase of the freeze starts and the general acceptance of fixes for bugs with severity: important in packages of priority: optional ends, so this might become a problem afterwards. 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201201443.ga4...@excalibur.cnev.de
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
Control: tag -1 patch On Wed, Nov 05, 2014 at 09:52:40PM +0100, Karsten Merker wrote: [Failing ethernet PHY detection in d-i on the BananaPi] Further experiments show that increasing the startup-delay-us value in the regulator definition seems to solve the issue. I'll do some further experiments to determine a value that is long enough for a reliable detection without being unnecessary long and discuss the issue with the upstream author. A patch to solve the issue has been accepted upstream (see https://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301727.html). Attached is a backport of this patch for inclusion into the upcoming linux 3.16.7-3 package. 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. Index: debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch === --- debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch (Revision 0) +++ debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch (Arbeitskopie) @@ -0,0 +1,35 @@ +From f82f99afaa65fd28d0f8409c50e8fcc65ee5e15b Mon Sep 17 00:00:00 2001 +From: Karsten Merker mer...@debian.org +Date: Wed, 12 Nov 2014 00:01:46 +0100 +Subject: ARM: dts: sunxi: Banana Pi: increase startup-delay for the GMAC PHY regulator +Origin: https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/dt-for-3.19id=f82f99afaa65fd28d0f8409c50e8fcc65ee5e15b + +On the LeMaker Banana Pi, probing the external ethernet PHY connected +to the SoC's internal GMAC module sometimes fails. The PHY power +supply is handled via a GPIO-controlled regulator, and the existing +regulator startup-delay of 5us is too short to make sure that the +PHY is always fully powered up when it is queried by phylib. Tests +have shown that to provide a reliable PHY detection, the startup-delay +has to be increased to at least 6us. To have a certain safety margin +and to cater for manufacturing variations between different boards, +the delay gets set to 10us as discussed on the linux-arm-kernel +mailinglist. + +Signed-off-by: Karsten Merker mer...@debian.org +Acked-by: Hans de Goede hdego...@redhat.com +Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com + +diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts +index 3de847d..1cf1214 100644 +--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts +@@ -207,7 +207,7 @@ + regulator-name = gmac-3v3; + regulator-min-microvolt = 330; + regulator-max-microvolt = 330; +- startup-delay-us = 5; ++ startup-delay-us = 10; + enable-active-high; + gpio = pio 7 23 0; + }; + Index: debian/patches/series === --- debian/patches/series (Revision 22061) +++ debian/patches/series (Arbeitskopie) @@ -113,6 +113,7 @@ features/arm/dts-sun7i-Add-spi0_pins_a-pinctrl-setting.patch features/arm/dts-sun7i-Add-uart3_pins_b-pinctrl-setting.patch features/arm/dts-sun7i-Add-Banana-Pi-board.patch +features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch features/arm64/drivers-net-Add-APM-X-Gene-SoC-ethernet-driver-suppo.patch features/arm64/drivers-net-NET_XGENE-should-depend-on-HAS_DMA.patch
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Wed, Nov 05, 2014 at 10:45:12AM +, Ian Campbell wrote: On Tue, 2014-11-04 at 22:37 +0100, Karsten Merker wrote: I have run further installation tests with today's current d-i images (still based on the same 3.16.5-1 kernel) OOI if you bodge your way through the install does the resulting system boot and discover the PHY reliably? IOW is it specific to d-i or not? Ethernet works in the installed system (tested with several cold and warm boots): [2.448442] stmmaceth 1c5.ethernet: no reset control found [2.454322] Ring mode enabled [2.457396] No HW DMA feature register supported [2.461941] Normal descriptors [2.465279] TX Checksum insertion supported [2.495563] libphy: stmmac: probed [2.499078] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [2.505490] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) i.e. the PHY appears to have a seperate regulator on the BananaPi but not on the Cubietruck and I wonder whether the startup-delay-us = 5; might play a role here. I think that's a decent theory. Decent enoguh that it is probably worth taking it up with the sunxi kernel folks. Might also be the power supply differs between the two boards? Running the BananaPi with the Cubietruck's power supply does not change the behaviour. I have now run several tests with a modified BananaPi dtb in which I have added a regulator-always-on stanza to the reg_gmac_3v3 definition. With this change the PHY detection in d-i has worked every time, so this would support the theory that the regulator might not be powered up fast enough for the PHY detection to succeed, but I cannot see why this problem only occurs within the d-i environment. 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105200107.ga4...@excalibur.cnev.de
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Wed, Nov 05, 2014 at 09:01:08PM +0100, Karsten Merker wrote: [Failing ethernet PHY detection in d-i on the BananaPi] I have now run several tests with a modified BananaPi dtb in which I have added a regulator-always-on stanza to the reg_gmac_3v3 definition. With this change the PHY detection in d-i has worked every time, so this would support the theory that the regulator might not be powered up fast enough for the PHY detection to succeed, but I cannot see why this problem only occurs within the d-i environment. Further experiments show that increasing the startup-delay-us value in the regulator definition seems to solve the issue. I'll do some further experiments to determine a value that is long enough for a reliable detection without being unnecessary long and discuss the issue with the upstream author. 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105205240.gb4...@excalibur.cnev.de
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Mon, Nov 03, 2014 at 12:26:33AM +, Ben Hutchings wrote: On Sun, 2014-11-02 at 21:43 +0100, Karsten Merker wrote: [...] Following is the log from a d-i run where /sbin/modprobe and /sbin/insmod have been replaced by a script that logs all invocations of these two binaries with a modules-debug prefix before executing the original binary: [...] The entry at 00:03:37 does not show a modprobe invocation before the initialization of the stmmac module, so the module does not seem to be loaded by calling modprobe, which would explain why no autoloading of the PHY driver happens there. What I do not understand is that I also see no insmod invocation, and logging insmod invocations works when I run insmod from a shell. So the question remains: how is the stmmac module loaded at that point? I first thought that something might invoke kmod directly (i.e. not by calling the insmod/modprobe aliases), but logging direct kmod invocations also shows nothing, so I am probably overlooking something. Any ideas? So far as I can see, ethdetect runs hw-detect, which runs update-dev, which runs 'udevadm trigger --action=add --subsystem-nomatch=sound' and that should result in udev loading stmmac. (udev won't have done that when it started because the stmmac module wasn't included in the initramfs.) udev is now linked with libkmod, so it can load modules without running modprobe, and most driver modules get loaded that way. But as I said before, this isn't the case for the PHY driver modules. So, I think this shows the kernel is not running modprobe for some reason. Things are getting even stranger: I have run further installation tests with today's current d-i images (still based on the same 3.16.5-1 kernel) - http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz dated 04-Nov-2014 05:16 and - http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo dated 2014-11-03 12:14) on a Cubietruck and on the BananaPi. On the Cubietruck everything works while on the BananaPi the PHY is not found. Both are booted from the same USB stick, so there cannot be any differences in the installer image. The hardware on both is rather similar (Allwinner A20 SoC with integrated MAC, external Realtek PHY) and they show the same PHY ID once the probing was successful, so I assume that they use identical PHY chips: Cubietruck: --- Jan 1 00:06:47 main-menu[179]: INFO: Menu item 'ethdetect' selected Jan 1 00:06:48 kernel: [ 78.983839] cfg80211: Calling CRDA to update world regulatory domain Jan 1 00:06:49 kernel: [ 78.998759] brcmfmac_sdio mmc1:0001:1: firmware: failed to load brcm/brcmfmac43362-sdio.bin (-2) Jan 1 00:06:49 kernel: [ 79.057067] stmmaceth 1c5.ethernet: no regulator found Jan 1 00:06:49 kernel: [ 79.057202] stmmaceth 1c5.ethernet: no reset control found Jan 1 00:06:49 kernel: [ 79.057218] Ring mode enabled Jan 1 00:06:49 kernel: [ 79.057226] No HW DMA feature register supported Jan 1 00:06:49 kernel: [ 79.057233] Normal descriptors Jan 1 00:06:49 kernel: [ 79.057241] TX Checksum insertion supported Jan 1 00:06:49 kernel: [ 79.171058] libphy: stmmac: probed Jan 1 00:06:49 kernel: [ 79.171089] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active Jan 1 00:06:49 kernel: [ 79.171100] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) BananaPi: - No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list. -- shell ~ # lsmod |grep realtek ~ # dmesg | tail -8 [ 32.138512] ISO 9660 Extensions: RRIP_1991A [ 77.235117] stmmaceth 1c5.ethernet: no reset control found [ 77.235192] Ring mode enabled [ 77.235202] No HW DMA feature register supported [ 77.235211] Normal descriptors [ 77.235219] TX Checksum insertion supported [ 77.242678] libphy: stmmac: probed [ 77.242708] eth0: No PHY found ~ # rmmod stmmac ~ # modprobe stmmac ~ # lsmod |grep realtek realtek 1563 0 ~ # dmesg | tail -8 [ 148.823456] stmmaceth 1c5.ethernet: no reset control found [ 148.823487] Ring mode enabled [ 148.823496] No HW DMA feature register supported [ 148.823502] Normal descriptors [ 148.823509] TX Checksum insertion supported [ 148.854654] libphy: stmmac: probed [ 148.854683] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 148.854694] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) ~ # The main visible difference between the two systems is that the Cubietruck also has a Broadcom 43362 SDIO Wifi module and d-i asks for the non-free firmware for it before the stmmac gets initialized, but I do not see how that should make a difference regarding the realtek PHY driver. What makes me wonder is the line stmmaceth 1c5.ethernet: no regulator found on the Cubietruck that does not appear on the BananaPi. Could there perhaps be some
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Tue, Oct 28, 2014 at 11:14:40PM +0100, Karsten Merker wrote: On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote: I don't understand this. Karsten Merker mer...@debian.org (2014-10-27): [...] [ 73.104782] libphy: stmmac: probed [ 73.104812] eth0: No PHY found i.e. the correct ethernet MAC driver (stmmac) gets loaded automatically, but the necessary PHY driver (realtek) does not. [...] [ 499.392561] libphy: stmmac: probed [ 499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) and the ethernet interface works. The kernel version used in this installer build is 3.16.5-1. $ modinfo -F alias realtek mdio:???111001100100100010101 mdio:???111001100100100010010 In hex those are 1cc915 and 1cc912. (The 11 most significant bits are unspecified.) So modprobe certainly should find this module when requested by phylib. I have retried the installation today and tried something I had not done yesterday: just rmmod and directly afterwards modprobe the stmmac module. This results in the realtek PHY module getting auto-loaded, so the modprobe mechanism seems to work correctly there, but the question remains why this does not happen upon the first loading of the stmmac module. A protocol from d-i: No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list. -- start shell ~ # lsmod Module Size Used by stmmac 73442 0 nls_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 ~ # dmesg | tail -8 [ 31.558145] ISO 9660 Extensions: RRIP_1991A [ 77.839161] stmmaceth 1c5.ethernet: no reset control found [ 77.839194] Ring mode enabled [ 77.839202] No HW DMA feature register supported [ 77.839210] Normal descriptors [ 77.839217] TX Checksum insertion supported [ 77.844560] libphy: stmmac: probed [ 77.844589] eth0: No PHY found ~ # rmmod stmmac ~ # modprobe stmmac ~ # dmesg | tail -8 [ 330.112850] stmmaceth 1c5.ethernet: no reset control found [ 330.112883] Ring mode enabled [ 330.112891] No HW DMA feature register supported [ 330.112898] Normal descriptors [ 330.112905] TX Checksum insertion supported [ 330.140101] libphy: stmmac: probed [ 330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) ~ # lsmod Module Size Used by realtek 1563 0 stmmac 73442 0 nls_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 As udev is *not* involved in loading MDIO PHY drivers (NIC drivers expect them to be bound synchronously) it isn't easy to monitor what's going on. You could replace modprobe with a script that logs its arguments to a file before calling the real modprobe. That should tell us whether the bug is in the kernel or userland. I
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote: On Tue, 2014-10-28 at 00:18 +0100, Cyril Brulebois wrote: Cc+=debian-kernel@ for input since I seem to recall having seen PHY drivers (including in a realtek context) being mentioned lately, at least on IRC, maybe on list as well. I don't understand this. Karsten Merker mer...@debian.org (2014-10-27): [...] [ 73.104782] libphy: stmmac: probed [ 73.104812] eth0: No PHY found i.e. the correct ethernet MAC driver (stmmac) gets loaded automatically, but the necessary PHY driver (realtek) does not. [...] [ 499.392561] libphy: stmmac: probed [ 499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) and the ethernet interface works. The kernel version used in this installer build is 3.16.5-1. $ modinfo -F alias realtek mdio:???111001100100100010101 mdio:???111001100100100010010 In hex those are 1cc915 and 1cc912. (The 11 most significant bits are unspecified.) So modprobe certainly should find this module when requested by phylib. I have retried the installation today and tried something I had not done yesterday: just rmmod and directly afterwards modprobe the stmmac module. This results in the realtek PHY module getting auto-loaded, so the modprobe mechanism seems to work correctly there, but the question remains why this does not happen upon the first loading of the stmmac module. A protocol from d-i: No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list. -- start shell ~ # lsmod Module Size Used by stmmac 73442 0 nls_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 ~ # dmesg | tail -8 [ 31.558145] ISO 9660 Extensions: RRIP_1991A [ 77.839161] stmmaceth 1c5.ethernet: no reset control found [ 77.839194] Ring mode enabled [ 77.839202] No HW DMA feature register supported [ 77.839210] Normal descriptors [ 77.839217] TX Checksum insertion supported [ 77.844560] libphy: stmmac: probed [ 77.844589] eth0: No PHY found ~ # rmmod stmmac ~ # modprobe stmmac ~ # dmesg | tail -8 [ 330.112850] stmmaceth 1c5.ethernet: no reset control found [ 330.112883] Ring mode enabled [ 330.112891] No HW DMA feature register supported [ 330.112898] Normal descriptors [ 330.112905] TX Checksum insertion supported [ 330.140101] libphy: stmmac: probed [ 330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) ~ # lsmod Module Size Used by realtek 1563 0 stmmac 73442 0 nls_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 As udev is *not* involved in loading MDIO PHY drivers (NIC drivers expect them to be bound synchronously) it isn't easy to monitor what's going on. You could replace modprobe with a script that logs its arguments to a file before calling the real modprobe. That should tell us
Bug#764967: Please backport dts for the Olimex A20-OLinuXino-LIME
On Sun, 12 Oct 2014 18:23:24 +0200 Christian Kastner deb...@kvr.at wrote:
would it be possible to include the dts for the Olimex
A20-OLinuXino-LIME in 3.16 so that it can be used with Jessie? This
device is almost identical to the already existing A10-OLinuXino-LIME;
they only differ in the processor.
The relevant commit from 3.17 is:
a71b443 ARM: sun7i: Add support for Olimex A20-OLinuXino-LIME
The patch from
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=a71b4438af8242f383906071205db95a8b8e7b6d
does not apply cleanly against the current 3.16.5-2 kernel
package SVN. A patch against current SVN with a refreshed
version of the original patch (no content changes) is attached.
A test build is currently running, but will take until tomorrow.
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.
Index: debian/patches/features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch
===
--- debian/patches/features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch (Revision 0)
+++ debian/patches/features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch (Arbeitskopie)
@@ -0,0 +1,160 @@
+From a71b4438af8242f383906071205db95a8b8e7b6d Mon Sep 17 00:00:00 2001
+From: FUKAUMI Naoki nao...@gmail.com
+Date: Wed, 20 Aug 2014 14:25:03 +0900
+Subject: ARM: sun7i: Add support for Olimex A20-OLinuXino-LIME
+
+This patch adds support for Olimex A20-OLinuXino-LIME board.
+
+Signed-off-by: FUKAUMI Naoki nao...@gmail.com
+Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
+
+--- a/arch/arm/boot/dts/Makefile
b/arch/arm/boot/dts/Makefile
+@@ -380,6 +380,7 @@
+ sun7i-a20-cubieboard2.dtb \
+ sun7i-a20-cubietruck.dtb \
+ sun7i-a20-i12-tvbox.dtb \
++ sun7i-a20-olinuxino-lime.dtb \
+ sun7i-a20-olinuxino-micro.dtb
+ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
+ tegra20-iris-512.dtb \
+--- /dev/null
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
+@@ -0,0 +1,137 @@
++/*
++ * This is based on sun4i-a10-olinuxino-lime.dts
++ *
++ * Copyright 2014 - Hans de Goede hdego...@redhat.com
++ * Copyright (c) 2014 FUKAUMI Naoki nao...@gmail.com
++ *
++ * The code contained herein is licensed under the GNU General Public
++ * License. You may obtain a copy of the GNU General Public License
++ * Version 2 or later at the following locations:
++ *
++ * http://www.opensource.org/licenses/gpl-license.html
++ * http://www.gnu.org/copyleft/gpl.html
++ */
++
++/dts-v1/;
++/include/ sun7i-a20.dtsi
++/include/ sunxi-common-regulators.dtsi
++
++/ {
++ model = Olimex A20-OLinuXino-LIME;
++ compatible = olimex,a20-olinuxino-lime, allwinner,sun7i-a20;
++
++ soc@01c0 {
++ mmc0: mmc@01c0f000 {
++ pinctrl-names = default;
++ pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_reference_design;
++ vmmc-supply = reg_vcc3v3;
++ bus-width = 4;
++ cd-gpios = pio 7 1 0; /* PH1 */
++ cd-inverted;
++ status = okay;
++ };
++
++ usbphy: phy@01c13400 {
++ usb1_vbus-supply = reg_usb1_vbus;
++ usb2_vbus-supply = reg_usb2_vbus;
++ status = okay;
++ };
++
++ ehci0: usb@01c14000 {
++ status = okay;
++ };
++
++ ohci0: usb@01c14400 {
++ status = okay;
++ };
++
++ ahci: sata@01c18000 {
++ target-supply = reg_ahci_5v;
++ status = okay;
++ };
++
++ ehci1: usb@01c1c000 {
++ status = okay;
++ };
++
++ ohci1: usb@01c1c400 {
++ status = okay;
++ };
++
++ pinctrl@01c20800 {
++ ahci_pwr_pin_olinuxinolime: ahci_pwr_pin@1 {
++allwinner,pins = PC3;
++allwinner,function = gpio_out;
++allwinner,drive = 0;
++allwinner,pull = 0;
++ };
++
++ led_pins_olinuxinolime: led_pins@0 {
++allwinner,pins = PH2;
++allwinner,function = gpio_out;
++allwinner,drive = 1;
++allwinner,pull = 0;
++ };
++ };
++
++ uart0: serial@01c28000 {
++ pinctrl-names = default;
++ pinctrl-0 = uart0_pins_a;
++ status = okay;
++ };
++
++ i2c0: i2c@01c2ac00 {
++ pinctrl-names = default;
++ pinctrl-0 = i2c0_pins_a;
++ status = okay;
++
++ axp209: pmic@34 {
++compatible = x-powers,axp209;
++reg = 0x34;
++interrupt-parent = nmi_intc;
++interrupts = 0 8;
++
++interrupt-controller;
++#interrupt-cells = 1;
++ };
++ };
++
++ gmac: ethernet@01c5 {
++ pinctrl-names = default;
++ pinctrl-0 = gmac_pins_mii_a;
++ phy = phy1;
++ phy-mode = mii;
++ status = okay;
++
++ phy1: ethernet-phy@1 {
++reg = 1;
++ };
++ };
++ };
++
++ leds {
++ compatible = gpio-leds;
++ pinctrl-names = default;
++ pinctrl-0 = led_pins_olinuxinolime;
++
++ green {
++ label = a20-olinuxino-lime:green:usr;
++ gpios = pio 7 2 0;
++ default-state = on;
++ };
++ };
++
++ reg_ahci_5v: ahci-5v {
++ pinctrl-0 = ahci_pwr_pin_olinuxinolime;
++ gpio = pio 2 3 0;
++ status = okay;
++ };
++
++
Bug#763897: linux 3.16.3-2: [PATCH] Please add a dts for the LeMaker Banana Pi
Source: linux Version: 3.16.3-2 Severity: Wishlist Tags: patch Hello, the LeMaker Banana Pi is a small ARM development board based on the Allwinner A20 SoC. Several DDs have received one of these boards at Debconf 14 and it would be really nice to have it supported in Jessie's kernel 3.16. Driver support for the board (UART, MMC, SATA, USB, Ethernet) is already available in kernel 3.16, just the device-tree information is missing. A dts patchset for the board has been written by Hans de Goede (see http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292110.html) and has been accepted upstream (see http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292431.html). Attached is a patch against the current sid linux package SVN tree that contains a backport of this patchset to kernel 3.16. No content changes were applied to the patchset, the patches were just refreshed to apply cleanly against 3.16. Included is also another dts patch from linux-next, on which the patchset depends: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=0fc2b7af8cd5918c0101dfb178b5a3a4b021a50b I would apprechiate very much if you could include this patch into the linux 3.16.3-3 package for Jessie. 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. Index: debian/patches/features/arm/dts-sun7i-Add-Banana-Pi-board.patch === --- debian/patches/features/arm/dts-sun7i-Add-Banana-Pi-board.patch (revision 0) +++ debian/patches/features/arm/dts-sun7i-Add-Banana-Pi-board.patch (working copy) @@ -0,0 +1,244 @@ +From: Hans de Goede hdego...@redhat.com +Subject: [PATCH v2 3/3] ARM: dts: sun7i: Add Banana Pi board +Date: Wed, 1 Oct 2014 09:26:06 +0200 + +The Banana Pi is an A20 based development board using Raspberry Pi compatible +IO headers. It comes with 1 GB RAM, 1 Gb ethernet, 2x USB host, sata, hdmi +and stereo audio out + various expenansion headers: + +http://www.lemaker.org/ + +Signed-off-by: Hans de Goede hdego...@redhat.com +--- + arch/arm/boot/dts/Makefile | 1 + + arch/arm/boot/dts/sun7i-a20-bananapi.dts | 214 +++ + 2 files changed, 215 insertions(+) + create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi.dts + +--- a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile +@@ -376,6 +376,7 @@ + sun6i-a31-colombus.dtb \ + sun6i-a31-m9.dtb + dtb-$(CONFIG_MACH_SUN7I) += \ ++ sun7i-a20-bananapi.dtb \ + sun7i-a20-cubieboard2.dtb \ + sun7i-a20-cubietruck.dtb \ + sun7i-a20-i12-tvbox.dtb \ +--- /dev/null b/arch/arm/boot/dts/sun7i-a20-bananapi.dts +@@ -0,0 +1,214 @@ ++/* ++ * Copyright 2014 Hans de Goede hdego...@redhat.com ++ * ++ * Hans de Goede hdego...@redhat.com ++ * ++ * This file is dual-licensed: you can use it either under the terms ++ * of the GPL or the X11 license, at your option. Note that this dual ++ * licensing only applies to this file, and not this project as a ++ * whole. ++ * ++ * a) This library is free software; you can redistribute it and/or ++ * modify it under the terms of the GNU General Public License as ++ * published by the Free Software Foundation; either version 2 of the ++ * License, or (at your option) any later version. ++ * ++ * This library is distributed in the hope that it will be useful, ++ * but WITHOUT ANY WARRANTY; without even the implied warranty of ++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ++ * GNU General Public License for more details. ++ * ++ * You should have received a copy of the GNU General Public ++ * License along with this library; if not, write to the Free ++ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, ++ * MA 02110-1301 USA ++ * ++ * Or, alternatively, ++ * ++ * b) Permission is hereby granted, free of charge, to any person ++ * obtaining a copy of this software and associated documentation ++ * files (the Software), to deal in the Software without ++ * restriction, including without limitation the rights to use, ++ * copy, modify, merge, publish, distribute, sublicense, and/or ++ * sell copies of the Software, and to permit persons to whom the ++ * Software is furnished to do so, subject to the following ++ * conditions: ++ * ++ * The above copyright notice and this permission notice shall be ++ * included in all copies or substantial portions of the Software. ++ * ++ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, ++ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES ++ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ++ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT ++ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, ++ *
Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
On Tue, Sep 23, 2014 at 11:42:08PM +0200, Michael Prokop wrote: * Karsten Merker [Tue Sep 23, 2014 at 11:22:32PM +0200]: Please always include ohci-platform, ehci-platform and phy-sun4i-usb into the initramfs if they are provided by the kernel for which the initramfs is built. Does this look like it would provide what you're asking for? http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/bug_762634id=3b835665015c0a9287284c2548b12ab7c8cabc78 Hello, outside d-i and for the MODULES=most configuration, this works fine: $ grep MODULES /etc/initramfs-tools/initramfs.conf # MODULES: [ most | netboot | dep | list ] MODULES=most $ sudo update-initramfs -u -k 3.16-2-armmp-lpae update-initramfs: Generating /boot/initrd.img-3.16-2-armmp-lpae Installing sun7i-a20-cubietruck.dtb 3.16-2-armmp-lpae into /boot Installing sun7i-a20-cubietruck.dtb 3.16-2-armmp-lpae into /boot flash-kernel: installing version 3.16-2-armmp-lpae Generating boot script u-boot image... done. Taking backup of boot.scr. Installing new boot.scr. $ lsinitramfs /boot/initrd.img-3.16-2-armmp-lpae |grep -e hci-platform -e phy-sun4i-usb lib/modules/3.16-2-armmp-lpae/kernel/drivers/phy/phy-sun4i-usb.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ohci-platform.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ehci-platform.ko Inside the /target chroot created by d-i, update-initramfs is by default configured to run with MODULES=dep and gives only the following modules on my armhf/sunxi test system: lib/modules/3.16-2-armmp-lpae/kernel/drivers lib/modules/3.16-2-armmp-lpae/kernel/drivers/scsi lib/modules/3.16-2-armmp-lpae/kernel/drivers/scsi/scsi_mod.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/scsi/sd_mod.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ehci-hcd.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/host/ehci-platform.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/storage lib/modules/3.16-2-armmp-lpae/kernel/drivers/usb/storage/usb-storage.ko lib/modules/3.16-2-armmp-lpae/kernel/drivers/md lib/modules/3.16-2-armmp-lpae/kernel/drivers/md/dm-mod.ko lib/modules/3.16-2-armmp-lpae/kernel/lib lib/modules/3.16-2-armmp-lpae/kernel/lib/crc16.ko lib/modules/3.16-2-armmp-lpae/kernel/lib/crc-t10dif.ko lib/modules/3.16-2-armmp-lpae/kernel/fs lib/modules/3.16-2-armmp-lpae/kernel/fs/mbcache.ko lib/modules/3.16-2-armmp-lpae/kernel/fs/ext4 lib/modules/3.16-2-armmp-lpae/kernel/fs/ext4/ext4.ko lib/modules/3.16-2-armmp-lpae/kernel/fs/jbd2 lib/modules/3.16-2-armmp-lpae/kernel/fs/jbd2/jbd2.ko lib/modules/3.16-2-armmp-lpae/kernel/crypto lib/modules/3.16-2-armmp-lpae/kernel/crypto/crct10dif_generic.ko lib/modules/3.16-2-armmp-lpae/kernel/crypto/crct10dif_common.ko The phy-sun4i-usb module is missing there, although it is loaded by the running kernel: # lsmod |grep phy_sun4i_usb phy_sun4i_usb 4260 4 Without phy_sun4i_usb, USB support does not work at all on this platform, so this module would always have to be included. The missing ohci-hcd and ohci-platform modules would be explained by the fact that this particular device technically has both EHCI and OHCI controllers, but the platform-dependent OHCI glue code is not yet implemented in the kernel, so the OHCI part is currently invisible to the kernel. When manually running update-initramfs with MODULES=most inside the d-i /target chroot, all three modules (ohci-platform, ehci-platform and phy-sun4i-usb) are there, but by default the user is not presented with a choice regarding MODULES=dep vs. MODULES=most in d-i. The relevant debconf prompt is only presented at debconf priority medium, i.e. when running d-i in expert mode, so I would appreciate very much if you could include the missing phy-sun4i-usb module also when building the initramfs with MODULES=dep. 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925061548.ga9...@excalibur.cnev.de
Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
On Thu, Sep 25, 2014 at 01:31:16PM +0200, Michael Prokop wrote: * Cyril Brulebois [Thu Sep 25, 2014 at 12:32:22PM +0200]: Michael Prokop m...@debian.org (2014-09-25): * Karsten Merker [Thu Sep 25, 2014 at 08:15:48AM +0200]: Inside the /target chroot created by d-i, update-initramfs is by default configured to run with MODULES=dep and gives only the following modules on my armhf/sunxi test system: Hmpf, I so much am not a fan of this default MODULES=dep behaviour of d-i... Can you please clarify? I see this in base-installer: | if db_get base-installer/initramfs-tools/driver-policy \ |[ -z $RET ]; then | # Get default for architecture [snip] Granted, no coffee yet. But I seem to recall that people having issues with MODULES=dep are those who actually selected it manually (e.g. through expert install). I'm just not a friend of MODULES=dep as a default behaviour, good to know that d-i uses a sane default here. :) Thanks for verifying! My local test confirms that a basic installation (netboot-gtk image on amd64 using udebs from sid) leads to MODULES=most in /target. I didn't go further than the popcon prompt though. Hello, I have just run another test on armhf with today's daily d-i build (dated 25-Sep-2014 05:17) and default debconf priority (at which no debconf prompt regarding initramfs-tools gets displayed). This results in: ~ # cat /target/etc/initramfs-tools/conf.d/driver-policy # Driver inclusion policy selected during installation # Note: this setting overrides the value set in the file # /etc/initramfs-tools/initramfs.conf MODULES=dep and the short module list in the initramfs confirms that it was really built with MODULES=dep. The comment marked above suggests that this is an architecture-dependent default, so we could possibly both be right ;-). If yes, we will have to find a solution regarding the inclusion of the phy-sun4i-usb module when building the initramfs with MODULES=dep, though. 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925200457.ga5...@excalibur.cnev.de
Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
On Thu, Sep 25, 2014 at 09:21:57AM +0200, Michael Prokop wrote:
Is there a /sys/... entry which would make it obvious for i-t that
phy-sun4i-usb exists/should be loaded?
Sorry, I do not know that. A possible approach could be parsing
some of the information in /proc/device-tree, as the module
initialization is triggered by the existence of certain
compatible properties in the device-tree.
From drivers/phy/phy-sun4i-usb.c in the kernel sources:
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = allwinner,sun4i-a10-usb-phy },
{ .compatible = allwinner,sun5i-a13-usb-phy },
{ .compatible = allwinner,sun6i-a31-usb-phy },
{ .compatible = allwinner,sun7i-a20-usb-phy },
{ },
};
MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
Something like grepping for the compatible strings in the result of
a find /proc/device-tree/ -iname compatible might work, but
I have not actually tested that yet.
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.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925205946.gb5...@excalibur.cnev.de
Bug#762634: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
Package: initramfs-tools Version: 0.116 Hello, running Debian with the root filesystem on a USB mass storage device (such as a USB harddisk) requires that the driver modules for the USB host controllers of the system are available in the initramfs. If they are missing, the root filesystem cannot be mounted, which currently happens on a number of armhf systems. On i386/amd64, the OHCI/EHCI host controllers are PCI devices which are supported by the ohci-pci and ehci-pci modules. On many armhf systems the USB host controllers are OHCI/EHCI-compatible, but implemented as a platform device, so they are not supported by ohci-pci and ehci-pci. Instead these systems need the following platform device driver modules: - ohci-platform - ehci-platform and in the case of armhf/sunxi-based systems an additional USB phy driver module: - phy-sun4i-usb These modules are not included in the initramfs built by initramfs-tools (even if MODULES=most is set in initramfs.conf), which makes it impossible to boot with the rootfs on a USB disk on such systems. Please always include ohci-platform, ehci-platform and phy-sun4i-usb into the initramfs if they are provided by the kernel for which the initramfs is built. 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140923212232.ga5...@excalibur.cnev.de
Bug#762219: linux 3.16.3-1 FTBS for the armel kirkwood flavor due to size limit
source: linux version: 3.16.3-1 [CCing debian-arm@lists.d.o] Hello, according to https://buildd.debian.org/status/fetch.php?pkg=linuxarch=armelver=3.16.3-1stamp=1411133746 linux 3.16.3-1 FTBFS for the armel kirkwood flavor due to the resulting image being too big for the platform by 648 bytes, so the kernel configuration for this platform will probably have to be trimmed down: make[3]: Leaving directory '/«PKGBUILDDIR»/debian/build/build_armel_none_kirkwood' python debian/bin/buildcheck.py debian/build/build_armel_none_kirkwood armel none kirkwood Can't read ABI reference. ABI not checked! Continuing. Image too large (2097728 2097080)! Refusing to continue. make[2]: *** [debian/stamps/build_armel_none_kirkwood_plain] Error 1 debian/rules.real:158: recipe for target 'debian/stamps/build_armel_none_kirkwood_plain' failed 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919175421.ga6...@excalibur.cnev.de
Bug#762221: linux 3.16.3-1 FTFBS for s390x with undefined reference to compat_sys_ni_syscall
source: linux version: 3.16.3-1 [CCing debian-s390@lists.d.o] According to https://buildd.debian.org/status/fetch.php?pkg=linuxarch=s390xver=3.16.3-1stamp=1411128376 linux 3.16.3-1 FTBFS on s390x with the following error: LINKvmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o arch/s390/built-in.o: In function `sys_call_table_emu': (.rodata+0x2bbc): undefined reference to `compat_sys_ni_syscall' arch/s390/built-in.o: In function `sys_call_table_emu': (.rodata+0x2bc0): undefined reference to `compat_sys_ni_syscall' make[5]: *** [vmlinux] Error 1 /«PKGBUILDDIR»/Makefile:891: recipe for target 'vmlinux' failed make[4]: *** [sub-make] Error 2 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919181001.gb6...@excalibur.cnev.de
Bug#761591: linux 3.16.2-3: missing usb platform modules in udeb
On Sun, Sep 14, 2014 at 10:31:56PM +0200, Karsten Merker wrote: the usb-modules udeb built by the linux 3.16.2-3 package does not contain the usb platform driver modules ehci-platform and ohci-platform. Systems that have EHCI- or OHCI-compatible USB host controllers which are not implemented as PCI devices, but as platform devices, need these modules to provide the necessary glue to make ehci-hcd and ohci-hcd work. Without them, there is no USB support in the Debian-installer on e.g. all sunxi-based devices. Attached is a small patch that should add the necessary modules to the udeb (test build still running). The test build has completed in the meantime and I have locally built a debian-installer based on it. Unfortunately my original patch has not been sufficient - besides the (ehci|ohci)-platform modules, on sunxi-based devices an additional phy driver (phy-sun4i-usb) appears to be required. Follwing is a new version of my original patch - a test build is running but due to the build host being rather slow, I probably won't be able to actually test it in d-i before tomorrow evening. Index: debian/installer/modules/usb-modules === --- debian/installer/modules/usb-modules(Revision 21845) +++ debian/installer/modules/usb-modules(Arbeitskopie) @@ -1,7 +1,10 @@ ehci-hcd ? ehci-pci ? +ehci-platform ? ohci-hcd ? ohci-pci ? +ohci-platform ? uhci-hcd ? xhci-hcd ? usbcore ? +phy-sun4i-usb ? 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916181332.ga5...@excalibur.cnev.de
linux: current sid SVN (3.16.2-4) FTBFS on armhf
Hello Ben, the current linux kernel package SVN head FTBFS on armhf with entry-common.S:105: Error: __NR_syscalls is not equal to the size of the syscall table This might be related to the recently introduced patches implementing additional syscalls: - shm: add memfd_create() syscall - mm: Add memfd_create() system call Attached is the full build log. 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. dpkg-buildpackage: Quellpaket linux dpkg-buildpackage: Quellversion 3.16.2-4 dpkg-buildpackage: Quelldistribution UNRELEASED dpkg-buildpackage: Quellen geändert durch Ben Hutchings b...@decadent.org.uk dpkg-buildpackage: Host-Architektur armhf dpkg-source --before-build linux dpkg-source: Information: Optionen aus linux/debian/source/local-options werden verwendet: --abort-on-upstream-changes dpkg-source: Information: Optionen aus linux/debian/source/options werden verwendet: --compression=xz --tar-ignore=debian/*.local fakeroot debian/rules clean dh_testdir rm -rf debian/build debian/stamps debian/lib/python/debian_linux/*.pyc debian/lib/python/debian_linux/__pycache__ $(find debian -maxdepth 1 -type d -name 'linux-*') debian/*-modules-*-di* debian/kernel-image-*-di* debian/xen-linux-system-* dh_clean debian/rules build-arch dh_testdir /usr/bin/make -f debian/rules.gen build-arch_armhf make[1]: Entering directory '/storage/tmp/debian-kernel/sid/linux' /usr/bin/make -f debian/rules.real build-arch ABINAME='3.16-2' ABINAME_PART='-2' ARCH='armhf' COMPILER='gcc-4.8' FEATURESET='none' FLAVOUR='armmp' IMAGE_FILE='arch/arm/boot/zImage' IMAGE_INSTALL_STEM='vmlinuz' KCONFIG='debian/config/config debian/config/kernelarch-arm/config debian/config/kernelarch-arm/config debian/config/armhf/config debian/config/armhf/config.armmp' KERNEL_ARCH='arm' LOCALVERSION='-armmp' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-armmp' MODULES='True' SOURCEVERSION='3.16.2-4' TYPE='plain' UPSTREAMVERSION='3.16' VERSION='3.16' make[2]: Entering directory '/storage/tmp/debian-kernel/sid/linux' test -d .pc set +e; QUILT_PC=.pc quilt unapplied --quiltrc - /dev/null echo 'Patch series not fully applied'; test $? -eq 1 mkdir -p 'debian/build/' python debian/bin/kconfig.py 'debian/build/config.armhf_none_armmp' debian/config/config debian/config/kernelarch-arm/config debian/config/kernelarch-arm/config debian/config/armhf/config debian/config/armhf/config.armmp series-Datei vollständig angewandt, endet in Patch features/all/sfc-Add-40G-link-capability-decoding.patch mkdir -p 'debian/build' rm -f 'debian/build/source_none' ln -s '/storage/tmp/debian-kernel/sid/linux' 'debian/build/source_none' rm -rf 'debian/build/build_armhf_none_armmp' mkdir 'debian/build/build_armhf_none_armmp' cp 'debian/build/config.armhf_none_armmp' 'debian/build/build_armhf_none_armmp/.config' echo 'override ARCH = arm' 'debian/build/build_armhf_none_armmp/.kernelvariables' echo 'override KERNELRELEASE = 3.16-2-armmp' 'debian/build/build_armhf_none_armmp/.kernelvariables' echo 'CCACHE = ccache' 'debian/build/build_armhf_none_armmp/.kernelvariables' echo 'CC = $(if $(DEBIAN_KERNEL_USE_CCACHE),$(CCACHE)) $(CROSS_COMPILE)gcc-4.8' 'debian/build/build_armhf_none_armmp/.kernelvariables' echo 'ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))' 'debian/build/build_armhf_none_armmp/.kernelvariables' echo 'override CROSS_COMPILE = $(DEB_HOST_GNU_TYPE)-' 'debian/build/build_armhf_none_armmp/.kernelvariables' echo 'endif' 'debian/build/build_armhf_none_armmp/.kernelvariables' env -u ABINAME -u ABINAME_PART -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR=Debian DISTRIBUTION_VERSION=3.16.2-4 KBUILD_BUILD_TIMESTAMP=Debian 3.16.2-4 (2014-09-13) KBUILD_BUILD_USER=debian-kernel KBUILD_BUILD_HOST=lists.debian.org /usr/bin/make -C 'debian/build/source_none' O='/storage/tmp/debian-kernel/sid/linux/debian/build/build_armhf_none_armmp' V=1 listnewconfig make[3]: Entering directory '/storage/tmp/debian-kernel/sid/linux' make[1]: Entering directory `/storage/tmp/debian-kernel/sid/linux/debian/build/build_armhf_none_armmp' /usr/bin/make -C /storage/tmp/debian-kernel/sid/linux/debian/build/build_armhf_none_armmp \ KBUILD_SRC=/storage/tmp/debian-kernel/sid/linux \ KBUILD_EXTMOD= -f /storage/tmp/debian-kernel/sid/linux/Makefile \ listnewconfig /usr/bin/make -f /storage/tmp/debian-kernel/sid/linux/scripts/Makefile.build obj=scripts/basic ln -fsn /storage/tmp/debian-kernel/sid/linux source /bin/bash /storage/tmp/debian-kernel/sid/linux/scripts/mkmakefile \ /storage/tmp/debian-kernel/sid/linux . 3 16 GEN ./Makefile gcc -Wp,-MD,scripts/basic/.fixdep.d -Iscripts/basic -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep
Bug#745972: Please enable additional kernel config options for sunxi support (starting with kernel 3.14)
Package: linux Severity: wishlist Hello, I am working on getting ARM platforms based on the Allwinner A10 (sun4i) and A20 (sun7i) SOCs better supported in Debian. During the last months quite a bit of drivers for these SOCs have been integrated into the mainline Linux kernel. I would therefore like to ask for the following additional kernel configuration options to be enabled in future Debian kernel packages: Kernel 3.14 === CONFIG_RTC_DRV_SUNXI=m (sunxi realtime clock support) CONFIG_USB_EHCI_HCD_PLATFORM=m (platform device for enabling the embedded EHCI controller) CONFIG_USB_OHCI_HCD_PLATFORM=m (platform device for enabling the embedded OHCI controller) CONFIG_SUNXI_WATCHDOG=m(embedded watchdog device) Kernel 3.15 (drivers accepted in 3.15rc1) === CONFIG_PHY_SUN4I_USB=m (PHY driver for the embedded OHCI and EHCI controllers) CONFIG_SPI=y CONFIG_SPI_SUNXI=m (sunxi SPI master driver) Kernel 3.16 (driver submitted and currently in review) === CONFIG_MMC_SUNXI=m (sunxi MMC/SD controller driver) 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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426202301.ga9...@excalibur.cnev.de
Bug#298230: Serial problems with kernel 2.4.27
Package: kernel-image-2.4.27-2 Version: 2.4.27-8 This bugreport describes several problems I have encountered in kernel-image-2.4.27-1-k7 and kernel-image-2.4.27-2-k7 in Sarge: Originally I had kernel-image-2.4.27-1-k7 installed and serial support was completely broken. Every connection on any serial port (tested with two onboard serial ports as well as with two different USB-serial adaptors) just delivered garbage. In every case the same port worked like a charm when used with kernel 2.6.8 and 2.6.9. I had talked to Andreas Barth about this at FOSDEM and he asked me to file an RC bug and CC debian-release and debian-kernel. Unfortunately I did not have time for it until today. In the meantime, kernel-image-2.4.27-2-k7 went into sarge, so I tried that as well. Interestingly, the local serial ports (16550A) work ok in kernel-image-2.4.27-2-k7, but on the USB-serial adapter, a PL2303, I get the strange effect that receiving data works ok, but sending does not work at all. The exact same adapter works fine for receiving as well as for sending with kernel 2.6.8 and 2.6.9 on the same machine. I do not have access to the other USB-serial adapter I used on kernel-image-2.4.27-1-k7, so I cannot repeat the test with that one. If anybody has one, I would be interested in the results. Another thing I get with 2.4.27 and not with 2.6.8/2.6.9 is the following: [...] usb.c: USB device not accepting new address=93 (error=-71) hub.c: new USB device 00:0f.2-1, assigned address 94 usb.c: USB device not accepting new address=94 (error=-71) hub.c: new USB device 00:0f.2-1, assigned address 95 usb.c: USB device not accepting new address=95 (error=-71) hub.c: new USB device 00:0f.2-1, assigned address 96 hub.c: USB hub found hub.c: 4 ports detected The USB device not accepting address happens about 20 times on boot, until the kernel actually accepts the USB hub. This is independant from the USB-serial adapter. It happens with the PL2303 connected or disconnected and the problems with the PL2303 occur regardless whether it is connected directly to the USB port on the computer or to the hub. As other people have reported USB problems with 2.4.27, this might be a general USB issue. Machine information: Elitegroup K7S5A with AMD Duron 1300 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) The USB hub is connected to the VIA EHCI controller. Regards, Karsten -- #include standard_disclaimer Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
