Re: [LEDE-DEV] early printk breaks kernel on the clearfog board
Am Dienstag, 25. April 2017, 02:08:48 CEST schrieb Syrone Wong: > try `make kernel_menuconfig` and select the corresponding one. Thats how it has to be done now. However I claim that the new one should be the default, and teh right way is to have people using old bootloaders do the hard way. However it is really not that simple: switching between CONFIG_DEBUG_MVEBU_UART0 and CONFIG_DEBUG_MVEBU_UART0_ALTERNATE does *not* switch CONFIG_DEBUG_UART_PHYS!!! If course nothing can be done to fix this kernel-side. Thats why I am asking what would be the proper way to deal with this from a higher level (Lede menuconfig). Quoting kernel menuconfig: DEBUG_MVEBU_UART0_ALTERNATE: "This option should be used with the new bootloaders that remap the internal registers at 0xf100. If the wrong DEBUG_MVEBU_UART* option is selected, when u-boot hands over to the kernel, the system silently crashes, with no serial output at all." DEBUG_MVEBU_UART0: "This option should be used with the old bootloaders ... " "This option will not work on older Marvell platforms (Kirkwood, Dove, MV78xx0, Orion5x), which should pick the "new bootloader" variant." It seems to be that "new"should be the default, and applicable to most, and all new platforms. Better not put bricks into peoples paths when they are starting out on new stuff. Of course one way would be to make a Lede menuconfig for this. br Josua Mayer > > > Best Regards, > Syrone Wong > > On Mon, Apr 24, 2017 at 11:18 PM, Josua Mayer wrote: > > Am Montag, 24. April 2017, 02:37:48 CEST schrieb Syrone Wong: > >> You may want to enable CONFIG_DEBUG_MVEBU_UART0_ALTERNATE > > > > Yes, this is the one. But it is not visible from the Lede menuconfig. The > > problem I was trying to point out is that in the kernel-config this is > > what > > should be selected when selecting early-printk in the Lede menuconfig. > > > >> or CONFIG_DEBUG_MVEBU_UART1_ALTERNATE if early printk is being enabled. > >> > >> > >> Best Regards, > >> Syrone Wong > >> > >> On Mon, Apr 24, 2017 at 3:39 AM, Josua Mayer > > > > wrote: > >> > Hi everybody, > >> > > >> > I noticed a serious problem with a Clearfog build that enables > >> > CONFIG_KERNEL_EARLY_PRINTK=y. > >> > In short: after Loading Kernel, the serial console stays completely > >> > silent, and apparently the board does *not* boot. > >> > > >> > This came as a serious surprise to me. > >> > Turns out the reason for this is the usage of the old uart physical > >> > address: CONFIG_DEBUG_UART_PHYS=0xd0012000 > >> > This is the default for if DEBUG_MVEBU_UART0 > >> > However the Clearfog Pro uses mainline u-boot, and requires: > >> > CONFIG_DEBUG_UART_PHYS=0xf1012000 > >> > > >> > Any opinions what should be done about this? > >> > I personally suggest to switch to what the kernel config calls "new > >> > bootloaders". > >> > After all this is quite the trap when somebody is so thoughtful to > >> > start > >> > with a debug build, only to find out that is the reason his builds > >> > don't > >> > boot. > >> > > >> > Imre Kaloz: you are the one who committed this setting with config-4.4, > >> > so I figured you may have some valuable insight here. > >> > > >> > br > >> > Josua Mayer > >> > > >> > > >> > ___ > >> > Lede-dev mailing list > >> > Lede-dev@lists.infradead.org > >> > http://lists.infradead.org/mailman/listinfo/lede-dev > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Policies for changes to LEDE stable branches, or LEDE patches in general?
Hi Bjørn, El 25/04/2017 a las 13:43, Bjørn Mork escribió: > Hello, > > I note that a recent commit to the lede-17.01 branch has added a few > driver patches which have barely hit the mainline kernel: > > https://github.com/lede-project/source/commit/1ab41265c39354332630bcba0ec704abd2e790f0 > > This surprised me quite a bit. I would expect any such fixes to go the > normal route from mainline to stable to LEDE, like they do for most > other current distros. This usually does not take more than a couple of > weeks anyway, and less if a fix is critical. You're right, but we're dealing with something that has been accepted upstream and has been tested and discussed by several developers, and I don't think that waiting for a fix to come from linux-stable is mandatory (@lede-dev correct me if I'm wrong). > > It was surprising enough that this hit the master branch. But going > into a stable LEDE branch before davem has considered it for stable > kernels? Why? Because it fixes a long standing bug for the Raspberry Pi (and any other devices bridging interfaces that rely on drivers that alter sk_buff data without duplicating its content). As far as I know, only fixes can be pushed to stable branches. You're right, davem hasn't yet considered it for stable branches, but in this case the patch has been tested by quite a lot of users (Raspberry Pi community), and I thought this was sufficient to consider it stable (BTW, I've also tested it myself). > > And then there is the issue of making LEDE patches for fixes which can > be, or already are, upstream: Is that wise use of resources? Reading > https://lede-project.org/docs/guide-developer/the-source-code I see that > I am wrong thinking that there are policies for this. > > But maybe there should be? > > > > Bjørn > ~Álvaro. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] target/arc770: switch to 4.9 kernel
On 2017-04-25 15:05, Alexey Brodkin wrote: > Hi Felix, > > On Thu, 2017-04-13 at 15:42 +0300, Alexey Brodkin wrote: > > [snip] > >> As you might have seen from my email to USB mailing list I >> was able to nail down the problem (which apparently has nothing to do >> with ARC or any other architecture in particular). >> >> I think it worth waiting for comments on the mailing list. >> If everybody is happy with my patch I'll submit it to Lede or >> you may just pick it up as well - it applies on top of 4.9 perfectly fine. >> >> FWIW that's a link to my message in linux-usb LM: >> http://marc.info/?l=linux-usb&m=149208684805545&w=2 > > Given there're no signs of activity regarding my patch I'm not sure when > it gets accepted. So I'm wondering if you prefer to wait until it really gets > accepted or I may send it to Lede/OWrt right away so you'll be able to > push my patches with kernel v4.9 for ARC in upstream branch sooner? Feel free to submit your patch for LEDE to get the 4.9 update in sooner. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC][17.01] ubox: bump to version 2017-03-10
Changes since current version 16f7e16 syslog: remove unnecessary sizeof struct between messages 21a4bd0 kmodloader: modprobe: return 0 for loaded modules 3dc78a4 kmodloader: don't store aliases info in struct module c553354 cmake: fix typo 8973576 kmodloader: fix not being able to find some modules fce9382 cmake: Check for getrandom system call ac2d43e kmodloader: support '-q' quiet option f8d3d16 ubox: Add an option for more accurate timestamps in log 14839f0 kmodloader: make insert_module() idempotent 6e3c6dc kmodloader: add module alias awareness 9371411 kmodloader: fix out-of-bound access when parsing .modinfo a62c946 kmodloader: modprobe: skip possible command line arguments 46a4b5f kmodloader: log to kmsg when loading directories of modules eacc426 kmodloader: remove redundant glob wildcard char 8488bb5 ubox: Initialize conditionally uninitialized variabled db070f1 ubox: Fix some memory leaks acc48b5 kmodloader: Fix typo in error message Size comparison on x86_64 host function old new delta main21902344+154 scan_module_folder 665 793+128 alloc_module_node - 113+113 .rodata 9461036 +90 alloc_module 202 245 +43 free_modules 77 119 +42 load_modprobe209 237 +28 scan_loaded_modules 241 265 +24 avl_modcmp45 67 +22 insert_module204 224 +20 find_module 13 30 +17 static.optind@@GLIBC_2 - 4 +4 static.load_moddeps 118 117 -1 scan_module_folders 55 54 -1 -- (add/remove: 2/0 grow/shrink: 10/2 up/down: 685/-2) Total: 683 bytes Fixes FS#684 with commit 21a4bd0 Signed-off-by: Yousong Zhou --- Hi, I actually thought about opening a 17.01 branch for the ubox repo and cherry-picking only bugfix commits there. What do you think? package/system/ubox/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/system/ubox/Makefile b/package/system/ubox/Makefile index cdf9265d31..3c9b4aa515 100644 --- a/package/system/ubox/Makefile +++ b/package/system/ubox/Makefile @@ -5,9 +5,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(LEDE_GIT)/project/ubox.git -PKG_SOURCE_DATE:=2017-01-15 -PKG_SOURCE_VERSION:=5649c028c426060616e2bd4e7ea83271cd333d21 -PKG_MIRROR_HASH:=28e5580d481a415697fbca46c160177bab6dc47a04ba7ddb73537827632b2dd6 +PKG_SOURCE_DATE:=2017-03-10 +PKG_SOURCE_VERSION:=16f7e16181e2f3e9cf3e2ce56a7e291844900d09 +PKG_MIRROR_HASH:=5f10f3df134eb8a69d281a73d39f5d2e2fc96af531a2f3960b0c6116ff11a707 CMAKE_INSTALL:=1 PKG_LICENSE:=GPL-2.0 -- 2.12.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] target/arc770: switch to 4.9 kernel
Hi Felix, On Thu, 2017-04-13 at 15:42 +0300, Alexey Brodkin wrote: [snip] > As you might have seen from my email to USB mailing list I > was able to nail down the problem (which apparently has nothing to do > with ARC or any other architecture in particular). > > I think it worth waiting for comments on the mailing list. > If everybody is happy with my patch I'll submit it to Lede or > you may just pick it up as well - it applies on top of 4.9 perfectly fine. > > FWIW that's a link to my message in linux-usb LM: > http://marc.info/?l=linux-usb&m=149208684805545&w=2 Given there're no signs of activity regarding my patch I'm not sure when it gets accepted. So I'm wondering if you prefer to wait until it really gets accepted or I may send it to Lede/OWrt right away so you'll be able to push my patches with kernel v4.9 for ARC in upstream branch sooner? -Alexey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Policies for changes to LEDE stable branches, or LEDE patches in general?
Hello, I note that a recent commit to the lede-17.01 branch has added a few driver patches which have barely hit the mainline kernel: https://github.com/lede-project/source/commit/1ab41265c39354332630bcba0ec704abd2e790f0 This surprised me quite a bit. I would expect any such fixes to go the normal route from mainline to stable to LEDE, like they do for most other current distros. This usually does not take more than a couple of weeks anyway, and less if a fix is critical. It was surprising enough that this hit the master branch. But going into a stable LEDE branch before davem has considered it for stable kernels? Why? And then there is the issue of making LEDE patches for fixes which can be, or already are, upstream: Is that wise use of resources? Reading https://lede-project.org/docs/guide-developer/the-source-code I see that I am wrong thinking that there are policies for this. But maybe there should be? Bjørn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] kernel: kmod-usb-net-pl: Add support for PL-27A1
Roman Spychała writes: > diff --git > a/target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch > > b/target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch > new file mode 100644 > index 00..794a861993 > --- /dev/null > +++ > b/target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch > @@ -0,0 +1,72 @@ > +From 07ddf5fce9dae47ced9f04653075021301052c99 Mon Sep 17 00:00:00 2001 > +From: =?UTF-8?q?Roman=20Spycha=C5=82a?= > +Date: Thu, 20 Apr 2017 11:40:14 +0200 > +Subject: [PATCH] usb: plusb: Add support for PL-27A1 > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +This patch adds support for the PL-27A1 by adding the appropriate > +USB ID's. This chip is used in the goobay Active USB 3.0 Data Link > +and Unitek Y-3501 cables. Why do we need LEDE patches for new device IDs? There is nothing LEDE specific about this. Surely it can be handled through the normal stable kernel updates? Bjørn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] kernel: kmod-usb-net-pl: Add support for PL-27A1
From: Roman Spychała
Just applying the same patch to 4.4 and 4.9 kernels.
Signed-off-by: Roman Spychała
---
package/kernel/linux/modules/usb.mk| 4 +-
.../870-usb-plusb-Add-support-for-PL-27A1.patch| 72 ++
.../870-usb-plusb-Add-support-for-PL-27A1.patch| 72 ++
3 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644
target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch
create mode 100644
target/linux/generic/patches-4.9/870-usb-plusb-Add-support-for-PL-27A1.patch
diff --git a/package/kernel/linux/modules/usb.mk
b/package/kernel/linux/modules/usb.mk
index 5ea508d6e3..f2059a516b 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -1284,7 +1284,7 @@ endef
$(eval $(call KernelPackage,usb-net-kalmia))
define KernelPackage/usb-net-pl
- TITLE:=Prolific PL-2301/2302/25A1 based cables
+ TITLE:=Prolific PL-2301/2302/25A1/27A1 based cables
KCONFIG:=CONFIG_USB_NET_PLUSB
FILES:=$(LINUX_DIR)/drivers/net/usb/plusb.ko
AUTOLOAD:=$(call AutoProbe,plusb)
@@ -1292,7 +1292,7 @@ define KernelPackage/usb-net-pl
endef
define KernelPackage/usb-net-pl/description
- Kernel support for Prolific PL-2301/2302/25A1 based cables
+ Kernel support for Prolific PL-2301/2302/25A1/27A1 based cables
endef
$(eval $(call KernelPackage,usb-net-pl))
diff --git
a/target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch
b/target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch
new file mode 100644
index 00..794a861993
--- /dev/null
+++
b/target/linux/generic/patches-4.4/870-usb-plusb-Add-support-for-PL-27A1.patch
@@ -0,0 +1,72 @@
+From 07ddf5fce9dae47ced9f04653075021301052c99 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Roman=20Spycha=C5=82a?=
+Date: Thu, 20 Apr 2017 11:40:14 +0200
+Subject: [PATCH] usb: plusb: Add support for PL-27A1
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This patch adds support for the PL-27A1 by adding the appropriate
+USB ID's. This chip is used in the goobay Active USB 3.0 Data Link
+and Unitek Y-3501 cables.
+
+Signed-off-by: Roman Spychała
+---
+ drivers/net/usb/Kconfig | 2 +-
+ drivers/net/usb/plusb.c | 15 +--
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
+index 3dd490f53e48..f28bd74ac275 100644
+--- a/drivers/net/usb/Kconfig
b/drivers/net/usb/Kconfig
+@@ -369,7 +369,7 @@ config USB_NET_NET1080
+ optionally with LEDs that indicate traffic
+
+ config USB_NET_PLUSB
+- tristate "Prolific PL-2301/2302/25A1 based cables"
++ tristate "Prolific PL-2301/2302/25A1/27A1 based cables"
+ # if the handshake/init/reset problems, from original 'plusb',
+ # are ever resolved ... then remove "experimental"
+ depends on USB_USBNET
+diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
+index 22e1a9a99a7d..6fe59373cba9 100644
+--- a/drivers/net/usb/plusb.c
b/drivers/net/usb/plusb.c
+@@ -102,7 +102,7 @@ static int pl_reset(struct usbnet *dev)
+ }
+
+ static const struct driver_info prolific_info = {
+- .description = "Prolific PL-2301/PL-2302/PL-25A1",
++ .description = "Prolific PL-2301/PL-2302/PL-25A1/PL-27A1",
+ .flags =FLAG_POINTTOPOINT | FLAG_NO_SETINT,
+ /* some PL-2302 versions seem to fail usb_set_interface() */
+ .reset =pl_reset,
+@@ -139,6 +139,17 @@ static const struct usb_device_id products [] = {
+* Host-to-Host Cable
+*/
+ .driver_info = (unsigned long) &prolific_info,
++
++},
++
++/* super speed cables */
++{
++ USB_DEVICE(0x067b, 0x27a1), /* PL-27A1, no eeprom
++ * also: goobay Active USB 3.0
++ * Data Link,
++ * Unitek Y-3501
++ */
++ .driver_info = (unsigned long) &prolific_info,
+ },
+
+ { },// END
+@@ -158,5 +169,5 @@ static struct usb_driver plusb_driver = {
+ module_usb_driver(plusb_driver);
+
+ MODULE_AUTHOR("David Brownell");
+-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
++MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/27A1 USB Host to Host Link
Driver");
+ MODULE_LICENSE("GPL");
+--
+2.12.2
+
diff --git
a/target/linux/generic/patches-4.9/870-usb-plusb-Add-support-for-PL-27A1.patch
b/target/linux/generic/patches-4.9/870-usb-plusb-Add-support-for-PL-27A1.patch
new file mode 100644
index 00..794a861993
--- /dev/null
+++
b/target/linux/generic/patches-4.9/870-usb-plusb-Add-support-for-PL-27A1.patch
@@ -0,0 +1,72 @@
+From 07ddf5fce9dae47ced9f04653075021301052c99 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Roman=20Spycha=C5=82a?=
[LEDE-DEV] [PATCH 1/2] kernel: add kmod-usb-net-pl package
From: Roman Spychała Kernel support for Prolific PL-2301/2302/25A1 based cables Signed-off-by: Roman Spychała --- package/kernel/linux/modules/usb.mk | 13 + 1 file changed, 13 insertions(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 591ba0a081..5ea508d6e3 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -1283,6 +1283,19 @@ endef $(eval $(call KernelPackage,usb-net-kalmia)) +define KernelPackage/usb-net-pl + TITLE:=Prolific PL-2301/2302/25A1 based cables + KCONFIG:=CONFIG_USB_NET_PLUSB + FILES:=$(LINUX_DIR)/drivers/net/usb/plusb.ko + AUTOLOAD:=$(call AutoProbe,plusb) + $(call AddDepends/usb-net) +endef + +define KernelPackage/usb-net-pl/description + Kernel support for Prolific PL-2301/2302/25A1 based cables +endef + +$(eval $(call KernelPackage,usb-net-pl)) define KernelPackage/usb-hid TITLE:=Support for USB Human Input Devices -- 2.12.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] MT7621 Hardware NAT offload
On my mt7621 router, I'm running LEDE with 4.4 kernel. I would like to have 'HW NAT Offload' implementation to increase the speed. On the net I saw hw nat offload for older kernels, which uses QoS & QDMA for 3.10 kernels. But the newer kernels are missing those implementations. Can someone guide me to port 'HW Nat Offlaod' in newer kernels. Thanks Mani ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: add kmod-snd-aloop package
On 2017-04-25 09:37, Roman Spychała wrote: > From: Roman Spychała > > Signed-off-by: Roman Spychała I'm curious, what are you using this for? - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: add kmod-snd-aloop package
From: Roman Spychała Signed-off-by: Roman Spychała --- package/kernel/linux/modules/sound.mk | 16 1 file changed, 16 insertions(+) diff --git a/package/kernel/linux/modules/sound.mk b/package/kernel/linux/modules/sound.mk index de5d8fc2c6..cd81c6bf20 100644 --- a/package/kernel/linux/modules/sound.mk +++ b/package/kernel/linux/modules/sound.mk @@ -289,6 +289,22 @@ endef $(eval $(call KernelPackage,sound-dummy)) +define KernelPackage/sound-aloop + $(call AddDepends/sound) + TITLE:=A loopback soundcard + KCONFIG:= \ +CONFIG_SND_ALOOP + FILES:= \ +$(LINUX_DIR)/sound/drivers/snd-aloop.ko + AUTOLOAD:=$(call AutoLoad,32,snd-aloop) +endef + +define KernelPackage/sound_aloop/description + Loopback soundcard returns played samples back to user space using standard ALSA PCM device +endef + +$(eval $(call KernelPackage,sound-aloop)) + define KernelPackage/sound-hda-core SUBMENU:=$(SOUND_MENU) TITLE:=HD Audio Sound Core Support -- 2.12.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
