Re: [OpenWrt-Devel] Second RGMII ethernet on MT7621?
John Crispin writes: > making gmac2 work s not trivial with the current driver. Thanks for confirming. Then I guess I can just wrap up what I have and make it public. Just want to figure out how the LEDs are connected first. Bootloader initiated blinking patterns are persistent, so I'm guessing some I2C(?) connected controller. Or something.. > however making the upstream mtk_eth_soc driver work on mt7621 is > pretty easy i think and will give you dual gmac support. upstream only > supports mt7623 arm atm. its been on my todo list for a while but i > simply have not been able to find the 2-3 days required to make it > work. I wish I could help. But I have enough self-insight to realize that it is way beyond my capabilities, after a quick look at the driver. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06 Status?
I think that the main source tree is in pretty good shape, so branching off the 18.0X rather soon might make sense. There is alweays the next new exiting feature to be included in, but if the intention is still to make several major releases per year, the next feature will get into the next release rather soon. So little stuff gets backported to 17.01, that a possible 17.01.5 would be just a quick temporary fix, not a proper solution. jow was talking about that ealier, and a 17.01.5 might be ok as a stopgap or "safe upgrade" from 17.01.x. If 17.01.5 is really made, at least the mvebu mwlwifi driver should be updated first. 17.01 still has the ancient June 2017 version of mwlwifi driver, while master was recently upgrdaed to 2018-03-30 that is likely the best driver version so far. Jaap Buurman kirjoitti 1.5.2018 klo 16:44: Dear all, If a 18.06 release is still going to require quite a bit of work, I propose we should look at another 17.01 point release. That should be a nice stopgap in the form of bug fixes for people that are still running a stable release. 17.01.4 is getting ancient to be honest. What do you think? Yours sincerely, Jaap Buurman On Tue, May 1, 2018 at 2:53 PM, Rich Brown wrote: Hi folks, It has been exactly a month since Hauke sent his note recommending a release process for the next OpenWrt stable. http://lists.infradead.org/pipermail/lede-dev/2018-April/011704.html I have not seen any further discussion of this proposal. Given that the OpenWrt/LEDE merger was founded on the desire to improve communication, I am concerned that we're not talking to each other about important questions. It would be OK if we all agreed that we have too many pieces in flux to talk about a stable release. But I don't think it's too soon to talk about pausing the project evolution briefly and making the hard decisions about what's in, what's out. Then most people (who're unwilling to run a snapshot) can get the benefit of all your effort over the last year. Thanks for listening, Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-29 21:32, Roman Yeryomin wrote:
On 2018-04-27 09:18, John Crispin wrote:
On 17/04/18 00:34, Roman Yeryomin wrote:
On 2018-04-15 20:22, Roman Yeryomin wrote:
On 2018-04-14 20:36, Hans Ulli Kroll wrote:
Hi Roman
On Tue, 10 Apr 2018, Linus Walleij wrote:
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin
wrote:
> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?
I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself
+diff --git a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct
usb_hcd
*hcd, u16 typeReq, u16 wValue,
+ /* see what we found out */
+ temp = check_reset_complete(fotg210, wIndex,
status_reg,
+ fotg210_readl(fotg210, status_reg));
++
++ /* restart schedule */
++ fotg210->command |= CMD_RUN;
++ fotg210_writel(fotg210, fotg210->command,
&fotg210->regs->command);
+ }
+
+ if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+
Didn't work for me :(
I've found why it didn't work:
[ 5.845199] Warning! fotg210_hcd should always be loaded before
uhci_hcd and ohci_hcd, not after
After fixing kernel config and applying your patch it works.
So your patch works and is needed indeed.
But there are other problems.
Second USB (USB1) port cannot be initialized and only USB0 is
working:
[ 5.843831] fotg210_hcd: FOTG210 Host Controller (EHCI) Driver
[ 5.844298] pinctrl-gemini 4000.syscon:pinctrl: ACTIVATE
function "usb" with group "usbgrp"
[ 5.845067] fotg210-hcd 6800.usb: initialized Gemini PHY
[ 5.845095] fotg210-hcd 6800.usb: Faraday USB2.0 Host
Controller
[ 5.845176] fotg210-hcd 6800.usb: new USB bus registered,
assigned bus number 1
[ 5.845696] fotg210-hcd 6800.usb: irq 29, io mem 0x6800
[ 5.877212] fotg210-hcd 6800.usb: USB 2.0 started, EHCI 1.00
[ 5.880314] hub 1-0:1.0: USB hub found
[ 5.880546] hub 1-0:1.0: 1 port detected
[ 5.904768] pinctrl-gemini 4000.syscon:pinctrl: pin T6 USB
GNDA U20 already requested by 6800.usb; cannot claim for
6900.usb
[ 5.904807] pinctrl-gemini 4000.syscon:pinctrl: pin-305
(6900.usb) status -22
[ 5.904845] pinctrl-gemini 4000.syscon:pinctrl: could not
request pin 305 (T6 USB GNDA U20) from group usbgrp on device
pinctrl-gemini
[ 5.904872] fotg210-hcd 6900.usb: Error applying setting,
reverse things back
[ 5.904928] fotg210-hcd: probe of 6900.usb failed with error
-22
After removing pinctrl from USB1 it is initialized but then only USB1
is working, USB0 is seen but there are no interrupts.
Didn't yet look at the code, maybe you will know where to fix right
away.
Regards,
Roman
Hi,
how shall we proceed ? merge 1, 2 and 3, let roman fix the regressions
and then merge 4 ? or drop the series for now and let you guys send a
V2 with the regression fixes integrated ?
Hi John,
I've prepared 4.14 branch here
https://github.com/yeryomin/openwrt/commits/gemini-4.14
I think it can be merged in it's current state. The only problem I'm
aware of is that usb is not fully working (afaik, Hans is working on
it).
Linus, could you test that branch on your device and see if network is
working by default?
Linus, if you have time, could you check if this helps to bring network
up on dir-685?
https://github.com/yeryomin/openwrt/commit/b0296b1f71bd3d677c931addd6de341203fbf18f
Note I have disabled video and input drivers, since dir-685 seems is the
only board which could potentially use them. And ili display wasn't
enabled anyway.
All those modules can be enabled via kernel modules. If you could test
the needed set we could add them to dir-685 packages.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ag71xx packet loss on AR9342 rev 3 / Zyxel NWA1123-AC
Hi! I am trying to make OpenWrt work on ZyXEL NWA1123-AC, I have created the entry on the OpenWrt toh page in 2015: https://openwrt.org/toh/zyxel/nwa1123-ac The corresponding forum is: https://forum.openwrt.org/viewtopic.php?id=56608 I am currently focusing on the LAN part. I fetched OpenWrt r6796-56ae9f9 and compiled it. Using the board parameter DB120 the LAN interface somehow works, but with strange packet loss. I realized this when I tried pinging from both sides: OpenWrt -> PC: ~22% packet loss PC -> OpenWrt: ~85% packet loss I monitored the direction OpenWrt -> PC with wireshark: if a loss happens, there is no ICMP echo REQUEST packet on the network, so the problem seems to be with the TX on the OpenWrt side. For the other direction PC -> OpenWrt I used the output from ifconfig: if a loss happens, indeed the RX and TX byte values increase, but there is no ICMP echo REPLY packet from OpenWrt on the network. The driver used is the ag71xx. I am not sure if the problem is in the driver for the built-in switch or for the LAN PHY. Perhaps these lines from the kernel boot messages will be helpful (see the full output below): [0.978637] libphy: Fixed MDIO Bus: probed [1.002134] libphy: ag71xx_mdio: probed [1.011246] libphy: ag71xx_mdio: probed [1.745154] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd072, driver=Atheros 8035 ethernet] [1.756139] eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII [2.386369] ag71xx-mdio.1: Found an AR934X built-in switch [2.438864] eth1: Atheros AG71xx at 0xba00, irq 5, mode:GMII Can you tell me how I can enable driver debugging? I'd guess there would be some helpful error messages. Any other suggestions are gratefully welcomed too! Thanks in advance! Cheers, Christian Full output from dmesg below: [0.00] Linux version 4.9.96 (chr@charlie) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r6796-56ae9f9) ) #0 Mon Apr 30 08:12:55 2018 [0.00] MyLoader: sysp=8829cc2d, boardp=82234a80, parts=06091402 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 0001974c (MIPS 74Kc) [0.00] SoC: Atheros AR9342 rev 3 [0.00] Determined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] User-defined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] On node 0 totalpages: 16384 [0.00] free_area_init_node: node 0, pgdat 80463dd4, node_mem_map 8120 [0.00] Normal zone: 128 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 16384 pages, LIFO batch:3 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: board=DB120 console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),8192k(rootfs),960k(uImage),6528k(reserve),256k(config),64k(mib0),64k(ART) mem=64M rootfstype=squashfs noinitrd [0.00] PID hash table entries: 256 (order: -2, 1024 bytes) [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] Memory: 59896K/65536K available (3153K kernel code, 170K rwdata, 792K rodata, 292K init, 213K bss, 5640K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:51 [0.00] Clocks: CPU:560.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:40.000MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 6825930166 ns [0.10] sched_clock: 32 bits at 280MHz, resolution 3ns, wraps every 7669584382ns [0.008332] Calibrating delay loop... 278.93 BogoMIPS (lpj=1394688) [0.081153] pid_max: default: 32768 minimum: 301 [0.086190] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.093245] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.103874] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.114383] futex hash table
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin wrote: > I've prepared 4.14 branch here > https://github.com/yeryomin/openwrt/commits/gemini-4.14 > I think it can be merged in it's current state. The only problem I'm aware > of is that usb is not fully working (afaik, Hans is working on it). I also think it should be merged as this, it will be a good base for Hans to work on the USB stuff. > Linus, could you test that branch on your device and see if network is > working by default? I've pulled in the branch and building it for D-Link DNS-313 right now. Will report back. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin wrote: > Linus, if you have time, could you check if this helps to bring network up > on dir-685? > https://github.com/yeryomin/openwrt/commit/b0296b1f71bd3d677c931addd6de341203fbf18f Wow OK I will test that too. > Note I have disabled video and input drivers, since dir-685 seems is the > only board which could potentially use them. And ili display wasn't enabled > anyway. That's fine, it's no regression anyways. v4.16+ we can add the bizarre graphics and input capabilities. I was planning to port "iptraf" or something else that just use ncurses and run that on the console, eventually so there is some use for it. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
I have been Eyeing your Gemni patches - any chance for support for the Goldengate SoC found in the Almond+. Currently attempting to reuse it for a home automation project but it's ancient kernel is terrible and even doing basic things like vlans are horribly broken with the Securfi hacked up NutsOS that runs on top of ancient openwrt. -Joel On 5 April 2018 at 08:34, Linus Walleij wrote: > This patch set forward-ports Gemini to v4.14 with as good > support as I can get. > > I don't know if all or any patches actually make it through > to the devel list. They are also posted here: > > https://dflund.se/~triad/krad/gemini/openwrt/ > > It would be nice if we could apply this and get a working > modernized base for the Gemini platforms. > > The v4.14 is a bit patchy. With v4.16 we will be looking > pretty neat. > > Linus Walleij (4): > firmware-utils: Add the DNS-313 image header tool > gemini: Forward-port to v4.14 > gemini: Add kernel v4.14 patches > gemini: Delete kernel 4.4 patches > > target/linux/gemini/Makefile | 15 +- > .../linux/gemini/base-files/etc/board.d/03_hdparm | 14 + > .../base-files/lib/preinit/05_set_ether_mac_gemini | 25 +- > target/linux/gemini/config-4.14| 587 > target/linux/gemini/config-4.4 | 165 - > .../files/arch/arm/mach-gemini/include/mach/gmac.h | 21 - > .../linux/gemini/files/arch/arm/mach-gemini/pci.c | 318 -- > .../linux/gemini/files/drivers/ata/pata_gemini.c | 234 -- > .../files/drivers/net/ethernet/gemini/Kconfig | 31 - > .../files/drivers/net/ethernet/gemini/Makefile |5 - > .../files/drivers/net/ethernet/gemini/sl351x.c | 2340 - > .../files/drivers/net/ethernet/gemini/sl351x_hw.h | 1436 > .../gemini/files/drivers/usb/host/ehci-fotg2.c | 258 -- > .../gemini/files/drivers/watchdog/gemini_wdt.c | 378 -- > target/linux/gemini/image/Makefile | 166 +- > target/linux/gemini/image/dns313-header/Makefile | 34 + > .../gemini/image/dns313-header/dns313-header.c | 239 ++ > target/linux/gemini/image/slask.mk | 56 + > .../0001-cache-patch-from-OpenWRT.patch} |9 + > ...0002-pinctrl-gemini-Add-missing-functions.patch | 33 + > ...ARM-dts-Add-TVE200-to-the-Gemini-SoC-DTSI.patch | 51 + > ...rl-Add-skew-delay-pin-config-and-bindings.patch | 73 + > ...0005-pinctrl-gemini-Use-generic-DT-parser.patch | 112 + > ...-gemini-Implement-clock-skew-delay-config.patch | 280 ++ > .../0007-pinctrl-gemini-Fix-GMAC-groups.patch | 186 + > ...nctrl-gemini-Fix-missing-pad-descriptions.patch | 27 + > ...inctrl-gemini-Add-two-missing-GPIO-groups.patch | 25 + > ...0-pinctrl-gemini-Fix-usage-of-3512-groups.patch | 25 + > ...trl-gemini-Support-drive-strength-setting.patch | 198 ++ > ...d-ethernet-PHYs-to-the-a-bunch-of-Geminis.patch | 113 + > ...s-Add-basic-devicetree-for-D-Link-DNS-313.patch | 272 ++ > ...RM-dts-Flags-D-Link-DIR-685-I2C-bus-gpios.patch | 27 + > ...0015-ARM-dts-Add-PCI-to-WBD111-and-WBD222.patch | 74 + > ...-Add-TVE-TVC-and-ILI9322-panel-to-DIR-685.patch | 113 + > ...tchdog-gemini-ftwdt010-rename-DT-bindings.patch | 88 + > ...gemini-ftwdt010-rename-driver-and-symbols.patch | 527 +++ > ...watchdog-ftwdt010-Make-interrupt-optional.patch | 93 + > .../0020-soc-Add-SoC-driver-for-Gemini.patch | 113 + > ...t-Add-DT-bindings-for-the-Gemini-ethernet.patch | 119 + > ...t-Add-a-driver-for-Gemini-gigabit-etherne.patch | 3661 > > ...23-ARM-dts-Add-ethernet-to-the-Gemini-SoC.patch | 74 + > .../0024-net-gemini-Depend-on-HAS_IOMEM.patch | 30 + > ...-dts-Set-D-Link-DNS-313-SATA-to-muxmode-0.patch | 36 + > ...r-gemini-poweroff-Avoid-spurious-poweroff.patch | 80 + > ...sb-host-add-DT-bindings-for-faraday-fotg2.patch | 65 + > ...28-usb-host-fotg2-add-device-tree-probing.patch | 61 + > ...usb-host-fotg2-add-silicon-clock-handling.patch | 99 + > ...b-host-fotg2-add-Gemini-specific-handling.patch | 131 + > ...RM-dts-Add-the-FOTG210-USB-host-to-Gemini.patch | 178 + > .../linux/gemini/patches-4.4/050-gpio-to-irq.patch | 21 - > .../110-watchdog-add-gemini_wdt-driver.patch | 29 - > .../111-arm-gemini-add-watchdog-device.patch | 33 - > .../112-arm-gemini-register-watchdog-devices.patch | 40 - > .../120-net-add-gemini-gmac-driver.patch | 20 - > .../121-arm-gemini-add-gmac-device.patch | 85 - > .../122-arm-gemini-register-ethernet.patch | 227 -- > .../130-usb-ehci-add-fot2g-driver.patch| 133 - > .../131-arm-gemini-add-usb-device.patch| 77 - > .../patches-4.4/132-arm-gemini-register-usb.patch | 65 - > .../140-arm-gemini-add-pci-support.patch | 66 - > .../linux/gemini/patches-4.4/150-gemini-pata.patch | 192 - > target/linux/gemini/raidsonic/config-default |5 - > target/linux/gemini/rai
