Bug#1033663: linux: reproducible-builds: Embedded build path in various binaries

[Vagrant Cascadian]

On 2023-07-14, Ben Hutchings wrote:
> On Wed, 2023-03-29 at 09:58 -0700, Vagrant Cascadian wrote:
>> The build path is embedded in various binaries:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/linux.html
>> 
>>   /usr/sbin/bpftool
>> 
>>   /build/1st/linux-6.1.20/tools/lib/bpf/libbpf.c:805
>>   vs.
>>   /build/2/linux-6.1.20/2nd/tools/lib/bpf/libbpf.c:805  
>> 
>> This *seems* like a regression from earlier versions, though I have not
>> tracked down when the tools started embedding the build paths...
> [...]
>
> Please see
> <https://salsa.debian.org/kernel-team/linux/-/merge_requests/741>.
>
> The embedded paths are mostly fixed by:
> <https://salsa.debian.org/kernel-team/linux/-/merge_requests/741/diffs?commit_id=7293fda0eef37c07214d1e0c4e5ff1d1fa3e2e60>.
>
> Perhaps I should finalise that MR even though it doesn't fix
> everything?

Very glad to see that merge request, thanks!

With my reproducible builds hat on, I would welcome partial fixes at
this point, especially for such core packages! It helps to troubleshoot
outstanding issues and also avoids duplication of work.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1033663: linux: reproducible-builds: Embedded build path in various binaries

[Vagrant Cascadian]

On 2023-03-29, Vagrant Cascadian wrote:
> The build path is embedded in various binaries:
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/linux.html
>
>   /usr/sbin/bpftool
>
>   /build/1st/linux-6.1.20/tools/lib/bpf/libbpf.c:805
>   vs.
>   /build/2/linux-6.1.20/2nd/tools/lib/bpf/libbpf.c:805  
>
> This *seems* like a regression from earlier versions, though I have not
> tracked down when the tools started embedding the build paths...
>
> The attached patches fix this for some of the binary packages and
> corresponding dbgsym packages (bpftool, hyperv-daemons, *cpupower*) by
> explicitly passing the -ffile-prefix-map argument (to avoid embedding
> the build path) in the CFLAGS or EXTRA_CFLAGS variables in
> debian/rules.d/.

Any objections to me merging these patches? Prefer if they remain
separate or squash them into a single patch?


> From 7dcacfb3415c5ec4caea8933dd2c12fb401bea52 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Tue, 28 Mar 2023 14:49:01 -0700
> Subject: [PATCH 1/4] debian/rules.d/tools/bpf/bpftool/Makefile: Pass
>  -ffile-prefix-map via EXTRA_CFLAGS.
>
> ---
>  debian/rules.d/tools/bpf/bpftool/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/rules.d/tools/bpf/bpftool/Makefile 
> b/debian/rules.d/tools/bpf/bpftool/Makefile
> index 17c27c104..9d3017e42 100644
> --- a/debian/rules.d/tools/bpf/bpftool/Makefile
> +++ b/debian/rules.d/tools/bpf/bpftool/Makefile
> @@ -5,7 +5,7 @@ MAKE_BPFTOOL += prefix=/usr
>  MAKE_BPFTOOL += mandir=/usr/share/man
>  MAKE_BPFTOOL += V=1
>  MAKE_BPFTOOL += ARCH=$(KERNEL_ARCH)
> -MAKE_BPFTOOL += EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)'
> +MAKE_BPFTOOL += EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS) 
> -ffile-prefix-map=$(top_srcdir)=.'
>  MAKE_BPFTOOL += EXTRA_LDFLAGS='$(LDFLAGS)'
>  
>  # dynamically linking with libbfd is not allowed in Debian
> -- 
> 2.39.2
>
> From cb11c490a41a0afbdeb00f272fa8a71cc3c69be1 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Tue, 28 Mar 2023 15:48:05 -0700
> Subject: [PATCH 2/4] debian/rules.d/tools/power/cpupower/Makefile: Pass
>  -ffile-prefix-map via MAKE_CPUPOWER CFLAGS.
>
> ---
>  debian/rules.d/tools/power/cpupower/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/rules.d/tools/power/cpupower/Makefile 
> b/debian/rules.d/tools/power/cpupower/Makefile
> index e4bd5202d..28ccf7004 100644
> --- a/debian/rules.d/tools/power/cpupower/Makefile
> +++ b/debian/rules.d/tools/power/cpupower/Makefile
> @@ -1,6 +1,6 @@
>  include $(top_rulesdir)/Makefile.inc
>  
> -MAKE_CPUPOWER := CFLAGS='$(CFLAGS) $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) 
> O=$(CURDIR) CPUFREQ_BENCH=false V=true mandir=/usr/share/man
> +MAKE_CPUPOWER := CFLAGS='$(CFLAGS) -ffile-prefix-map=$(top_srcdir)=. 
> $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) O=$(CURDIR) CPUFREQ_BENCH=false 
> V=true mandir=/usr/share/man
>  
>  MAKE_CPUPOWER += DEBUG=$(if $(filter noopt,$(DEB_BUILD_OPTIONS)),true,)
>  
> -- 
> 2.39.2
>
> From 2cf67982526879524548e37df0efac5f8b37e0d3 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Tue, 28 Mar 2023 16:57:01 -0700
> Subject: [PATCH 3/4] debian/rules.d/tools/power/x86/*/Makefile: Add
>  -ffile-prefix-map to CFLAGS.
>
> ---
>  debian/rules.d/tools/power/x86/turbostat/Makefile  | 2 ++
>  debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/debian/rules.d/tools/power/x86/turbostat/Makefile 
> b/debian/rules.d/tools/power/x86/turbostat/Makefile
> index eb5124d3a..019fcbde6 100644
> --- a/debian/rules.d/tools/power/x86/turbostat/Makefile
> +++ b/debian/rules.d/tools/power/x86/turbostat/Makefile
> @@ -7,3 +7,5 @@ include $(top_rulesdir)/Makefile.inc
>  CPPFLAGS += -I"$(top_srcdir)/tools/include" 
> -DMSRHEADER='"$(top_srcdir)/arch/x86/include/asm/msr-index.h"' 
> -DINTEL_FAMILY_HEADER='"$(top_srcdir)/arch/x86/include/asm/intel-family.h"'
>  
>  LDLIBS += -lcap -lrt
> +
> +CFLAGS += -ffile-prefix-map=$(top_srcdir)=.
> diff --git a/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile 
> b/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
> index b9ec56c89..a86da0f1e 100644
> --- a/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
> +++ b/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
> @@ -5,3 +5,5 @@ installdir = /usr/sbin
>  include $(top_rulesdir)/Makefile.inc
>  
>  CPPFLAGS += -I"$(top_srcdir)/tools/include" 
> -DMSRHEADER='"$(top_srcdir)/arch/x86/include/asm/msr-index.h"'
> +
> +CFLAGS +

Bug#1033663: linux: reproducible-builds: Embedded build path in various binaries

[Vagrant Cascadian]

Source: linux
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/linux.html

  /usr/sbin/bpftool

  /build/1st/linux-6.1.20/tools/lib/bpf/libbpf.c:805
  vs.
  /build/2/linux-6.1.20/2nd/tools/lib/bpf/libbpf.c:805  

This *seems* like a regression from earlier versions, though I have not
tracked down when the tools started embedding the build paths...

The attached patches fix this for some of the binary packages and
corresponding dbgsym packages (bpftool, hyperv-daemons, *cpupower*) by
explicitly passing the -ffile-prefix-map argument (to avoid embedding
the build path) in the CFLAGS or EXTRA_CFLAGS variables in
debian/rules.d/.

I unsuccessfully tried applying similar patches for other tools packages
(rtla, perf, usbip) but was not able to convince the tools to take the
passed flags...

It would, of course, be better to figure out a way to get the various
tools to respect the default CFLAGS, as -ffile-prefix-map is included in
the default CFLAGS.

Unfortunately, these patches do not fix all reproducibility issues, but
applying these patches could reduce some of the noise and make it easier
to debug the remaining issues.

Thanks for maintaining linux!

live well,
  vagrant
From 7dcacfb3415c5ec4caea8933dd2c12fb401bea52 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 28 Mar 2023 14:49:01 -0700
Subject: [PATCH 1/4] debian/rules.d/tools/bpf/bpftool/Makefile: Pass
 -ffile-prefix-map via EXTRA_CFLAGS.

---
 debian/rules.d/tools/bpf/bpftool/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules.d/tools/bpf/bpftool/Makefile b/debian/rules.d/tools/bpf/bpftool/Makefile
index 17c27c104..9d3017e42 100644
--- a/debian/rules.d/tools/bpf/bpftool/Makefile
+++ b/debian/rules.d/tools/bpf/bpftool/Makefile
@@ -5,7 +5,7 @@ MAKE_BPFTOOL += prefix=/usr
 MAKE_BPFTOOL += mandir=/usr/share/man
 MAKE_BPFTOOL += V=1
 MAKE_BPFTOOL += ARCH=$(KERNEL_ARCH)
-MAKE_BPFTOOL += EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)'
+MAKE_BPFTOOL += EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS) -ffile-prefix-map=$(top_srcdir)=.'
 MAKE_BPFTOOL += EXTRA_LDFLAGS='$(LDFLAGS)'
 
 # dynamically linking with libbfd is not allowed in Debian
-- 
2.39.2

From cb11c490a41a0afbdeb00f272fa8a71cc3c69be1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 28 Mar 2023 15:48:05 -0700
Subject: [PATCH 2/4] debian/rules.d/tools/power/cpupower/Makefile: Pass
 -ffile-prefix-map via MAKE_CPUPOWER CFLAGS.

---
 debian/rules.d/tools/power/cpupower/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules.d/tools/power/cpupower/Makefile b/debian/rules.d/tools/power/cpupower/Makefile
index e4bd5202d..28ccf7004 100644
--- a/debian/rules.d/tools/power/cpupower/Makefile
+++ b/debian/rules.d/tools/power/cpupower/Makefile
@@ -1,6 +1,6 @@
 include $(top_rulesdir)/Makefile.inc
 
-MAKE_CPUPOWER := CFLAGS='$(CFLAGS) $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) O=$(CURDIR) CPUFREQ_BENCH=false V=true mandir=/usr/share/man
+MAKE_CPUPOWER := CFLAGS='$(CFLAGS) -ffile-prefix-map=$(top_srcdir)=. $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) O=$(CURDIR) CPUFREQ_BENCH=false V=true mandir=/usr/share/man
 
 MAKE_CPUPOWER += DEBUG=$(if $(filter noopt,$(DEB_BUILD_OPTIONS)),true,)
 
-- 
2.39.2

From 2cf67982526879524548e37df0efac5f8b37e0d3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 28 Mar 2023 16:57:01 -0700
Subject: [PATCH 3/4] debian/rules.d/tools/power/x86/*/Makefile: Add
 -ffile-prefix-map to CFLAGS.

---
 debian/rules.d/tools/power/x86/turbostat/Makefile  | 2 ++
 debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/debian/rules.d/tools/power/x86/turbostat/Makefile b/debian/rules.d/tools/power/x86/turbostat/Makefile
index eb5124d3a..019fcbde6 100644
--- a/debian/rules.d/tools/power/x86/turbostat/Makefile
+++ b/debian/rules.d/tools/power/x86/turbostat/Makefile
@@ -7,3 +7,5 @@ include $(top_rulesdir)/Makefile.inc
 CPPFLAGS += -I"$(top_srcdir)/tools/include" -DMSRHEADER='"$(top_srcdir)/arch/x86/include/asm/msr-index.h"' -DINTEL_FAMILY_HEADER='"$(top_srcdir)/arch/x86/include/asm/intel-family.h"'
 
 LDLIBS += -lcap -lrt
+
+CFLAGS += -ffile-prefix-map=$(top_srcdir)=.
diff --git a/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile b/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
index b9ec56c89..a86da0f1e 100644
--- a/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -5,3 +5,5 @@ installdir = /usr/sbin
 include $(top_rulesdir)/Makefile.inc
 
 CPPFLAGS += -I"$(top_srcdir)/tools/include" -DMSRHEADER='"$(top_srcdir)/arch/x86/include/asm/msr-index.h&

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Vagrant Cascadian]

Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson)
platforms and u-boot list to CC.

On 2023-03-22, Salvatore Bonaccorso wrote:
> Thanks for tracking this down. I would like to loop in Masahiro and
> upstream to see if something can/should be done on upstream side.
>
> Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
> special treatment for the link order of head.o") (which got backported
> as well to 6.1.14) caused the vmlinuz size to icrease significantly,
> causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
> parameters previously working. Full quoting the Debian report below

In general it would be nice to not have the kernel grow nearly 25% in
size from a single commit; was that an expected outcome from the above
upstream change? Was the "special treament" originally done to keep the
kernel size down?

As for u-boot, It seems u-boot might need to update the various load
addresses for the kernel, device tree and ramdisk at some point
regardless of weather this particular issue gets fixed in the kernel, as
the kernel will likely continue to grow a bit over time...

Aurelien Jarno included a patch referenced below which bumps the
tolerances in u-boot from 36MB to 42MB.


> On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
>> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
>> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
>> to boot with:
>> 
>> | 40175552 bytes read in 1695 ms (23 MiB/s)
>> | 43794863 bytes read in 1817 ms (23 MiB/s)
>> | Moving Image from 0x8 to 0x20, end=299
>> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
>> 
>> I tracked the issue to a significant increase of the kernel size between
>> version 6.1.12-1 and 6.15-1:
>> 
>> | 31492   /boot/vmlinuz-6.1.0-5-arm64
>> | 39236   /boot/vmlinuz-6.1.0-6-arm64
>> 
>> This is more than the 36MB that is allowed by u-boot with the default
>> load addresses. A workaround is to shift the load addresses at the
>> u-boot level as in the attached patch.
>> 
>> I have tracked issue on the upstream kernel side to the following commit
>> on the stable tree:
>> 
>> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
>> | Author: Masahiro Yamada 
>> | Date:   Thu Oct 13 08:35:00 2022 +0900
>> | 
>> | arm64: remove special treatment for the link order of head.o
>> | 
>> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
>> | 
>> | In the previous discussion (see the Link tag), Ard pointed out that
>> | arm/arm64/kernel/head.o does not need any special treatment - the only
>> | piece that must appear right at the start of the binary image is the
>> | image header which is emitted into .head.text.
>> | 
>> | The linker script does the right thing to do. The build system does
>> | not need to manipulate the link order of head.o.
>> | 
>> | Link: 
>> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
>> | Suggested-by: Ard Biesheuvel 
>> | Signed-off-by: Masahiro Yamada 
>> | Reviewed-by: Nicolas Schier 
>> | Link: 
>> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
>> | Signed-off-by: Will Deacon 
>> | Signed-off-by: Tom Saeger 
>> | Signed-off-by: Greg Kroah-Hartman 
>> 
>> The problem is still reproducible on Linus' master.
>> 
>> I am reporting the bug to the linux package as I believed there is no
>> real reason for such an increase in the kernel size. In case I missed
>> something and this is actually wanted, the bug can be reassigned to the
>> u-boot package.
>> 
>> Regards
>> Aurelien
>
>> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
>> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
>> @@ -95,32 +95,32 @@
>>   *   text_offset bytes (specified in the header of the Image) into a 2MB
>>   *   boundary. The 'booti' command relocates the image if necessary. Linux 
>> uses
>>   *   a default text_offset of 0x8.  In summary, loading at 0x8
>> - *   satisfies all these constraints and reserving memory up to 0x0240
>> - *   permits fairly large (roughly 36M) kernels.
>> + *   satisfies all these constraints and reserving memory up to 0x02a0
>> + *   permits fairly large (roughly 42M) kernels.
>>   *
>>   * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
>>   * conflict with something else. Reserving 1M for each of them at
>> - * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
>> + * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
>>   *
>>   * On ARM, both the DTB and any possible initrd must be loaded such that 
>> they
>>   * fit inside the lowmem mapping in Linux. In practice, this usually means 
>> not
>>   * more than ~700M away from the start of the kernel image but this number 
>> can
>>   * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
>>   * parameter given to the 

Re: Assist in Development of Patch for Bug 1011542 - Missing phy-gmii-sel.ko Module in Debian Bullseye Installer for Armhf

[Vagrant Cascadian]

On 2022-05-24, David Kaiser wrote:
> I am interested in assisting in the development and testing of a patch
> for this bug report.

Thanks for looking into this!


> I am assuming that the patch may be very simple;
> e.g., simply editing a list of included module names.

Probably just adding phy-gmii-sel to
installer/modules/armhf-armmp/nic-modules or
installer/modules/armhf-armmp/kernel-image in the linux kernel package:

  https://salsa.debian.org/kernel-team/linux

Building the kernel package can definitely be very time consuming and a
little unusual as packages go, but you should be able to cross-build it
on an amd64 machine...

Sounds like you'll also want to get this added into bullseye's kernel,
though normally the process is to first get it fixed in unstable, and
then backport the fix to stable.


> I will need some direction as to where to begin looking for the
> relevant patch source repository and source file.

Getting your custom kernel into a custom-built installer image is a
little trickier...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

[Vagrant Cascadian]

On 2022-04-24, Vagrant Cascadian wrote:
> On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
>> currently, we add the following to the arm64 kernel config provided by
>> the Debian kernel packaging to build a kernel that powers the MNT Reform
>> 2 open source laptop:
>
> Thanks!
>
> Merged most of the changes so far except...

Which I can confirm boots!  Although no output on the LCD, just serial
console...


>> CONFIG_DRM_CDNS_HDMI_CEC=m
>> CONFIG_DRM_IMX_CDNS_MHDP=m
>
> These are not yet in upstream 5.17.x, so I left them out.

Presumably LCD and HDMI don't work due to missing those, and/or other
not-yet-upstream patches...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

[Vagrant Cascadian]

Control: tags 1009858 pending

On 2022-04-24, Vagrant Cascadian wrote:
> On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
>> currently, we add the following to the arm64 kernel config provided by
>> the Debian kernel packaging to build a kernel that powers the MNT Reform
>> 2 open source laptop:
>
> Thanks!
>
> Merged most of the changes so far except...

https://salsa.debian.org/kernel-team/linux/-/commit/aa9f2cfbd99e598ad02043d9238bf7886fc21d1a


live well,
  vagrant

Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

[Vagrant Cascadian]

On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
> currently, we add the following to the arm64 kernel config provided by
> the Debian kernel packaging to build a kernel that powers the MNT Reform
> 2 open source laptop:

Thanks!

Merged most of the changes so far except...


> CONFIG_DRM_CDNS_HDMI_CEC=m
> CONFIG_DRM_IMX_CDNS_MHDP=m

These are not yet in upstream 5.17.x, so I left them out.


> CONFIG_NO_HZ_IDLE=y

It seems that the default defined in debian/config/config is
NO_HZ_FULL=y should default to the same behavior as NO_HZ_IDLE unless a
boot parameter is passed, according to kernel/time/Kconfig.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Vagrant Cascadian]

Control: tags 982270 pending

On 2021-06-18, Vagrant Cascadian wrote:
> On 2021-06-01, Vagrant Cascadian wrote:
>> On 2021-06-01, Rick Thomas wrote:
>>> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
>>> show up in the installer at [1] ?  I'd love to test it!
>> ...
>>> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>>
>> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
>> should also have it.
>>
>> I only tested it outside of debian-installer (e.g. upgrading kernel on
>> an already installed system), so it is also possible that more modules
>> are needed in one of the kernel udebs used by the installer, or that
>> you're experiencing a different issue from the one that was fixed. I'll
>> try to test debian-installer on Cubox-i4pro to see if I still have an
>> issue.
>
> Just tested d-i daily[1] on a Cubox-I4pro, and it definitely fails to
> find the network card.

And same behavior on a wandboard quad...

> Same hardware, same kernel finds it just fine on an already installed
> system... so this most likely means we need to add more modules to one
> of the kernel .udebs.

What's more confusing, is the ethernet is CONFIG_FEC which is enabled as
a built-in, but still needs gpio-mxc to actually function!

Pushed a fix to git:

  
https://salsa.debian.org/kernel-team/linux/-/commit/f952b94621847732b3ed96a74babb89b6a1862f6


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Vagrant Cascadian]

Control: tags 982270 confirmed

On 2021-06-01, Vagrant Cascadian wrote:
> On 2021-06-01, Rick Thomas wrote:
>> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
>> show up in the installer at [1] ?  I'd love to test it!
> ...
>> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>
> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
> should also have it.
>
> I only tested it outside of debian-installer (e.g. upgrading kernel on
> an already installed system), so it is also possible that more modules
> are needed in one of the kernel udebs used by the installer, or that
> you're experiencing a different issue from the one that was fixed. I'll
> try to test debian-installer on Cubox-i4pro to see if I still have an
> issue.

Just tested d-i daily[1] on a Cubox-I4pro, and it definitely fails to
find the network card.

Same hardware, same kernel finds it just fine on an already installed
system... so this most likely means we need to add more modules to one
of the kernel .udebs.

[1] 
https://d-i.debian.org/daily-images/armhf/20210618-00:15/netboot/SD-card-images/

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Vagrant Cascadian]

On 2021-06-01, Rick Thomas wrote:
> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
> show up in the installer at [1] ?  I'd love to test it!
...
> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/

It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
should also have it.

I only tested it outside of debian-installer (e.g. upgrading kernel on
an already installed system), so it is also possible that more modules
are needed in one of the kernel udebs used by the installer, or that
you're experiencing a different issue from the one that was fixed. I'll
try to test debian-installer on Cubox-i4pro to see if I still have an
issue.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988966: /boot/vmlinuz-5.10.0-6-armmp-lpae: lamobo-r1 ethernet/bridge failure

[Vagrant Cascadian]

Package: src:linux
Version: 5.10.28-1
Severity: normal
File: /boot/vmlinuz-5.10.0-6-armmp-lpae
X-Debbugs-Cc: vagr...@debian.org
Control: block 986767 by -1

The ethernet bridge fails to work on 5.10.x (also tried 5.10.38-1),
but works fine on 4.19.x from buster. (This was also reported in
https://bugs.debian.org/986767)

I noticed these messages when booting up:

[6.254047] bcm53xx stmmac-0:1e: failed to register switch: -517
[6.339663] bcm53xx stmmac-0:1e: failed to register switch: -517



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
Hardware: Allwinner sun7i (A20) Family
Revision: 
Device Tree model: Lamobo R1

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

** PCI devices:

** USB devices:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-7-armmp-lpae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-6-armmp-lpae depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-6-armmp-lpae recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-6-armmp-lpae suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-6-armmp-lpae is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

[Vagrant Cascadian]

On 2021-02-11, Vagrant Cascadian wrote:
> Control: reassign 982270 linux
> Control: retitle 982270 linux: [armhf] several imx6 systems unable to detect 
> ethernet
> Control: found 982270 5.10.13-1
>
> On 2021-02-07, Rick Thomas wrote:
>> It booted fine but when it got to the "Detect network hardware" phase,
>> it failed and said:
>>
>>> 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.
>>> Driver needed by your Ethernet card:
>
> I can confirm this is an issue on hummingboard-i2ex, cubox-i4x4 and
> wandboard quad, all of which are similar imx6 systems, and all of which
> use the SoC's gigabit ethernet interface.
>
> I've had better luck with linux 5.9.x and 4.19.x versions, although
> possibly backported patches on the stable branches may also trigger
> similar issues, just not consistantly. 5.10.x seems to consistantly
> result in no working ethernet interface.
>
> Marked as found in 5.10.13-1, but I believe this affects all 5.10.x
> versions I have seen.
>
> Possibly related to changes to the mdio interface infrastructure, but
> this pretty much needs someone to able take the time to git bisect and
> boot test the issue...

I'm also experiencing periodic issues on 4.19.x:

   fec 2188000.ethernet eth0: MDIO read timeout

Not sure if that is related or a separate issue... there the ethernet
interface is present, but periodically becomes unusable, and bringing
the interface down and up again "fixes" the problem:

  $ ip a
  ...
  2: eth0:  mtu 1500 qdisc pfifo_fast
  state DOWN group default qlen 1000
  link/ether 12:4f:47:94:87:e1 brd ff:ff:ff:ff:ff:ff
  inet 10.0.0.56/24 brd 10.0.0.255 scope global eth0
 valid_lft forever preferred_lft forever
  inet6 fe80::104f:47ff:fe94:87e1/64 scope link
 valid_lft forever preferred_lft forever

  $ ping 10.0.0.1
  PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
  ^C
  --- 10.0.0.1 ping statistics ---
  1 packets transmitted, 0 received, 100% packet loss, time 0ms


  $ sudo ifdown eth0 ; sudo ifup eth0
  $ ping 10.0.0.1
  PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
  From 10.0.0.56 icmp_seq=1 Destination Host Unreachable
  64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.265 ms
  64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.452 ms
  ^C
  --- 10.0.0.1 ping statistics ---
  3 packets transmitted, 2 received, +1 errors, 33.% packet loss,
  time 2024ms


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988574: linux-image-armmp-lpae: ethernet on orange pi plus does not work

[Vagrant Cascadian]

Source: linux
Version: 5.10.28-1
Severity: normal
Tags: patch
X-Debbugs-Cc: vagr...@reproducible-builds.org

When upgrading the reproducible builds infrastructure to bullseye, on
the orange pi plus ethernet stopped working with 5.10.x.

Applying a fix from upstream for a similar board appears to fix the
issue:

a900cac3750b9f0b8f5ed0503d9c6359532f644d
ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode


dtdiff sun8i-h3-orangepi-plus-orig.dtb sun8i-h3-orangepi-plus.dtb
--- /dev/fd/63  2021-05-16 02:52:30.519751297 +
+++ /dev/fd/62  2021-05-16 02:52:30.523751128 +
@@ -364,7 +364,7 @@
interrupt-names = "macirq";
interrupts = <0x00 0x52 0x04>;
phy-handle = <0x14>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-supply = <0x16>;
pinctrl-0 = <0x15>;
pinctrl-names = "default";


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vagrant Cascadian]

