Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
Citeren Hauke Mehrtens : This adds support for kernel 4.9. Please test this, I am lacking especially NAND devices. The most recent version of these patches can be found here: https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx Hauke Mehrtens (4): ar71xx: Copy kernel 4.4 code for kernel 4.9 ar71xx: make the target compile with kernel 4.9 ar71xx: fix section mismatches ar71xx: switch to kernel 4.9 by default I checked the above patches on a WNDR4300 (a NAND device). No issues when building, but the device entered a bootloop after flashing with sysupgrade. Since this is a production system, I didn't have time to dig into what is exactly causing this. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
Arjen de Korte wrote: > Citeren Hauke Mehrtens : > > This adds support for kernel 4.9. > > Please test this, I am lacking especially NAND devices. > > > > The most recent version of these patches can be found here: > > https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx > > > > Hauke Mehrtens (4): > > ar71xx: Copy kernel 4.4 code for kernel 4.9 > > ar71xx: make the target compile with kernel 4.9 > > ar71xx: fix section mismatches > > ar71xx: switch to kernel 4.9 by default > I checked the above patches on a WNDR4300 (a NAND device). No issues > when building, but the device entered a bootloop after flashing with > sysupgrade. Since this is a production system, I didn't have time to > dig into what is exactly causing this. ar934x NAND driver missing cmd_ctrl() function - so NAND devices not work at all. [3.575549] nand: chip.cmd_ctrl() callback is not provided [3.581103] ar934x-nfc ar934x-nfc: nand_scan_ident failed, err:-22 [3.587515] ar934x-nfc: probe of ar934x-nfc failed with error -22 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: bump 4.4 to 4.4.91
Refresh patches. Compile-tested for: ar71xx Archer C7 v2 Run-tested on: ar71xx Archer C7 v2 Signed-off-by: Kevin Darbyshire-Bryant --- include/kernel-version.mk | 4 ++-- target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch | 2 +- .../680-NET-skip-GRO-for-foreign-MAC-addresses.patch | 10 +- target/linux/generic/pending-4.4/721-phy_packets.patch | 2 +- .../oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 75a1e1d..ab2eaeb 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -3,11 +3,11 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .71 -LINUX_VERSION-4.4 = .90 +LINUX_VERSION-4.4 = .91 LINUX_VERSION-4.9 = .53 LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 -LINUX_KERNEL_HASH-4.4.90 = 6826ccd213ac79bbfd47e63912e89ef7ec70324b7aa3684a4d4560fc2b436331 +LINUX_KERNEL_HASH-4.4.91 = cb9d2b8c1afe58414de5bc7d65429cc9f5f37c80fc229d0e83c55c5c3c254ffb LINUX_KERNEL_HASH-4.9.53 = 32915a33bb0b993b779257748f89f31418992edba53acbe1160cb0f8ef3cb324 ifdef KERNEL_PATCHVER diff --git a/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch b/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch index 23b8e86..d43e8c7 100644 --- a/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch +++ b/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch @@ -58,7 +58,7 @@ return; + } - if (hw_read_otgsc(ci, OTGSC_BSV)) + if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active) usb_gadget_vbus_connect(&ci->gadget); --- a/include/linux/usb/chipidea.h +++ b/include/linux/usb/chipidea.h diff --git a/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch b/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch index 0616eaa..b7ba384 100644 --- a/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch +++ b/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch @@ -17,7 +17,7 @@ Signed-off-by: Felix Fietkau --- a/net/core/dev.c +++ b/net/core/dev.c -@@ -4256,6 +4256,9 @@ static enum gro_result dev_gro_receive(s +@@ -4259,6 +4259,9 @@ static enum gro_result dev_gro_receive(s enum gro_result ret; int grow; @@ -27,7 +27,7 @@ Signed-off-by: Felix Fietkau if (!(skb->dev->features & NETIF_F_GRO)) goto normal; -@@ -5422,6 +5425,48 @@ static void __netdev_adjacent_dev_unlink +@@ -5425,6 +5428,48 @@ static void __netdev_adjacent_dev_unlink &upper_dev->adj_list.lower); } @@ -76,7 +76,7 @@ Signed-off-by: Felix Fietkau static int __netdev_upper_dev_link(struct net_device *dev, struct net_device *upper_dev, bool master, void *private) -@@ -5493,6 +5538,7 @@ static int __netdev_upper_dev_link(struc +@@ -5496,6 +5541,7 @@ static int __netdev_upper_dev_link(struc goto rollback_lower_mesh; } @@ -84,7 +84,7 @@ Signed-off-by: Felix Fietkau call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev, &changeupper_info.info); return 0; -@@ -5619,6 +5665,7 @@ void netdev_upper_dev_unlink(struct net_ +@@ -5622,6 +5668,7 @@ void netdev_upper_dev_unlink(struct net_ list_for_each_entry(i, &upper_dev->all_adj_list.upper, list) __netdev_adjacent_dev_unlink(dev, i->dev, i->ref_nr); @@ -92,7 +92,7 @@ Signed-off-by: Felix Fietkau call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev, &changeupper_info.info); } -@@ -6159,6 +6206,7 @@ int dev_set_mac_address(struct net_devic +@@ -6162,6 +6209,7 @@ int dev_set_mac_address(struct net_devic if (err) return err; dev->addr_assign_type = NET_ADDR_SET; diff --git a/target/linux/generic/pending-4.4/721-phy_packets.patch b/target/linux/generic/pending-4.4/721-phy_packets.patch index 89ffdc5..a7a2327 100644 --- a/target/linux/generic/pending-4.4/721-phy_packets.patch +++ b/target/linux/generic/pending-4.4/721-phy_packets.patch @@ -86,7 +86,7 @@ help --- a/net/core/dev.c +++ b/net/core/dev.c -@@ -2743,10 +2743,20 @@ static int xmit_one(struct sk_buff *skb, +@@ -2746,10 +2746,20 @@ static int xmit_one(struct sk_buff *skb, if (!list_empty(&ptype_all) || !list_empty(&dev->ptype_all)) dev_queue_xmit_nit(skb, dev); diff --git a/target/linux/oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch b/target/linux/oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch index d6c5c62..a94ac22 100644 --- a/target/linux/oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch +++ b/target/lin
[LEDE-DEV] build problem in layerscape target
Hi Yangbo, I am seeing the following build problem in the layerscape target in the master tree. I fixed the missing config symbol problem, found by the build bots, but they will run into this in the next run. I saw this on the 64bit and the 32 bit build. -- CC [M] drivers/usb/host/ehci-fsl.o In file included from drivers/usb/host/ehci-fsl.c:45:0: drivers/usb/host/ehci.h: In function 'ehci_readl': drivers/usb/host/ehci.h:757:9: error: implicit declaration of function 'readl' [-Werror=implicit-function-declaration] return readl(regs); ^ drivers/usb/host/ehci.h: In function 'ehci_writel': drivers/usb/host/ehci.h:784:3: error: implicit declaration of function 'writel' [-Werror=implicit-function-declaration] writel(val, regs); ^ In file included from drivers/usb/host/ehci-fsl.c:26:0: drivers/usb/host/ehci-fsl.c: In function 'hcd_to_ehci_fsl': ./include/linux/kernel.h:836:27: error: 'struct ehci_fsl' has no member named 'ehci' const typeof( ((type *)0)->member ) *__mptr = (ptr); \ ^ drivers/usb/host/ehci-fsl.c:100:8: note: in expansion of macro 'container_of' return container_of(ehci, struct ehci_fsl, ehci); ^ ./include/linux/kernel.h:836:48: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] const typeof( ((type *)0)->member ) *__mptr = (ptr); \ ^ drivers/usb/host/ehci-fsl.c:100:8: note: in expansion of macro 'container_of' return container_of(ehci, struct ehci_fsl, ehci); ^ In file included from ./include/linux/compiler.h:58:0, from ./include/linux/linkage.h:4, from ./include/linux/kernel.h:6, from drivers/usb/host/ehci-fsl.c:26: ./include/linux/compiler-gcc.h:159:2: error: 'struct ehci_fsl' has no member named 'ehci' __builtin_offsetof(a, b) ^ ./include/linux/stddef.h:16:32: note: in expansion of macro '__compiler_offsetof' #define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER) ^ ./include/linux/kernel.h:837:29: note: in expansion of macro 'offsetof' (type *)( (char *)__mptr - offsetof(type,member) );}) ^ drivers/usb/host/ehci-fsl.c:100:8: note: in expansion of macro 'container_of' return container_of(ehci, struct ehci_fsl, ehci); ^ drivers/usb/host/ehci-fsl.c: At top level: drivers/usb/host/ehci-fsl.c:126:8: error: redefinition of 'struct ehci_fsl' struct ehci_fsl { ^ drivers/usb/host/ehci-fsl.c:85:8: note: originally defined here struct ehci_fsl { ^ drivers/usb/host/ehci-fsl.c:146:8: error: unknown type name 'strut' static strut ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd) ^ drivers/usb/host/ehci-fsl.c:146:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token static strut ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd) ^ drivers/usb/host/ehci-fsl.c: In function 'fsl_ehci_drv_probe': drivers/usb/host/ehci-fsl.c:259:3: error: implicit declaration of function 'clrsetbits_be32' [-Werror=implicit-function-declaration] clrsetbits_be32(hcd->regs + FSL_SOC_USB_CTRL, ^ drivers/usb/host/ehci-fsl.c:265:3: error: implicit declaration of function 'iowrite32be' [-Werror=implicit-function-declaration] iowrite32be(USB_CTRL_USB_EN, hcd->regs + FSL_SOC_USB_CTRL); ^ drivers/usb/host/ehci-fsl.c: In function 'usb_phy_clk_valid': drivers/usb/host/ehci-fsl.c:333:8: error: implicit declaration of function 'in_be32' [-Werror=implicit-function-declaration] if (!(in_be32(non_ehci + FSL_SOC_USB_CTRL) & PHY_CLK_VALID)) ^ drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_setup_phy': drivers/usb/host/ehci-fsl.c:361:4: error: implicit declaration of function 'clrbits32' [-Werror=implicit-function-declaration] clrbits32(non_ehci + FSL_SOC_USB_CTRL, ^ drivers/usb/host/ehci-fsl.c:387:31: error: too few arguments to function 'usb_phy_clk_valid' pdata->have_sysif_regs && !usb_phy_clk_valid(hcd)) { ^ drivers/usb/host/ehci-fsl.c:327:13: note: declared here static bool usb_phy_clk_valid(struct usb_hcd *hcd, ^ drivers/usb/host/ehci-fsl.c:415:9: error: implicit declaration of function 'ioread32be' [-Werror=implicit-function-declaration] if (!(ioread32be(non_ehci + FSL_SOC_USB_CTRL) & ^ drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_drv_suspend': drivers/usb/host/ehci-fsl.c:747:30: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd); ^ drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_drv_resume': drivers/usb/host/ehci-fsl.c:791:30: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd); ^ dri
Re: [LEDE-DEV] Kernel version in next major release
Hello Hauke, On 07.10.2017 13:43, Hauke Mehrtens wrote: [...] What is your opinion on this topic? Am I missing some arguments? Currently I would prefer solution 3 going with kernel 4.9 and 4.14. I prefer option 3 as well. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Kernel version in next major release
On 10/07/2017 04:43 AM, Hauke Mehrtens wrote:> > What is your opinion on this topic? Am I missing some arguments? > Currently I would prefer solution 3 going with kernel 4.9 and 4.14. Option 3 is both pragmatic and realistic, +1 -- Florian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
Hi, On 10/07/2017 04:48 PM, Jason A. Donenfeld wrote: > Hey, > > I'm upstream on the ipset-dns project: > https://git.zx2c4.com/ipset-dns/about/ > > It's a part of a core LEDE repo: > https://git.lede-project.org/?p=source.git;a=tree;f=package/network/services/ipset-dns > > Pretty soon after I wrote ipset-dns, I thought it was kind of a > hassle, and so I rewrote the whole thing instead as a patch to > dnsmasq, submitted it upstream to Simon, and it was accepted. This > seems to work much more easily than my original ipset-dns, and I > imagine it's what most people use for that kind of thing on LEDE. > Funny enough, when I look at the git repo for ipset-dns, on February > 15, 2013, I made the "initial commit." On the 23rd, 8 days later, I > added a note telling people to use dnsmasq instead. > > In spite of this, it went into LEDE, and I assume people used it in > between then and whenever my patch inside of dnsmasq was released in a > version that was inside of LEDE. > > But this was all years ago. > > So, I'm wondering: does anybody actually use ipset-dns? Does it have > any utility? As cool as it is having a piece of my code in the core > LEDE repo, I can't help wondering if it should be removed... Still using ipset-dns here, thanks for the reminder, I should probably migrate to dnsmasq now to achieve the same goals. There may be other users out there though ;) -- Florian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
On Sun, Oct 8, 2017 at 3:02 PM, Florian Fainelli wrote: > Still using ipset-dns here, thanks for the reminder, I should probably > migrate to dnsmasq now to achieve the same goals. There may be other > users out there though ;) Cool, okay, good to know! In that case, I'll take a closer look at the patches LEDE ships for the package and merging them into the upstream repo. Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
On 10/08/2017 01:31 PM, Andrey Jr. Melnikov wrote: > Arjen de Korte wrote: >> Citeren Hauke Mehrtens : > >>> This adds support for kernel 4.9. >>> Please test this, I am lacking especially NAND devices. >>> >>> The most recent version of these patches can be found here: >>> https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx >>> >>> Hauke Mehrtens (4): >>> ar71xx: Copy kernel 4.4 code for kernel 4.9 >>> ar71xx: make the target compile with kernel 4.9 >>> ar71xx: fix section mismatches >>> ar71xx: switch to kernel 4.9 by default > >> I checked the above patches on a WNDR4300 (a NAND device). No issues >> when building, but the device entered a bootloop after flashing with >> sysupgrade. Since this is a production system, I didn't have time to >> dig into what is exactly causing this. > > ar934x NAND driver missing cmd_ctrl() function - so NAND devices not work at > all. > > [3.575549] nand: chip.cmd_ctrl() callback is not provided > [3.581103] ar934x-nfc ar934x-nfc: nand_scan_ident failed, err:-22 > [3.587515] ar934x-nfc: probe of ar934x-nfc failed with error -22 Hi, Thanks for testing and reporting back. I tried to fix this problem, can you please try the most recent version from my git tree. This now has this additional change: https://git.lede-project.org/?p=lede/hauke/staging.git;a=commitdiff;h=42a49cbca96875be43913688da60d637cbdff604 Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
On Sun, Oct 8, 2017 at 3:04 PM, Jason A. Donenfeld wrote: > In that case, I'll take a closer look at the patches LEDE ships for > the package and merging them into the upstream repo. If you don't wind up removing that, future packages won't need to include that patch any longer: https://git.zx2c4.com/ipset-dns/commit/?id=ade2cf88e933f4f90451e0a6171f0aa4a523f989 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
On 08-10-17 16:20, Jason A. Donenfeld wrote: > On Sun, Oct 8, 2017 at 3:04 PM, Jason A. Donenfeld wrote: >> In that case, I'll take a closer look at the patches LEDE ships for >> the package and merging them into the upstream repo. > If you don't wind up removing that, future packages won't need to > include that patch any longer: > https://git.zx2c4.com/ipset-dns/commit/?id=ade2cf88e933f4f90451e0a6171f0aa4a523f989 Updated in my staging tree: https://git.lede-project.org/ffd778ea Thanks, Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] mktplinkfw2 cleanup tests (was [PATCH 1/3] mktplinkfw2: use hw rev for board detection too)
Hello Mathias, On Thu, Oct 5, 2017 at 9:13 AM, Mathias Kresin wrote: > At the moment I'm reviewing https://github.com/lede-project/source/pull/1399 [skipped] > The PR drops any hardcoded board params from mktplinkfw2.c in favour of > commandline arguments, to provide only one way of creating tp-link images. > It has the nice benefit that this file most likely doesn't need to be > touched any more if new tp-link boards gets added. > > Would be nice if you can give the PR a try to test for regressions. It's better late than never. I had tested these patches, which already landed to the tree. All work as expected. I had not test upgrading from vendor firmware to LEDE, but sysupgrade works well with the new image on TP-Link Archer C20v1. So image generation is still alive after these change. P.S. I noticed that the old configuration is not preserved during the sysupgrade. sysupgrade.tgz archive is generated and appended to the jffs2 partition, as expected. But the archive is disappears (with all the old configs) during the first boot after sysupgrade. It seems that preserving the config has never worked with C20/C20i so latest changes in mktplink2 had nothing to do with this. -- Sergey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address
The boot process on a WRT54GL works the following way: 1. CFE gets loaded by the boot rom from flash 2. CFE loads the loader from the flash and gzip uncompresses it 3. CFE starts the loader 4. The loader stores the FW arguments and relocates itself to BZ_TEXT_START (now 0x8060) 5. The loader reads the Linux image from flash 6. The loader lzma decompresses the Linux image to LOADADDR (0x80001000) 7. The loader executes the uncompress Linux image at LOADADDR The BZ_TEXT_START was set to 0x8040 before. When the kernel gets uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote the loader which was currently uncompressing it and made the board crash. Increase the BZ_TEXT_START my 2 MB to have more space for the kernel. Even on 16MB RAM devices the memory goes till 0x80FF so this should not be a problem. Signed-off-by: Hauke Mehrtens --- target/linux/brcm47xx/image/lzma-loader/src/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile b/target/linux/brcm47xx/image/lzma-loader/src/Makefile index 3320e565d0..444039c558 100644 --- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile +++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile @@ -18,7 +18,7 @@ # TEXT_START := 0x80001000 -BZ_TEXT_START := 0x8040 +BZ_TEXT_START := 0x8060 OBJCOPY:= $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R .note -R .comment -R .mdebug -S -- 2.11.0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported
On 25-09-17 18:43, Stijn Tintel wrote: > On 25-09-17 00:20, Baptiste Jonglez wrote: >> On 24-09-17, Stijn Tintel wrote: >>> My bad. When we update a package, we bump the version in the Makefile >>> and remove the current hash, then run "make package/foo/dowload; make >>> package/foo/check FIXUP=1". This downloads the tarbal for the new >>> version, and FIXUP writes its hash to the Makefile. This is what's >>> broken since the change. >> Ok, I see the issue now. >> >> As mentioned in the commit message, we definitely should add an explicit >> option to download.pl to skip hash verification, and then implement >> something like this: >> >> $ make package/foo/download SKIPHASH=1 >> >> What do you think? > We were thinking in that direction on #lede-dev, not sure why we > couldn't agree. Let's wait a bit if anybody else chimes in? Maybe just send an RFC patch with the suggested change, as nobodoy seems to be responding. Thanks, Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Kernel version in next major release
On 07-10-17 14:43, Hauke Mehrtens wrote: > What is your opinion on this topic? Am I missing some arguments? > Currently I would prefer solution 3 going with kernel 4.9 and 4.14. I actually preferred to have a 2nd major release in 2017, using only kernel 4.9, and then a 3rd major release early 2018 using only kernel 4.14. Unfortunately we seem to lack the manpower to get this done, so I am fine with exploring option 3. My only concern with this, is that it will increase the workload for service releases. Either way, as I said on IRC, I think we should give option 3 a try for our next major release, and revert back to supporting a single kernel version per release if that proves to be too difficult to maintain. For > 4.9, please have a look at https://git.lede-project.org/?p=lede/stintel/staging.git;a=shortlog;h=refs/heads/kernel This was in perfect shape, but I messed up when reworking after the split of patches directory to {backport,hack,pending}. Nonetheless it should be easier to start from there than to redo everything from scratch. Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address
On 10/08/2017 05:06 PM, Hauke Mehrtens wrote: > The boot process on a WRT54GL works the following way: > 1. CFE gets loaded by the boot rom from flash > 2. CFE loads the loader from the flash and gzip uncompresses it > 3. CFE starts the loader > 4. The loader stores the FW arguments and relocates itself to >BZ_TEXT_START (now 0x8060) > 5. The loader reads the Linux image from flash > 6. The loader lzma decompresses the Linux image to LOADADDR (0x80001000) > 7. The loader executes the uncompress Linux image at LOADADDR > > The BZ_TEXT_START was set to 0x8040 before. When the kernel gets > uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote > the loader which was currently uncompressing it and made the board > crash. Increase the BZ_TEXT_START my 2 MB to have more space for the > kernel. Even on 16MB RAM devices the memory goes till 0x80FF so this > should not be a problem. > > Signed-off-by: Hauke Mehrtens > --- > target/linux/brcm47xx/image/lzma-loader/src/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile > b/target/linux/brcm47xx/image/lzma-loader/src/Makefile > index 3320e565d0..444039c558 100644 > --- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile > +++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile > @@ -18,7 +18,7 @@ > # > > TEXT_START := 0x80001000 > -BZ_TEXT_START:= 0x8040 > +BZ_TEXT_START:= 0x8060 > > OBJCOPY := $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R > .note -R .comment -R .mdebug -S This makes my WRT54GS boot a kernel 4.9 with CONFIG_KALLSYMS. Without this patch it is not booting up. The FW arguments are more or less useless, I got these in Linux from CFE forwarded by the loader: fw_arg0: 0x803401a0, fw_arg1: 0x0, fw_arg2: 0x803029c8, fw_arg3: 0x43464531 They are pointing somewhere into CFE: Total memory used by CFE: 0x8030 - 0x8043DF30 (1302320) Initialized Data: 0x803381A0 - 0x8033A550 (9136) BSS Area: 0x8033A550 - 0x8033BF30 (6624) Local Heap:0x8033BF30 - 0x8043BF30 (1048576) Stack Area:0x8043BF30 - 0x8043DF30 (8192) Text (code) segment: 0x8030 - 0x803381A0 (229792) Boot area (physical): 0x0043E000 - 0x0047E000 Relocation Factor: I: - D: See section 8.2.3 "Registers passed to boot loaders" for details on what these arguments mean: http://melbourne.wireless.org.au/files/wrt54/cfe.pdf Our image does not use them anyway so this is also save. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] brcm47xx: relocate the stack in loader
By default we are reusing the stack provided by CFE, like it is intended by CFE. On my WRT54GS it is located at 0x8043BF30, so a big kernel image could overwrite it. Relocate it to a different memory region which is still under the 8MB RAM, but in the higher area. We only need this memory region for the stack of the loader, Linux will set up this for its own. Signed-off-by: Hauke Mehrtens --- target/linux/brcm47xx/image/lzma-loader/src/Makefile | 5 +++-- target/linux/brcm47xx/image/lzma-loader/src/head.S | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile b/target/linux/brcm47xx/image/lzma-loader/src/Makefile index 444039c558..a08fc05b9f 100644 --- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile +++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile @@ -19,6 +19,7 @@ TEXT_START := 0x80001000 BZ_TEXT_START := 0x8060 +BZ_STACK_START := 0x8070 OBJCOPY:= $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R .note -R .comment -R .mdebug -S @@ -28,9 +29,9 @@ CFLAGS= -D__KERNEL__ -Wall -Wstrict-prototypes -Wno-trigraphs -Os \ -mabi=32 -march=mips32 -Wa,-32 -Wa,-march=mips32 -Wa,-mips32 -Wa,--trap CFLAGS += -DLOADADDR=$(TEXT_START) -D_LZMA_IN_CB -ASFLAGS= $(CFLAGS) -D__ASSEMBLY__ -DBZ_TEXT_START=$(BZ_TEXT_START) +ASFLAGS= $(CFLAGS) -D__ASSEMBLY__ -DBZ_TEXT_START=$(BZ_TEXT_START) -DBZ_STACK_START=$(BZ_STACK_START) -SEDFLAGS := s/BZ_TEXT_START/$(BZ_TEXT_START)/;s/TEXT_START/$(TEXT_START)/ +SEDFLAGS := s/BZ_TEXT_START/$(BZ_TEXT_START)/;s/BZ_STACK_START/$(BZ_STACK_START)/;s/TEXT_START/$(TEXT_START)/ OBJECTS:= head.o data.o diff --git a/target/linux/brcm47xx/image/lzma-loader/src/head.S b/target/linux/brcm47xx/image/lzma-loader/src/head.S index 930c9ba277..50c159ce57 100644 --- a/target/linux/brcm47xx/image/lzma-loader/src/head.S +++ b/target/linux/brcm47xx/image/lzma-loader/src/head.S @@ -38,6 +38,7 @@ .text LEAF(startup) .set noreorder + li sp, BZ_STACK_START addisp, -48 sw a0, 16(sp) sw a1, 20(sp) -- 2.11.0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
Hi Stijn, That was quick. Thanks! Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address
On 10/08/2017 08:29 AM, Hauke Mehrtens wrote: > On 10/08/2017 05:06 PM, Hauke Mehrtens wrote: >> The boot process on a WRT54GL works the following way: >> 1. CFE gets loaded by the boot rom from flash >> 2. CFE loads the loader from the flash and gzip uncompresses it >> 3. CFE starts the loader >> 4. The loader stores the FW arguments and relocates itself to >>BZ_TEXT_START (now 0x8060) >> 5. The loader reads the Linux image from flash >> 6. The loader lzma decompresses the Linux image to LOADADDR (0x80001000) >> 7. The loader executes the uncompress Linux image at LOADADDR >> >> The BZ_TEXT_START was set to 0x8040 before. When the kernel gets >> uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote >> the loader which was currently uncompressing it and made the board >> crash. Increase the BZ_TEXT_START my 2 MB to have more space for the >> kernel. Even on 16MB RAM devices the memory goes till 0x80FF so this >> should not be a problem. >> >> Signed-off-by: Hauke Mehrtens >> --- >> target/linux/brcm47xx/image/lzma-loader/src/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile >> b/target/linux/brcm47xx/image/lzma-loader/src/Makefile >> index 3320e565d0..444039c558 100644 >> --- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile >> +++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile >> @@ -18,7 +18,7 @@ >> # >> >> TEXT_START := 0x80001000 >> -BZ_TEXT_START := 0x8040 >> +BZ_TEXT_START := 0x8060 >> >> OBJCOPY := $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R >> .note -R .comment -R .mdebug -S > > > This makes my WRT54GS boot a kernel 4.9 with CONFIG_KALLSYMS. Without > this patch it is not booting up. > > The FW arguments are more or less useless, I got these in Linux from CFE > forwarded by the loader: > fw_arg0: 0x803401a0, fw_arg1: 0x0, fw_arg2: 0x803029c8, fw_arg3: 0x43464531 Yes, those do not really matter on brcm47xx since the CFE environment and all associated services (cfe_getenv, cfe_write) are not available anyway... > > They are pointing somewhere into CFE: > > Total memory used by CFE: 0x8030 - 0x8043DF30 (1302320) > Initialized Data: 0x803381A0 - 0x8033A550 (9136) > BSS Area: 0x8033A550 - 0x8033BF30 (6624) > Local Heap:0x8033BF30 - 0x8043BF30 (1048576) > Stack Area:0x8043BF30 - 0x8043DF30 (8192) > Text (code) segment: 0x8030 - 0x803381A0 (229792) > Boot area (physical): 0x0043E000 - 0x0047E000 > Relocation Factor: I: - D: > > See section 8.2.3 "Registers passed to boot loaders" for details on what > these arguments mean: > http://melbourne.wireless.org.au/files/wrt54/cfe.pdf > > Our image does not use them anyway so this is also save. > > > Hauke > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > -- Florian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
Citeren Hauke Mehrtens : On 10/08/2017 01:31 PM, Andrey Jr. Melnikov wrote: Arjen de Korte wrote: Citeren Hauke Mehrtens : This adds support for kernel 4.9. Please test this, I am lacking especially NAND devices. The most recent version of these patches can be found here: https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx Hauke Mehrtens (4): ar71xx: Copy kernel 4.4 code for kernel 4.9 ar71xx: make the target compile with kernel 4.9 ar71xx: fix section mismatches ar71xx: switch to kernel 4.9 by default I checked the above patches on a WNDR4300 (a NAND device). No issues when building, but the device entered a bootloop after flashing with sysupgrade. Since this is a production system, I didn't have time to dig into what is exactly causing this. ar934x NAND driver missing cmd_ctrl() function - so NAND devices not work at all. [3.575549] nand: chip.cmd_ctrl() callback is not provided [3.581103] ar934x-nfc ar934x-nfc: nand_scan_ident failed, err:-22 [3.587515] ar934x-nfc: probe of ar934x-nfc failed with error -22 Hi, Thanks for testing and reporting back. I tried to fix this problem, can you please try the most recent version from my git tree. This now has this additional change: https://git.lede-project.org/?p=lede/hauke/staging.git;a=commitdiff;h=42a49cbca96875be43913688da60d637cbdff604 Tested your staging tree on a WNDR4300, looking well. I'll keep an eye on it over the next few days. Regards, Arjen ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
Thanks. I compiled kernel 4.9 for my old WNDR3700v2 and WNDR3800. Both routers booted ok and seem to work ok at the first glance. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address
Hi Hauke, > When the kernel gets uncompressed and is bigger than > BZ_TEXT_START - LOADADDR it overwrote the loader which was currently > uncompressing > it and made the board crash. Currently, BZ_TEXT_START - LOADADDR = 0x8040 - 0x80001000 = 3FF000 = 4190208 bytes Today's trunk brcm47xx kernel is 4069124 bytes. So increasing the address is actually just a preventive countermeasure for future kernels.(?) The WRT54GL CFEs seem to use a memory area about half the size of your WRT54GS' So I guess, the actual problem for the WRT54GL was that the stack was smashed? Once my compiling machine finishes your ar71xx with kernel 4.9, I'll test this one here :-) Happy to see, that this problem seems to be solved. Regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address
Citeren p.wa...@gmx.at: Hi Hauke, When the kernel gets uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote the loader which was currently uncompressing it and made the board crash. Currently, BZ_TEXT_START - LOADADDR = 0x8040 - 0x80001000 = 3FF000 = 4190208 bytes Today's trunk brcm47xx kernel is 4069124 bytes. So increasing the address is actually just a preventive countermeasure for future kernels.(?) The change from 4.4 to 4.9, will add approximately 500 kbytes to the kernel (assuming the increase will be similar as for ar71xx), so this won't fit anymore. So this preventive measure may be needed sooner than you think. The WRT54GL CFEs seem to use a memory area about half the size of your WRT54GS' So I guess, the actual problem for the WRT54GL was that the stack was smashed? Once my compiling machine finishes your ar71xx with kernel 4.9, I'll test this one here :-) Happy to see, that this problem seems to be solved. Regards, P. Wassi ___ 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] [PATCH] brcm47xx: relocate loader to higher address
On 10/08/2017 09:25 PM, p.wa...@gmx.at wrote: > Hi Hauke, > >> When the kernel gets uncompressed and is bigger than >> BZ_TEXT_START - LOADADDR it overwrote the loader which was currently >> uncompressing >> it and made the board crash. > > Currently, BZ_TEXT_START - LOADADDR = 0x8040 - 0x80001000 = 3FF000 = > 4190208 bytes > Today's trunk brcm47xx kernel is 4069124 bytes. So increasing the address is > actually > just a preventive countermeasure for future kernels.(?) > The WRT54GL CFEs seem to use a memory area about half the size of your > WRT54GS' > So I guess, the actual problem for the WRT54GL was that the stack was smashed? > > Once my compiling machine finishes your ar71xx with kernel 4.9, I'll test > this one here :-) > > Happy to see, that this problem seems to be solved. Hi, The stack was not a problem with my kernel, I just added it to prevent later problems, now I debugged this, I do not want to debug this again in 2 years. My vmlinux kernel file is 4277380 bytes, so bigger than the available size you calculated. The stack starts at 0x8043BF30 so there are 4435760 bytes available till my image would overwrite the stack. It does not matter where CFE is located as we do not need it any more after the loader started, we will never jump back into it and use the memory region used for CFE later also for Linux. With both patches there is now almost 6 MB space available. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ipset-dns - does anybody actually use this?
One usecase not currently supported is managing dnsmasq ipset lists through LuCI, which enables anyone to maintain them. With ipset-dns this is easy to do using LuCI "dhcp.@dnsmasq[0].server" entries. If it was added, I think ipset-dns could be deprecated. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
Will this also work on WNDR3700v4? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9
Citeren Paul Blazejowski : Will this also work on WNDR3700v4? I guess so, the image for the WNDR3700v4 is the same as for the WNDR4300v1. I can confirm the version from Hauke's staging tree works on the latter, so it is likely that it will also work for the first too. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Kernel version in next major release
On 10/08/2017 01:18 AM, David Lang wrote: > On Sat, 7 Oct 2017, Hauke Mehrtens wrote: > >> * Port the generic patches > > what are the 'generic patches' and is there an effort to get them > upstream so that they don't need to be ported in each release? Some of them are backports from more recent kernel versions, some are on their way upstream and some are hacks, see the patches here: https://git.lede-project.org/?p=source.git;a=tree;f=target/linux/generic/backport-4.9 https://git.lede-project.org/?p=source.git;a=tree;f=target/linux/generic/pending-4.9 https://git.lede-project.org/?p=source.git;a=tree;f=target/linux/generic/hack-4.9 It would be good to make most of this upstream. >> * Make all the out of tree modules work with it > > is there any work being done to make these in-tree? It depends these are mostly drivers or other kernel modules which are not mainly developed for LEDE. >> * Port all targets to this kernel version >> * Some targets are not so well maintained any more and there an >> additional delay could be introduced. > > do we have a list of these devices? do any of these warrent "we need a > maintainer or they won't be supported" calls? I think mvebu is on of the targets which is popular, but not so well maintained. All the targets which are still at 3.18 are not well maintained for sure. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Tue, 3 Oct 2017 03:27:21 +0300 Sergey Ryazanov wrote: > After these lines, I carefully examine available data about WRT300Nv2 > and related code and found several interesting things. > > Usually SoC in the router have only one ethernet interface and vendors > pair it with manageable switch IC. This swith IC accepts packets from > LAN and WAN ports, then it tags them and forward to the SoC. Thus, > using VLAN tags, SoC can distinguish from which port the packet was > received and handle it appropriately. So the firmware should contains > a driver for switch IC to be able to properly configure ports and > VLANs inside the switch. > > In case of WRT300Nv2 the SoC contains two ethernet adapters: NPE-C > (eth1), which has own phy and acted as a WAN port and NPE-B (eth0), > which is connected to switch IC, each port of which is acting as LAN > port. So since all ports of switch are equal then the switch themself > requires a minimal (if any) configuration. And this router can > possibly act without any special driver for switch IC. > > Also I found why the switch is properly detected on the MDIO bus but > not used as phy-device. This happened because PHY ID for eth0 is > hardcoded inside WRT300Nv2 setup code. > > To check whether your board can act without dedicated driver for 88E6060: > * revert any earlier modifications to LEDE if you do any > * disable any drivers for 88E6060 (e.g. disable both > CONFIG_NET_DSA_MV88E6060 and CONFIG_MVSWITCH_PHY) > * place attached patch to the target/linux/ixp4xx/patches-4.4 > * rebuild and boot new firmware > * check dmesg for "eth0: link up" message > * check eth0 functioning: check packets receiving with tcpdump or > manually assign IP address to the eth0 interface (without any VLAN's > and so on) and try to ping. I did this, and now when booting I see [0.999140] eth0: MII PHY 32 on NPE-B [1.005714] eth1: MII PHY 1 on NPE-C ... [6.531972] NPE-B: firmware functionality 0x2, revision 0x2:1 [6.540066] eth0: link up, speed 100 Mb/s, full duplex [9.070970] mount_root: jffs2 not ready yet, using temporary tmpfs overlay [9.118732] urandom-seed: Seed file not found (/etc/urandom.seed) [9.250596] eth0: link down I assigned IP with a command ip a a 192.168.0.10/24 dev eth0 but ping from PC does not answer. ifconfig -a shows a few RX and TX packets: eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.0.10 Bcast:0.0.0.0 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 but the packet count does not increase after pinging. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
On Sun, Oct 8, 2017 at 11:12 PM, Nerijus Baliunas wrote: > I assigned IP with a command > ip a a 192.168.0.10/24 dev eth0 > > but ping from PC does not answer. > > ifconfig -a shows a few RX and TX packets: > eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE > inet addr:192.168.0.10 Bcast:0.0.0.0 Mask:255.255.255.0 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:5 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 > > but the packet count does not increase after pinging. Have you bring eth0 UP? I mean, could you do "ifconfig eth0 192.168.0.10 up" and try pinging again? -- Sergey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Sun, 8 Oct 2017 23:44:58 +0300 Sergey Ryazanov wrote: > > I assigned IP with a command > > ip a a 192.168.0.10/24 dev eth0 > > > > but ping from PC does not answer. > > Have you bring eth0 UP? I mean, could you do "ifconfig eth0 > 192.168.0.10 up" and try pinging again? Just tried: # ifconfig eth0 192.168.0.10 up ifconfig: SIOCSIFFLAGS: Out of memory # dmesg|grep eth [0.998445] eth0: MII PHY 32 on NPE-B [1.005134] eth1: MII PHY 1 on NPE-C [6.540687] eth0: link up, speed 100 Mb/s, full duplex [9.323993] eth0: link down [ 36.266247] device eth0 entered promiscuous mode # ifconfig eth0 192.168.0.10 up ifconfig: SIOCSIFFLAGS: Out of memory # ifconfig -a br-lanLink encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fde1:e263:bcc::1/60 Scope:Global UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:92 (92.0 B) TX bytes:1551 (1.5 KiB) Ping still does not answer. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
On Mon, Oct 9, 2017 at 12:00 AM, Nerijus Baliunas wrote: > On Sun, 8 Oct 2017 23:44:58 +0300 Sergey Ryazanov > wrote: >> > I assigned IP with a command >> > ip a a 192.168.0.10/24 dev eth0 >> > >> > but ping from PC does not answer. >> >> Have you bring eth0 UP? I mean, could you do "ifconfig eth0 >> 192.168.0.10 up" and try pinging again? > > Just tried: > # ifconfig eth0 192.168.0.10 up > ifconfig: SIOCSIFFLAGS: Out of memory > # dmesg|grep eth > [0.998445] eth0: MII PHY 32 on NPE-B > [1.005134] eth1: MII PHY 1 on NPE-C > [6.540687] eth0: link up, speed 100 Mb/s, full duplex > [9.323993] eth0: link down > [ 36.266247] device eth0 entered promiscuous mode Check please, is there any new kernel messages after 'ifconfig ... up' failure (may be not directly related to eth0). Just run dmesg without grep. It is also stranger that something bring eth0 up and then putting it back to down. Is these strings (eth0: link up/eth0: link down) appear in the kernel log during preinit procedure? -- Sergey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Mon, 9 Oct 2017 01:31:29 +0300 Sergey Ryazanov wrote: > > Just tried: > > # ifconfig eth0 192.168.0.10 up > > ifconfig: SIOCSIFFLAGS: Out of memory > > # dmesg|grep eth > > [0.998445] eth0: MII PHY 32 on NPE-B > > [1.005134] eth1: MII PHY 1 on NPE-C > > [6.540687] eth0: link up, speed 100 Mb/s, full duplex > > [9.323993] eth0: link down > > [ 36.266247] device eth0 entered promiscuous mode > > Check please, is there any new kernel messages after 'ifconfig ... up' > failure (may be not directly related to eth0). Just run dmesg without > grep. I don't see anything suspicious. The full serial console log (dmesg included) is here - https://paste.fedoraproject.org/paste/P5sDjdpJr1hFZ-hp~Prwcw > It is also stranger that something bring eth0 up and then putting it > back to down. Is these strings (eth0: link up/eth0: link down) appear > in the kernel log during preinit procedure? Seems so: [4.981198] init: - preinit - [6.473760] random: jshn: uninitialized urandom read (4 bytes read, 10 bits of entropy available) [6.544511] random: jshn: uninitialized urandom read (4 bytes read, 10 bits of entropy available) [6.761251] NPE-B: firmware's license can be found in /usr/share/doc/LICENSE.IPL [6.768796] NPE-B: firmware functionality 0x2, revision 0x2:1 [6.776745] eth0: link up, speed 100 Mb/s, full duplex Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level [ 10.310754] mount_root: jffs2 not ready yet, using temporary tmpfs overlay [ 10.359891] urandom-seed: Seed file not found (/etc/urandom.seed) [ 10.492841] eth0: link down Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev