e can ask the kernel people what the situation is. I
agree that broken rPi4 ethernet on the installer is quite bad.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2021-04-12 16:30 +0200, Salvatore Bonaccorso wrote:
>
> Thanks Wookey for the testing feedback. This really starts to become
> late for the bullseye release, so we need to be careful enough. We
> will see what we can do.
Understood. I see we were just 2 days too late for the 5.
ce of config options to
SOC variants is:
IMX8MN == i.MX8M Nano
IMX8MQ == i.MX8M Quad
IMX8QXP == i.MX8 QuadXPlus
IMX8MP == i.MX8M Plus
--
Wookey
nce of one more hardware enablement
upload for bullseye, or does this feel like too big a change? If not,
getting this into a point release would make debian stable useful on a
lot more hardware. What testing would make the kernel team reasonably
happy about doing that?
--
Wookey
On 2021-03-17 19:43 +0100, Vincent Blut wrote:
> Le 2021-03-17 15:49, Wookey a écrit :
> > On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> > > Le 2021-01-27 12:57, Wookey a écrit :
> > > > Version: Please enable ARM CMN-600 power management on arm64
> > > &
On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> Control: tags -1 moreinfo
>
> Hi Wookey,
>
> Le 2021-01-27 12:57, Wookey a écrit :
> > Source: linux
> > Version: Please enable ARM CMN-600 power management on arm64
> > Severity: normal
> > Tags: patch
> &g
There is hardware publicly available to buy now that uses the CMN-600
interconnect so we really should turn it on for this stable release if
at all possible.
The Ampere ALTRA:https://store.avantek.co.uk/arm-servers.html
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http
Source: linux
Version: Please enable ARM CMN-600 power management on arm64
Severity: normal
Tags: patch
Current arm hardware such as graviton2 (AWS arm64 hardware) has
'Coherent Mesh Network' interconnect (between components in a
soc). It's important that support for this is built in the kernel so
On 2019-10-28 00:45 +, Wookey wrote:
> On 2019-03-15 11:09 -0600, Mathieu Poirier wrote:
> > Starting with the 5.1 Linux kernel cycle it is mandatory to add the command
> > line
> > option "CORESIGHT=1" to enable CoreSight support when compiling the perf
&g
echanism to get this right? I've
left out the profile info to match the rest of the file, but it feels
unlikely to be correct.
Patch attached.
Ben suggested that I do a pull request to help make this happen. I'll do that
next.
Wookey
--
Principal hats: Linaro, Debian, Wookware, A
mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc
powerpcspe ppc64 ppc64el sparc x32] ,
libperl-dev ,
libunwind8-dev [amd64 armel armhf arm64 i386] ,
+ libopencsd-dev ,
python3-dev ,
# used by upstream to build usbip
autoconf ,
thanks.
Wookey
--
Principal hats: Linaro, Debian
, so this patch to allow the perf
build to use it can now be applied.
Thanks
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
On 2018-04-07 12:06 +, Debian Bug Tracking System wrote:
libopencsd is now in the NEW queue. I'm not sure if you'll get a
noticfication when the ITP bug closure unblocks this one so I'll
comment again here when that happens.
Wookey
--
Principal hats: Linaro, Debian, Woo
0 +
+++ linux-4.16~rc6/debian/changelog 2018-04-06 21:12:15.0 +
@@ -1,3 +1,10 @@
+linux (4.16~rc6-1~exp2) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * add build-dep on libopencsd for perf on arm
+
+ -- Wookey Fri, 06 Apr 2018 22:12:15 +0100
+
linux (
On 2017-09-07 16:01 +0100, Ben Hutchings wrote:
> On Thu, 2017-09-07 at 15:01 +0100, Wookey wrote:
> > OK, but we need the kernel-headers package in order build the
> > toolchain, so at least that needs to be built (which is in fact all I
> > have done/tested so far).
>
&
OK, but we need the kernel-headers package in order build the
toolchain, so at least that needs to be built (which is in fact all I
have done/tested so far).
I agree that the arm64 kernel will work for both. But will
dependencies work for automatically bringing that in?
Wookey
--
Principal hats: Linar
s in
debian:
https://anonscm.debian.org/cgit/users/wookey/rebootstrap.git/commit/?h=ilp32-stable&id=01fe063bff353cba63b2048ff803f41314b888a5
Status for the port (in Debian) is tracked here:
https://wiki.debian.org/Arm64ilp32Port
commit e12a78fddd7bdf77768b94645cd8ae0d8e5f2070
Author: Wookey
Date: Tue A
Package: firmware-brcm80211
Version: 20160824-1
Severity: normal
The firmware file brcm/brcmfmac43362-sdio.bin is available in the
package, but the driver brcmfmac (at least on cubietruck and maybe
always) does not work unless the file brcmfmac43362-sdio.txt is also
supplied.
See the thread here
good to work out the runes for flashing just the uboot
with lower-level tools, and automating the setting of the uboot runes
as much as possible.
I guess we can call this bug closed, as it's not the kernel that's at fault.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
works.
Why would this work OK with kernel 4.5, but not 4.6? The userspace
should be the same, although I presume we are still in the initrd at
this point, and those could differ in some important way?
Clues welcome.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookwar
Package: linux-image-4.6.0-1-armmp-lpae
Version: 4.6.1-1
Severity: normal
I installed an nvidia jetson board (armhf, v7) with the stretch alpha6
installer. It all worked nicely.
See documentation at:
https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1
On upgrading the kernel to 'current
ge. I could be
wrong...
Author: Wookey
Date: Thu Dec 10 17:44:12 2015 +
Fix for 4.4 kernels udebs
diff --git a/debian/installer/package-list b/debian/installer/package-list
index e79890b..adaee53 100644
--- a/debian/installer/package-list
+++ b/debian/installer/package-list
@@ -180,7 +
ebian/changelog
--- linux-4.0.4/debian/changelog 2015-05-26 02:30:07.0 +0100
+++ linux-4.0.4.new/debian/changelog 2015-06-05 03:13:13.936808845 +0100
@@ -1,3 +1,10 @@
+linux (4.0.4-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on amd64 (Closes: #787004)
+
+ -- W
+++ Debian Bug Tracking System [2015-04-25 03:39 +]:
Confirming that the above patch lets the build complete. I don't know
enough about the modules involved to know if it is sufficient/complete.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
-
-01-17
05:58:35.0 +
+++ debian/installer/armhf/modules/armhf-armmp/fb-modules 2015-04-25
03:08:44.914590107 +0100
@@ -1,3 +1,3 @@
imx-ipuv3-crtc
-imx-hdmi
+dw_hdmi-imx
tegra-drm
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE
27; failed
make[2]: *** [install-udeb_armhf] Error 2
make[2]: Leaving directory '/home/wookey/linaro/installer/D01/linux-4.0'
debian/rules.gen:63: recipe for target 'binary-arch_armhf' failed
make[1]: *** [binary-arch_armhf] Error 2
make[1]: Leaving directory '/home/wookey/lin
Source: linux
Version: 3.13.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
End of the build log at:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=3.13.4-1&stamp=1393291598
...
kernel-wedge find-dups 3.13-1-orion5x
some m
c'? Having 'arm64' for both arch and flavour seems a bit clumsy.
Does a config/arm64/config.arm64 file do anything if we already have
config/arm64/config? Or should it just be deleted? None of the other
arches give an example of a null $flavour. Or do we need to keep it
arch=arm64, fl
eed to keep backporting new kernels to add fex integration
forevermore
If they want to keep existing tools and fex workflow then a fex<->DT
translation tool will be needed. (It's not clear to me to what degree
DT can simply be used instead directly)
Wookey
--
Principal hats: Linaro, Emd
internalised by the package.
I entirely leave it to you guys what the best/least intrusive way is
of getting the desired effect of having a stage1 build that just does
linux-libc-headers, and normal builds as currently. I don't believe
that any further stages are needed (at least for
Package: linux
Version: linux-3.6.4-1~experimental.1
Severity: wishlist
Tags: experimental patch
In order to bootstrap a new architecture, a cross-toolchain must be
built. A suitable linux-libc-dev_$arch package is needed for this. In
order to make this (and cross-toolchain builds in general)
auto
re is currently engaged would
allow me to confirm this more directly next time.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe".
s (or stop using xz so that it can
be
installed on very old machines, but that's probably not worth doing for this
rather
obscure case).
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.
Package: linux-image-2.6.30-2-amd64
Version: 2.6.30-8
Severity: normal
With the ethernet device on this laptop (Lenovo ideapad u350) the tg3
driver it needs doesn't actually work unless the broadcom module is
loaded first to provide the PHY. However because this is only true for
some tg3-driven de
34 matches
Mail list logo
