Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Sat, May 5, 2018 at 5:19 PM, Roman Yeryomin wrote: > On 2018-05-05 17:32, Linus Walleij wrote: >> >> 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 >> >> >> Sadly not. At least not outofthebox. I do not know what other >> devices using the RTL8366RB is doing apart from this. > > > What did dmesg say about it? > Did you try swconfig tool? E.g. `swconfig list` and/or `swconfig dev switch0 > show` I had to add swconfig and the kmod for the rtl8366rb and make a patch to the device tree first. (I will send this separately.) Then things happened! [ 19.087592] Realtek RTL8366RB ethernet switch driver version 0.2.4 [ 19.125518] rtl8366rb rtl8366rb: using GPIO pins 502 (SDA) and 501 (SCK) [ 19.167312] rtl8366rb rtl8366rb: RTL5937 ver. 3 chip found [ 19.960943] libphy: rtl8366rb: probed root@OpenWrt:/# swconfig list Found: switch0 - rtl8366rb root@OpenWrt:~# swconfig dev switch0 show Global attributes: enable_learning: 1 enable_vlan: 1 enable_vlan4k: 0 blinkrate: 0 enable_qos: 1 enable_mirror_rx: 0 enable_mirror_tx: 0 enable_monitor_isolation: 0 enable_mirror_pause_frames: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters IfInOctets : 696 EtherStatsOctets: 696 EtherStatsUnderSizePkts : 0 EtherFragments : 0 EtherStatsPkts64Octets : 0 EtherStatsPkts65to127Octets : 0 EtherStatsPkts128to255Octets: 4 EtherStatsPkts256to511Octets: 0 EtherStatsPkts512to1023Octets : 0 EtherStatsPkts1024to1518Octets : 0 EtherOversizeStats : 0 EtherStatsJabbers : 0 IfInUcastPkts : 0 EtherStatsMulticastPkts : 4 EtherStatsBroadcastPkts : 0 EtherStatsDropEvents: 0 Dot3StatsFCSErrors : 0 Dot3StatsSymbolErrors : 0 Dot3InPauseFrames : 0 Dot3ControlInUnknownOpcodes : 0 IfOutOctets : 0 Dot3StatsSingleCollisionFrames : 0 Dot3StatMultipleCollisionFrames : 0 Dot3sDeferredTransmissions : 0 Dot3StatsLateCollisions : 0 EtherStatsCollisions: 0 Dot3StatsExcessiveCollisions: 0 Dot3OutPauseFrames : 0 Dot1dBasePortDelayExceededDiscards : 0 Dot1dTpPortInDiscards : 0 IfOutUcastPkts : 0 IfOutMulticastPkts : 0 IfOutBroadcastPkts : 0 led: 2 disable: 0 rate_in: 1048512 rate_out: 1048512 pvid: 1 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters IfInOctets : 0 EtherStatsOctets: 0 EtherStatsUnderSizePkts : 0 EtherFragments : 0 EtherStatsPkts64Octets : 0 EtherStatsPkts65to127Octets : 0 EtherStatsPkts128to255Octets: 0 EtherStatsPkts256to511Octets: 0 EtherStatsPkts512to1023Octets : 0 EtherStatsPkts1024to1518Octets : 0 EtherOversizeStats : 0 EtherStatsJabbers : 0 IfInUcastPkts : 0 EtherStatsMulticastPkts : 0 EtherStatsBroadcastPkts : 0 EtherStatsDropEvents: 0 Dot3StatsFCSErrors : 0 Dot3StatsSymbolErrors : 0 Dot3InPauseFrames : 0 Dot3ControlInUnknownOpcodes : 0 IfOutOctets : 0 Dot3StatsSingleCollisionFrames : 0 Dot3StatMultipleCollisionFrames : 0 Dot3sDeferredTransmissions : 0 Dot3StatsLateCollisions : 0 EtherStatsCollisions: 0 Dot3StatsExcessiveCollisions: 0 Dot3OutPauseFrames : 0 Dot1dBasePortDelayExceededDiscards : 0 Dot1dTpPortInDiscards : 0 IfOutUcastPkts : 0 IfOutMulticastPkts : 0 IfOutBroadcastPkts : 0 led: 3 disable: 0 rate_in: 1048512 rate_out: 1048512 pvid: 2 link: port:1 link:down Port 2: mib: Port 2 MIB counters IfInOctets : 0 EtherStatsOctets: 0 EtherStatsUnderSizePkts : 0 EtherFragments : 0 EtherStatsPkts64Octets : 0 EtherStatsPkts65to127Octets : 0 EtherStatsPkts128to255Octets: 0 EtherStatsPkts256to511Octets: 0 EtherStatsPkts512to1023Octets : 0 EtherStatsPkts1024to1518Octets : 0 EtherOversizeStats : 0 EtherStatsJabbers : 0 IfInUcastPkts
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-05 16:35, Linus Walleij wrote: On Sat, May 5, 2018 at 11:25 AM, Linus Walleij wrote: On Fri, May 4, 2018 at 11:49 PM, Linus Walleij wrote: On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin wrote: The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? kmod-leds-gpio is part of DEFAULT_PACKAGES now I guess you should run menuconfig and/or clean tmp/ to refresh profile package set. Hm I ran menuconfig and it doesn't work, and removing tmp/ didn't help either, but selecting a different target and then selecting CS351x again worked... shaky. OK rebuilding this overnight and retesting. It is still not working. Do you get GPIO LEDs on your device with this? AFAICT the problem is that there is no script in /etc/modules-boot.d to load the GPIO LED module. I'm digging into it to figure out more about how this module load is supposed to work... Sorry probably bad mechanics from my side, like replacing the rootfs but not the kernel :( The good news is: it works like a charm. All vital components are running, drivers probe, modules load correctly from the hard drive. Yeah.. they should be, that's one of the most common modules here :) On Raidsonic: root@OpenWrt:/# lsmod | grep led leds_gpio 2772 0 ledtrig_heartbeat 1570 0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-05 17:32, Linus Walleij wrote: 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 Sadly not. At least not outofthebox. I do not know what other devices using the RTL8366RB is doing apart from this. What did dmesg say about it? Did you try swconfig tool? E.g. `swconfig list` and/or `swconfig dev switch0 show` Regards, Roman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [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 Sadly not. At least not outofthebox. I do not know what other devices using the RTL8366RB is doing apart from this. I built the platform with this small-ish patch on top because I needed to extract the zImage: diff --git a/target/linux/gemini/image/Makefile b/target/linux/gemini/image/Makefile index 25371f6f1358..3e122fc457ae 100644 --- a/target/linux/gemini/image/Makefile +++ b/target/linux/gemini/image/Makefile @@ -7,9 +7,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -# Build the special D-Link DNS-313 header generator tool -# needed to generate the hard disk boot images then -# build D-Link DNS-313 images using the special header tool. +# Just copy the zImage for D-Link DIR-685 +define Build/dir685-images + cp $(IMAGE_KERNEL) $(BIN_DIR)/$(IMG_PREFIX)-dir685-zImage +endef + +# Build D-Link DNS-313 images using the special header tool. # rootfs.tgz and rd.tgz contains nothing, we only need them # to satisfy the boot loader on the device. The zImage is # the only real content. @@ -79,6 +82,8 @@ define Device/dlink-dir-685 DEVICE_TITLE := D-Link DIR-685 Xtreme N Storage Router DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES) \ kmod-switch-rtl8366rb swconfig + IMAGES += dir685-image + IMAGE/dir685-image := dir685-images endef TARGET_DEVICES += dlink-dir-685 But I guess I should work on getting some proper flash image support in place for this device. I plan to repost my mainline RTL8366RB DSA patches after some redesign,they are still not working for me, but at least getting better in all other aspects, except actually providing networking :( Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Sat, May 5, 2018 at 11:25 AM, Linus Walleij wrote: > On Fri, May 4, 2018 at 11:49 PM, Linus Walleij > wrote: >> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin wrote: >> The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? >>> >>> kmod-leds-gpio is part of DEFAULT_PACKAGES now >>> I guess you should run menuconfig and/or clean tmp/ to refresh profile >>> package set. >> >> Hm I ran menuconfig and it doesn't work, and removing >> tmp/ didn't help either, but selecting a different target >> and then selecting CS351x again worked... shaky. >> >> OK rebuilding this overnight and retesting. > > It is still not working. Do you get GPIO LEDs on your > device with this? > > AFAICT the problem is that there is no script in > /etc/modules-boot.d to load the GPIO LED module. > > I'm digging into it to figure out more about how this > module load is supposed to work... Sorry probably bad mechanics from my side, like replacing the rootfs but not the kernel :( The good news is: it works like a charm. All vital components are running, drivers probe, modules load correctly from the hard drive. Tested-by: Linus Walleij Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 05/05/2018 11:25 AM, Linus Walleij wrote: > On Fri, May 4, 2018 at 11:49 PM, Linus Walleij > wrote: >> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin wrote: >> The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? >>> >>> kmod-leds-gpio is part of DEFAULT_PACKAGES now >>> I guess you should run menuconfig and/or clean tmp/ to refresh profile >>> package set. >> >> Hm I ran menuconfig and it doesn't work, and removing >> tmp/ didn't help either, but selecting a different target >> and then selecting CS351x again worked... shaky. >> >> OK rebuilding this overnight and retesting. > > It is still not working. Do you get GPIO LEDs on your > device with this? > > AFAICT the problem is that there is no script in > /etc/modules-boot.d to load the GPIO LED module. > > I'm digging into it to figure out more about how this > module load is supposed to work... AutoProbe has a optional 2. parameter for boot flags, please try to replace AUTOLOAD:=$(call AutoProbe,) with: AUTOLOAD:=$(call AutoProbe,, 1) Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Fri, May 4, 2018 at 11:49 PM, Linus Walleij wrote: > On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin wrote: > >>> The GPIO LEDs does not come up though? >>> CONFIG_LEDS_GPIO is not in config, and >>> /sys/class/leds is empty. >>> >>> Does it need a separate kmod? >> >> kmod-leds-gpio is part of DEFAULT_PACKAGES now >> I guess you should run menuconfig and/or clean tmp/ to refresh profile >> package set. > > Hm I ran menuconfig and it doesn't work, and removing > tmp/ didn't help either, but selecting a different target > and then selecting CS351x again worked... shaky. > > OK rebuilding this overnight and retesting. It is still not working. Do you get GPIO LEDs on your device with this? AFAICT the problem is that there is no script in /etc/modules-boot.d to load the GPIO LED module. I'm digging into it to figure out more about how this module load is supposed to work... Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin wrote: >> The GPIO LEDs does not come up though? >> CONFIG_LEDS_GPIO is not in config, and >> /sys/class/leds is empty. >> >> Does it need a separate kmod? > > kmod-leds-gpio is part of DEFAULT_PACKAGES now > I guess you should run menuconfig and/or clean tmp/ to refresh profile > package set. Hm I ran menuconfig and it doesn't work, and removing tmp/ didn't help either, but selecting a different target and then selecting CS351x again worked... shaky. OK rebuilding this overnight and retesting. Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-04 20:15, Linus Walleij wrote: On Fri, May 4, 2018 at 5:26 PM, Roman Yeryomin wrote: [ 11.345619] kmodloader: 3 modules could not be probed [ 11.376633] kmodloader: dependency not loaded mbcache [ 11.407619] kmodloader: dependency not loaded jbd2 I think those should be fixed now (after compiling in jbd2 and mbcache): https://github.com/yeryomin/openwrt/commit/14ff513daeb81a47d179c55f440ed652e407c32b It's working pretty well :) Thanks for efforts and testing! :) My harddisk never goes to sleep but keeps spinning due to the missing hdparm script (I guess you dropped it), but we can always fix that later, it would ideally need a way to indicate that this busybox command should get built and I don't know how to do that. Yeah... that should be addressed separately. I still have few things in TODO, will add this one too. The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? kmod-leds-gpio is part of DEFAULT_PACKAGES now I guess you should run menuconfig and/or clean tmp/ to refresh profile package set. Regards, Roman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Fri, May 4, 2018 at 5:26 PM, Roman Yeryomin wrote: >> [ 11.345619] kmodloader: 3 modules could not be probed >> [ 11.376633] kmodloader: dependency not loaded mbcache >> [ 11.407619] kmodloader: dependency not loaded jbd2 > > I think those should be fixed now (after compiling in jbd2 and mbcache): > https://github.com/yeryomin/openwrt/commit/14ff513daeb81a47d179c55f440ed652e407c32b It's working pretty well :) My harddisk never goes to sleep but keeps spinning due to the missing hdparm script (I guess you dropped it), but we can always fix that later, it would ideally need a way to indicate that this busybox command should get built and I don't know how to do that. The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-02 11:01, Linus Walleij wrote: There is some moaning in dmesg: [ 10.071561] Btrfs loaded, crc32c=crc32c-generic [ 10.105705] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.161586] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.209501] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.264368] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.312050] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.368142] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.415827] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.500774] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.548542] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.604267] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 10.651342] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.699520] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.754306] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.802014] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.855212] ehci-platform: EHCI generic platform driver [ 10.895311] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.943323] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.998070] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.045793] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.102146] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.150097] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.205504] usbcore: registered new interface driver usb-storage [ 11.249732] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.297491] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.345619] kmodloader: 3 modules could not be probed [ 11.376633] kmodloader: dependency not loaded mbcache [ 11.407619] kmodloader: dependency not loaded jbd2 I think those should be fixed now (after compiling in jbd2 and mbcache): https://github.com/yeryomin/openwrt/commit/14ff513daeb81a47d179c55f440ed652e407c32b Regards, Roman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
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 --- Hi On Wed, 2 May 2018, Linus Walleij wrote: > 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. I use vanilla kernel for testing The USB OTG protocol is complicated enough here, I must handle three different drivers in three different places. Hans Ulli --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Wed, May 2, 2018 at 10:01 AM, Linus Walleij wrote: > Network does not come up either, I suspect it is because of missing the > Realtek PHY driver, so will investigate this further. I found the culprit, sent you a patch adding ethernet to the DNS-313 and Wiliboard device trees. (A variant of a patch that is already upstream in v4.16). Now my DNS-313 works like a charm! :D I guess we should also update the wikipage at OpenWRT with some instructions, I don't know how to properly do that. Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
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 --- Hi On Wed, 2 May 2018, Joel Wirāmu Pauling wrote: > It's Cortina but arm7 IIRC; there was a NDA available SDK for it based on > 2.6.something - which I started to go through the process of getting access > too a few years ago, but the platform was bought out by Realtek who > scuttled it as it was in competition with their own designs. > > The Almond+ has Zwave and Zigbee on PCI bus and Qualcomm AR9880 AC and N > radios, and a USB3 hub. Jtag fully exposed and there is even a Touchscreen > (which I think is I2C based). It would be a nice target to get working with > trunk. > Looking at wikidevi, this should be this one https://wikidevi.com/wiki/Securifi_Almond%2B There is also a spec datasheet on http://www.cortina-access.com/dhp/download/203/996/61 Hans Ulli --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-02 11:01, Linus Walleij wrote: On Wed, May 2, 2018 at 12:18 AM, Linus Walleij wrote: On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin wrote: 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. I found some initial snags and sent you a patch for it, mostly some chicken-and-egg problem for harddisk boot and clumsy attempt to patch the command line from my side that I replaced with bootargs in the device tree. It boots, mounts root and gets to prompt now. I will submit the bootargs patches upstream. There is some moaning in dmesg: [ 10.071561] Btrfs loaded, crc32c=crc32c-generic [ 10.105705] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.161586] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) Oh.. wait... I've missed that DNS-313 doesn't have any onboard flash and boots from hdd! Seems we need CONFIG_JBD2=y and CONFIG_FS_MBCACHE=y (along with ext4 and other fs) back. I guess you see this too? Related to the USB mess I guess, we can live with it. No, I don't have the same, Raidsonic (and other boards, afaik) have onboard flash which can be used for system. So hard drives can be used for pure storage, which is more convenient, IMO. Network does not come up either, I suspect it is because of missing the Realtek PHY driver, so will investigate this further. Could be... what does dmesg say about that? does it read any phy_id ? Raidsonic has Marvell 88e1116 phy but works as generic phy just fine: [5.731760] Generic PHY gpio-0:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=gpio-0:01, irq=POLL) [5.731781] phy_id=0x01410e11, phy_mode=rgmii Regards, Roman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Wed, May 2, 2018 at 12:41 AM, Joel Wirāmu Pauling wrote: > 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. No idea what SoC that is, sorry, even less do I have any development board or anything for it... if it is a Cortina or StorLink SoC there is chance you can reuse some of the drivers for the basic IP blocks but that is as much as I can help. Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Wed, May 2, 2018 at 12:18 AM, Linus Walleij wrote: > On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin wrote: >> >> 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. I found some initial snags and sent you a patch for it, mostly some chicken-and-egg problem for harddisk boot and clumsy attempt to patch the command line from my side that I replaced with bootargs in the device tree. It boots, mounts root and gets to prompt now. I will submit the bootargs patches upstream. There is some moaning in dmesg: [ 10.071561] Btrfs loaded, crc32c=crc32c-generic [ 10.105705] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.161586] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.209501] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.264368] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.312050] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.368142] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.415827] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.500774] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.548542] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.604267] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 10.651342] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.699520] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.754306] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.802014] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.855212] ehci-platform: EHCI generic platform driver [ 10.895311] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.943323] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.998070] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.045793] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.102146] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.150097] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.205504] usbcore: registered new interface driver usb-storage [ 11.249732] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.297491] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.345619] kmodloader: 3 modules could not be probed [ 11.376633] kmodloader: dependency not loaded mbcache [ 11.407619] kmodloader: dependency not loaded jbd2 I guess you see this too? Related to the USB mess I guess, we can live with it. Network does not come up either, I suspect it is because of missing the Realtek PHY driver, so will investigate this further. BTW: since OpenWRT by default loads all these RAID business I guess we should try to get the RAID XOR engine going, I think it's a very simple piece of hardware. Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [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 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [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 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [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
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 29/04/18 20: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?
Regards,
Roman
Great, please send patches or a PR once you feel happy with the series.
John
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
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?
Regards,
Roman
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
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 ?
John
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Tue, Apr 17, 2018 at 11:23 AM, Linus Walleij wrote: > On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin wrote: > >> 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. > > I always wondered about that thing, it looks a bit puzzleing, something is not > right... > > The SQ201 has a VIA Vectro VT6212LUSB 2.0 USB controller on PCI, > which is of course EHCI. EHCI req Damned google mail. EHCI requires UHCI to be activated in Kconfig. So to support all Geminis we are between a rock and a hard place here... if I can get the fotg210 working on some board I can maybe look into it. But just supporting fotg210 is fine for now, the SQ201 is not a regression, it's new stuff. Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin wrote: > 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. I always wondered about that thing, it looks a bit puzzleing, something is not right... The SQ201 has a VIA Vectro VT6212LUSB 2.0 USB controller on PCI, which is of course EHCI. EHCI req ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
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
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-17 00:36, Linus Walleij wrote: On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin wrote: Looking at your tree... I don't see any (affecting) differences in ethernet driver itself. Probably it's something else.. MDIO? After looking into ethernet I've found several issues. 1. skew delay settings were not ported from old driver to dts for nas4220b board 2. kernel config in you patches (accidentally?) disabled bridge support 3. driver crashes if you try to disable unused gmac in dts because of access to uninitialized port(0|1) member of struct gemini_ethernet Ouch. Sorry for my sucky backport. :( So after fixing all above ethernet on nas4220b is working ok. You are my hero :) Can you confirm that after enabling bridge support back (just remove CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up on D-link boards? That is with default network config. I think it's best if I test your entire set-up on the D-Link routers. Do you have a git branch I can grab? Will try to prepare that tomorrow. Target kernel config must be cleaned up, it's redundant in some places and overrides some things which it should not. I've managed to get usb working, it was kernel config error again (and Hans' patch he sent earlier is actually working). But still usb has problems, e.g. I couldn't get both ports working, only one of them. SATA seems to be working out of the box, which is good! Regards, Roman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin wrote: >> Looking at your tree... >> I don't see any (affecting) differences in ethernet driver itself. >> Probably it's something else.. MDIO? >> > > After looking into ethernet I've found several issues. > 1. skew delay settings were not ported from old driver to dts for nas4220b > board > 2. kernel config in you patches (accidentally?) disabled bridge support > 3. driver crashes if you try to disable unused gmac in dts because of access > to uninitialized port(0|1) member of struct gemini_ethernet Ouch. Sorry for my sucky backport. :( > So after fixing all above ethernet on nas4220b is working ok. You are my hero :) > Can you confirm that after enabling bridge support back (just remove > CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up on > D-link boards? That is with default network config. I think it's best if I test your entire set-up on the D-Link routers. Do you have a git branch I can grab? DNS-313 has working ethernet, DIR-685 is not yet working because of missing upstream RTL8366RB support (working on it!) so it is still a bit of WIP. Yours, Linus Walleij ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-12 00:37, Roman Yeryomin wrote: On 2018-04-11 00:51, 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? Hm I tested mostly the rootfs and that the kernel would get to prompt. But for my D-Link devices I tested mostly with kernel v4.16 because I'm working close to mainline. Testing now it seems network is not coming up here either :/ as it works like a charm on v4.16 it must be some minor issue. Looking at your tree... I don't see any (affecting) differences in ethernet driver itself. Probably it's something else.. MDIO? After looking into ethernet I've found several issues. 1. skew delay settings were not ported from old driver to dts for nas4220b board 2. kernel config in you patches (accidentally?) disabled bridge support 3. driver crashes if you try to disable unused gmac in dts because of access to uninitialized port(0|1) member of struct gemini_ethernet So after fixing all above ethernet on nas4220b is working ok. Can you confirm that after enabling bridge support back (just remove CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up on D-link boards? That is with default network config. Regards, Roman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