On 2021-04-27, Lionel Fourquaux wrote:
> On Mon, Apr 26, 2021 at 11:19:29PM +0200, Vincent Blut wrote:
>>A merge request [1] has been proposed today to improve support for the 
>>Pinebook
>>Pro.
>
> Thanks! (The merge request and this report are related.)
>
> Some additional information: I (finally) managed to (cross-)build 
> a Debian kernel package and test this:
>   * the battery gauge is working!
>   * the usb-c port gets its FUSB302 driver, but hits an error later:

I've tested that a usb-c dock works (for the most part) with this patch
applied, so that's pretty exciting. Charging also worked, though not
necessarily when using the dock... though sometimes.

I have the impression the orientation of the usb-c connector *should
not* matter, but after flipping it all the usb-3 devices and ports on
the dock consistently started working...


> [8.656555] OF: graph: no port node found in /i2c@ff3d/fusb30x@22

I didn't notice this in the logs, but didn't check... will look at next
boot.


> (This may be related to this patch to the DTD:
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-...@endlessos.org/
> which made the monitor work, or possibly another missing driver.)

Seems unlikely related to that...


>   * pulseaudio starts correctly (unlike before), but no sound (note: the 
> internal switch controlling the audio jack is set in "serial port" 
> mode; I'm not sure whether this affects the speakers, I will try 
> flipping the switch later).

I did get audio out working via the audio jack after fiddling
haphazardly with the dozens of audio control sliders, but was unable to
get the microphone to work. I think I had to unmute the left and right
headphone mux or something. I got some sign that the speakers were
enabled when muting or unmuting (a little pop sound each time), but no
working audio.


> So this is clearly an improvement (especially the battery gauge), but not 
> a complete solution.

Agreed!


Thanks for pointing us to enabling these features!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

[Vagrant Cascadian]

Control: reassign 982270 linux
Control: retitle 982270 linux: [armhf] several imx6 systems unable to detect 
ethernet
Control: found 982270 5.10.13-1

On 2021-02-07, Rick Thomas wrote:
> It booted fine but when it got to the "Detect network hardware" phase, 
> it failed and said:
>
>> 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. 
>> Driver needed by your Ethernet card:  

I can confirm this is an issue on hummingboard-i2ex, cubox-i4x4 and
wandboard quad, all of which are similar imx6 systems, and all of which
use the SoC's gigabit ethernet interface.

I've had better luck with linux 5.9.x and 4.19.x versions, although
possibly backported patches on the stable branches may also trigger
similar issues, just not consistantly. 5.10.x seems to consistantly
result in no working ethernet interface.

Marked as found in 5.10.13-1, but I believe this affects all 5.10.x
versions I have seen.

Possibly related to changes to the mdio interface infrastructure, but
this pretty much needs someone to able take the time to git bisect and
boot test the issue...


live well,
  vagrant


> ==
> Installer hardware-summary:
> ==
> uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) 
> armv7l GNU/Linux
> usb-list: 
> usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
> usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 
> 01
> usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd
> usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
> usb-list: 
> usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
> usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 
> 01
> usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd
> usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
> lsmod: Module  Size  Used by
> lsmod: dm_mod122880  9
> lsmod: md_mod143360  0
> lsmod: jfs   184320  0
> lsmod: btrfs1241088  0
> lsmod: libcrc32c  16384  1 btrfs
> lsmod: xor16384  1 btrfs
> lsmod: zstd_decompress61440  1 btrfs
> lsmod: zstd_compress 159744  1 btrfs
> lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
> lsmod: zlib_deflate   28672  1 btrfs
> lsmod: raid6_pq   98304  1 btrfs
> lsmod: vfat   24576  0
> lsmod: fat73728  1 vfat
> lsmod: ext4  618496  3
> lsmod: crc16  16384  1 ext4
> lsmod: mbcache16384  1 ext4
> lsmod: jbd2  102400  1 ext4
> lsmod: crc32c_generic 16384  6
> lsmod: fscrypto   28672  1 ext4
> lsmod: ecb16384  0
> lsmod: brcmfmac  253952  0
> lsmod: brcmutil   16384  1 brcmfmac
> lsmod: cfg80211  548864  1 brcmfmac
> lsmod: rfkill 28672  1 cfg80211
> lsmod: usb_storage53248  0
> lsmod: sd_mod 49152  3
> lsmod: ahci_imx   20480  2
> lsmod: libahci_platform   20480  1 ahci_imx
> lsmod: libahci32768  2 libahci_platform,ahci_imx
> lsmod: libata208896  3 libahci_platform,libahci,ahci_imx
> lsmod: scsi_mod  196608  3 sd_mod,usb_storage,libata
> lsmod: sdhci_esdhc_imx24576  0
> lsmod: sdhci_pltfm16384  1 sdhci_esdhc_imx
> lsmod: sdhci  53248  2 sdhci_pltfm,sdhci_esdhc_imx
> lsmod: ci_hdrc_imx16384  0
> lsmod: ci_hdrc45056  1 ci_hdrc_imx
> lsmod: ulpi   16384  1 ci_hdrc
> lsmod: ehci_hcd   77824  1 ci_hdrc
> lsmod: udc_core   36864  1 ci_hdrc
> lsmod: usbcore   221184  4 usb_storage,ehci_hcd,brcmfmac,ci_hdrc
> lsmod: usbmisc_imx16384  1 ci_hdrc_imx
> lsmod: imxdrm 28672  0
> lsmod: anatop_regulator   16384  1
> lsmod: phy_mxs_usb16384  2
> lsmod: dw_hdmi_imx16384  0
> lsmod: dw_hdmi36864  1 dw_hdmi_imx
> lsmod: imx_ipu_v3 94208  1 imxdrm
> lsmod: cec49152  1 dw_hdmi
> lsmod: drm_kms_helper147456  2 dw_hdmi,imxdrm
> lsmod: drm   356352  5 
> imx_ipu_v3,dw_hdmi,dw_hdmi_imx,imxdrm,drm_kms_helper
> lsmod: at803x 16384  1
> df: Filesystem   1K-blocks  Used Available Use% Mounted on
> df: none20627656206220   0% /run
> df: devtmpfs   1010736 0   1010736   0% /dev
> df: /dev/mapper/ncube--vg-root
> df:   19092136769744  17329524   4% /target
> df: /dev/sda1   482922 31992425996   7% /target/boot
> df: 

Bug#973369: linux-image-5.9.0: No network at Banana Pi M3

[Vagrant Cascadian]

On 2020-11-17, Salvatore Bonaccorso wrote:
> On Mon, Nov 09, 2020 at 02:32:21PM +0100, Bernhard wrote:
>> Regarding correction:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts?h=next-20201029=57dbe558457bf4042169bc1f334e3b53a8480a1c
>> 
>> Currently, i had a look at kernel.org:
>> In kernel 5.9.6, the necessary correction is not included.
>> Also in kernel 5.10-RC3, this correction is not included.
>> 
>> Without this correction, the on-board-ethernet of my Banana Pi M3 is not 
>> working.
>> An external attached USB-->LAN interface works.
>> 
>> Do you think, there is a chance to add the very small correction to the 
>> Debian kernel?
>> 
>> Best regards and thank you for your great support.
>
> I have applied the change in
> https://salsa.debian.org/kernel-team/linux/-/commit/0cfcaef8b5e52549952e89cb31cff1530a5efa42
> .
>
> Vagrant, can you double-check please.

I don't think I have any affected hardware to test on, sorry.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#960152: linux-image-5.6.0-1-arm64: Enable compressed modules

[Vagrant Cascadian]

Package: src:linux
Version: 5.6.7-1
Severity: wishlist

The on-disk kernel modules take up a significant amount of the package
installation size, and most modules aren't actively used on any given
system. In debian-installer, the "on-disk" modules take up space in ram
during the installation.

From the linux Makefile:

  # CONFIG_MODULE_COMPRESS, if defined, will cause module to be compressed
  # after they are installed in agreement with CONFIG_MODULE_COMPRESS_GZIP
  # or CONFIG_MODULE_COMPRESS_XZ.

I'm not sure how to enable it; I don't see it mentioned in any Kconfig
files. It does appear possible to manually compress the individual .ko
files as an alternative method, if that is somehow more flexible.


The kmod utility supports xz compressed modules since version 25-1 (26-1
is present in buster, the current debian stable release). Unfortunately,
gzip isn't supported in kmod yet (patch submitted in #960149).

What other software needs support enabled in order to support on-disk
compressed modules in the linux kernel packages?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#946510: Support for accelerated graphics and video decoding on PINE A64+ in bullseye

[Vagrant Cascadian]

Control: tags 946510 pending

On 2019-12-14, Andrei POPESCU wrote:
> On Vi, 06 dec 19, 19:57:07, Andrei POPESCU wrote:
>> On Vi, 06 dec 19, 15:05:32, Marcin Juszkiewicz wrote:
>> > Use Lima (Pine A64) or Panfrost (Rock64)?
>> 
>> Sure... how?
>> 
>> I changed my xorg.conf as per [1], but not apparent change. What (else) 
>> is missing?
>
> For the Allwinner A64 the sun8i-mixer module is missing, see #946510.

Thanks for looking into this!

Did some basic compile testing and pushed to the git kernel repository,
should land in the next linux 5.3.x and 5.4.x uploads.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted)

[Vagrant Cascadian]

On 2019-06-07, Guillem Jover wrote:
> On Tue, 2019-04-09 at 10:02:25 +0200, Santiago Vila wrote:
>> Hmm, I said:
>> > Is dpkg in buster calling tar with any options that makes this
>> > behaviour to happen more easily? Is tar in buster more prone to this
>> > failure when using overlayfs?
>> 
>> By looking at my build logs I see that this is not really related to
>> buster, but related to the fact that I started to use virtual machines
>> from Scaleway. Apparently this is really easy to happen there.
>> 
>> Still, I would like to know if there is some kind of workaround other
>> than stopping using overlayfs.
>
> I don't really know. I just know that overlayfs has caused compliance
> problems in the past, so I'd recommend avoiding it TBH.

I'm having intermittant similar issues with sbuild+overlay fs (from the
linux kernel, not the fuse implementation; I presume ) with building "linux" on 
my
laptop.

The build failures were really infrequent when running stretch (less
than 1 out of 100 builds) but have recently started becoming much more
frequent since upgrading to buster... (e.g. it had it happen 3 times in
a row and the 4th worked fine).


dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building linux using existing
./linux_5.1.7.orig.tar.xz
tar: linux-5.1.7/arch/csky/boot/dts/include: Directory renamed before
its status could be extracted
tar: linux-5.1.7/arch/csky/boot/dts: Directory renamed before its status
could be extracted
tar: linux-5.1.7/arch/csky/boot: Directory renamed before its status
could be extracted
tar: linux-5.1.7/arch/csky: Directory renamed before its status could be
extracted
tar: linux-5.1.7/arch/arm64/boot/dts/arm: Directory renamed before its
status could be extracted
tar: linux-5.1.7/arch/arm64/boot/dts: Directory renamed before its
status could be extracted
tar: linux-5.1.7/arch/arm64/boot: Directory renamed before its status
could be extracted
tar: linux-5.1.7/arch/arm64: Directory renamed before its status could
be extracted
tar: Exiting with failure status due to previous errors
dpkg-source: error: tar -xf - --no-same-permissions --no-same-owner
subprocess returned exit status 2


The upperdir is a tmpfs and the lowerdir is an ext4 filesystem in my
case.


I'm not sure if there's some way to generate the .orig.tar.xz in a way
that reduces the likelihood of this happening? I've been using
"debian/bin/genorig.py ." from a git repository that also contains
upstream tags.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928451: linux: riscv64 updates (change kernel image type to flat image and enable vdso)

[Vagrant Cascadian]

Control: tags 928451 pending

On 2019-05-05, Karsten Merker wrote:
> 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, so
> we need to ship arch/riscv/boot/Image instead of an ELF vmlinux. 
> This also enables us to get rid of BBL (the RISC-V Berkeley
> BootLoader) and make the move to U-Boot/GRUB on riscv64.

This was just merged to master:

  
https://salsa.debian.org/kernel-team/linux/commit/05218aa3a21b7dff4e8741bafec411ef07f63bf8


> With kernel 5.0 we can now also enable the vdso config option in
> the package for riscv64 as the necessary infrastructure is now in
> the upstream kernel (this wasn't the case when riscv64 support
> was originally added to the Debian kernel package).

This was added in 4.19.x already.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928457: arm64: please apply workaround for A64 timer instability

[Vagrant Cascadian]

Control: tag 928457 pending

On 2019-05-05, Andrei POPESCU wrote:
> The Allwinner A64 is affected by a bug that makes the clock jump, 
> usually 95 years into the future.
>
> The mainline kernel contains a workaround merged for 5.1:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=c950ca8c35eeb32224a63adc47e12f9e226da241

This is backported to 4.19.31 upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=e19ca3fe6cf230a0e5df70da7acade133f2b670c

The debian kernel git repository will include 4.19.37 (or newer) in the
next upload.


> Please kindly apply this and the corresponding needed DT change for the 
> buster kernel.

The device-tree was patched in the kernel packaging for 4.19.28-1.

https://salsa.debian.org/kernel-team/linux/commit/357888c75c82ff508623568bb5411ebb28eaeb6d


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

On 2019-03-09, Adam D. Barratt wrote:
> On Thu, 2019-03-07 at 22:01 +, Ben Hutchings wrote:
>> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
>> [...]
>> > > * Rebuild the debian-installer images, pulling in updates from
>> > >   stretch-updates, leaving only armhf netboot targets broken. 
>> > 
>> > Expanding a bit: rebuilding src:debian-installer from the stretch
>> > branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> > couple of its udebs, at build time; the resulting netboot images
>> > wouldn't know about s-p-u though at run time, and would try to load
>> > udebs from stretch.
>> 
>> [...]
>> 
>> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
>> kernel image, and the module udebs don't have versioned dependencies.
>
> However, as an additional data point, the kernel currently sat in NEW
> and destined for stable has an ABI bump. If that's accepted, then I
> assume things will "just work" in the meantime as the old binary
> packages will hang around until they're decrufted, but it's worth
> bearing in mind.

A debian-installer build for stretch-proposed-updates was made, which
may not get merged into stretch before the next point release. For the
time being:

  
https://deb.debian.org/debian/dists/stretch-proposed-updates/main/installer-armhf/

I've successfully tested version "20170615+deb9u5+b3", as well as at
least one other person. It should continue to work until the next point
release, and I'll do at least some minimal testing of the next point
release on armhf before pushing it to stretch so this doesn't happen
again.

More details in:

  https://bugs.debian.org/924129


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#913119: Bug#913138: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Vagrant Cascadian]

Control: tag 913138 pending
Control: tag 913119 pending

On 2019-02-26, martin wrote:
> On 2019-02-26 21:11, Cesare Leonardi wrote:
>> On 13/02/19 18:21, Dragan Milenkovic wrote:
>>> This patch is already on its way to stable branches. I have tested it 
>>> and confirmed that it resolves the problem.
>> 
>> Hello Dragan, do you know if the patch was eventually included
>> upstream and possibly in which version?
>
> Looking at the change log it's in here:
> https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24
>
> towards the bottom search for "blk-mq: fix a hung issue when fsync"

Newer versions are in sid git, should be in next upload.


live well,
  vagrant

Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)

[Vagrant Cascadian]

Package: src:linux
Version: 4.19.16-1
Severity: normal
File: /boot/vmlinuz-4.19.0-2-arm64
X-Debbugs-Cc: klaus.go...@theobroma-systems.com

When running dmidecode as root on puma-rk3399, it consistantly causes a
kernel panic.

Other similar rockchip rk3399 boards do not seem to have this
problem. All older (maybe 4.16-4.18) and newer (v4.20) kernels I've
tried seem to be affected.

live well,
  vagrant

Kernel panic:

[  209.234792] SError Interrupt on CPU4, code 0xbf00 -- SError
[  209.234796] CPU: 4 PID: 829 Comm: dmidecode Not tainted 4.19.0-2-arm64 #1 
Debian 4.19.16-1
[  209.234798] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  209.234801] pstate: 2000 (nzCv daif -PAN -UAO)
[  209.234802] pc : afeff28c
[  209.234804] lr : d7f49a0c
[  209.234806] sp : d355d260
[  209.234808] x29: d355d260 x28: 
[  209.234814] x27: 0001 x26: afe6c000
[  209.234819] x25: 0003 x24: 000f
[  209.234824] x23:  x22: 0001
[  209.234829] x21: d7f63000 x20: ece51490
[  209.234834] x19: d7f4c3b8 x18: 
[  209.234838] x17: afeff190 x16: d7f63e50
[  209.234843] x15: 0002 x14: 
[  209.234848] x13:  x12: 
[  209.234852] x11:  x10: 
[  209.234857] x9 :  x8 : 00de
[  209.234861] x7 :  x6 : 
[  209.234866] x5 : ece61490 x4 : afe7c000
[  209.234871] x3 : ece51490 x2 : 0001
[  209.234875] x1 : afe6c000 x0 : ece51490
[  209.234881] Kernel panic - not syncing: Asynchronous SError Interrupt
[  209.234884] CPU: 4 PID: 829 Comm: dmidecode Not tainted 4.19.0-2-arm64 #1 
Debian 4.19.16-1
[  209.234886] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  209.234888] Call trace:
[  209.234890]  dump_backtrace+0x0/0x180
[  209.234892]  show_stack+0x24/0x30
[  209.234894]  dump_stack+0x90/0xb4
[  209.234895]  panic+0x128/0x290
[  209.234897]  nmi_panic+0x7c/0x80
[  209.234899]  arm64_serror_panic+0x80/0x8c
[  209.234901]  is_valid_bugaddr+0x0/0x1c
[  209.234903]  el0_error_naked+0x10/0x18
[  209.234935] SMP: stopping secondary CPUs
[  209.234937] Kernel Offset: disabled
[  209.234939] CPU features: 0x0,2180600c
[  209.234941] Memory Limit: none
[  209.435889] ---[ end Kernel panic - not syncing: Asynchronous SError 
Interrupt ]---
[  214.345190] WARNING: CPU: 4 PID: 829 at kernel/sched/core.c:1162 
set_task_cpu+0x1b0/0x1c0
[  214.345193] Modules linked in: cpufreq_conservative cpufreq_powersave 
cpufreq_userspace cpufreq_ondemand binfmt_misc aes_ce_blk crypto_simd cryptd 
aes_ce_cipher sg ghash_ce gf128mul sha2_ce sha256_arm64 sha1_ce rockchipdrm 
dw_hdmi leds_gpio analogix_dp drm_kms_helper dw_wdt drm nvmem_rockchip_efuse 
pwm_rockchip rockchip_io_domain rockchip_thermal pl330 cpufreq_dt ip_tables 
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb aes_arm64 
sd_mod uas usb_storage scsi_mod xhci_plat_hcd xhci_hcd dwc3 rtc_rk808 
rk808_regulator micrel clk_rk808 udc_core ulpi rk808 fan53555 ohci_platform 
dwc3_of_simple sdhci_of_arasan ehci_platform dwmac_rk sdhci_pltfm 
stmmac_platform ohci_hcd dw_mmc_rockchip stmmac cqhci dw_mmc_pltfm ehci_hcd 
phy_rockchip_pcie phy_rockchip_emmc of_mdio phy_rockchip_inno_usb2
[  214.345297]  usbcore phy_rockchip_typec fixed_phy dw_mmc sdhci libphy 
i2c_rk3x usb_common fixed
[  214.345313] CPU: 4 PID: 829 Comm: dmidecode Not tainted 4.19.0-2-arm64 #1 
Debian 4.19.16-1
[  214.345315] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  214.345318] pstate: 2085 (nzCv daIf -PAN -UAO)
[  214.345320] pc : set_task_cpu+0x1b0/0x1c0
[  214.345322] lr : try_to_wake_up+0x1a0/0x4b0
[  214.345324] sp : 08023b60
[  214.345325] x29: 08023b60 x28: 80007d81c400
[  214.345330] x27: 80007d807000 x26: 0001
[  214.345335] x25: 09089738 x24: 08d2a840
[  214.345340] x23: 0080 x22: 0004
[  214.345344] x21: 09089708 x20: 0001
[  214.345349] x19: 80007d0fe3c0 x18: 0010
[  214.345353] x17:  x16: 
[  214.345358] x15:  x14: 0720072007200720
[  214.345363] x13: 0720072007200720 x12: 0720072007200720
[  214.345367] x11: 0720072007200720 x10: 0040
[  214.345372] x9 : 090a6c40 x8 : 800077c034a0
[  214.345376] x7 : 80007ff81840 x6 : 11adb43d
[  214.345381] x5 : 00ff x4 : 0015
[  214.345385] x3 : 02c9 x2 : 0001
[  214.345390] x1 : 09089f88 x0 : 0008
[  214.345395] Call trace:
[  214.345397]  set_task_cpu+0x1b0/0x1c0
[  214.345399]  try_to_wake_up+0x1a0/0x4b0
[  214.345401]  wake_up_process+0x28/0x38
[  214.345402]  insert_work+0xa8/0xc8
[  214.345404]  

Re: Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

On 2019-03-07, Ben Hutchings wrote:
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
>> > * Rebuild the debian-installer images, pulling in updates from
>> >   stretch-updates, leaving only armhf netboot targets broken. 
>> 
>> Expanding a bit: rebuilding src:debian-installer from the stretch
>> branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> couple of its udebs, at build time; the resulting netboot images
>> wouldn't know about s-p-u though at run time, and would try to load
>> udebs from stretch.
> [...]
>
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

If that's indeed the case, then that does seem like the best
approach. Happy to test images to confirm.


live well,
  vagrant


signature.asc
Description: PGP signature

Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

Due to #922478, the debian-installer images for stretch are currently
not bootable on the armhf architecture.

While the linux kernel packages have been fixed in stretch-updates and
stretch-proposed-updates, the debian-installer images still were built
with the broken kernel.

Even rebuilding the debian-installer images, while pulling in a working
kernel that would boot, debian-installer would load .udeb modules from
stretch, not stretch-updates. This might be ok for hd-media targets or
targets that do not load module .udeb files from the network, but
netboot targets are not likely to work at all.

So some of the options at the moment appear to be:

* Wait for another point release, rebuild debian-installer, leaving
  debian-installer on armhf broken until then. How long till the next
  point release?

* Rebuild the debian-installer images, pulling in updates from
  stretch-updates, leaving only armhf netboot targets broken. 

* Another point release with the kernel update sooner than planned, and
  rebuild debian-installer images.

* Other options?


In the future, I plan on setting up at least one or two of armhf
machines running stable-proposed-updates to try to catch this sort of
thing before release...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable

[Vagrant Cascadian]

On 2019-02-17, Vagrant Cascadian  wrote:
> On 2019-02-17, Timo Sigurdsson wrote:
>> Cyril Brulebois schrieb am 17.02.2019 19:38:
>>> Jürgen Löb  (2019-02-16):
> FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
> git, and it worked on a wandboard quad.
>
> $ uname -a
> Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) 
> armv7l GNU/Linux

That seemed to work fine on several tested boards.

I also did a local build commenting out
"debian/arm-avoid-abi-change-in-4.9.139.patch" in debian/patches and
removing "debian/abi/4.9.0-8/armhf_none_armmp" so that the abi conflicts
didn't fail to build...

$ uname -a
Linux cbxi4b 4.9.0-8-armmp #1 SMP Debian 4.9.144-4~20190217~1 (2019-02-17) 
armv7l GNU/Linux

Sounds like there may be a less intrusive patch in the works...


live well,
  vagrant

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable

[Vagrant Cascadian]

Control: retitle 922478 upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 
4.9.130-2 to 4.9.144-3 renders many systems unbootable

On 2019-02-17, Timo Sigurdsson wrote:
> Cyril Brulebois schrieb am 17.02.2019 19:38:
>> Jürgen Löb  (2019-02-16):
>>> Package: linux-image-4.9.0-8-armmp-lpae
>>> Version: 4.9.144-3
>>> Severity: serious

FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
git, and it worked on a wandboard quad.

$ uname -a
Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) armv7l 
GNU/Linux

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#922478: have yet to find an armhf board that works with 4.9.144-3

[Vagrant Cascadian]

After upgrading to the latest 4.9.x kernel in sid, all of the armhf
boards running this kernel failed to boot.

Adding to the list:

imx6: Cubox-i4pro, Cubox-i4x4, Wandboard Quad
exynos5: Odroid-XU4
exynos4: Odroid-U3
rk3328: firefly-rk3288
sunxi A20: Cubietruck


So it clearly impacts a wide variety of systems...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#906769: arm kernels fail to boot

[Vagrant Cascadian]

On 2018-08-21, Salvatore Bonaccorso wrote:
> armhf packages:
> https://people.debian.org/~carnil/tmp/linux/armhf/

Looks good to me!


Tested successfully on boards that previously failed:

Cubietruck
Firefly-rk3288 (2gb variant)
Firefly-rk3288 (4gb variant)
Jetson-TK1
Odroid-XU4
Odroid-U3 

Also tested successfully on systems where -8 seemed to work fine:

Cubox-i4x4
Cubox-i4pro
Wandboard Quad


Thanks everyone for all the work on this.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#906769: arm kernels fail to boot

[Vagrant Cascadian]

On 2018-08-20, Vagrant Cascadian wrote:
> I can confirm this on several machines in the reproducible builds zoo,
> running linux-image-4.9.0-8-armmp-lpae version 4.9.110-3+deb9u3.
>
> What I've noticed is that machines running the "armmp" variant appear to
> be unaffected, all of the systems that failed were running the
> "armmp-lpae" variant.

If it matters, three imx6 and one exynos4 system running "armmp" seem to
work without problems.

The systems running "armmp-lpae" that are broken include exynos5,
rk3288, allwinner A20, and tegra124.

> Switching to linux-image-4.9.0-8-armmp kernel variant on an affected
> system appears to workaround the issue, or downgrading to
> linux-image-4.9.0-7-armmp-lpae.

Downgrading to the "armmp" variant didn't fully solve the issue; it
allowed the systems to boot, but they tended to eventually hang, just
much slower than when running an "armmp-lpae" variant.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#886440: linux: Support to build linux-libc-dev for the upcoming riscv64 architecture

[Vagrant Cascadian]

Control: tags 886440 pending

On 2018-01-06, Manuel A. Fernandez Montecelo wrote:
> 2018-01-06 18:15 GMT+01:00 Ben Hutchings :
>> On Sat, 2018-01-06 at 01:09 +0100, Manuel A. Fernandez Montecelo wrote:
>>> The 4.15 kernel comes with initial support for RISC-V.
>>>
>>> Enabling support to build linux-libc-dev is one of the first steps to 
>>> bootstrap
>>> the architecture, so please consider enabling it.
>>>
>>> If there's anything wrong or missing, please let me know.
>>
>> You've missed out several steps:
>>
>> 1. Add the architecture definition to dpkg/unstable.
>> 2. Backport that addition to dpkg/stable.
>> 3. Get the stable update installed on ftp-master.
>>
>> dak will reject uploads that mention an architecture that the local
>> dpkg doesn't recognise.
>
> It's requested, but not done:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822914
>
> Didn't know about dak, thanks for the notice.

The dpkg patches have been included in stable, and we have reports of at
least one package with riscv64 enabled being successfully uploaded
without getting rejected by dak, so I've enabled this and should be
included in the next upload to sid:

  
https://salsa.debian.org/kernel-team/linux/commit/ba1733832fd94334fc88847ee013c3d62be29009


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#901159: linux-image-arm64: enable configuration options needed by Firefly-RK3399 board

[Vagrant Cascadian]

Control: tags 901159 pending

On 2018-06-09, Heinrich Schuchardt wrote:
> to fully support the Firefly-RK3399 board, please, enable the following
> configuration items for linux-image-arm64:
>
> CONFIG_DRM_ROCKCHIP
> CONFIG_PHY_ROCKCHIP_TYPEC
> CONFIG_ROCKCHIP_ANALOGIX_DP
> CONFIG_ROCKCHIP_DW_HDMI
> CONFIG_ROCKCHIP_DW_MIPI_DSI
> CONFIG_ROCKCHIP_EFUSE
> CONFIG_ROCKCHIP_IOMMU
> CONFIG_ROCKCHIP_SARADC
> CONFIG_ROCKCHIP_THERMAL

Thanks!

Committed to git:

  
https://salsa.debian.org/kernel-team/linux/commit/5cd2c3b57c99877fa78436620e6f79eaf83716d4


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#895490: cpufreq problems on Odroid-XU4.

[Vagrant Cascadian]

Package: src:linux
Version: 4.15.11-1
Severity: normal
File: /lib/modules/4.15.0-2-armmp-lpae/kernel/drivers/cpufreq/cpufreq-dt.ko

Accessing files in /sys regarding cpufreq stats doesn't appear to work.

  $ ls -l  /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
  -r--r--r-- 1 root root 4096 Apr 11 20:15 
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
  $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state

And "cat" just sits there indefinitely. Using "cpufreq-info" similarly
hangs indefinitely...

After downgrading to linux-image-4.14.0-0.bpo.3-armmp-lpae
4.14.13-1~bpo9+1 from stretch-backports, accessing cpufreq files in
/sys works as well as "cpufreq-info".

I've observed the same behavior on another Odroid-XU4 board running
stretch.


live well,
  vagrant

-- Package-specific info:
** Version:
Linux version 4.15.0-2-armmp-lpae (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-11)) #1 SMP Debian 4.15.11-1 (2018-03-20)

** Command line:
  console=ttySAC2,115200n8 

** Tainted: D (128)
 * Kernel has oopsed before.

** Kernel log:
[   83.977854] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   83.983924] PC is at 0xe7fddef0
[   83.987046] LR is at notifier_call_chain+0x58/0x94
[   83.991805] pc : []lr : []psr: 20010013
[   83.998043] sp : ed1f59e0  ip : c0eba69c  fp : ed1f5a04
[   84.003249] r10: cf829178  r9 : c10e4a38  r8 : 
[   84.003256] r7 :   r6 : ed1f5a64  r5 : e7fddef0  r4 : 
[   84.003263] r3 : e7fddef0  r2 : ed1f5a64  r1 :   r0 : c0eba69c
[   84.003271] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   84.003291] Control: 30c5387d  Table: 6e7f2a40  DAC: 
[   84.003302] Process systemd-udevd (pid: 384, stack limit = 0xaeec5f83)
[   84.003309] Stack: (0xed1f59e0 to 0xed1f6000)
[   84.003319] 59e0:  c10e4a40 ed1f5a64 cf829100 c10e49e0 c10e4a38 
ed1f5a2c ed1f5a08
[   84.003329] 5a00: c029a51c c0299b58  c10e4c10 ed1f5a2c ed1f5a64 
c115ef38 
[   84.003339] 5a20: ed1f5a5c ed1f5a30 c08376a8 c029a4d4 ed1f5a5c ed1f5a40 
c083563c cf829100
[   84.003348] 5a40: c1005dd8 c10e4c10 c115ef38 c10e49e0 ed1f5b84 ed1f5a60 
c0837d28 c0837630
[   84.003357] 5a60:  000f 000f 000f   
ed2de700 0013d620
[   84.003367] 5a80: 00030d40 00025990 00030d40 0013d620 000c3500  
 
[   84.003375] 5aa0:  c10e4c10     
 ffe0
[   84.003384] 5ac0: cf82915c cf82915c c0837a50 00030d40 0013d620 cfe52e40 
0001 c10e4a38
[   84.003393] 5ae0: c10e4a38 ed2debc0 cf829184 cf829184 ee34ce40  
c10e4a70 cfcece40
[   84.003401] 5b00: 0001 0003   cf8291ac cf8291ac 
0001 cf8291b8
[   84.003410] 5b20: cf8291b8   ed1d8f00   
0001 
[   84.003418] 5b40:     cf8291ec cf8291ec 
 ed2de340
[   84.003426] 5b60: ed2de280 af3200b3  cf829100  c10e4a38 
ed1f5bcc ed1f5b88
[   84.003435] 5b80: c0838308 c0837cac  c1005dd8   
cf8291b4 60010013
[   84.003444] 5ba0: c04d38b0  c10d66bc c1005dd8 ee262600 ee262638 
c10e4a28 ee262638
[   84.003452] 5bc0: ed1f5bec ed1f5bd0 c0838524 c0837d94 c073cc08 c09cc244 
c10e4a20 c10e4a20
[   84.003460] 5be0: ed1f5c2c ed1f5bf0 c073da90 c08384a8 ee262658 ee45f734 
 af3200b3
[   84.003470] 5c00: c09e1d34 bf46a03c c115ef38 ee7d9c00 c10e49e0 bf46a0c0 
 0036
[   84.003479] 5c20: ed1f5c54 ed1f5c30 c08361ac c073d9d4 ed1f5c54 ed1f5c40 
 eed69020
[   84.003488] 5c40: ee7d9c00 fdfb ed1f5c74 ed1f5c58 bf468638 c0836034 
ee7d9c10 ffed
[   84.003497] 5c60: bf46a0c0 fdfb ed1f5c94 ed1f5c78 c0741470 bf4685b0 
ee7d9c10 c115dc9c
[   84.003506] 5c80: c115dca0  ed1f5ccc ed1f5c98 c073f024 c074141c 
c09e1d34 c02f1cc4
[   84.003516] 5ca0: ee7d9c44 ee7d9c44 ee7d9c10 bf46a0c0 c1005dd8 bf46d000 
bf46a1c0 c1005dd8
[   84.003525] 5cc0: ed1f5cec ed1f5cd0 c073f268 c073ed1c  bf46a0c0 
c073f198 c1005dd8
[   84.003534] 5ce0: ed1f5d1c ed1f5cf0 c073ca94 c073f1a4 ee262a6c ee262a58 
ee730d34 af3200b3
[   84.003542] 5d00: bf46a0c0 c10d6630 cfeca700  ed1f5d2c ed1f5d20 
c073e774 c073ca30
[   84.003550] 5d20: ed1f5d54 ed1f5d30 c073e100 c073e754 bf4693b0 ed1f5d40 
bf46a0c0 
[   84.003559] 5d40: e000 ed2def00 ed1f5d6c ed1f5d58 c073ffd0 c073df54 
c1005dd8 
[   84.003568] 5d60: ed1f5d7c ed1f5d70 c07413b8 c073ff54 ed1f5d8c ed1f5d80 
bf46d024 c0741374
[   84.003576] 5d80: ed1f5e04 ed1f5d90 c02021a8 bf46d00c c03e1d94 c09e1d34 
 0001
[   84.003585] 5da0: ed1f5dc4 ed1f5db0 c09e1d34 c02f1cc4 014000c0 c042c0ec 
ed1f5e04 ed1f5dc8
[   84.003593] 5dc0: c042c0ec c0442940 0001 c040d91c eac24e04 eac24504 
ed0e1080 af3200b3
[   84.003602] 5de0: bf46a1c0 0001 ed2de8c0 ed2def00 ed2de8e4 bf46a1c0 
ed1f5e2c ed1f5e08
[   84.003610] 5e00: c031b29c c0202150 ed1f5e2c 

Bug#884061: This bug severely affects anybody using intel graphics cards from 2015

[Vagrant Cascadian]

Control: fixed 884061 4.9.80-1

On 2018-01-22, Marga Manterola wrote:
> This bug can make machines that include the affected graphics card
> completely unusable.
...
> Any chance we can get a new kernel without that commit?

I can confirm 4.9.80-1 from stretch-proposed-updates fixes the issue for
me. I've been running it for several days without issue.

It appears 4.9.80-2 is out now as well.

Not sure how long till the next point release, but at least one can use
stretch-proposed-updates for now.

Thanks to everyone who helped resolve the issue!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#884061: #884061: linux-image-4.9.0-4-amd64: screen scrolls wildly

[Vagrant Cascadian]

Control: tags 884061 +patch

On 2017-12-12, Nick Smallbone wrote:
> I get this too after upgrading from 4.9.30-2+deb9u5 to 4.9.65-3.
> Same dmesg error as Vagrant, together with either crazy flickering
> or a hard crash. It happens usually about 30 seconds after starting X.
>
> I tried using "git bisect" on the upstream linux-stable repository.
> It points the finger at the following commit:
>
>   7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8 is the first bad commit
>   commit 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8
>   Author: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
>   Date:   Thu Oct 19 17:13:40 2017 +0200
>   
>   drm/i915: Do not rely on wm preservation for ILK watermarks
>   
>   commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 upstream.

Thanks for bisecting the issue!

I just tested simply reverting this patch with 4.9.65-3+deb9u1, and it's
been running without problem for at least three hours. So that confirms
that it works around the issue, at least.

I'm not sure if there's a better fix than simply reverting this; this is
clearly a regression for at least two users that makes the system almost
unusable.


From 4c01095ae53794023e772f9afb753bef67c3d84c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagr...@debian.org>
Date: Thu, 28 Dec 2017 11:21:30 -0800
Subject: [PATCH] Revert "drm/i915: Do not rely on wm preservation for ILK
 watermarks"

This reverts commit 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8.
---
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 52 +++-
 2 files changed, 31 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ce9ba30d827..a19ec06f9e42 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -457,6 +457,7 @@ struct intel_crtc_scaler_state {
 
 struct intel_pipe_wm {
struct intel_wm_level wm[5];
+   struct intel_wm_level raw_wm[5];
uint32_t linetime;
bool fbc_wm_enabled;
bool pipe_enabled;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 277a8026460b..49de4760cc16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -27,7 +27,6 @@
 
 #include 
 #include 
-#include 
 #include "i915_drv.h"
 #include "intel_drv.h"
 #include "../../../platform/x86/intel_ips.h"
@@ -2018,9 +2017,9 @@ static void ilk_compute_wm_level(const struct 
drm_i915_private *dev_priv,
 const struct intel_crtc *intel_crtc,
 int level,
 struct intel_crtc_state *cstate,
-const struct intel_plane_state *pristate,
-const struct intel_plane_state *sprstate,
-const struct intel_plane_state *curstate,
+struct intel_plane_state *pristate,
+struct intel_plane_state *sprstate,
+struct intel_plane_state *curstate,
 struct intel_wm_level *result)
 {
uint16_t pri_latency = dev_priv->wm.pri_latency[level];
@@ -2342,24 +2341,28 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state 
*cstate)
struct intel_pipe_wm *pipe_wm;
struct drm_device *dev = state->dev;
const struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_plane *plane;
-   const struct drm_plane_state *plane_state;
-   const struct intel_plane_state *pristate = NULL;
-   const struct intel_plane_state *sprstate = NULL;
-   const struct intel_plane_state *curstate = NULL;
+   struct intel_plane *intel_plane;
+   struct intel_plane_state *pristate = NULL;
+   struct intel_plane_state *sprstate = NULL;
+   struct intel_plane_state *curstate = NULL;
int level, max_level = ilk_wm_max_level(dev), usable_level;
struct ilk_wm_maximums max;
 
pipe_wm = >wm.ilk.optimal;
 
-   drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, 
>base) {
-   const struct intel_plane_state *ps = 
to_intel_plane_state(plane_state);
+   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
+   struct intel_plane_state *ps;
 
-   if (plane->type == DRM_PLANE_TYPE_PRIMARY)
+   ps = intel_atomic_get_existing_plane_state(state,
+  intel_plane);
+   if (!ps)
+   continue;
+
+   if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY)
pristate = ps;
-   else if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+   else if (intel_plane->base.t

Bug#884061: linux-image-4.9.0-4-amd64: screen scrolls wildly

[Vagrant Cascadian]

On 2017-12-10, Vagrant Cascadian wrote:
> Since upgrading to 4.9.65-3, my screen occasionally starts rapidly
> scrolling sideways, flashing on and off repeatedly...
...
> When this starts to happen, usually there is a log in the dmesg output
> like this:
>
>   [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
...
> I'm going to try to find the last kernel version before I upgraded and
> see if I the issue is also triggered on that...

Have been running 4.9.51-1 without issue today, so it seems like it
really was introduced in 4.9.65-3. Also tried a 4.13.x kernel from
stretch-backports, which seemed to have the same issue (though *maybe*
less severe)...

So I'm guessing some fix/feature was backported to 4.9 that triggers
this problem.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#884061: linux-image-4.9.0-4-amd64: screen scrolls wildly

[Vagrant Cascadian]

Package: src:linux
Version: 4.9.65-3
Severity: normal

Since upgrading to 4.9.65-3, my screen occasionally starts rapidly
scrolling sideways, flashing on and off repeatedly... looks almost like
the refresh rate or sync was off, and it's displaying the leftmost part
of the screen on the rightmost or the top of the display in the middle
of the screen and other similar behaviors...

When this starts to happen, usually there is a log in the dmesg output
like this:

  [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Closing the lid and openening it again seems to fix it for a while, or
makes it less severe (e.g. brief moments where the screen slides around
or flickers).

I'm going to try to find the last kernel version before I upgraded and
see if I the issue is also triggered on that...

live well,
  vagrant


-- Package-specific info:
** Version:
Linux version 4.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3 (2017-12-03)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-4-amd64 root=/dev/mapper/yucca--vg-root ro quiet

** Not tainted

** Kernel log:
[   15.039432] tun: Universal TUN/TAP device driver, 1.6
[   15.039434] tun: (C) 1999-2004 Max Krasnyansky 
[   20.700661] input: BYDPS/2 BYD TouchPad as 
/devices/platform/i8042/serio1/input/input16
[   80.954137] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
[  170.836656] PM: Syncing filesystems ... done.
[  170.842268] PM: Preparing system for sleep (mem)
[  170.842382] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  170.843569] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) 
done.
[  170.846679] PM: Suspending system (mem)
[  170.846687] Suspending console(s) (use no_console_suspend to debug)
[  170.846858] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  170.847683] sd 0:0:0:0: [sda] Stopping disk
[  171.622232] PM: suspend of devices complete after 775.439 msecs
[  171.641624] PM: late suspend of devices complete after 19.389 msecs
[  171.642387] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[  171.681571] PM: noirq suspend of devices complete after 39.943 msecs
[  171.681842] ACPI: Preparing to enter system sleep state S3
[  171.681903] ACPI : EC: event blocked
[  171.681903] ACPI : EC: EC stopped
[  171.681904] PM: Saving platform NVS memory
[  171.681905] Disabling non-boot CPUs ...
[  171.683157] smpboot: CPU 1 is now offline
[  171.683865] Broke affinity for irq 49
[  171.684874] smpboot: CPU 2 is now offline
[  171.685248] Broke affinity for irq 1
[  171.685255] Broke affinity for irq 9
[  171.685260] Broke affinity for irq 12
[  171.685273] Broke affinity for irq 47
[  171.685274] Broke affinity for irq 49
[  171.686288] smpboot: CPU 3 is now offline
[  171.687652] ACPI: Low-level resume complete
[  171.687705] ACPI : EC: EC started
[  171.687706] PM: Restoring platform NVS memory
[  171.688023] Suspended for 4.062 seconds
[  171.688050] Enabling non-boot CPUs ...
[  171.688106] x86: Booting SMP configuration:
[  171.688106] smpboot: Booting Node 0 Processor 1 APIC 0x1
[  171.690656]  cache: parent cpu1 should not be sleeping
[  171.690885] CPU1 is up
[  171.690936] smpboot: Booting Node 0 Processor 2 APIC 0x3
[  171.693606]  cache: parent cpu2 should not be sleeping
[  171.694177] CPU2 is up
[  171.694277] smpboot: Booting Node 0 Processor 3 APIC 0x2
[  171.697493]  cache: parent cpu3 should not be sleeping
[  171.698318] CPU3 is up
[  171.706857] ACPI: Waking up from system sleep state S3
[  171.727103] xhci_hcd :00:14.0: System wakeup disabled by ACPI
[  171.747157] PM: noirq resume of devices complete after 40.223 msecs
[  171.747360] PM: early resume of devices complete after 0.186 msecs
[  171.747431] ACPI : EC: event unblocked
[  171.747529] ath: phy0: ASPM enabled: 0x43
[  171.757620] sd 0:0:0:0: [sda] Starting disk
[  171.820062] rtc_cmos 00:03: System wakeup disabled by ACPI
[  172.070341] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  172.070732] ata1.00: supports DRM functions and may not be fully accessible
[  172.072477] ata1.00: disabling queued TRIM support
[  172.073107] ata1.00: supports DRM functions and may not be fully accessible
[  172.073834] ata1.00: disabling queued TRIM support
[  172.074067] ata1.00: configured for UDMA/133
[  172.175151] PM: resume of devices complete after 427.782 msecs
[  172.175516] PM: Finishing wakeup.
[  172.175518] Restarting tasks ... done.
[  172.267311] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[  172.295044] usb 1-5: new full-speed USB device number 6 using xhci_hcd
[  172.309093] r8169 :02:00.0 enp2s0: link down
[  172.309140] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[  172.310073] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[  172.415056] usb 1-5: device descriptor read/64, error -71
[  172.643192] usb 1-5: device descriptor read/64, error -71
[  172.875059] usb 1-5: new full-speed USB 

Bug#879072: /boot/vmlinuz-4.14.0-rc5-arm64: eMMC corruption on Odroid-c2

[Vagrant Cascadian]

Control: found 879072 4.14-1~exp1

On 2017-10-18, Vagrant Cascadian wrote:
> I tried upgrading from 4.13 to the 4.14.0-rc5 kernel, and it caused eMMC
> corruption, with messages like this scattered throughout the boot
> process:
>
> [   27.286913] mmcblk1: response CRC error sending r/w cmd command, card 
> status 0xd00
> [   27.294374] mmcblk1: response CRC error sending r/w cmd command, card 
> status 0xd00
> [   27.301021] print_req_error: I/O error, dev mmcblk1, sector 2052096
>
> After booting with this kernel, / was mounted read-only, the /boot
> partition required an fsck, and the swap partition needed to be
> reinitialized...

This patch to the device-tree seems to work reasonably well with
4.14-1~exp1:

From 56159e51bc67bd006c676546c5692e451e7e323d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagr...@debian.org>
Date: Tue, 21 Nov 2017 10:58:52 -0800
Subject: [PATCH] Set eMMC maximum frequency to 100MHz.

---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 1ffa1c238a72..786a69b9736d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -276,7 +276,7 @@
pinctrl-names = "default", "clk-gate";
 
bus-width = <8>;
-   max-frequency = <2>;
+   max-frequency = <1>;
non-removable;
disable-wp;
cap-mmc-highspeed;
-- 
2.11.0


Since the default value has been there since the original upstream
commit for eMMC support, I suspect other bugs hid the issue for 4.13 and
earlier...

There may be other trhings required to make this upstreamable, but at
least this much is working for me after a few hours, with some basic
read/write testing...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#879072: /boot/vmlinuz-4.14.0-rc5-arm64: eMMC corruption on Odroid-c2

[Vagrant Cascadian]

Package: src:linux
Version: 4.14~rc5-1~exp1
Severity: normal
File: /boot/vmlinuz-4.14.0-rc5-arm64
Control: found -1 4.14~rc3-1~exp1

I tried upgrading from 4.13 to the 4.14.0-rc5 kernel, and it caused eMMC
corruption, with messages like this scattered throughout the boot
process:

[   27.286913] mmcblk1: response CRC error sending r/w cmd command, card status 
0xd00
[   27.294374] mmcblk1: response CRC error sending r/w cmd command, card status 
0xd00
[   27.301021] print_req_error: I/O error, dev mmcblk1, sector 2052096

After booting with this kernel, / was mounted read-only, the /boot
partition required an fsck, and the swap partition needed to be
reinitialized...

Also tried with 4.14.0-rc3, which behaved similarly. Booting 4.13 from
sid works fine.


live well,
  vagrant


-- Package-specific info:
** Kernel log: boot messages should be attached

2017-10-18_21:38:49.74212 
GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:0;READ:0;CHK:F3;SD:0;READ:0;CHK:0;
2017-10-18_21:38:50.74242 TE: 606271
2017-10-18_21:38:50.74246 no sdio debug board detected 
2017-10-18_21:38:50.74248 
2017-10-18_21:38:50.74251 BL2 Built : 11:44:26, Nov 25 2015. 
2017-10-18_21:38:50.74253 gxb gfb13a3b-c2 - jcao@wonton
2017-10-18_21:38:50.74255 
2017-10-18_21:38:50.74258 Board ID = 8
2017-10-18_21:38:50.74260 set vcck to 1100 mv
2017-10-18_21:38:50.74262 set vddee to 1050 mv
2017-10-18_21:38:50.74264 CPU clk: 1536MHz
2017-10-18_21:38:50.74266 DDR channel setting: DDR0 Rank0+1 same
2017-10-18_21:38:50.74269 DDR0: 2048MB(auto) @ 912MHz(2T)-13
2017-10-18_21:38:50.74271 DataBus test pass!
2017-10-18_21:38:50.74273 AddrBus test pass!
2017-10-18_21:38:50.74275 Load fip header from SD, src: 0xc200, des: 
0x0140, size: 0x00b0
2017-10-18_21:38:50.74278 Load bl30 from SD, src: 0x00010200, des: 0x0100, 
size: 0x9ef0
2017-10-18_21:38:50.74280 Sending 
bl30OK. 
2017-10-18_21:38:50.74283 Run bl30...
2017-10-18_21:38:50.74285 Load bl301 from SD, src: 0x0001c200, des: 0x0100, 
size: 0x12d0
2017-10-18_21:38:50.74287 Wait bl30...Done
2017-10-18_21:38:50.74289 Sending bl301.OK. 
2017-10-18_21:38:50.74292 Run bl301...
2017-10-18_21:38:50.74294 Lo.d bl31 from SD, src: 0x00020200, des: 0x1010, 
size: 0x00011130
2017-10-18_21:38:50.74296 
2017-10-18_21:38:50.74298 .
2017-10-18_21:38:50.74301 --- UART initialized after reboot ---.
2017-10-18_21:38:50.74303 [Reset cause: unknown].
2017-10-18_21:38:50.74310 [Image: unknown, amlogic_v1.1.3046-00db630-dirty 
2016-08-31 09:24:14 tao.zeng@droid04].
2017-10-18_21:38:50.74313 bl30: check_permit, count is 1.
2017-10-18_21:38:50.74316 .bl30: check_permit: ok!.
2017-10-18_21:38:50.74318 .chipid: ef be ad dLoad bl33 from SD, src: 
0x00034200, des: 0x0100, size: 0x0005a4b0
2017-10-18_21:38:50.74334 e d f0 ad ba ef be ad de not ES chip.
2017-10-18_21:38:50.74336 [0.721249 Inits done].
2017-10-18_21:38:50.74339 secure task start!
2017-10-18_21:38:50.74341 high task start!
2017-10-18_21:38:50.74343 low task start!
2017-10-18_21:38:50.74346 NOTICE:  BL3-1: v1.0(debug):4d2e34d
2017-10-18_21:38:50.74348 NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
2017-10-18_21:38:50.74350 INFO:BL3-1: Initializing runtime services
2017-10-18_21:38:50.74353 INFO:BL3-1: Preparing for EL3 exit to normal world
2017-10-18_21:38:50.74355 INFO:BL3-1: Next image address = 0x100
2017-10-18_21:38:50.74357 INFO:BL3-1: Next image spsr = 0x3c9
2017-10-18_21:38:50.74359 
2017-10-18_21:38:50.74362 
2017-10-18_21:38:50.74364 U-Boot 2017.09+dfsg1-1 (Sep 12 2017 - 20:19:29 +) 
odroid-c2
2017-10-18_21:38:50.74366 
2017-10-18_21:38:50.74368 DRAM:  2 GiB
2017-10-18_21:38:50.74370 MMC:   mmc@72000: 0, mmc@74000: 1
2017-10-18_21:38:50.74373 Using default environment
2017-10-18_21:38:50.74375 
2017-10-18_21:38:50.74377 In:serial@4c0
2017-10-18_21:38:50.74379 Out:   serial@4c0
2017-10-18_21:38:50.74381 Err:   serial@4c0
2017-10-18_21:38:50.74384 Net:   eth0: ethernet@c941
2017-10-18_21:38:51.74282 Hit any key to stop autoboot:  2  1  0 
2017-10-18_21:38:52.74304 => 
2017-10-18_21:38:55.74548 => boot
2017-10-18_21:38:56.74616 switch to partitions #0, OK
2017-10-18_21:38:56.74620 mmc0 is current device
2017-10-18_21:38:56.74622 Failed to mount ext2 filesystem...
2017-10-18_21:38:56.74625 ** Unrecognized filesystem type **
2017-10-18_21:38:56.74627 switch to partitions #0, OK
2017-10-18_21:38:56.74629 mmc1(part 0) is current device
2017-10-18_21:38:56.74632 Scanning mmc 1:2...
2017-10-18_21:38:56.74634 Found /extlinux/extlinux.conf
2017-10-18_21:38:56.74636 Retrieving file: /extlinux/extlinux.conf
2017-10-18_21:38:56.74638 1827 bytes read in 4 ms (445.3 KiB/s)
2017-10-18_21:38:56.74641 U-Boot menu
2017-10-18_21:38:56.74643 1:Debian GNU/Linux kernel 4.14.0-rc5-arm64
2017-10-18_21:38:56.74645 2:Debian GNU/Linux kernel 4.14.0-rc5-arm64 
(rescue target)
2017-10-18_21:38:56.74648 3:Debian GNU/Linux kernel 4.13.0-1-arm64

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

Control: found 4.13.4-1 4.14~rc3-1~exp1

On 2017-10-02, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:linux package:
>
> #843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with 
> rootfs on USB

It seems only partially fixed...

With 4.13.4-1 it usually detects the USB device, but I've gotten several
boots where it kernel panics on mounting swap (an lvm volume on the USB
device) or sometimes on unmounting swap as part of powerdown or
reboot. Not really any better luck with 4.14~rc3-1~exp1.

Both versions seem slightly more reliable in a warm boot vs. a cold
boot, or if usb is started from u-boot, but I've still seen kernel
panics even then. Setting rootdelay=30 seems to help, but not every
time. Sounds a bit racy...

The patched .dtb I was running with 4.9.30-2+deb9u5 and another with
4.13.2-1~exp1 both had an uptime of 8 days and counting. Oddly, dtdiff
cannot tell the difference between the patched 4.13.2-1~exp1 dtb and the
dtb shipped with 4.13.4-1, though the checksums do differ.

Hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-09-24, Jochen Sprickerhof wrote:
> Finally I had the time and hardware available to look into this again 
> and found a better way to fix it. Applying the attached patch results in 
> a new exynos5422-odroidxu4.dtb that could simply be copied to /boot/dtbs/*/
> I've tested this with the current kernel in sid (linux-image-4.12.0-2-armmp)
> as well as stretch (linux-image-4.9.0-3-armmp). More tests welcome.

Thanks!

I'm testing the patched .dtb on linux-image-4.9.0-3-armmp-lpae on two
machines and one machine running linux-image-4.13.0-trunk-armmp-lpae.
All use USB for rootfs and a build partition, so should test USB
reasonable well. Seems to work fine so far.

Using a patched .dtb is a much easier workaround than having to
recompile the whole kernel (and follow security updates and so on)!

I'd be happy to also do some testing with newer mainline kernels, if
you'd like to CC me on patch submissions upstream.


live well,
  vagrant

> Cheers Jochen
> From 0d3552be829d5a275d549cbf6ab468bfdb026e49 Mon Sep 17 00:00:00 2001
> From: Jochen Sprickerhof 
> Date: Sun, 24 Sep 2017 08:28:12 +0200
> Subject: [PATCH] ARM: dts: exynos: Use dwc3 quirk for USB3 and LAN on Odroid
>  XU4
>
> First proposed in https://lkml.org/lkml/2015/3/18/400 and discussed
> again in https://lkml.org/lkml/2017/1/24/402.
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..3861f74b2ecc 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,11 @@
>   status = "okay";
>  };
>  
> +_dwc3_0 {
> + snps,dis_u3_susphy_quirk;
> +};
> +
>  _dwc3_1 {
>   dr_mode = "host";
> + snps,dis_u3_susphy_quirk;
>  };
> -- 
> 2.14.1


signature.asc
Description: PGP signature

Bug#876035: linux: i386: i/o with PAE kernels and > 8GB ram

[Vagrant Cascadian]

Source: linux
Severity: important
Version: 4.2
Tags: upstream
Control: affects -1 jenkins.debian.org
Control: block 875990 by -1

It seems that since linux 4.2, PAE systems suffer from severe i/o write
performance issues on systems with more than 8GB of ram. The bug was
probably there all along, but recent changes in the kernel made the
impacts more obvious...

  https://bugzilla.kernel.org/show_bug.cgi?id=196157
  https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1698118


A detailed description of the issue:

  http://flaterco.com/kb/PAE_slowdown.html


This can be seen on the reproducible builds i386 nodes, after upgrading
to stretch late june/early july 2017, there was a huge spike in iowait:

  
https://jenkins.debian.net/munin/debian.net/profitbricks-build2-i386.debian.net/cpu.html
  
https://jenkins.debian.net/munin/debian.net/profitbricks-build12-i386.debian.net/cpu.html


Switching to an amd64 kernel for hardware that supports it is an option
in many cases, though at least for reproducible builds purposes, doesn't
test reproducibility issues case by 32-bit vs. 64-bit kernel variations.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-07-16, Vagrant Cascadian wrote:
> On 2017-07-10, Vagrant Cascadian wrote:
>> On 2017-07-08, Steinar H. Gunderson wrote:
>>> On Sat, Jul 08, 2017 at 07:50:03AM +0200, Jochen Sprickerhof wrote:
>>>> For v4.9 the only patch needed is:
>>>> 
>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=0001-usb-dwc3-core-setup-phy-before-trying-to-read-from-i.patch;msg=97
>>>
>>> Don't you also want this?
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=2166ffd004e04a61887eb2a39f8639dc12140c58-updated.diff;msg=75
>>
>> I've built patched linux 4.9 packages using the above two patches, and
>> am running them on several odroid-xu4 boards used in the reproducible
>> builds builders, running rootfs and a build partition on USB. So that
>> should test USB reasonably well... I'll report if there are any major
>> stability issues.

4.9 still working reasonably well...


>> I'll also try to switch one of them over to a patched 4.11 or 4.12
>> soonish... to make sure there aren't further regressions there.
>
> One of them was running 4.11, and didn't seem any better or worse.

And updated to testing on 4.12.10 on one of the boards...


Any progress getting these patches upstream?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-07-10, Vagrant Cascadian wrote:
> On 2017-07-08, Steinar H. Gunderson wrote:
>> On Sat, Jul 08, 2017 at 07:50:03AM +0200, Jochen Sprickerhof wrote:
>>> For v4.9 the only patch needed is:
>>> 
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=0001-usb-dwc3-core-setup-phy-before-trying-to-read-from-i.patch;msg=97
>>
>> Don't you also want this?
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=2166ffd004e04a61887eb2a39f8639dc12140c58-updated.diff;msg=75
>
> I've built patched linux 4.9 packages using the above two patches, and
> am running them on several odroid-xu4 boards used in the reproducible
> builds builders, running rootfs and a build partition on USB. So that
> should test USB reasonably well... I'll report if there are any major
> stability issues.

There have been infrequent USB resets, but it usually handles them
successfully:

[500623.473890] scsi host0: uas_eh_bus_reset_handler start
[500623.483176] sd 0:0:0:0: [sda] tag#22 uas_zap_pending 0 uas-tag 23
inflight: CMD
[500623.489235] sd 0:0:0:0: [sda] tag#22 CDB: Write(10) 2a 00 01 a4 51
10 00 00 10 00
[500623.496778] sd 0:0:0:0: [sda] tag#23 uas_zap_pending 0 uas-tag 24
inflight: CMD
[500623.504219] sd 0:0:0:0: [sda] tag#23 CDB: Read(10) 28 00 00 66 59 20
00 00 60 00
[500623.511678] sd 0:0:0:0: [sda] tag#24 uas_zap_pending 0 uas-tag 25
inflight: CMD
[500623.519120] sd 0:0:0:0: [sda] tag#24 CDB: Write(10) 2a 00 04 d4 c1
e8 00 00 18 00
[500623.526667] sd 0:0:0:0: [sda] tag#25 uas_zap_pending 0 uas-tag 26
inflight: CMD
[500623.534112] sd 0:0:0:0: [sda] tag#25 CDB: Read(10) 28 00 00 50 b1 10
00 00 08 00
[500623.541570] sd 0:0:0:0: [sda] tag#26 uas_zap_pending 0 uas-tag 27
inflight: CMD
[500623.549012] sd 0:0:0:0: [sda] tag#26 CDB: Write(10) 2a 00 04 d4 c6
58 00 00 08 00
[500623.556561] sd 0:0:0:0: [sda] tag#27 uas_zap_pending 0 uas-tag 28
inflight: CMD
[500623.564003] sd 0:0:0:0: [sda] tag#27 CDB: Read(10) 28 00 00 66 58 e0
00 00 40 00
[500623.654698] usb 4-1.2: reset SuperSpeed USB device number 3 using
xhci-hcd
[500623.681540] scsi host0: uas_eh_bus_reset_handler success

This is no worse than when running on 4.7.


> I'll also try to switch one of them over to a patched 4.11 or 4.12
> soonish... to make sure there aren't further regressions there.

One of them was running 4.11, and didn't seem any better or worse.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-07-08, Steinar H. Gunderson wrote:
> On Sat, Jul 08, 2017 at 07:50:03AM +0200, Jochen Sprickerhof wrote:
>> For v4.9 the only patch needed is:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=0001-usb-dwc3-core-setup-phy-before-trying-to-read-from-i.patch;msg=97
>
> Don't you also want this?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=2166ffd004e04a61887eb2a39f8639dc12140c58-updated.diff;msg=75

I've built patched linux 4.9 packages using the above two patches, and
am running them on several odroid-xu4 boards used in the reproducible
builds builders, running rootfs and a build partition on USB. So that
should test USB reasonably well... I'll report if there are any major
stability issues.

I'll also try to switch one of them over to a patched 4.11 or 4.12
soonish... to make sure there aren't further regressions there.


Thanks everyone for working on this!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-07-07, Jochen Sprickerhof wrote:
> I've created patches for v4.12 (applies to v4.11 as well) and git
> master and send them to the subsystem maintainers. Would be great to see
> them included in the Debian kernel as well.

Thanks!

Is this the only patch needed? Does it also need one of the patches
mentioned earlier in this bug? This is a single patch, with a v4.12 and
v4.11 variant, or two very similar looking patches?

I'd be happy to test on debian's 4.9 and 4.11 kernels, but it is a
little unclear to me exactly which patches are meant for what.

live well,
  vagrant

> From 7b12187f59ff43571e664b9f6987534ee622700f Mon Sep 17 00:00:00 2001
> From: Jochen Sprickerhof 
> Date: Fri, 7 Jul 2017 19:38:03 +0200
> Subject: [PATCH] v4.12: usb: dwc3: core: Setup phy before trying to read from
>  it
>
> Commit c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths")
> moved the call to dwc3_phy_setup() from dwc3_probe() to dwc3_core_init()
> and after the dwc3_readl() (now in dwc3_core_is_valid). This broke USB
> and Ethernet on Odroid XU4, because dwc3_readl() needs dwc3_phy_setup()
> to be run before.
>
> Fix this by moving the call to dwc3_phy_setup() before
> dwc3_core_is_valid().
>
> This fixes USB and Ethernet on Odroid XU4.
>
> Also see https://bugs.debian.org/843448
>
> Signed-off-by: Jochen Sprickerhof 
> Fixes: c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths")
> ---
>  drivers/usb/dwc3/core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 455d89a1cd6d..2418979a883a 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -732,6 +732,10 @@ static int dwc3_core_init(struct dwc3 *dwc)
>   u32 reg;
>   int ret;
>  
> + ret = dwc3_phy_setup(dwc);
> + if (ret)
> + goto err0;
> +
>   if (!dwc3_core_is_valid(dwc)) {
>   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
>   ret = -ENODEV;
> @@ -755,10 +759,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
>   if (ret)
>   goto err0;
>  
> - ret = dwc3_phy_setup(dwc);
> - if (ret)
> - goto err0;
> -
>   dwc3_core_setup_global_control(dwc);
>   dwc3_core_num_eps(dwc);
>  
> -- 
> 2.13.2
>
> From 6b7d33243a364c668530a5ae11ed5a57cecd42d9 Mon Sep 17 00:00:00 2001
> From: Jochen Sprickerhof 
> Date: Fri, 7 Jul 2017 19:38:03 +0200
> Subject: [PATCH] usb: dwc3: core: Setup phy before trying to read from it
>
> Commit c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths")
> moved the call to dwc3_phy_setup() from dwc3_probe() to dwc3_core_init()
> and after the dwc3_readl() (now in dwc3_core_is_valid). This broke USB
> and Ethernet on Odroid XU4, because dwc3_readl() needs dwc3_phy_setup()
> to be run before.
>
> Fix this by moving the call to dwc3_phy_setup() before
> dwc3_core_is_valid().
>
> This fixes USB and Ethernet on Odroid XU4.
>
> This needs and is supposed to be applied on top of
> https://patchwork.kernel.org/patch/9815981/
>
> Also see https://bugs.debian.org/843448
>
> Signed-off-by: Jochen Sprickerhof 
> Fixes: c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths")
> ---
>  drivers/usb/dwc3/core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 03474d3575ab..3c6faddc1394 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -747,6 +747,10 @@ static int dwc3_core_init(struct dwc3 *dwc)
>   u32 reg;
>   int ret;
>  
> + ret = dwc3_phy_setup(dwc);
> + if (ret)
> + goto err0;
> +
>   if (!dwc3_core_is_valid(dwc)) {
>   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
>   ret = -ENODEV;
> @@ -774,10 +778,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
>   if (ret)
>   goto err0;
>  
> - ret = dwc3_phy_setup(dwc);
> - if (ret)
> - goto err0;
> -
>   dwc3_core_setup_global_control(dwc);
>   dwc3_core_num_eps(dwc);
>  
> -- 
> 2.13.2


signature.asc
Description: PGP signature

Bug#860976: linux: [arm64] Enable support for Rockchip systems

[Vagrant Cascadian]

On 2017-05-04, Vagrant Cascadian wrote:
> On 2017-04-22, Vagrant Cascadian wrote:
>> Please add the following options to enable Rockchip support on arm64.
>>
>> Tested on a firefly-rk3399 using linux 4.11.0-rc7 to boot stretch
>> debian-installer.
>
> Updated patch, tested with 4.11.0-trunk:

Also tested with 4.11.3-1~exp1:

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index e447cc4d1..64dc3af97 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -51,6 +51,7 @@ CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_QCOM=y
+CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_THUNDER=y
@@ -104,6 +105,7 @@ CONFIG_IPMI_SSIF=m
 ## file: drivers/clk/Kconfig
 ##
 CONFIG_COMMON_CLK_XGENE=y
+CONFIG_COMMON_CLK_RK808=y
 
 ##
 ## file: drivers/clk/hisilicon/Kconfig
@@ -268,6 +270,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=m
 CONFIG_I2C_MESON=m
 CONFIG_I2C_MV64XXX=m
 CONFIG_I2C_QUP=m
+CONFIG_I2C_RK3X=m
 CONFIG_I2C_TEGRA=m
 CONFIG_I2C_THUNDERX=m
 CONFIG_I2C_CROS_EC_TUNNEL=m
@@ -278,6 +281,12 @@ CONFIG_I2C_XGENE_SLIMPRO=m
 ##
 CONFIG_QCOM_SPMI_IADC=m
 CONFIG_QCOM_SPMI_VADC=m
+CONFIG_ROCKCHIP_SARADC=m
+
+##
+## file: drivers/iio/imu/inv_mpu6050/Kconfig
+##
+CONFIG_INV_MPU6050_I2C=m
 
 ##
 ## file: drivers/input/keyboard/Kconfig
@@ -322,6 +331,7 @@ CONFIG_MFD_CROS_EC_SPI=m
 CONFIG_MFD_HI655X_PMIC=m
 CONFIG_MFD_MAX77620=y
 CONFIG_MFD_QCOM_RPM=m
+CONFIG_MFD_RK808=m
 CONFIG_MFD_SPMI_PMIC=m
 
 ##
@@ -347,11 +357,13 @@ CONFIG_MMC_QCOM_DML=m
 CONFIG_MMC_SDHCI_PLTFM=m
 CONFIG_MMC_SDHCI_TEGRA=m
 CONFIG_MMC_SDHCI_IPROC=m
+CONFIG_MMC_SDHCI_OF_ARASAN=m
 CONFIG_MMC_MESON_GX=m
 CONFIG_MMC_SDHCI_MSM=m
 CONFIG_MMC_SPI=m
 CONFIG_MMC_DW=m
 CONFIG_MMC_DW_K3=m
+CONFIG_MMC_DW_ROCKCHIP=m
 CONFIG_MMC_SUNXI=m
 
 ##
@@ -465,6 +477,7 @@ CONFIG_STMMAC_PLATFORM=m
 CONFIG_DWMAC_GENERIC=m
 CONFIG_DWMAC_IPQ806X=m
 CONFIG_DWMAC_MESON=m
+CONFIG_DWMAC_RK=m
 
 ##
 ## file: drivers/net/fddi/Kconfig
@@ -526,6 +539,7 @@ CONFIG_QCOM_QFPROM=m
 CONFIG_PCI_HISI=y
 CONFIG_PCIE_QCOM=y
 CONFIG_PCIE_ARMADA_8K=y
+CONFIG_PCIE_ROCKCHIP=y
 
 ##
 ## file: drivers/pci/host/Kconfig
@@ -546,6 +560,9 @@ CONFIG_PHY_QCOM_IPQ806X_SATA=m
 CONFIG_PHY_XGENE=m
 CONFIG_PHY_QCOM_UFS=m
 CONFIG_PHY_MESON8B_USB2=m
+CONFIG_PHY_ROCKCHIP_INNO_USB2=m
+CONFIG_PHY_ROCKCHIP_EMMC=m
+CONFIG_PHY_ROCKCHIP_PCIE=m
 
 ##
 ## file: drivers/phy/tegra/Kconfig
@@ -574,6 +591,12 @@ CONFIG_CHROME_PLATFORMS=y
 CONFIG_CROS_KBD_LED_BACKLIGHT=m
 
 ##
+## file: drivers/power/avs/Kconfig
+##
+CONFIG_POWER_AVS=y
+CONFIG_ROCKCHIP_IODOMAIN=m
+
+##
 ## file: drivers/power/reset/Kconfig
 ##
 CONFIG_POWER_RESET_HISI=y
@@ -595,6 +618,7 @@ CONFIG_CHARGER_QCOM_SMBB=m
 CONFIG_PWM=y
 CONFIG_PWM_BCM2835=m
 CONFIG_PWM_MESON=m
+CONFIG_PWM_ROCKCHIP=m
 CONFIG_PWM_TEGRA=m
 
 ##
@@ -602,10 +626,12 @@ CONFIG_PWM_TEGRA=m
 ##
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=m
+CONFIG_REGULATOR_FAN53555=m
 CONFIG_REGULATOR_GPIO=m
 CONFIG_REGULATOR_HI655X=m
 CONFIG_REGULATOR_MAX77620=m
 CONFIG_REGULATOR_PWM=m
+CONFIG_REGULATOR_RK808=m
 CONFIG_REGULATOR_QCOM_RPM=m
 CONFIG_REGULATOR_QCOM_SMD_RPM=m
 CONFIG_REGULATOR_QCOM_SPMI=m
@@ -637,6 +663,7 @@ CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_PM8XXX=m
+CONFIG_RTC_DRV_RK808=y
 CONFIG_RTC_DRV_TEGRA=y
 CONFIG_RTC_DRV_XGENE=y
 
@@ -667,6 +694,11 @@ CONFIG_QCOM_SMSM=m
 CONFIG_QCOM_WCNSS_CTRL=m
 
 ##
+## file: drivers/soc/rockchip/Kconfig
+##
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+
+##
 ## file: drivers/soc/tegra/Kconfig
 ##
 CONFIG_ARCH_TEGRA_132_SOC=y
@@ -697,6 +729,7 @@ CONFIG_THERMAL=y
 CONFIG_CPU_THERMAL=y
 CONFIG_HISI_THERMAL=m
 CONFIG_QCOM_SPMI_TEMP_ALARM=m
+CONFIG_ROCKCHIP_THERMAL=m
 
 ##
 ## file: drivers/thermal/qcom/Kconfig
@@ -838,6 +871,11 @@ CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_SOC=m
 
 ##
+## file: sound/soc/generic/Kconfig
+##
+CONFIG_SND_SIMPLE_CARD=m
+
+##
 ## file: sound/soc/bcm/Kconfig
 ##
 CONFIG_SND_BCM2835_SOC_I2S=m
@@ -849,6 +887,12 @@ CONFIG_SND_SOC_QCOM=m
 CONFIG_SND_SOC_APQ8016_SBC=m
 
 ##
+## file: sound/soc/rockchip/Kconfig
+##
+CONFIG_SND_SOC_ROCKCHIP=m
+CONFIG_SND_SOC_ROCKCHIP_I2S=m
+
+##
 ## file: sound/soc/tegra/Kconfig
 ##
 CONFIG_SND_SOC_TEGRA=m


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#863907: Fix cross compilation build-dependencies for 4.9.x

[Vagrant Cascadian]

Package: src:linux
Version: 4.9.25-1
Severity: normal

Please consider cherry-picking the following commit from the master
branch to fix cross-compilation:

commit 84e53d21c3676c8165e959687e3b9417e242400c
Author: Ben Hutchings 
Date:   Thu Feb 2 02:35:55 2017 +

debian/control: Fix compiler build-dependencies for cross-building

gcc cross-compilers *do* now have Multi-Arch: foreign, so we have
to take the :native qualfiication off again.


This appears relevent for sid and stretch's 4.9.x kernels, and it worked
for me. Only conflict was in debian/changelog.

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-05-27, Vagrant Cascadian wrote:
> I've also got a BeagleBoard-X15 that works reasonably well without the
> patch; will test the patched kernel to see if it appears to cause any
> problems.

Of course, the BeagleBoard-X15 isn't using USB for anything, so this
isn't much of a test, but it's the only other board I have available
that uses dwc3.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-05-27, Steinar H. Gunderson wrote:
> On Wed, May 24, 2017 at 11:37:36PM +0200, Steinar H. Gunderson wrote:
>> Well, it's a revert of something that's supposed to only be a
>> cleanup/refactor (but isn't, presumably due to phy bugs). So it _should_ be
>> safe, at least in theory.
>> 
>> FWIW, after a bit over two hours, this happened:
>> 
>>   [ 7912.391226] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
>>   [ 7912.413744] usb 4-1: New USB device found, idVendor=05e3, idProduct=0616
>>   [ 7912.413752] usb 4-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=0
>>   [ 7912.413758] usb 4-1: Product: USB3.0 Hub
>>   [ 7912.413764] usb 4-1: Manufacturer: GenesysLogic
>>   [ 7912.417680] hub 4-1:1.0: USB hub found
>>   [ 7912.417989] hub 4-1:1.0: 2 ports detected
>
> 72 hours uptime now, with no more ill effects. NIC works fine.

The three odroid-xu4 reproducible builds nodes, with rootfs and a build
partition on USB, have mostly been working under load with ~2.5 days
uptime for 2/3 of the machines:

  
https://jenkins.debian.net/munin/debian.net/odxu4-armhf-rb.debian.net/index.html
  
https://jenkins.debian.net/munin/debian.net/odxu4b-armhf-rb.debian.net/index.html
  
https://jenkins.debian.net/munin/debian.net/odxu4c-armhf-rb.debian.net/index.html

I've also got a BeagleBoard-X15 that works reasonably well without the
patch; will test the patched kernel to see if it appears to cause any
problems.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-05-23, Steinar H. Gunderson wrote:
>   
> https://github.com/hardkernel/linux/commit/74b9605e5587b30912d6b6093e9d7fb06d043c33
...
> I've applied the former patch (the revert) on top of Debian's 4.9.25 kernel
> (linux-image-4.9.0-3-armmp-lpae), and it boots with working USB and thus
> networking on my XU4. I saw this at some point after boot, though:
>
>   [  550.087389] xhci-hcd xhci-hcd.5.auto: Cannot set link state.
>   [  550.087426] usb usb6-port1: cannot disable (err = -32)

I've also applied the patch and was able to boot an odroid-xu4 with
it. I've got three of them used for the reproducible builds farm that
have been stuck on the 4.7.x kernel, so many thanks for identifying a
workaround! Will start using 4.9.x with this patch...


> In any case, it essentially takes the system from “totally broken” to “might
> have some problems”. Would you consider taking it in for stretch, so that the
> XU4 has networking? I'll keep running with this kernel to get more
> experience.

Unfortunately, there are numerous other boards using dwc3, so I'm not
sure this is a good idea...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#860976: linux: [arm64] Enable support for Rockchip systems

[Vagrant Cascadian]

On 2017-04-22, Vagrant Cascadian wrote:
> Please add the following options to enable Rockchip support on arm64.
>
> Tested on a firefly-rk3399 using linux 4.11.0-rc7 to boot stretch
> debian-installer.

Updated patch, tested with 4.11.0-trunk:

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index d44595123..d0e0631ed 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -51,6 +51,7 @@ CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_QCOM=y
+CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_THUNDER=y
@@ -104,6 +105,7 @@ CONFIG_IPMI_SSIF=m
 ## file: drivers/clk/Kconfig
 ##
 CONFIG_COMMON_CLK_XGENE=y
+CONFIG_COMMON_CLK_RK808=y
 
 ##
 ## file: drivers/clk/hisilicon/Kconfig
@@ -260,6 +262,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=m
 CONFIG_I2C_MESON=m
 CONFIG_I2C_MV64XXX=m
 CONFIG_I2C_QUP=m
+CONFIG_I2C_RK3X=m
 CONFIG_I2C_TEGRA=m
 CONFIG_I2C_THUNDERX=m
 CONFIG_I2C_CROS_EC_TUNNEL=m
@@ -270,6 +273,12 @@ CONFIG_I2C_XGENE_SLIMPRO=m
 ##
 CONFIG_QCOM_SPMI_IADC=m
 CONFIG_QCOM_SPMI_VADC=m
+CONFIG_ROCKCHIP_SARADC=m
+
+##
+## file: drivers/iio/imu/inv_mpu6050/Kconfig
+##
+CONFIG_INV_MPU6050_I2C=m
 
 ##
 ## file: drivers/input/keyboard/Kconfig
@@ -314,6 +323,7 @@ CONFIG_MFD_CROS_EC_SPI=m
 CONFIG_MFD_HI655X_PMIC=m
 CONFIG_MFD_MAX77620=y
 CONFIG_MFD_QCOM_RPM=m
+CONFIG_MFD_RK808=m
 CONFIG_MFD_SPMI_PMIC=m
 
 ##
@@ -339,11 +349,13 @@ CONFIG_MMC_QCOM_DML=m
 CONFIG_MMC_SDHCI_PLTFM=m
 CONFIG_MMC_SDHCI_TEGRA=m
 CONFIG_MMC_SDHCI_IPROC=m
+CONFIG_MMC_SDHCI_OF_ARASAN=m
 CONFIG_MMC_MESON_GX=m
 CONFIG_MMC_SDHCI_MSM=m
 CONFIG_MMC_SPI=m
 CONFIG_MMC_DW=m
 CONFIG_MMC_DW_K3=m
+CONFIG_MMC_DW_ROCKCHIP=m
 CONFIG_MMC_SUNXI=m
 
 ##
@@ -457,6 +469,7 @@ CONFIG_STMMAC_PLATFORM=m
 CONFIG_DWMAC_GENERIC=m
 CONFIG_DWMAC_IPQ806X=m
 CONFIG_DWMAC_MESON=m
+CONFIG_DWMAC_RK=m
 
 ##
 ## file: drivers/net/fddi/Kconfig
@@ -518,6 +531,7 @@ CONFIG_QCOM_QFPROM=m
 CONFIG_PCI_HISI=y
 CONFIG_PCIE_QCOM=y
 CONFIG_PCIE_ARMADA_8K=y
+CONFIG_PCIE_ROCKCHIP=y
 
 ##
 ## file: drivers/pci/host/Kconfig
@@ -538,6 +552,9 @@ CONFIG_PHY_QCOM_IPQ806X_SATA=m
 CONFIG_PHY_XGENE=m
 CONFIG_PHY_QCOM_UFS=m
 CONFIG_PHY_MESON8B_USB2=m
+CONFIG_PHY_ROCKCHIP_INNO_USB2=m
+CONFIG_PHY_ROCKCHIP_EMMC=m
+CONFIG_PHY_ROCKCHIP_PCIE=m
 
 ##
 ## file: drivers/phy/tegra/Kconfig
@@ -566,6 +583,12 @@ CONFIG_CHROME_PLATFORMS=y
 CONFIG_CROS_KBD_LED_BACKLIGHT=m
 
 ##
+## file: drivers/power/avs/Kconfig
+##
+CONFIG_POWER_AVS=y
+CONFIG_ROCKCHIP_IODOMAIN=m
+
+##
 ## file: drivers/power/reset/Kconfig
 ##
 CONFIG_POWER_RESET_HISI=y
@@ -587,6 +610,7 @@ CONFIG_CHARGER_QCOM_SMBB=m
 CONFIG_PWM=y
 CONFIG_PWM_BCM2835=m
 CONFIG_PWM_MESON=m
+CONFIG_PWM_ROCKCHIP=m
 CONFIG_PWM_TEGRA=m
 
 ##
@@ -594,10 +618,12 @@ CONFIG_PWM_TEGRA=m
 ##
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=m
+CONFIG_REGULATOR_FAN53555=m
 CONFIG_REGULATOR_GPIO=m
 CONFIG_REGULATOR_HI655X=m
 CONFIG_REGULATOR_MAX77620=m
 CONFIG_REGULATOR_PWM=m
+CONFIG_REGULATOR_RK808=m
 CONFIG_REGULATOR_QCOM_RPM=m
 CONFIG_REGULATOR_QCOM_SMD_RPM=m
 CONFIG_REGULATOR_QCOM_SPMI=m
@@ -629,6 +655,7 @@ CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_PM8XXX=m
+CONFIG_RTC_DRV_RK808=y
 CONFIG_RTC_DRV_TEGRA=y
 CONFIG_RTC_DRV_XGENE=y
 
@@ -659,6 +686,11 @@ CONFIG_QCOM_SMSM=m
 CONFIG_QCOM_WCNSS_CTRL=m
 
 ##
+## file: drivers/soc/rockchip/Kconfig
+##
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+
+##
 ## file: drivers/soc/tegra/Kconfig
 ##
 CONFIG_ARCH_TEGRA_132_SOC=y
@@ -689,6 +721,7 @@ CONFIG_THERMAL=y
 CONFIG_CPU_THERMAL=y
 CONFIG_HISI_THERMAL=m
 CONFIG_QCOM_SPMI_TEMP_ALARM=m
+CONFIG_ROCKCHIP_THERMAL=m
 
 ##
 ## file: drivers/thermal/qcom/Kconfig
@@ -830,6 +863,11 @@ CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_SOC=m
 
 ##
+## file: sound/soc/generic/Kconfig
+##
+CONFIG_SND_SIMPLE_CARD=m
+
+##
 ## file: sound/soc/bcm/Kconfig
 ##
 CONFIG_SND_BCM2835_SOC_I2S=m
@@ -841,6 +879,12 @@ CONFIG_SND_SOC_QCOM=m
 CONFIG_SND_SOC_APQ8016_SBC=m
 
 ##
+## file: sound/soc/rockchip/Kconfig
+##
+CONFIG_SND_SOC_ROCKCHIP=m
+CONFIG_SND_SOC_ROCKCHIP_I2S=m
+
+##
 ## file: sound/soc/tegra/Kconfig
 ##
 CONFIG_SND_SOC_TEGRA=m


signature.asc
Description: PGP signature

Bug#860976: linux: [arm64] Enable support for Rockchip systems

[Vagrant Cascadian]

Package: linux
Version: 4.10.7-1~exp1
Severity: wishlist
Tags: patch

Please add the following options to enable Rockchip support on arm64.

Tested on a firefly-rk3399 using linux 4.11.0-rc7 to boot stretch
debian-installer.

The device-tree used isn't yet in mainline, but I used patches from the
linux-rockchip v4.13-armsoc/dts64 branch, so should land in next
eventually. Other rockchip boards may be better supported, but I didn't
have available to test.


Working: serial console, USB2, eMMC

Somewhat working: ethernet (unreliable)

Not working: USB3, microSD

Not tested: hdmi and other video, analog and spdiff audio, pcie, msata,
LTE slot, simd card, wifi


The options below were either present in arch/arm64/configs/defconfig or
relevent to the device-tree used. Some additional options might also be
useful, but I haven't looked in-depth. It's a start.


live well,
  vagrant


diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index 985a357e8..041b2171c 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -46,6 +46,7 @@ CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_QCOM=y
+CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_THUNDER=y
@@ -99,6 +100,7 @@ CONFIG_IPMI_SSIF=m
 ## file: drivers/clk/Kconfig
 ##
 CONFIG_COMMON_CLK_XGENE=y
+CONFIG_COMMON_CLK_RK808=y
 
 ##
 ## file: drivers/clk/hisilicon/Kconfig
@@ -255,6 +257,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=m
 CONFIG_I2C_MESON=m
 CONFIG_I2C_MV64XXX=m
 CONFIG_I2C_QUP=m
+CONFIG_I2C_RK3X=m
 CONFIG_I2C_TEGRA=m
 CONFIG_I2C_THUNDERX=m
 CONFIG_I2C_CROS_EC_TUNNEL=m
@@ -314,6 +317,7 @@ CONFIG_MFD_CROS_EC_SPI=m
 CONFIG_MFD_HI655X_PMIC=m
 CONFIG_MFD_MAX77620=y
 CONFIG_MFD_QCOM_RPM=m
+CONFIG_MFD_RK808=m
 CONFIG_MFD_SPMI_PMIC=m
 
 ##
@@ -339,11 +343,13 @@ CONFIG_MMC_QCOM_DML=m
 CONFIG_MMC_SDHCI_PLTFM=m
 CONFIG_MMC_SDHCI_TEGRA=m
 CONFIG_MMC_SDHCI_IPROC=m
+CONFIG_MMC_SDHCI_OF_ARASAN=m
 CONFIG_MMC_MESON_GX=m
 CONFIG_MMC_SDHCI_MSM=m
 CONFIG_MMC_SPI=m
 CONFIG_MMC_DW=m
 CONFIG_MMC_DW_K3=m
+CONFIG_MMC_DW_ROCKCHIP=m
 CONFIG_MMC_SUNXI=m
 
 ##
@@ -457,6 +463,7 @@ CONFIG_STMMAC_PLATFORM=m
 CONFIG_DWMAC_GENERIC=m
 CONFIG_DWMAC_IPQ806X=m
 CONFIG_DWMAC_MESON=m
+CONFIG_DWMAC_RK=m
 
 ##
 ## file: drivers/net/fddi/Kconfig
@@ -518,6 +525,7 @@ CONFIG_QCOM_QFPROM=m
 CONFIG_PCI_HISI=y
 CONFIG_PCIE_QCOM=y
 CONFIG_PCIE_ARMADA_8K=y
+CONFIG_PCIE_ROCKCHIP=y
 
 ##
 ## file: drivers/pci/host/Kconfig
@@ -538,6 +546,9 @@ CONFIG_PHY_QCOM_IPQ806X_SATA=m
 CONFIG_PHY_XGENE=m
 CONFIG_PHY_QCOM_UFS=m
 CONFIG_PHY_MESON8B_USB2=m
+CONFIG_PHY_ROCKCHIP_INNO_USB2=m
+CONFIG_PHY_ROCKCHIP_EMMC=m
+CONFIG_PHY_ROCKCHIP_PCIE=m
 
 ##
 ## file: drivers/phy/tegra/Kconfig
@@ -587,6 +598,7 @@ CONFIG_CHARGER_QCOM_SMBB=m
 CONFIG_PWM=y
 CONFIG_PWM_BCM2835=m
 CONFIG_PWM_MESON=m
+CONFIG_PWM_ROCKCHIP=m
 CONFIG_PWM_TEGRA=m
 
 ##
@@ -598,6 +610,7 @@ CONFIG_REGULATOR_GPIO=m
 CONFIG_REGULATOR_HI655X=m
 CONFIG_REGULATOR_MAX77620=m
 CONFIG_REGULATOR_PWM=m
+CONFIG_REGULATOR_RK808=m
 CONFIG_REGULATOR_QCOM_RPM=m
 CONFIG_REGULATOR_QCOM_SMD_RPM=m
 CONFIG_REGULATOR_QCOM_SPMI=m
@@ -629,6 +642,7 @@ CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_PM8XXX=m
+CONFIG_RTC_DRV_RK808=y
 CONFIG_RTC_DRV_TEGRA=y
 CONFIG_RTC_DRV_XGENE=y
 
@@ -852,3 +866,4 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_ROCKCHIP_PM_DOMAINS=y


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2017-04-22, Vagrant Cascadian wrote:
> On 2016-11-12, Ben Hutchings wrote:
>> On Sun, 2016-11-06 at 10:00 -0800, Vagrant Cascadian wrote:
>>> When upgrading to linux 4.8.x on an Odroid-XU4 system, it no longer
>>> detects the USB sata adapter where rootfs is located.
>>> 
>>> Downgrading to the 4.7.x kernel from jessie-backports works fine.
> ...
>> This message (from the core hub driver) looks important:
>>
>> 2016-11-06_17:33:29.19077 [7.510995] usb usb3-port1: connect-debounce 
>> failed
...
> Will try with stretch's d-i next...

With stretch's d-i, I don't see the debounce messages, but USB fails to
work, and ethernet is implemented over USB, so this fails on the d-i
netboot image.

Attached is the full dmesg output from within d-i.

~ # uname -a
Linux (none) 4.9.0-2-armmp #1 SMP Debian 4.9.18-1 (2017-03-30) armv7l
GNU/Linux
~ #
~ # lsmod
Module  Size  Used by
dwc3_exynos 3827  0
ohci_exynos 4178  0
ohci_hcd   37898  1 ohci_exynos
ehci_exynos 4269  0
ehci_hcd   64996  1 ehci_exynos
dw_mmc_exynos   5942  0
usbcore   195888  4
ehci_exynos,ehci_hcd,ohci_hcd,ohci_exynos
dw_mmc_pltfm2485  1 dw_mmc_exynos
dw_mmc 25740  2 dw_mmc_pltfm,dw_mmc_exynos
phy_exynos_usb2 9238  2
phy_exynos5_usbdrd  7053  0
usb_common  3659  1 usbcore


live well,
  vagrant



odxu4c.log
Description: Binary data


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

On 2016-11-12, Ben Hutchings wrote:
> On Sun, 2016-11-06 at 10:00 -0800, Vagrant Cascadian wrote:
>> When upgrading to linux 4.8.x on an Odroid-XU4 system, it no longer
>> detects the USB sata adapter where rootfs is located.
>> 
>> Downgrading to the 4.7.x kernel from jessie-backports works fine.
...
> This message (from the core hub driver) looks important:
>
> 2016-11-06_17:33:29.19077 [7.510995] usb usb3-port1: connect-debounce 
> failed
>
> The device tree source for Exynos 5422 was changed between 4.7 and 4.8
> so some of the USB definitions could be shared with the 5410 (commit
> cb0896562228703209644e92926ed445150cc594).  This obviously shouldn't
> have a functional difference to the 5422 but maybe it did?

I tried booting 4.9 from jessie-backports just now using the dts from
4.7, and it had the same behavior. So I'm guessing that's not the issue.

I also tried with an initramfs that had all of the available driver
modules included, with no luck.

Will try with stretch's d-i next...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#860855: linux: [arm64] Please add support for Allwinner boards (pine64)

[Vagrant Cascadian]

Package: linux
Version: 4.10.7-1~exp1
Severity: wishlist
Tags: patch

The following config options should enable support for basic SUNXI boards on 
arm64.

Tested on Pine64+ board with MMC, USB and serial console working.

Requires linux 4.11-rc+ for all of the features to work.

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index 27da44863..2106a32d8 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -847,3 +847,7 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_ARCH_SUNXI=y
+CONFIG_RTC_DRV_SUN6I=y
+CONFIG_MMC_SUNXI=m
+CONFIG_PHY_SUN4I_USB=m


signature.asc
Description: PGP signature

Bug#852132: linux-latest: Add support for Hardkernel Odroid-C2

[Vagrant Cascadian]

On 2017-01-24, Heinrich Schuchardt wrote:
> On 01/24/2017 05:47 PM, Ben Hutchings wrote:
>> On Sat, 21 Jan 2017 21:00:18 +0100 Heinrich Schuchardt
>>  wrote:
>>> please, add support for the Hardkernel Odroid C2 to the kernel 
>>> configuration.
>>>  
>>> For 4.9 kernels this involves:
>>>  
>>> CONFIG_ARCH_MESON=y
...
>>> CONFIG_COMMON_CLK_AMLOGIC=y
>> 
>> I can do all this, except I think the watchdog driver can and should be
>> a module.

Thanks for moving this forward! Was working on this too, and adding
support for u-boot, but the mainline u-boot support is still too
unreliable.


>>> For 4.10 kernels this involves
>>>  
>>> CONFIG_ARCH_MESON=y
...
>>> CONFIG_PHY_MESON8B_USB2=m
>>> CONFIG_MESON_SM=y
>>> CONFIG_COMMON_CLK_AMLOGIC=y
>> 
>> Given that we're going to be using 4.9 in Debian 9 'stretch', are you
>> interested in getting the Meson changes in 4.10 backported?
>
> USB is not yet really usable in 4.10. So what would deserve backporting
> is MMC and some networking patches.

I did have working USB with odroid-c2 in using linux-next tag
next-20170113, for what it's worth.


I'll try testing your patches against sid's kernel soon.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#845075: kernel-image-4.8.0-1-armmp-di: Lamobo R1 cannot access network

[Vagrant Cascadian]

On 2017-01-04, Ben Hutchings wrote:
>> I want to install Debian Stretch on my Lamobo R1 using the network
>> installer.
>> 
>> It is unable to connect to the DHCP server.
>> 
>> Please, add the b53 module to the kernel.
>> 
>> CONFIG_B53=y
>> CONFIG_B53_SPI_DRIVER=y
>
> I think we already enabled the necessary options:
>
>   * [armhf] dsa: Enable drivers for Lamobo R1 (aka BPi-R1): B53,
> B53_MDIO_DRIVER as modules (Closes: #836231, thanks to Vagrant Cascadian)
>
> From the device tree, it seems pretty clear that we do want
> B53_MDIO_DRIVER and not B53_SPI_DRIVER.  Are you sure the installer
> version you used had a verison 4.8 kernel, not 4.7?

I had very mixed luck with the switch driver with 4.7.x and 4.8.x, but
ethernet generally worked ok. With 4.9.x, I was able to get all ports
working well.

Were you plugging into the WAN port, or one of the switch ports?

Is the b53 module listed in nic-modules udeb? I don't see mention of it
at a quick glance, or is it pulled in with some globbing?


live well,
  vagrant

p.s. I've haven't been tracking the udebs as much lately, tired of
playing whack-a-mole with the exact right modules in the exact right
udeb... instead I've been manually appending all the drivers into the
initrd as an additional cpio archive...


signature.asc
Description: PGP signature

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[Vagrant Cascadian]

Package: src:linux
Version: 4.8.5-1
Severity: important

When upgrading to linux 4.8.x on an Odroid-XU4 system, it no longer
detects the USB sata adapter where rootfs is located.

Downgrading to the 4.7.x kernel from jessie-backports works fine.

I didn't see anything obviously missing when diffing /boot/config-*.

Boot log attached.

If there's nothing obvious fromt the boot log, I can try taking it
offline and doing an install with stretch or sid to do more debugging.


live well,
  vagrant

-- Package-specific info:
** Model information
Hardware: SAMSUNG EXYNOS (Flattened Device Tree)
Revision: 
Device Tree model: Hardkernel Odroid XU4

** PCI devices:

** USB devices:
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA 
bridge
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental'), 
(1, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.7.0-0.bpo.1-armmp-lpae (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.8.0-1-armmp-lpae depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.120+deb8u2
ii  kmod18-3
ii  linux-base  4.3~bpo8+1

Versions of packages linux-image-4.8.0-1-armmp-lpae recommends:
ii  firmware-linux-free  3.3
ii  irqbalance   1.0.6-3

Versions of packages linux-image-4.8.0-1-armmp-lpae suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.8   

Versions of packages linux-image-4.8.0-1-armmp-lpae is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information



odxu4c.log
Description: Binary data


signature.asc
Description: PGP signature

Bug#840137: linux-image-4.7.0-1-armmp: Please add device-tree for imx53-usbarmory.

[Vagrant Cascadian]

Package: linux-image-4.7.0-1-armmp
Severity: wishlist
Tags: patch

Please add the device-tree for the imx53-usbarmory, which was recently
merged in linux mainline. Patch below.

>From 17028ca2a5030a2e97f87b3290f814ba860480c0 Mon Sep 17 00:00:00 2001
From: Andrej Rosano <and...@inversepath.com>
Date: Mon, 5 Sep 2016 12:11:17 +0200
Subject: [PATCH] ARM: dts: imx53: add support for USB armory board

Add support for Inverse Path USB armory board, an open source
flash-drive sized computer based on NXP i.MX53 SoC.

https://inversepath.com/usbarmory

Signed-off-by: Andrej Rosano <and...@inversepath.com>
Tested-by: Vagrant Cascadian <vagr...@debian.org>
Signed-off-by: Shawn Guo <shawn...@kernel.org>
---
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/imx53-usbarmory.dts | 224 ++
 2 files changed, 225 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx53-usbarmory.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5dcc239..f79cac2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -315,6 +315,7 @@ dtb-$(CONFIG_SOC_IMX53) += \
imx53-smd.dtb \
imx53-tx53-x03x.dtb \
imx53-tx53-x13x.dtb \
+   imx53-usbarmory.dtb \
imx53-voipac-bsb.dtb
 dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-apf6dev.dtb \
diff --git a/arch/arm/boot/dts/imx53-usbarmory.dts 
b/arch/arm/boot/dts/imx53-usbarmory.dts
new file mode 100644
index 000..6782d7f
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-usbarmory.dts
@@ -0,0 +1,224 @@
+/*
+ * USB armory MkI device tree file
+ * https://inversepath.com/usbarmory
+ *
+ * Copyright (C) 2015, Inverse Path
+ * Andrej Rosano <and...@inversepath.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 file 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 file 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.
+ *
+ * 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,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx53.dtsi"
+
+/ {
+   model = "Inverse Path USB armory";
+   compatible = "inversepath,imx53-usbarmory", "fsl,imx53";
+};
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+
+   memory {
+   reg = <0x7000 0x2000>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led>;
+
+   user {
+   label = "LED";
+   gpios = < 27 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+};
+
+/*
+ * Not every i.MX53 P/N supports clock > 800MHz.
+ * As USB armory does not mount a specific P/N set a safe clock upper limit.
+ */
+ {
+   operating-points = <
+   /* kHz */
+   16  85
+   40  90
+   80 105
+   >;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_esdhc1>;
+   status = "okay";
+};
+
+ {
+   pinctrl_es

Bug#836251: linux: [armhf] Please enable support for veyron-speedy

[Vagrant Cascadian]

On 2016-08-31, Vagrant Cascadian wrote:
> Please enable support for veyron-speedy (a.k.a. ASUS Chromebook C201)
> to linux 4.8.x.
...
> Haven't had success getting output form the speakers or headphone
> jack, though the OS seems to detect at least one device.

headphone jack works, too!


live well,
  vagrant


> diff --git a/debian/config/armhf/config b/debian/config/armhf/config
> index 0a9be6f..4fc638c 100644
> --- a/debian/config/armhf/config
> +++ b/debian/config/armhf/config
> @@ -1262,3 +1263,28 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
>  CONFIG_SND_SOC_TEGRA_MAX98090=m
>  CONFIG_SND_SOC_TEGRA_RT5677=m
>  
> +CONFIG_BATTERY_SBS=m
> +CONFIG_DRM_PANEL=y
> +CONFIG_DRM_PANEL_SIMPLE=m
> +CONFIG_BACKLIGHT_PWM=m
> +CONFIG_CHARGER_GPIO=m
> +CONFIG_MFD_CROS_EC=m
> +CONFIG_I2C_CROS_EC_TUNNEL=m
> +CONFIG_MOUSE_ELAN_I2C=m
> +CONFIG_KEYBOARD_CROS_EC=m
> +CONFIG_KEYBOARD_GPIO=m
> +CONFIG_POWER_RESET_GPIO=y
> +CONFIG_POWER_RESET_GPIO_RESTART=y
> +CONFIG_MFD_RK808=y
> +CONFIG_COMMON_CLK_RK808=m
> +CONFIG_REGULATOR_RK808=m
> +CONFIG_RTC_DRV_RK808=y
> +CONFIG_PHY_ROCKCHIP_DP=m
> +CONFIG_MFD_CROS_EC_SPI=m
> +CONFIG_ROCKCHIP_DW_MIPI_DSI=m
> +CONFIG_DRM_ANALOGIX_DP=m
> +CONFIG_ROCKCHIP_ANALOGIX_DP=m
> +CONFIG_PHY_ROCKCHIP_EMMC=m
> +CONFIG_ROCKCHIP_IODOMAIN=m
> +CONFIG_POWER_AVS=y
> +CONFIG_ROCKCHIP_PM_DOMAINS=y


signature.asc
Description: PGP signature

Bug#837627: [armhf] linux-image-4.7.0-1-armmp: Enable options for Novena

[Vagrant Cascadian]

Package: linux
Version: 4.7.2-1
Severity: wishlist
Tags: patch

Please enable the following options to add support for hardware
present on Novena systems.

Thanks!

live well,
  vagrant

diff --git a/debian/config/armhf/config b/debian/config/armhf/config
index 0a9be6f..d17e003 100644
--- a/debian/config/armhf/config
+++ b/debian/config/armhf/config
@@ -1262,3 +1262,10 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_BACKLIGHT_PWM=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_MFD_STMPE=y
+CONFIG_TOUCHSCREEN_STMPE=m
+CONFIG_SND_SOC_IMX_ES8328=m
+CONFIG_BATTERY_SBS=m
+CONFIG_MMA8452=m


signature.asc
Description: PGP signature

Bug#821027: Additional modules for HiKey support

[Vagrant Cascadian]

On 2016-09-09, Ben Hutchings wrote:
> On Fri, 2016-09-09 at 15:42 -0700, Vagrant Cascadian wrote:
>> Unfortunately, I'm unable to get a serial console with both 4.7 and 4.8
>> (4.6 from jessie-backports gets a serial console, but not much
>> else). After adding "earlycon" to the boot arguments, I get the log
>> below:
> [...]
>> [0.393618] uart-pl011 f7112000.uart: could not find pctldev for node 
>> /soc/pinmux@f701/uart2_pmx_func, deferring probe
>
> So we're missing the pinctrl driver, pinctrl-single.
...
> Since the boot loader will always set up pinmuxing for the console UART
> you could get away without pinctrl-single before this.
>
> Anyway I've now enabled CONFIG_PINCTRL_SINGLE for arm64.

Thanks!

I can confirm that enabling CONFIG_PINCTRL_SINGLE fixed serial console
with v4.8-rc5.


The sad news is all the other drivers still don't seem to work. At
least, no working eMMC/SD or USB... hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#821027: Additional modules for HiKey support

[Vagrant Cascadian]

On 2016-09-02, Martin Michlmayr wrote:
> * Vagrant Cascadian <vagr...@debian.org> [2016-06-04 18:20]:
...
> I enabled these (and some more) options in git, so please try out the
> next upload to experimental.

Thanks!

Unfortunately, I'm unable to get a serial console with both 4.7 and 4.8
(4.6 from jessie-backports gets a serial console, but not much
else). After adding "earlycon" to the boot arguments, I get the log
below:

  Booting a command list

Loading Linux 4.8.0-rc5-arm64 ...
Loading initial ramdisk ...
Loading device tree ...
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.0-rc5-arm64 (debian-kernel@lists.debian.org) 
(gcc version 5.4.1 20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.8~rc5-1~exp1 
(2016-09-07)
[0.00] Boot CPU: AArch64 Processor [410fd033]
[0.00] earlycon: pl11 at MMIO 0xf7113000 (options '115200n8')
[0.00] bootconsole [pl11] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.40 by Linaro HiKey EFI Nov 28 2015 10:50:07
[0.00] efi:
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.0 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: Trusted OS migration not required
[0.00] percpu: Embedded 22 pages/cpu @ffc07fe78000 s49176 r8192 
d32744 u90112
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: enabling workaround for ARM erratum 845719
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 507406
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-rc5-arm64 
root=UUID=ff313567-e9f1-5a5d-9895-3ba130b4a864 ro console=ttyAMA3,115200 
earlycon
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.00] Memory: 1976540K/2062392K available (6204K kernel code, 1034K 
rwdata, 1948K rodata, 3136K init, 613K bss, 85852K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] modules : 0xff80 - 0xff800800   (   128 
MB)
[0.00] vmalloc : 0xff800800 - 0xffbebfff   (   250 
GB)
[0.00]   .text : 0xff800808 - 0xff800869   (  6208 
KB)
[0.00] .rodata : 0xff800869 - 0xff800888   (  1984 
KB)
[0.00]   .init : 0xff800888 - 0xff8008b9   (  3136 
KB)
[0.00]   .data : 0xff8008b9 - 0xff8008c92800   (  1034 
KB)
[0.00].bss : 0xff8008c92800 - 0xff8008d2be3c   (   614 
KB)
[0.00] fixed   : 0xffbefe7fd000 - 0xffbefec0   (  4108 
KB)
[0.00] PCI I/O : 0xffbefee0 - 0xffbeffe0   (16 
MB)
[0.00] vmemmap : 0xffbf - 0xffc0   ( 4 
GB maximum)
[0.00]   0xffbf - 0xffbf0200   (32 
MB actual)
[0.00] memory  : 0xffc0 - 0xffc08000   (  2048 
MB)
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 64.
[0.00]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=8.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=8
[0.00] NR_IRQS:64 nr_irqs:64 0
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arm_arch_timer: Architected cp15 timer(s) running at 1.20MHz 
(phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x11b661f8e, max_idle_ns: 1763180809113 ns
[0.04] sched_clock: 56 bits at 1200kHz, resolution 833ns, wraps every 
4398046510838ns
[0.008440] clocksource: arm,sp804: mask: 0x max_cycles: 0x, 
max_idle_ns: 99544814920 ns
[0.018019] sched_clock: 32 bits at 19MHz, resolution 52ns, wraps every 
111848106981ns
[0.026546] Console: colour dummy device 80x25
[0.031054] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 2.40 BogoMIPS (lpj=4800)
[0.041256] pid_max: default: 32768 minimum: 301
[0.046053] Security Framework initialized
[0.050196] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.056897] AppArmor: AppArmor disabled by boot time parameter
[0.062834] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[0.069609] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[0.077420] ftrace: allocating 22279 entries in 88 pages
[0.117166] ASID allocator initialised with 65536 entries
[0.12450

Bug#837110: linux: armhf: nic-modules: FTBFS: dwmac-socfpga module renamed to dwmac-altr-socfpga

[Vagrant Cascadian]

Package: linux
Version: 4.8~rc5-1~exp1
Severity: grave
Tags: patch
Justification: renders package unusable

It appears the dwmac-socfpga module was renamed to dwmac-altr-socfpga
in 4.8.x, in commit:

  commit fb3bbdb859891e6bc27fd1afb3a07319f82c2ee4
  Author: Tien Hock Loh 
  Date:   Thu Jul 7 20:23:30 2016 -0700

net: ethernet: Add TSE PCS support to dwmac-socfpga


I haven't tested if there are other module renames that would also
lead to a FTBFS.


diff --git a/debian/installer/armhf/modules/armhf-armmp/nic-modules 
b/debian/installer/armhf/modules/armhf-armmp/nic-modules
index e3d0df7..75a4eb9 100644
--- a/debian/installer/armhf/modules/armhf-armmp/nic-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/nic-modules
@@ -5,7 +5,7 @@ smsc911x
 stmmac
 stmmac-platform
 dwmac-generic
-dwmac-socfpga
+dwmac-altr-socfpga
 dwmac-sunxi
 sun4i-emac
 xgmac


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#711470: ath9k_htc updated firmware for firmware-linux-free

[Vagrant Cascadian]

It seems like the biggest blocker is that building ath9k_htc requires
building an entire (cross)toolchain.

There is an open issue about getting ath9k_htc firmware into Debian at:

  https://github.com/qca/open-ath9k-htc-firmware/issues/90

These issues are also mentioned in an RFP for ath9k-htc-firmware:

  https://bugs.debian.org/751339


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#836251: linux: [armhf] Please enable support for veyron-speedy

[Vagrant Cascadian]

Package: linux
Severity: wishlist
Tags: patch

Please enable support for veyron-speedy (a.k.a. ASUS Chromebook C201)
to linux 4.8.x.

It detects all four cores and 4GB of ram.  Tested working HDMI, LCD
panel, touchpad (w/ some multitouch), keyboard, microSD, cpufreq,
battery and charger. All in all, a fairly complete ARM system!

eMMC may need a small fix/workaround to work reliably, submitted
upstream:

  http://www.spinics.net/lists/devicetree/msg140632.html

Haven't had success getting output form the speakers or headphone
jack, though the OS seems to detect at least one device.

The wifi requires non-free firmware-brcm80211, though I haven't had much
luck with it. USB ethernet and USB wifi adapters work, though.

Thanks!


live well,
  vagrant


diff --git a/debian/config/armhf/config b/debian/config/armhf/config
index 0a9be6f..4fc638c 100644
--- a/debian/config/armhf/config
+++ b/debian/config/armhf/config
@@ -1262,3 +1263,28 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_BATTERY_SBS=m
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_BACKLIGHT_PWM=m
+CONFIG_CHARGER_GPIO=m
+CONFIG_MFD_CROS_EC=m
+CONFIG_I2C_CROS_EC_TUNNEL=m
+CONFIG_MOUSE_ELAN_I2C=m
+CONFIG_KEYBOARD_CROS_EC=m
+CONFIG_KEYBOARD_GPIO=m
+CONFIG_POWER_RESET_GPIO=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
+CONFIG_MFD_RK808=y
+CONFIG_COMMON_CLK_RK808=m
+CONFIG_REGULATOR_RK808=m
+CONFIG_RTC_DRV_RK808=y
+CONFIG_PHY_ROCKCHIP_DP=m
+CONFIG_MFD_CROS_EC_SPI=m
+CONFIG_ROCKCHIP_DW_MIPI_DSI=m
+CONFIG_DRM_ANALOGIX_DP=m
+CONFIG_ROCKCHIP_ANALOGIX_DP=m
+CONFIG_PHY_ROCKCHIP_EMMC=m
+CONFIG_ROCKCHIP_IODOMAIN=m
+CONFIG_POWER_AVS=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y


signature.asc
Description: PGP signature

Bug#836231: linux: [armhf] Please enable B53 mdio switch driver

[Vagrant Cascadian]

Source: linux
Severity: wishlist
Tags: patch

Please enable the B53 mdio switch driver modules introduced in linux
4.8.x, which is used on the Lamobo-R1 (a.k.a. BPI-R1, Bananpi-R1).

live well,
  vagrant

diff --git a/debian/config/armhf/config b/debian/config/armhf/config
index 0a9be6f..18d2f74 100644
--- a/debian/config/armhf/config
+++ b/debian/config/armhf/config
@@ -1262,3 +1262,5 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_B53=m
+CONFIG_B53_MDIO_DRIVER=m


signature.asc
Description: PGP signature

Bug#835893: linux-image-4.7.0-rc7-armmp: Please add support for OpenPandora

[Vagrant Cascadian]

Package: linux-image-4.7.0-rc7-armmp
Version: 4.7~rc7-1~exp1
Severity: wishlist
Tags: patch

Please enable the following options in the armhf kernel configuration,
to enable support for the OpenPandora console. It's still a little
rough around the edges but MMC, NAND, serial console, cpufreq, LCD
panel and touchscreen works. Keyboard mostly works, although the
function keys aren't recognized.

Thanks for considering!

live well,
  vagrant

p.s. If applying to v4.8.x, be sure to adjust CONFIG_DISPLAY_* to
CONFIG_DRM_OMAP_*.

diff --git a/debian/config/armhf/config b/debian/config/armhf/config
index 88aa489..3ef7a95 100644
--- a/debian/config/armhf/config
+++ b/debian/config/armhf/config
@@ -1259,3 +1259,17 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_DISPLAY_CONNECTOR_ANALOG_TV=m
+CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1=m
+CONFIG_OMAP2_DSS_DSI=y
+CONFIG_DRM_OMAP_NUM_CRTCS=2
+CONFIG_BACKLIGHT_PANDORA=m
+CONFIG_VIDEO_OMAP3=m
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+CONFIG_CHARGER_TWL4030=m
+CONFIG_BATTERY_TWL4030_MADC=m
+CONFIG_SENSORS_TWL4030_MADC=m
+CONFIG_HDQ_MASTER_OMAP=m
+CONFIG_POWER_AVS_OMAP=y
+CONFIG_POWER_AVS_OMAP_CLASS3=y
+CONFIG_POWER_AVS=y


signature.asc
Description: PGP signature

Bug#825139: linux-image-4.5.0-2-armmp: Please support Odroid-U3 (Exynos4)

[Vagrant Cascadian]

On 2016-05-28, Roger Shimizu wrote:
>> +## drivers/mfd/Kconfig
>> +CONFIG_MFD_MAX77686=m
>> +
>> +## drivers/regulator/Kconfig
>> +CONFIG_REGULATOR_MAX77686=m
>> +
>> +## drivers/rtc/Kconfig
>> +CONFIG_RTC_DRV_MAX77686=m
>> +
>> +## drivers/mmc/host/Kconfig
>> +CONFIG_MMC_SDHCI_S3C=m
>
> Thanks!
> Applied your patch to sid branch, and with my slight modification.

Great, thanks!


> Just one question / doubt:
> all other RTC around RTC_DRV_MAX77686 are built-in, maybe we should
> also make RTC_DRV_MAX77686 as built-in?

Sounds good to me; I think you'll also need CONFIG_MFD_MAX77686=y as
well, as the RTC depends on it.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#825139: linux-image-4.5.0-2-armmp: Please support Odroid-U3 (Exynos4)

[Vagrant Cascadian]

Package: src:linux
Version: 4.5.4-1
Severity: wishlist
Tags: patch

Please enable the following options in the armmp kernel configuration,
which enables support for Exynos4, tested on Odroid-U3.

It detects all four CPUs, 2GB of ram, ethernet, and supports USB on
both 4.5.x and 4.6.x. It also supports microSD, and 4.6.x worked fine,
but 4.5.x had some outstanding issues that prevented it from working
correctly.  I did not test video or audio output, though modules for
video output did appear to load.

Thanks!

live well,
  vagrant

diff --git a/debian/config/armhf/config.armmp b/debian/config/armhf/config.armmp
index cef254e..a9eaf2a 100644
--- a/debian/config/armhf/config.armmp
+++ b/debian/config/armhf/config.armmp
@@ -46,7 +46,7 @@ CONFIG_ARCH_BCM2835=y
 ##
 CONFIG_ARCH_EXYNOS=y
 # CONFIG_ARCH_EXYNOS3 is not set
-# CONFIG_ARCH_EXYNOS4 is not set
+CONFIG_ARCH_EXYNOS4=y
 CONFIG_ARCH_EXYNOS5=y
 CONFIG_EXYNOS5420_MCPM=y

@@ -1223,3 +1223,18 @@ CONFIG_SND_SUN4I_CODEC=m
 ##
 CONFIG_SND_SOC_TEGRA=m

+
+## drivers/clk/Kconfig
+CONFIG_COMMON_CLK_MAX77686=m
+
+## drivers/mfd/Kconfig
+CONFIG_MFD_MAX77686=m
+
+## drivers/regulator/Kconfig
+CONFIG_REGULATOR_MAX77686=m
+
+## drivers/rtc/Kconfig
+CONFIG_RTC_DRV_MAX77686=m
+
+## drivers/mmc/host/Kconfig
+CONFIG_MMC_SDHCI_S3C=m


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
Hardware: SAMSUNG EXYNOS (Flattened Device Tree)
Revision: 
Device Tree model: Hardkernel ODROID-U3 board based on Exynos4412

** PCI devices:
not available

** USB devices:
Bus 001 Device 004: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s 
bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
Bus 001 Device 003: ID 0424:3503 Standard Microsystems Corp. 
Bus 001 Device 002: ID 0424:9730 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.6.0-trunk-armmp (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.5.0-2-armmp depends on:
ii  debconf [debconf-2.0]   1.5.59
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod22-1.1
ii  linux-base  4.0

Versions of packages linux-image-4.5.0-2-armmp recommends:
pn  firmware-linux-free  
pn  irqbalance   

Versions of packages linux-image-4.5.0-2-armmp suggests:
pn  debian-kernel-handbook  
pn  fdutils 
pn  linux-doc-4.5   

Versions of packages linux-image-4.5.0-2-armmp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- debconf information:
  linux-image-4.5.0-2-armmp/prerm/removing-running-kernel-4.5.0-2-armmp: true


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

On 2016-05-02, Vagrant Cascadian wrote:
> On 2016-05-02, Ben Hutchings wrote:
>> On Sun, 2016-05-01 at 18:20 -0700, Vagrant Cascadian wrote:
>>> On 2016-04-28, Ben Hutchings wrote:
>>> > Could you test with turbo_mode re-enabled and with this patch applied?
>>> > 
>>> > Also could you test network receive throughput (e.g. with netperf -t
>>> > TCP_STREAM, sending *to* the RPi) in these three different
>>> > configurations:
>>> Ok, if I understood you correctly...
>>> 
>>> Installed netperf on another machine, and ran:
>>> 
>>>   netperf -t TCP_STREAM 10.0.0.50
>>
>> That is not correct syntax; you need to put a -H before the IP address.
>
> Ok. Never used netperf before... will try again!

Ok, this time with:

  netperf -l 60 -t TCP_STREAM -H 10.0.0.50

4.5.2-1, with turbo disabled:
  
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 ()
  port 0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638460.04  93.95
  
4.5.2-1, with turbo enabled:
  
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 ()
  port 0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638460.03  94.15
  
  
4.5.2, patched with turbo enabled:
  
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 ()
  port 0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638460.04  94.15


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

On 2016-05-02, Ben Hutchings wrote:
> On Sun, 2016-05-01 at 18:20 -0700, Vagrant Cascadian wrote:
>> On 2016-04-28, Ben Hutchings wrote:
>> > Could you test with turbo_mode re-enabled and with this patch applied?
>> > 
>> > Also could you test network receive throughput (e.g. with netperf -t
>> > TCP_STREAM, sending *to* the RPi) in these three different
>> > configurations:
>> Ok, if I understood you correctly...
>> 
>> Installed netperf on another machine, and ran:
>> 
>>   netperf -t TCP_STREAM 10.0.0.50
>
> That is not correct syntax; you need to put a -H before the IP address.

Ok. Never used netperf before... will try again!

For what it's worth, the patched driver did still appear to eventually
generate the error logs reported:

  smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

So at best, it reduces the problem, rather than solving it.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

Control: tag 820622 -moreinfo

On 2016-04-28, Ben Hutchings wrote:

> Could you test with turbo_mode re-enabled and with this patch applied?
>
> Also could you test network receive throughput (e.g. with netperf -t
> TCP_STREAM, sending *to* the RPi) in these three different
> configurations:

Ok, if I understood you correctly...

Installed netperf on another machine, and ran:

  netperf -t TCP_STREAM 10.0.0.50

Where 10.0.0.50 is the raspberry pi 2.

Ran netperf twice for each combination, rebooting the raspberry pi 2
between changes in turbo_mode or kernel. Double-checked
/sys/module/smsc95xx/parameters/turbo_mode contained N when booted with
turbo_mode=0, and Y when turbo_mode=1.

To my untrained eye, doesn't look like a significant difference between
any of the modes. None of them triggered the kernel messages that
prompted the bug report.


> 1. turbo_mode=0

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638410.021781.22

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638410.021847.21


> 2. turbo_mode=1, current driver

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.021812.38   
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.021843.34   


> 3. turbo_mode=1, patched driver

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.031822.99   
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.031824.52   


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#821311: linux-image-4.5.0-1-armmp-lpae: ethernet fails to detect carrier on Firefly boards

[Vagrant Cascadian]

Control: notfound 821311 4.6~rc3-1~exp1

On 2016-04-17, Vagrant Cascadian wrote:
> Running the 4.5.x kernel doesn't appear to have working carrier
> detection on ethernet for the Firefly board. Earlier 4.4.x versions of
> the kernel work fine.

Well, at least the 4.6-rc3 kernel from experimental at appears to work
fine...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#821311: linux-image-4.5.0-1-armmp-lpae: ethernet fails to detect carrier on Firefly boards

[Vagrant Cascadian]

Package: src:linux
Version: 4.5.1-1
Severity: important

Running the 4.5.x kernel doesn't appear to have working carrier
detection on ethernet for the Firefly board. Earlier 4.4.x versions of
the kernel work fine.

  ~$ ip address show dev eth0
  2: eth0:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:7b:f3:31:72:8e brd ff:ff:ff:ff:ff:ff
  inet 10.0.0.61/24 brd 10.0.0.255 scope global eth0
 valid_lft forever preferred_lft forever
  ~$ sudo ip link set dev eth0 up
  [  357.403006] libphy: PHY stmmac-0: not found
  [  357.407922] eth0: Could not attach to PHY
  [  357.411980] stmmac_open: Cannot attach to PHY (error: -19)
  RTNETLINK answers: No such device
  ~$ ping 10.0.0.1
  connect: Network is unreachable


live well,
  vagrant


-- Package-specific info:
** Version:
Linux version 4.5.0-1-armmp-lpae (debian-kernel@lists.debian.org) (gcc version 
5.3.1 20160323 (Debian 5.3.1-13) ) #1 SMP Debian 4.5.1-1 (2016-04-14)

** Command line:
console=ttyS2,115200

** Tainted: E (8192)
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[9.020241] rk3x-i2c ff66.i2c: using default SCL frequency: 10
[9.020579] rk3x-i2c ff66.i2c: Initialized RK3xxx I2C bus at f1166000
[9.078823] [drm] Initialized drm 1.1.0 20060810
[9.079820] dwmmc_rockchip ff0c.dwmmc: IDMAC supports 32-bit address 
mode.
[9.079868] dwmmc_rockchip ff0c.dwmmc: Using internal DMA controller.
[9.079881] dwmmc_rockchip ff0c.dwmmc: Version ID is 270a
[9.079913] dwmmc_rockchip ff0c.dwmmc: DW MMC controller at irq 29,32 
bit host data width,256 deep fifo
[9.081306] dwmmc_rockchip ff0d.dwmmc: IDMAC supports 32-bit address 
mode.
[9.081369] dwmmc_rockchip ff0d.dwmmc: Using internal DMA controller.
[9.081384] dwmmc_rockchip ff0d.dwmmc: Version ID is 270a
[9.081415] dwmmc_rockchip ff0d.dwmmc: DW MMC controller at irq 30,32 
bit host data width,256 deep fifo
[9.081570] dwmmc_rockchip ff0d.dwmmc: Failed getting OCR mask: 0
[9.082349] rockchip-saradc ff10.saradc: failed to get regulator, -517
[9.083487] dwmmc_rockchip ff0f.dwmmc: IDMAC supports 32-bit address 
mode.
[9.083561] dwmmc_rockchip ff0f.dwmmc: Using internal DMA controller.
[9.083581] dwmmc_rockchip ff0f.dwmmc: Version ID is 270a
[9.083610] dwmmc_rockchip ff0f.dwmmc: DW MMC controller at irq 31,32 
bit host data width,256 deep fifo
[9.086176] rk_gmac-dwmac ff29.ethernet: phy regulator is not available 
yet, deferred probing
[9.090813] Registered IR keymap rc-empty
[9.091261] input: gpio_ir_recv as 
/devices/platform/ir-receiver/rc/rc0/input1
[9.105208] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[9.140854] dwmmc_rockchip ff0c.dwmmc: IDMAC supports 32-bit address 
mode.
[9.140905] dwmmc_rockchip ff0c.dwmmc: Using internal DMA controller.
[9.140919] dwmmc_rockchip ff0c.dwmmc: Version ID is 270a
[9.140952] dwmmc_rockchip ff0c.dwmmc: DW MMC controller at irq 29,32 
bit host data width,256 deep fifo
[9.142571] dwmmc_rockchip ff0d.dwmmc: IDMAC supports 32-bit address 
mode.
[9.142624] dwmmc_rockchip ff0d.dwmmc: Using internal DMA controller.
[9.142637] dwmmc_rockchip ff0d.dwmmc: Version ID is 270a
[9.142713] dwmmc_rockchip ff0d.dwmmc: DW MMC controller at irq 30,32 
bit host data width,256 deep fifo
[9.142878] dwmmc_rockchip ff0d.dwmmc: Failed getting OCR mask: 0
[9.143909] rockchip-saradc ff10.saradc: failed to get regulator, -517
[9.144965] dwmmc_rockchip ff0f.dwmmc: IDMAC supports 32-bit address 
mode.
[9.145033] dwmmc_rockchip ff0f.dwmmc: Using internal DMA controller.
[9.145047] dwmmc_rockchip ff0f.dwmmc: Version ID is 270a
[9.145074] dwmmc_rockchip ff0f.dwmmc: DW MMC controller at irq 31,32 
bit host data width,256 deep fifo
[9.147603] rk_gmac-dwmac ff29.ethernet: phy regulator is not available 
yet, deferred probing
[9.150131] lirc_dev: IR Remote Control driver registered, major 243 
[9.202015] dwmmc_rockchip ff0c.dwmmc: IDMAC supports 32-bit address 
mode.
[9.202068] dwmmc_rockchip ff0c.dwmmc: Using internal DMA controller.
[9.202082] dwmmc_rockchip ff0c.dwmmc: Version ID is 270a
[9.202115] dwmmc_rockchip ff0c.dwmmc: DW MMC controller at irq 29,32 
bit host data width,256 deep fifo
[9.202239] vcc_io: supplied by vcc_sys
[9.202458] vcc_sd: supplied by vcc_io
[9.202818] vccio_sd: supplied by vcc_sys
[9.322714] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, 
actual 40HZ div = 0)
[9.338775] dwmmc_rockchip ff0c.dwmmc: 1 slots initialized
[9.340008] dwmmc_rockchip ff0d.dwmmc: IDMAC supports 32-bit address 
mode.
[9.340069] dwmmc_rockchip ff0d.dwmmc: Using internal DMA controller.
[9.340082] dwmmc_rockchip ff0d.dwmmc: Version ID 

Bug#812540: [arm64] Additional modules for HiKey support

[Vagrant Cascadian]

Control: clone 812540 -1
Control: retitle -1 [arm64] Additional modules for HiKey support
Control: severity -1 wishlist

On 2016-04-10, Vagrant Cascadian wrote:
> I was able to get it to boot with both 4.4 and 4.5 to an initramfs
> prompt and a serial console, but MMC support still needs to be enabled
> in the device-tree, along with USB, wireless, and just about anything
> else you might actually want to use. :)

I'm not sure what the policy on enabling modules for boards that don't
yet have the corresponding device-tree entries, but it would be nice to
have all of the modules mentioned below enabled, so that when
device-tree support is available for HiKey (or other boards) upstream,
the debian kernel packages will "just work". It also makes it easier to
use a user-supplied device-tree without having to recompile the kernel.


> For wireless it needs additional drivers enabled in the kernel:
...
>   # on 4.5+
>   CONFIG_WLAN_VENDOR_TI=y
>
>   CONFIG_WL18XX=m
>
> Still need these drivers enabled in 4.5.x:
>
>   CONFIG_COMMON_RESET_HI6220=m
>   CONFIG_PHY_HI6220_USB=m
>
> And when the time comes, these in 4.6+:
>
>   CONFIG_HI6220_MBOX=m
>
>   # while this is present in mainline, it seems to depend on
>   # MFD_HI655X_PMIC which isn't yet present... so hrm.
>   CONFIG_REGULATOR_HI655X=m


Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

On 2016-04-10, Vagrant Cascadian wrote:
> On 2016-04-10, Ben Hutchings wrote:
>> On Sun, 2016-04-10 at 22:49 +0200, Diederik de Haas wrote:
>>> At https://plugwash.raspbian.org/linux_3.18/ you can find the things for 
>>> the 
>>> latest raspbian.org kernel.
>>
>> Thanks.  That has a patch to turn off the turbo_mode module parameter
>> by default.
>>
>> Vagrant, could you try putting "options smsc95xx turbo_mode=N" in
>> /etc/modprobe.d/smsc95xx.conf ?
>
> Added to one of the two machines, updated the initramfs (just in case
> the module gets loaded in initramfs), and rebooted ... will see if that
> works.
>
> The other option I was pointed to was to update to the latest boot
> firmware, though I haven't tried that yet:

New boot firmware didn't help. Configuring the module to not use
turbo_mode did.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820834: linux: [armhf] Please enable watchdog timer module for Firefly-RK3288

[Vagrant Cascadian]

Source: linux
Version: 4.5-1~exp1
Severity: wishlist
Tags: patch

Please enable the designware watchdog timer module, used on the
Firefly-RK3288.

Tested on 4.5, but is also available in 4.4.x and would be nice to
have there too.

diff --git a/debian/config/armhf/config.armmp b/debian/config/armhf/config.armmp
index 996eeff..d7dbe99 100644
--- a/debian/config/armhf/config.armmp
+++ b/debian/config/armhf/config.armmp
@@ -1086,6 +1086,7 @@ CONFIG_TWL4030_WATCHDOG=m
 CONFIG_IMX2_WDT=m
 CONFIG_TEGRA_WATCHDOG=m
 CONFIG_BCM2835_WDT=m
+CONFIG_DW_WATCHDOG=m
 
 ##
 ## file: kernel/power/Kconfig


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

On 2016-04-10, Vagrant Cascadian wrote:
> On 2016-04-10, Ben Hutchings wrote:

>> Vagrant, could you try putting "options smsc95xx turbo_mode=N" in
>> /etc/modprobe.d/smsc95xx.conf ?
>
> Added to one of the two machines, updated the initramfs (just in case
> the module gets loaded in initramfs), and rebooted ... will see if that
> works.

Haven't seen any messages since adding those module options, so that's
at least a viable workaround.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

On 2016-04-10, Ben Hutchings wrote:
> On Sun, 2016-04-10 at 22:49 +0200, Diederik de Haas wrote:
>> At https://plugwash.raspbian.org/linux_3.18/ you can find the things for the 
>> latest raspbian.org kernel.
>
> Thanks.  That has a patch to turn off the turbo_mode module parameter
> by default.
>
> Vagrant, could you try putting "options smsc95xx turbo_mode=N" in
> /etc/modprobe.d/smsc95xx.conf ?

Added to one of the two machines, updated the initramfs (just in case
the module gets loaded in initramfs), and rebooted ... will see if that
works.

The other option I was pointed to was to update to the latest boot
firmware, though I haven't tried that yet:

  https://wiki.gentoo.org/wiki/Raspberry_Pi#Troubleshooting

  Troubleshooting

Problem: dmesg is full of smsc95xx 1-1.1:1.0: eth0: kevent 2 may
have been dropped and/or page allocation failure messages:
Solution: Try to update all firmware files in /boot,
especially fixup.dat.
Solution: If the former fails, add smsc95xx.turbo_mode=N to
kernel parameters, or vm.min_free_kbytes=4096 to /etc/sysctl.conf


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#812540: Add ARCH_HISI for Lemaker HiKey support

[Vagrant Cascadian]

On 2016-03-13, Ian Campbell wrote:
> That makes sense, thanks for the info. Since MMC + serial in 4.4 is a
> basically useful thing (and I'm hoping the WiFi is some preexisting
> driver too) this seemed like a useful set of stuff to enable. So I have
> done so in git.

Thanks for enabling it!

I was able to get it to boot with both 4.4 and 4.5 to an initramfs
prompt and a serial console, but MMC support still needs to be enabled
in the device-tree, along with USB, wireless, and just about anything
else you might actually want to use. :)

For wireless it needs additional drivers enabled in the kernel:

  # on 4.4.x
  CONFIG_WL_TI=y
  # on 4.5+
  CONFIG_WLAN_VENDOR_TI=y

  CONFIG_WL18XX=m

Still need these drivers enabled in 4.5.x:

  CONFIG_COMMON_RESET_HI6220=m
  CONFIG_PHY_HI6220_USB=m

And when the time comes, these in 4.6+:

  CONFIG_HI6220_MBOX=m

  # while this is present in mainline, it seems to depend on
  # MFD_HI655X_PMIC which isn't yet present... so hrm.
  CONFIG_REGULATOR_HI655X=m


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

On 2016-04-10, Ben Hutchings wrote:
> On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> Thanks for enabling support for raspberry pi 2!
>
> Thanks for confirming it works, because I was working without any
> access to hardware.

For what it's worth, I've not been able to get the 4.4.x kernels from
Debian to even show console output with an otherwise identical setup. So
there must be something missing from the backported rpi patchset.


> I see you've updated flash-kernel to support it as
> well.

Yeah, I tested it with the u-boot-rpi package.


>> It works for the most part, but floods syslog with messages:
>> 
>> [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> 
>> It seems to function ok, though I'm not sure if there's degraded
>> network performance...
> [...]
>
> I understand network performance on all RPi models is poor due to lack
> of a built-in Ethernet MAC and the poor design of the USB interface.
> Also that message is a generic error message from the usbnet core and
> is not specific to the smsc95xx driver.
>
> Were you using the network heavily, or do these messages appear
> regardless of the level of network traffic?

They have pretty steady network traffic. I haven't monitored network
traffic with enough granularity to really correlate if the messages
occur at the same time as peak network usage, though.

vnstat --hours output:

 eth0 19:58 
  ^ r   
  | r   
  | r   
  | r   
  | rrr 
  |  r  r  r rr 
  |  r  r t r  r r   r  r r 
  |  r  r t r  r r   r  r  r  r 
  |  r  r  r rt r   r  r r r r  r  r  r 
  |  r  r  r rt r   r  r   tr  r r  r  r  rt r  r  r  r 
 -+---> 
  |  20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

 h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB) 
20337,957 35,64904 53,478 17,62812252,402  3,730
21248,322  4,69005107,901  3,20213 67,155 18,629
22119,047 32,82706105,470  5,66914170,309  2,387
23 39,099  4,73607 50,548 68,11015 66,700 81,917
00172,232258,62608 50,122  3,18816397,451 11,037
01574,549 10,33709166,691  2,46017246,196 15,701
02 14,133  1,08810337,027  6,79818215,436 15,847
03312  2,16711  9,29362519366,292  8,472

And syslogs of the messages:

Apr 10 08:33:35 rpi2b kernel: [467762.422149] net_ratelimit: 3837 callbacks 
suppressed
Apr 10 08:33:35 rpi2b kernel: [467762.427247] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 08:33:42 rpi2b kernel: [467769.491572] net_ratelimit: 5501 callbacks 
suppressed
Apr 10 08:33:42 rpi2b kernel: [467769.496651] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 09:01:45 rpi2b kernel: [469453.280337] net_ratelimit: 996 callbacks 
suppressed
Apr 10 09:01:45 rpi2b kernel: [469453.285330] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 09:09:53 rpi2b kernel: [469940.843408] net_ratelimit: 11182 callbacks 
suppressed
Apr 10 09:09:53 rpi2b kernel: [469940.848708] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 09:11:13 rpi2b kernel: [470020.740828] net_ratelimit: 4669 callbacks 
suppressed
Apr 10 09:11:13 rpi2b kernel: [470020.745911] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 09:28:45 rpi2b kernel: [471072.895953] net_ratelimit: 2945 callbacks 
suppressed
Apr 10 09:28:45 rpi2b kernel: [471072.901033] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 09:50:03 rpi2b kernel: [472350.602289] net_ratelimit: 157500 callbacks 
suppressed
Apr 10 09:50:03 rpi2b kernel: [472350.607546] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may have been dropped
--
Apr 10 09:50:08 rpi2b kernel: [472356.167786] net_ratelimit: 6353 callbacks 
suppressed
Apr 10 09:50:08 rpi2b kernel: [472356.172989] smsc95xx 1-1.1:1.0 eth0: kevent 2 
may 

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Vagrant Cascadian]

Package: src:linux
Version: 4.5-1~exp1
Severity: normal

Thanks for enabling support for raspberry pi 2!

It works for the most part, but floods syslog with messages:

[501966.870273] net_ratelimit: 35702 callbacks suppressed
[501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

It seems to function ok, though I'm not sure if there's degraded
network performance...

Not sure if the version of the boot firmware and/or u-boot would likely
impact this, or running stretch/sid vs. jessie.

I also experience this on a second rpi2, similarly configured.


live well,
  vagrant


-- Package-specific info:
** Version:
Linux version 4.5.0-trunk-armmp-lpae (debian-kernel@lists.debian.org) (gcc 
version 5.3.1 20160316 (Debian 5.3.1-12) ) #1 SMP Debian 4.5-1~exp1 (2016-03-20)

** Command line:
root=/dev/mapper/rpi2b-root console=ttyAMA0,115200

** Not tainted

** Kernel log:
[496926.383178] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.390069] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.397026] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.405843] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.412441] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.419085] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.425923] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.433675] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.440371] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496926.447153] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496931.412674] net_ratelimit: 6206 callbacks suppressed
[496931.417762] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.093933] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.108465] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.164059] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.208265] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.226975] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.246691] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.265630] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.287754] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[496932.294860] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.490001] net_ratelimit: 285 callbacks suppressed
[497554.495003] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.501775] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.510097] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.516646] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.523284] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.531653] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.538317] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.545981] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.554849] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[497554.561473] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498179.500059] net_ratelimit: 5196 callbacks suppressed
[498179.505139] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498190.972627] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498192.138691] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.264114] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.270634] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.278020] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.284598] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.291305] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.298322] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.305610] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498193.312196] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498667.628700] net_ratelimit: 6384 callbacks suppressed
[498667.633789] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.372264] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.379072] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.385927] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.392619] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.399375] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.406110] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.412718] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.419497] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.426310] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[498741.433143] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
[501393.624239] net_ratelimit: 2507 callbacks suppressed
[501393.629322] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

Bug#819390: linux-image-4.5.0-trunk-armmp-lpae: Ethernet on Firefly-RK3288

[Vagrant Cascadian]

Package: src:linux
Version: 4.5-1~exp1
Severity: normal

When upgrading to linux 4.5-1~exp1, the ethernet no longer responds
correctly.  Downgrading back to 4.4.6-1 from sid/stretch fixes the issue.

I see these messages in syslog:

Mar 27 21:25:37 ff2a systemd[1]: Reached target System Time Synchronized.
Mar 27 21:25:37 ff2a networking[311]: Configuring network interfaces...[ERROR] 
Could not read permanent MAC: Device or resource busy
Mar 27 21:25:37 ff2a networking[311]: Current MAC:   00:00:00:00:00:00 (XEROX 
CORPORATION)
Mar 27 21:25:37 ff2a networking[311]: Permanent MAC: 00:00:00:00:00:00 (XEROX 
CORPORATION)
Mar 27 21:25:37 ff2a networking[311]: New MAC:   4e:e3:67:92:21:0e (unknown)
Mar 27 21:25:37 ff2a networking[311]: RTNETLINK answers: No such device
Mar 27 21:25:37 ff2a networking[311]: Failed to bring up eth0.
Mar 27 21:25:37 ff2a networking[311]: done.
Mar 27 21:25:37 ff2a systemd[1]: Started LSB: Raise network interfaces..
Mar 27 21:25:37 ff2a systemd[1]: Starting Network.
--
Mar 27 21:25:37 ff2a kernel: [   10.182806]  mmcblk1: p1 p2
Mar 27 21:25:37 ff2a kernel: [   10.552168] Adding 5242876k swap on 
/dev/mapper/ff2a-swap.  Priority:-1 extents:1 across:5242876k FS
Mar 27 21:25:37 ff2a kernel: [   10.705565] EXT4-fs (dm-2): mounted filesystem 
with ordered data mode. Opts: (null)
Mar 27 21:25:37 ff2a atd[494]: File a1017285b2 is in wrong format - aborting
Mar 27 21:25:37 ff2a kernel: [   11.637423] EXT4-fs (mmcblk1p2): mounted 
filesystem with ordered data mode. Opts: (null)
Mar 27 21:25:37 ff2a kernel: [   12.169292] libphy: PHY stmmac-0: not 
found
Mar 27 21:25:37 ff2a kernel: [   12.174209] eth0: Could not attach to PHY
Mar 27 21:25:37 ff2a kernel: [   12.178246] stmmac_open: Cannot attach to PHY 
(error: -19)
Mar 27 21:25:37 ff2a systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Mar 27 21:25:37 ff2a kernel: [   13.051128] ip6_tables: (C) 2000-2006 Netfilter 
Core Team

Full syslog from boot attached.

live well,
  vagrant


-- Package-specific info:
** Kernel log: syslog attached

** Model information
Hardware: Rockchip (Device Tree)
Revision: 
Device Tree model: Firefly-RK3288

** PCI devices:

** USB devices:
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 152d:1561 JMicron Technology Corp. / JMicron USA 
Technology Corp. 
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental'), 
(1, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.0-1-armmp-lpae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.5.0-trunk-armmp-lpae depends on:
ii  debconf [debconf-2.0]   1.5.56
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod18-3
ii  linux-base  3.5

Versions of packages linux-image-4.5.0-trunk-armmp-lpae recommends:
ii  firmware-linux-free  3.3
ii  irqbalance   1.0.6-3

Versions of packages linux-image-4.5.0-trunk-armmp-lpae suggests:
pn  debian-kernel-handbook  
pn  fdutils 
pn  linux-doc-4.5   

Versions of packages linux-image-4.5.0-trunk-armmp-lpae is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
pn  firmware-iwlwifi
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
pn  firmware-ralink 
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  
linux-image-4.5.0-trunk-armmp-lpae/prerm/removing-running-kernel-4.5.0-trunk-armmp-lpae:
 true



syslog-4.5.0-trunk-armmp.lpae.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#819379: linux: arrmp-lpae: Please support octa-core systems.

[Vagrant Cascadian]

Source: linux
Version: 4.5-1~exp1
Severity: wishlist
Tags: patch

Tested the following patch on an Odroid-XU4 to enable all 8 CPU cores.

The options are also available on 4.4.x, but I haven't tested with
that version.

diff --git a/debian/config/armhf/config.lpae b/debian/config/armhf/config.lpae
index d5045f1..3dd94f1 100644
--- a/debian/config/armhf/config.lpae
+++ b/debian/config/armhf/config.lpae
@@ -19,3 +19,6 @@ CONFIG_ARM_LPAE=y
 ##
 CONFIG_ARM_SMMU=y
 
+CONFIG_NR_CPUS=8
+CONFIG_EXYNOS5420_MCPM=y
+CONFIG_MCPM=y
-- 
2.1.4


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#819377: linux: Please enable watchdog timer module for Odroid-XU4.

[Vagrant Cascadian]

Source: linux
Version: 4.5-1~exp1
Severity: wishlist
Tags: patch

Please enable the watchdog timer used on Odroid-XU4 systems, and
possibly others. Tested the following patch on an Odroid-XU4.

The module is also available in 4.4.x, although I haven't tested it.

diff --git a/debian/config/armhf/config.armmp b/debian/config/armhf/config.armmp
index 996eeff..6429453 100644
--- a/debian/config/armhf/config.armmp
+++ b/debian/config/armhf/config.armmp
@@ -1086,6 +1086,7 @@ CONFIG_TWL4030_WATCHDOG=m
 CONFIG_IMX2_WDT=m
 CONFIG_TEGRA_WATCHDOG=m
 CONFIG_BCM2835_WDT=m
+CONFIG_S3C2410_WATCHDOG=m
 
 ##
 ## file: kernel/power/Kconfig
-- 
2.1.4


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1

[Vagrant Cascadian]

On 2016-03-14, Ian Campbell wrote:
> On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
>> On 2016-02-06, Heinrich Schuchardt wrote:
>> > Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
>> > linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
>> > leaving me with a system that will not boot.
>> >
>> > With imx6q-wandboard-revb1.dtb the system boots.
...
>> When the revc was added, backwards compatibility was broken by renaming
>> the revb .dtb file instead of keeping it and introducing the revc in a
>> new .dtb... kind of hard to fix correctly now...

>> Adding support for flash-kernel to copy multiple, or even optionally all
>> .dtb files could at least work around the issue.

> flash-kernel's DTB entry can reference a script to run which prints the
> DTB filename to use, so if you can distinguish the variants by poking
> at /sys etc (e.g the current sole user is kirkwood-qnap which looks at
> properties of the PCI host bridge etc) then that might be an option?

I still think it would be better to copy multiple .dtb files, to make
sure all variants are available. This also makes it possible to use the
same SD card image on multiple wandboards.


> Were any of these boards supported in Jessie?

In Jessie, they both work using the same .dtb provided by linux 3.16.x,
although installing 4.x from jessie-backports on a wandboard rev B might
cause issues.


> If so then making upgrade work smoothly would be nice, but if not then
> this might just be a case of Testing/Unstable users having
> occasionally to manually fix things, but once this is done and the
> correct DTB is in use flash-kernel should form then on DTRT and
> Stretch will just work for fresh installs.

Upgrading u-boot is the tricky part, as we don't currently automatically
upgrade u-boot(and it's a bit tricky to do so). Depending on which
u-boot version is installed, u-boot will set fdtfile to a value that may
not be correct depending on which combination of linux + flash-kernel +
board variant is being booted.

I think this can partially be worked around by updating the wandboard
bootscript to have fallbacks to /boot/dtb-$ver (like the u-boot-generic
bootscript). Then the user can set the appropriate .dtb in
/etc/flash-kernel/db.

Though I still think it makes sense to support multiple .dtb files for a
platform, and optionally install all .dtbs. I'd take another stab at
coding one or both of those.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#812540: Add ARCH_HISI for Lemaker HiKey support

[Vagrant Cascadian]

On 2016-03-12, Ian Campbell wrote:
> On Fri, 2016-03-11 at 20:03 -0800, Vagrant Cascadian wrote:
>> On 2016-03-10, Martin Michlmayr wrote:
>> > * Ian Campbell <i...@debian.org> [2016-01-25 09:57]:
>> Most drivers aren't even available in 4.4.x, and some aren't even in
>> 4.5.x yet. From a breif glance, the dts files for
>> arch/arm64/boot/dts/hisilicon/hi6220*, don't look to contain support
>> for
>> much more than the CPU, memory and serial...
>> 
>> 
>> > This might be a good starting point:
>> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg109864
>> 4.html
>> 
>> Reading that patch, I'm guessing the following are available and
>> possibly needed or desired, though possibly may require device-tree
>> patches as well:
>> 
>> available in 4.4.x:
>> 
>> CONFIG_ARCH_HISI=y
>> CONFIG_POWER_RESET_HISI=y
>> CONFIG_HISI_THERMAL=m
>> CONFIG_MMC_DW=m
>> CONFIG_MMC_DW_K3=m
>> CONFIG_I2C_DESIGNWARE_PLATFORM=m
>> 
>> available in 4.5.x:
>> 
>> CONFIG_COMMON_RESET_HI6220=m
>> CONFIG_PHY_HI6220_USB=m
>> 
>> linux-next tag next-20160311:
>> 
>> CONFIG_HI6220_MBOX=m
>> CONFIG_REGULATOR_HI655X=m
>> 
>> 
>> Will build a few test kernels and report back...
>
> Thanks, for things other than the ones listed above the ones I'd be
> most curious about would be serial and networking (wifi only on this
> platform IIRC). Both of those could possibly be supported already via
> existing generic drivers, I've no idea...

Not sure about WIFI, but serial seems already enabled:

  CONFIG_SERIAL_AMBA_PL011=y
  CONFIG_SERIAL_AMBA_PL011_CONSOLE=y

arch/arm64/boot/dts/hisilicon/hi6220.dtsi:

uart0: uart@f8015000 {/* console */
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0xf8015000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI6220_UART0_PCLK>,
 <_ctrl HI6220_UART0_PCLK>;
clock-names = "uartclk", "apb_pclk";
};


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#812540: Add ARCH_HISI for Lemaker HiKey support

[Vagrant Cascadian]

On 2016-03-10, Martin Michlmayr wrote:
> * Ian Campbell  [2016-01-25 09:57]:
>> I suppose it will need more than just ARCH_HISI. Are you able to identify
>> the full set of options (e.g. drivers and such) which are needed to make
>> useful Lemaker support? If so I'd appreciate it (if not I can probably try
>> and dig those out myself, but it might take me a while to around to it).

Most drivers aren't even available in 4.4.x, and some aren't even in
4.5.x yet. From a breif glance, the dts files for
arch/arm64/boot/dts/hisilicon/hi6220*, don't look to contain support for
much more than the CPU, memory and serial...


> This might be a good starting point:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1098644.html

Reading that patch, I'm guessing the following are available and
possibly needed or desired, though possibly may require device-tree
patches as well:

available in 4.4.x:

CONFIG_ARCH_HISI=y
CONFIG_POWER_RESET_HISI=y
CONFIG_HISI_THERMAL=m
CONFIG_MMC_DW=m
CONFIG_MMC_DW_K3=m
CONFIG_I2C_DESIGNWARE_PLATFORM=m

available in 4.5.x:

CONFIG_COMMON_RESET_HI6220=m
CONFIG_PHY_HI6220_USB=m

linux-next tag next-20160311:

CONFIG_HI6220_MBOX=m
CONFIG_REGULATOR_HI655X=m


Will build a few test kernels and report back...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#815848: linux: [armhf] udeb: Include modules needed on BeagleBoard-X15

[Vagrant Cascadian]

Source: linux
Version: 4.4.2-3
Severity: normal
Tags: patch

The following modules are needed to support USB disk installs on
BeagleBoard-X15.

diff --git a/debian/installer/armhf/modules/armhf-armmp/usb-modules 
b/debian/installer/armhf/modules/armhf-armmp/usb-modules
index 7861c82..f82d68b 100644
--- a/debian/installer/armhf/modules/armhf-armmp/usb-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/usb-modules
@@ -9,3 +9,6 @@ ehci-orion
 ehci-tegra
 ci_hdrc_imx
 dwc2
+dwc3
+omap-ocp2scp
+extcon-usb-gpio

Tested with the patch applied from #815476.

In theory, omap-ocp2scp (and maybe extcon-usb-gpio) is needed to support
eSATA as well, although at the moment sata support doesn't work on the
BeagleBoard-X15. So maybe there's a more appropriate place for some of
these modules... not sure where exactly.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Vagrant Cascadian]

On 2016-02-24, Vagrant Cascadian wrote:
> On 2016-02-04, Ben Hutchings wrote:
>> Oh, so the MODULES=most case is bust and we need to list more host
>> controller drivers (or include all modules under drivers/usb/host/).
>> How about MODULES=dep; does that work now?
>
> MODULES=dep appears to pull in the necessary drivers on a recent stretch
> install on a wandboard solo, using initramfs-tools 0.123, but
> MODULES=most still requires manually including them in
> /etc/initramfs-tools/modules.

And, FWIW, MODULES=dep appears to also workaround the issue on the wandboard 
dual
with initramfs-tools 0.120.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Vagrant Cascadian]

On 2016-02-04, Ben Hutchings wrote:
> On Wed, 2016-02-03 at 15:43 -0800, Vagrant Cascadian wrote:
>> On 2016-01-25, Ben Hutchings wrote:
>> > On Thu, 12 Nov 2015 09:49:33 + Ian Campbell <i...@hellion.org.uk> 
>> > wrote:
>> > > On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
>> > > > Would definitely like to see this, with a recent install on a Wandboard
>> > > > Dual with a USB2 sata disk for the rootfs. It installed fine with
>> > > > jessie's debian-installer, but failed on initial boot.
>> > > >  
>> > > > I worked around it by adding to /etc/initramfs-tools/modules:
>> > > >  
>> > > >   ci_hdrc_imx
>> > > >   phy_mxs_usb
>> > > >  
>> > > > I haven't yet verified if only adding "phy_mxs_usb" instead of both 
>> > > > will
>> > > > work.
>> ...
>> > > I think Ben essentially did this in #762042[0], which ends up adding any
>> > > phy-* which are currently loaded to the initramfs. That change appears to
>> > > be in v0.119 while Jessie has v0.120 so perhaps something else is going 
>> > > on.
>> > >  
>> > > ci-* isn't covered by this logic, so that might be it in the first case.
>> > > What is ci-*?
>> > 
>> > Thaose are the chipidea USB controller drivers, which should get found
>> > through sysfs.
>> > 
>> > Please can you clear out /etc/initramfs-tools/modules (temporarily) and
>> > run:
>> > 
>> >     sh -x /usr/sbin/mkinitramfs -o /dev/null 3.16.0-4-armmp 
>> > >mkinitramfs.log 2>&1
>> > 
>> > Then send the log so we can see how this is going wrong.
>> 
>> Attached is a log of the above command with /etc/initramfs-tools/modules
>> cleared out.
>
> Oh, so the MODULES=most case is bust and we need to list more host
> controller drivers (or include all modules under drivers/usb/host/).
> How about MODULES=dep; does that work now?

MODULES=dep appears to pull in the necessary drivers on a recent stretch
install on a wandboard solo, using initramfs-tools 0.123, but
MODULES=most still requires manually including them in
/etc/initramfs-tools/modules.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#815476: linux: [armhf] udeb: Add modules needed on Firefly-RK3288.

[Vagrant Cascadian]

On 2016-02-23, Vagrant Cascadian wrote:
> With a couple more changes (there were some phy-usb modules missing),
> the patch below adds the additional modules needed for rockchip and a
> few others. Tried adding wildcards for the regulator modules, but was
> unsuccessful. 

This patch handles regulator modules in the core-modules udeb as well:

diff --git a/debian/installer/armhf/modules/armhf-armmp/core-modules 
b/debian/installer/armhf/modules/armhf-armmp/core-modules
index 3128393..ff4ff9f 100644
--- a/debian/installer/armhf/modules/armhf-armmp/core-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/core-modules
@@ -14,17 +14,4 @@ phy-omap-control ?
 phy-ti-pipe3 ?
 
 # Regulators
-act8865-regulator ?
-anatop-regulator ?
-axp20x-regulator ?
-da9052-regulator ?
-gpio-regulator ?
-mc13783-regulator ?
-mc13892-regulator ?
-pbias-regulator
-pfuze100-regulator ?
-s2mpa01 ?
-s2mps11 ?
-s5m8767 ?
-ti-abb-regulator ?
-vexpress ?
+drivers/regulator/**


debdiff:

core-modules
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/regulator/act8865-regulator.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/regulator/fan53555.ko

Control files: lines which differ (wdiff format)

Installed-Size: [-396-] {+429+}
Version: [-4.4.2-3-] {+4.4.2-4~20160223~5+}


signature.asc
Description: PGP signature

Bug#815476: linux: [armhf] udeb: Add modules needed on Firefly-RK3288.

[Vagrant Cascadian]

On 2016-02-22, Ben Hutchings wrote:
> We need to either exclude the USB-attached MMC host controllers from
> mmc-modules:
>
> ushc -
> vub300 -

That still needed more exclusions; I didn't track them all down...

> or make mmc-modules depend on usb-modules.

Adding usb-modules dependency worked better, or at least, didn't FTBFS.

With a couple more changes (there were some phy-usb modules missing),
the patch below adds the additional modules needed for rockchip and a
few others. Tried adding wildcards for the regulator modules, but was
unsuccessful. Checked the result against a debdiff of mmc-modules,
usb-modules and core-modules:

usb-modules
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/phy/phy-rockchip-usb.ko

Control files: lines which differ (wdiff format)

Installed-Size: [-1726-] {+1732+}
Version: [-4.4.2-3-] {+4.4.2-4~20160223~3+}

core-modules
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/regulator/act8865-regulator.ko

Control files: lines which differ (wdiff format)

Installed-Size: [-396-] {+417+}
Version: [-4.4.2-3-] {+4.4.2-4~20160223~3+}

mmc-modules
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mfd/rtsx_pci.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mfd/rtsx_usb.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/misc/cb710/cb710.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/cb710-mmc.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/dw_mmc-rockchip.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/mvsdio.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/omap.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/rtsx_pci_sdmmc.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/rtsx_usb_sdmmc.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/ushc.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/via-sdmmc.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/vub300.ko
-rw-r--r--  root/root   
/lib/modules/4.4.0-1-armmp/kernel/drivers/mmc/host/wmt-sdmmc.ko

Control files: lines which differ (wdiff format)

Depends: kernel-image-4.4.0-1-armmp-di, [-core-modules-4.4.0-1-armmp-di-] 
{+core-modules-4.4.0-1-armmp-di, usb-modules-4.4.0-1-armmp-di+}
Installed-Size: [-403-] {+768+}
Version: [-4.4.2-3-] {+4.4.2-4~20160223~3+}



diff --git a/debian/installer/armhf/modules/armhf-armmp/core-modules 
b/debian/installer/armhf/modules/armhf-armmp/core-modules
index 7ea5f6d..3128393 100644
--- a/debian/installer/armhf/modules/armhf-armmp/core-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/core-modules
@@ -14,6 +14,7 @@ phy-omap-control ?
 phy-ti-pipe3 ?
 
 # Regulators
+act8865-regulator ?
 anatop-regulator ?
 axp20x-regulator ?
 da9052-regulator ?
diff --git a/debian/installer/armhf/modules/armhf-armmp/mmc-modules 
b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
index 287ff3f..dadfd53 100644
--- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
@@ -1,8 +1 @@
 #include 
-sdhci-esdhc-imx
-sdhci-tegra
-mmci
-omap_hsmmc
-sunxi-mmc
-dw_mmc-exynos
-sdhci-bcm2835
diff --git a/debian/installer/armhf/modules/armhf-armmp/usb-modules 
b/debian/installer/armhf/modules/armhf-armmp/usb-modules
index 663e915..7861c82 100644
--- a/debian/installer/armhf/modules/armhf-armmp/usb-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/usb-modules
@@ -9,17 +9,3 @@ ehci-orion
 ehci-tegra
 ci_hdrc_imx
 dwc2
-
-# USB PHYs
-phy-am335x ?
-phy-am335x-control ?
-phy-exynos-usb2
-phy-exynos5-usbdrd ?
-phy-generic ?
-phy-mxs-usb
-phy-omap-usb2
-phy-sun4i-usb
-phy-sun9i-usb ?
-phy-tegra-usb ?
-phy-twl4030-usb ?
-phy-twl6030-usb ?
diff --git a/debian/installer/modules/mmc-modules 
b/debian/installer/modules/mmc-modules
index ce8b176..0bae54e 100644
--- a/debian/installer/modules/mmc-modules
+++ b/debian/installer/modules/mmc-modules
@@ -7,3 +7,4 @@ tifm_sd ?
 dw_mmc ?
 dw_mmc_pltfm ?
 toshsd ?
+drivers/mmc/host/**
diff --git a/debian/installer/modules/usb-modules 

Bug#815476: linux: [armhf] udeb: Add modules needed on Firefly-RK3288.

[Vagrant Cascadian]

On 2016-02-21, Ben Hutchings wrote:
> On Sun, 2016-02-21 at 16:11 -0800, Vagrant Cascadian wrote:
>> On 2016-02-21, Ben Hutchings wrote:
>> > > --- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules
>> > > +++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
>> > > @@ -5,4 +5,5 @@ mmci
>> > >  omap_hsmmc
>> > >  sunxi-mmc
>> > >  dw_mmc-exynos
>> > > +dw_mmc-rockchip
>> > >  sdhci-bcm2835
>> > 
>> > Would it make sense to replace this list with a wildcard in the default
>> > mmc-modules file:
>> > 
>> >     drivers/mmc/host/**
>> 
>> Overall, I like the idea of using wildcards to include enabled drivers
>> by default, so that drivers for new platforms get automatically
>> included.
...
> Please can you test whether that change would do the right thing for armhf.

First attempt resulted in:

kernel-wedge find-dups 4.4.0-1-armmp
some modules are in more than one package
debian/usb-modules-4.4.0-1-armmp-di
lib/modules/4.4.0-1-armmp/kernel/drivers/usb/common/usb-common.ko
debian/mmc-modules-4.4.0-1-armmp-di
lib/modules/4.4.0-1-armmp/kernel/drivers/usb/common/usb-common.ko
debian/usb-modules-4.4.0-1-armmp-di
lib/modules/4.4.0-1-armmp/kernel/drivers/usb/core/usbcore.ko
debian/mmc-modules-4.4.0-1-armmp-di
lib/modules/4.4.0-1-armmp/kernel/drivers/usb/core/usbcore.ko
command exited with status 1
make[2]: *** [install-udeb_armhf] Error 2
debian/rules.real:449: recipe for target 'install-udeb_armhf' failed

That was using the following patch:

diff --git a/debian/installer/armhf/modules/armhf-armmp/core-modules 
b/debian/installer/armhf/modules/armhf-armmp/core-modules
index 7ea5f6d..4c26273 100644
--- a/debian/installer/armhf/modules/armhf-armmp/core-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/core-modules
@@ -14,16 +14,8 @@ phy-omap-control ?
 phy-ti-pipe3 ?
 
 # Regulators
-anatop-regulator ?
-axp20x-regulator ?
-da9052-regulator ?
-gpio-regulator ?
-mc13783-regulator ?
-mc13892-regulator ?
-pbias-regulator
-pfuze100-regulator ?
+drivers/regulators/*-regulator ?
 s2mpa01 ?
 s2mps11 ?
 s5m8767 ?
-ti-abb-regulator ?
 vexpress ?
diff --git a/debian/installer/armhf/modules/armhf-armmp/mmc-modules 
b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
index 287ff3f..dadfd53 100644
--- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
@@ -1,8 +1 @@
 #include 
-sdhci-esdhc-imx
-sdhci-tegra
-mmci
-omap_hsmmc
-sunxi-mmc
-dw_mmc-exynos
-sdhci-bcm2835
diff --git a/debian/installer/armhf/modules/armhf-armmp/usb-modules 
b/debian/installer/armhf/modules/armhf-armmp/usb-modules
index 663e915..2e14200 100644
--- a/debian/installer/armhf/modules/armhf-armmp/usb-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/usb-modules
@@ -10,16 +10,4 @@ ehci-tegra
 ci_hdrc_imx
 dwc2
 
-# USB PHYs
-phy-am335x ?
-phy-am335x-control ?
-phy-exynos-usb2
-phy-exynos5-usbdrd ?
-phy-generic ?
-phy-mxs-usb
-phy-omap-usb2
-phy-sun4i-usb
-phy-sun9i-usb ?
-phy-tegra-usb ?
-phy-twl4030-usb ?
-phy-twl6030-usb ?
+# USB PHYs included in usb-modules
diff --git a/debian/installer/modules/mmc-modules 
b/debian/installer/modules/mmc-modules
index ce8b176..4367117 100644
--- a/debian/installer/modules/mmc-modules
+++ b/debian/installer/modules/mmc-modules
@@ -7,3 +7,4 @@ tifm_sd ?
 dw_mmc ?
 dw_mmc_pltfm ?
 toshsd ?
+drivers/mmc/host/**
\ No newline at end of file
diff --git a/debian/installer/modules/usb-modules 
b/debian/installer/modules/usb-modules
index 3198f10..af92252 100644
--- a/debian/installer/modules/usb-modules
+++ b/debian/installer/modules/usb-modules
@@ -7,3 +7,7 @@ sl811_cs -
 sl811-hcd -
 u132-hcd -
 whci-hcd -
+
+# Include USB PHY drivers by default
+drivers/phy/phy-*-usb ?
+drivers/usb/phy/* ?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#815476: linux: [armhf] udeb: Add modules needed on Firefly-RK3288.

[Vagrant Cascadian]

On 2016-02-21, Ben Hutchings wrote:
>> --- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules
>> +++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
>> @@ -5,4 +5,5 @@ mmci
>>  omap_hsmmc
>>  sunxi-mmc
>>  dw_mmc-exynos
>> +dw_mmc-rockchip
>>  sdhci-bcm2835
>
> Would it make sense to replace this list with a wildcard in the default
> mmc-modules file:
>
>     drivers/mmc/host/**

Overall, I like the idea of using wildcards to include enabled drivers
by default, so that drivers for new platforms get automatically
included.

The only downside I see, is if a driver was accidentally disabled in the
config (or due to some new conflicting config), it will happily produce
a package without that driver...

The obvious advantage is it will likely reduce the number of round-trip
bug reports to enable drivers in both the kernel and the udebs, so I'd
be supportive of using wildcards for that reason.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#815476: linux: [armhf] udeb: Add modules needed on Firefly-RK3288.

[Vagrant Cascadian]

Source: linux
Version: 4.4.2-2
Severity: normal
Tags: patch

The following modules are needed in order to support ethernet, USB,
and MMC on Firefly-RK3288 in debian-installer.

Please consider enabling them!

live well,
  vagrant


commit 60653f57a9eac67bfde342604fb0adf5b4e2d359
Author: Vagrant Cascadian <vagr...@debian.org>
Date:   Sun Feb 21 12:08:28 2016 -0800

[armhf] udeb: Add modules needed on Firefly-RK3288.
- Add act8865-regulator to core-modules
- Add dw_mmc-rockchip to mmc-modules
- Add phy-rockchip-usb to usb-modules

diff --git a/debian/installer/armhf/modules/armhf-armmp/core-modules 
b/debian/installer/armhf/modules/armhf-armmp/core-modules
index 7ea5f6d..3128393 100644
--- a/debian/installer/armhf/modules/armhf-armmp/core-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/core-modules
@@ -14,6 +14,7 @@ phy-omap-control ?
 phy-ti-pipe3 ?
 
 # Regulators
+act8865-regulator ?
 anatop-regulator ?
 axp20x-regulator ?
 da9052-regulator ?
diff --git a/debian/installer/armhf/modules/armhf-armmp/mmc-modules 
b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
index 287ff3f..6bdda66 100644
--- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
@@ -5,4 +5,5 @@ mmci
 omap_hsmmc
 sunxi-mmc
 dw_mmc-exynos
+dw_mmc-rockchip
 sdhci-bcm2835
diff --git a/debian/installer/armhf/modules/armhf-armmp/usb-modules 
b/debian/installer/armhf/modules/armhf-armmp/usb-modules
index 663e915..454e77d 100644
--- a/debian/installer/armhf/modules/armhf-armmp/usb-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/usb-modules
@@ -18,6 +18,7 @@ phy-exynos5-usbdrd ?
 phy-generic ?
 phy-mxs-usb
 phy-omap-usb2
+phy-rockchip-usb
 phy-sun4i-usb
 phy-sun9i-usb ?
 phy-tegra-usb ?


signature.asc
Description: PGP signature