| Message ID | 20180404203406.25197-1-linus.walleij@linaro.org |
|---|---|
| Headers | show |
| Series | Gemini forward-port to kernel v4.14 | expand |
On 2018-04-04 23: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 > Hi Linus, thanks for the patches! 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? Regards, Roman
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin <roman@advem.lv> 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. I would guess Hans Ulli Kroll can help with USB, I just applied the patches and have nothing to test it with. I never used USB... The v4.16 stack is pretty small and there the network for sure works (not a finished patch set): https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=openwrt-v4.16 If it's hard to get v4.14 to backport we could maybe aim to use v4.16 instead? Or is there some OpenWRT baselining involved? Yours, Linus Walleij
On 2018-04-11 00:51, Linus Walleij wrote: > On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin <roman@advem.lv> 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? > I would guess Hans Ulli Kroll can help with USB, I just applied the > patches and have nothing to test it with. I never used USB... Hans, did you have a chance to test 4.14 (or 4.16) on any of gemini boards? > The v4.16 stack is pretty small and there the network for sure > works (not a finished patch set): > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=openwrt-v4.16 > > If it's hard to get v4.14 to backport we could maybe aim to > use v4.16 instead? Or is there some OpenWRT baselining involved? Yeah, generic comes first and that's not 10min work :) Regards, Roman
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. Hi Roman On Tue, 10 Apr 2018, Linus Walleij wrote: > On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin <roman@advem.lv> 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 From 10be6c15addac0bdb9c2d196d450aee1fcb2070b Mon Sep 17 00:00:00 2001 From: Hans Ulli Kroll <ulli.kroll@googlemail.com> Date: Sat, 14 Apr 2018 19:13:11 +0200 Subject: [PATCH] gemini: fix fotg2 stall after port reset Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> --- ...b-host-fotg2-restart-hcd-after-port-reset.patch | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch diff --git a/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch b/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch new file mode 100644 index 0000000000..3f1de0d107 --- /dev/null +++ b/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch @@ -0,0 +1,31 @@ +From 731a2896e11b4e6a8d252e6c14edb1b09dbfcd46 Mon Sep 17 00:00:00 2001 +From: Hans Ulli Kroll <ulli.kroll@googlemail.com> +Date: Sat, 14 Apr 2018 18:49:57 +0200 +Subject: [PATCH 1/2] usb: host: fotg2: restart hcd after port reset + +on Gemini SoC FOTG2 stalls after port reset +rerstart the hcd. + +Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> +--- + drivers/usb/host/fotg210-hcd.c | 4 ++++ + 1 file changed, 4 insertions(+) + +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 +
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 <roman@advem.lv> >> 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 :( Regards, Roman
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 <roman@advem.lv> >> 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
On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin <roman@advem.lv> 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
On 2018-04-17 00:36, Linus Walleij wrote: > On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin <roman@advem.lv> 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
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 <roman@advem.lv> >>> 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 40000000.syscon:pinctrl: ACTIVATE function "usb" with group "usbgrp" [ 5.845067] fotg210-hcd 68000000.usb: initialized Gemini PHY [ 5.845095] fotg210-hcd 68000000.usb: Faraday USB2.0 Host Controller [ 5.845176] fotg210-hcd 68000000.usb: new USB bus registered, assigned bus number 1 [ 5.845696] fotg210-hcd 68000000.usb: irq 29, io mem 0x68000000 [ 5.877212] fotg210-hcd 68000000.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 40000000.syscon:pinctrl: pin T6 USB GNDA U20 already requested by 68000000.usb; cannot claim for 69000000.usb [ 5.904807] pinctrl-gemini 40000000.syscon:pinctrl: pin-305 (69000000.usb) status -22 [ 5.904845] pinctrl-gemini 40000000.syscon:pinctrl: could not request pin 305 (T6 USB GNDA U20) from group usbgrp on device pinctrl-gemini [ 5.904872] fotg210-hcd 69000000.usb: Error applying setting, reverse things back [ 5.904928] fotg210-hcd: probe of 69000000.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
On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin <roman@advem.lv> 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
On Tue, Apr 17, 2018 at 11:23 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin <roman@advem.lv> 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
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 <roman@advem.lv> >>>> 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 40000000.syscon:pinctrl: ACTIVATE > function "usb" with group "usbgrp" > [ 5.845067] fotg210-hcd 68000000.usb: initialized Gemini PHY > [ 5.845095] fotg210-hcd 68000000.usb: Faraday USB2.0 Host Controller > [ 5.845176] fotg210-hcd 68000000.usb: new USB bus registered, > assigned bus number 1 > [ 5.845696] fotg210-hcd 68000000.usb: irq 29, io mem 0x68000000 > [ 5.877212] fotg210-hcd 68000000.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 40000000.syscon:pinctrl: pin T6 USB GNDA > U20 already requested by 68000000.usb; cannot claim for 69000000.usb > [ 5.904807] pinctrl-gemini 40000000.syscon:pinctrl: pin-305 > (69000000.usb) status -22 > [ 5.904845] pinctrl-gemini 40000000.syscon:pinctrl: could not > request pin 305 (T6 USB GNDA U20) from group usbgrp on device > pinctrl-gemini > [ 5.904872] fotg210-hcd 69000000.usb: Error applying setting, > reverse things back > [ 5.904928] fotg210-hcd: probe of 69000000.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
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 <roman@advem.lv> >>>>> 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 40000000.syscon:pinctrl: ACTIVATE >> function "usb" with group "usbgrp" >> [ 5.845067] fotg210-hcd 68000000.usb: initialized Gemini PHY >> [ 5.845095] fotg210-hcd 68000000.usb: Faraday USB2.0 Host >> Controller >> [ 5.845176] fotg210-hcd 68000000.usb: new USB bus registered, >> assigned bus number 1 >> [ 5.845696] fotg210-hcd 68000000.usb: irq 29, io mem 0x68000000 >> [ 5.877212] fotg210-hcd 68000000.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 40000000.syscon:pinctrl: pin T6 USB GNDA >> U20 already requested by 68000000.usb; cannot claim for 69000000.usb >> [ 5.904807] pinctrl-gemini 40000000.syscon:pinctrl: pin-305 >> (69000000.usb) status -22 >> [ 5.904845] pinctrl-gemini 40000000.syscon:pinctrl: could not >> request pin 305 (T6 USB GNDA U20) from group usbgrp on device >> pinctrl-gemini >> [ 5.904872] fotg210-hcd 69000000.usb: Error applying setting, >> reverse things back >> [ 5.904928] fotg210-hcd: probe of 69000000.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
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 <roman@advem.lv> >>>>>> 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 40000000.syscon:pinctrl: ACTIVATE >>> function "usb" with group "usbgrp" >>> [ 5.845067] fotg210-hcd 68000000.usb: initialized Gemini PHY >>> [ 5.845095] fotg210-hcd 68000000.usb: Faraday USB2.0 Host Controller >>> [ 5.845176] fotg210-hcd 68000000.usb: new USB bus registered, >>> assigned bus number 1 >>> [ 5.845696] fotg210-hcd 68000000.usb: irq 29, io mem 0x68000000 >>> [ 5.877212] fotg210-hcd 68000000.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 40000000.syscon:pinctrl: pin T6 USB >>> GNDA U20 already requested by 68000000.usb; cannot claim for >>> 69000000.usb >>> [ 5.904807] pinctrl-gemini 40000000.syscon:pinctrl: pin-305 >>> (69000000.usb) status -22 >>> [ 5.904845] pinctrl-gemini 40000000.syscon:pinctrl: could not >>> request pin 305 (T6 USB GNDA U20) from group usbgrp on device >>> pinctrl-gemini >>> [ 5.904872] fotg210-hcd 69000000.usb: Error applying setting, >>> reverse things back >>> [ 5.904928] fotg210-hcd: probe of 69000000.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
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 <roman@advem.lv> >>>>>> 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 40000000.syscon:pinctrl: ACTIVATE >>> function "usb" with group "usbgrp" >>> [ 5.845067] fotg210-hcd 68000000.usb: initialized Gemini PHY >>> [ 5.845095] fotg210-hcd 68000000.usb: Faraday USB2.0 Host >>> Controller >>> [ 5.845176] fotg210-hcd 68000000.usb: new USB bus registered, >>> assigned bus number 1 >>> [ 5.845696] fotg210-hcd 68000000.usb: irq 29, io mem 0x68000000 >>> [ 5.877212] fotg210-hcd 68000000.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 40000000.syscon:pinctrl: pin T6 USB >>> GNDA U20 already requested by 68000000.usb; cannot claim for >>> 69000000.usb >>> [ 5.904807] pinctrl-gemini 40000000.syscon:pinctrl: pin-305 >>> (69000000.usb) status -22 >>> [ 5.904845] pinctrl-gemini 40000000.syscon:pinctrl: could not >>> request pin 305 (T6 USB GNDA U20) from group usbgrp on device >>> pinctrl-gemini >>> [ 5.904872] fotg210-hcd 69000000.usb: Error applying setting, >>> reverse things back >>> [ 5.904928] fotg210-hcd: probe of 69000000.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
On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin <roman@advem.lv> 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
On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin <roman@advem.lv> 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
On Wed, May 2, 2018 at 12:18 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin <roman@advem.lv> 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
On Wed, May 2, 2018 at 12:41 AM, Joel Wirāmu Pauling <joel@aenertia.net> 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
On 2018-05-02 11:01, Linus Walleij wrote: > On Wed, May 2, 2018 at 12:18 AM, Linus Walleij > <linus.walleij@linaro.org> wrote: >> On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin <roman@advem.lv> >> 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
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. 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
On Wed, May 2, 2018 at 10:01 AM, Linus Walleij <linus.walleij@linaro.org> 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
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. Hi On Wed, 2 May 2018, Linus Walleij wrote: > On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin <roman@advem.lv> 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
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
On Fri, May 4, 2018 at 5:26 PM, Roman Yeryomin <roman@advem.lv> 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
On 2018-05-04 20:15, Linus Walleij wrote: > On Fri, May 4, 2018 at 5:26 PM, Roman Yeryomin <roman@advem.lv> 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
On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin <roman@advem.lv> 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
On Fri, May 4, 2018 at 11:49 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin <roman@advem.lv> 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
On 05/05/2018 11:25 AM, Linus Walleij wrote: > On Fri, May 4, 2018 at 11:49 PM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin <roman@advem.lv> 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,<module name>) with: AUTOLOAD:=$(call AutoProbe,<module name>, 1) Hauke
On Sat, May 5, 2018 at 11:25 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, May 4, 2018 at 11:49 PM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin <roman@advem.lv> 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 <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin <roman@advem.lv> 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
On 2018-05-05 17:32, Linus Walleij wrote: > On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin <roman@advem.lv> 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
On 2018-05-05 16:35, Linus Walleij wrote: > On Sat, May 5, 2018 at 11:25 AM, Linus Walleij > <linus.walleij@linaro.org> wrote: >> On Fri, May 4, 2018 at 11:49 PM, Linus Walleij >> <linus.walleij@linaro.org> wrote: >>> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin <roman@advem.lv> >>> 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
On Sat, May 5, 2018 at 5:19 PM, Roman Yeryomin <roman@advem.lv> wrote: > On 2018-05-05 17:32, Linus Walleij wrote: >> >> On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin <roman@advem.lv> 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 : 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: 4 disable: 0 rate_in: 1048512 rate_out: 1048512 pvid: 3 link: port:2 link:down Port 3: mib: Port 3 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: 0 disable: 0 rate_in: 1048512 rate_out: 1048512 pvid: 4 link: port:3 link:down Port 4: mib: Port 4 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: ??? disable: 0 rate_in: 1048512 rate_out: 1048512 pvid: 5 link: port:4 link:down Port 5: mib: Port 5 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 : 696 Dot3StatsSingleCollisionFrames : 0 Dot3StatMultipleCollisionFrames : 0 Dot3sDeferredTransmissions : 0 Dot3StatsLateCollisions : 0 EtherStatsCollisions : 0 Dot3StatsExcessiveCollisions : 0 Dot3OutPauseFrames : 0 Dot1dBasePortDelayExceededDiscards : 0 Dot1dTpPortInDiscards : 0 IfOutUcastPkts : 0 IfOutMulticastPkts : 4 IfOutBroadcastPkts : 0 led: ??? disable: 0 rate_in: 1048512 rate_out: 1048512 pvid: 6 link: port:5 link:up speed:1000baseT full-duplex txflow rxflow auto VLAN 1: info: VLAN 1: Ports: '05', members=0021, untag=0021, fid=0 fid: 0 ports: 0 5 VLAN 2: info: VLAN 2: Ports: '15', members=0022, untag=0022, fid=0 fid: 0 ports: 1 5 VLAN 3: info: VLAN 3: Ports: '25', members=0024, untag=0024, fid=0 fid: 0 ports: 2 5 VLAN 4: info: VLAN 4: Ports: '35', members=0028, untag=0028, fid=0 fid: 0 ports: 3 5 VLAN 5: info: VLAN 5: Ports: '45', members=0030, untag=0030, fid=0 fid: 0 ports: 4 5 VLAN 6: info: VLAN 6: Ports: '012345', members=003f, untag=003f, fid=0 fid: 0 ports: 0 1 2 3 4 5 However despite setting up the static IP to 169.254.1.2 and my host connected with a crossed ethernet as 169.254.1.1 (this works fine for TFTP boot!) it doesn't answer to ping. root@OpenWrt:~# ifconfig br-lan Link encap:Ethernet HWaddr 02:EE:17:81:C5:3D inet addr:169.254.1.2 Bcast:169.254.1.255 Mask:255.255.255.0 inet6 addr: fd8d:ded0:53fe::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) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:128 errors:0 dropped:0 overruns:0 frame:0 TX packets:128 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8760 (8.5 KiB) TX bytes:8760 (8.5 KiB) root@OpenWrt:~# ping 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes (hangs, same from host) Yours, Linus Walleij
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/raidsonic/target.mk | 17 - target/linux/gemini/wiligear/target.mk | 10 - tools/firmware-utils/Makefile | 1 + tools/firmware-utils/src/dns313-header.c | 239 ++ 66 files changed, 8277 insertions(+), 6278 deletions(-) create mode 100755 target/linux/gemini/base-files/etc/board.d/03_hdparm create mode 100644 target/linux/gemini/config-4.14 delete mode 100644 target/linux/gemini/config-4.4 delete mode 100644 target/linux/gemini/files/arch/arm/mach-gemini/include/mach/gmac.h delete mode 100644 target/linux/gemini/files/arch/arm/mach-gemini/pci.c delete mode 100644 target/linux/gemini/files/drivers/ata/pata_gemini.c delete mode 100644 target/linux/gemini/files/drivers/net/ethernet/gemini/Kconfig delete mode 100644 target/linux/gemini/files/drivers/net/ethernet/gemini/Makefile delete mode 100644 target/linux/gemini/files/drivers/net/ethernet/gemini/sl351x.c delete mode 100644 target/linux/gemini/files/drivers/net/ethernet/gemini/sl351x_hw.h delete mode 100644 target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c delete mode 100644 target/linux/gemini/files/drivers/watchdog/gemini_wdt.c create mode 100644 target/linux/gemini/image/dns313-header/Makefile create mode 100644 target/linux/gemini/image/dns313-header/dns313-header.c create mode 100644 target/linux/gemini/image/slask.mk rename target/linux/gemini/{patches-4.4/060-cache-fa.patch => patches-4.14/0001-cache-patch-from-OpenWRT.patch} (79%) create mode 100644 target/linux/gemini/patches-4.14/0002-pinctrl-gemini-Add-missing-functions.patch create mode 100644 target/linux/gemini/patches-4.14/0003-ARM-dts-Add-TVE200-to-the-Gemini-SoC-DTSI.patch create mode 100644 target/linux/gemini/patches-4.14/0004-pinctrl-Add-skew-delay-pin-config-and-bindings.patch create mode 100644 target/linux/gemini/patches-4.14/0005-pinctrl-gemini-Use-generic-DT-parser.patch create mode 100644 target/linux/gemini/patches-4.14/0006-pinctrl-gemini-Implement-clock-skew-delay-config.patch create mode 100644 target/linux/gemini/patches-4.14/0007-pinctrl-gemini-Fix-GMAC-groups.patch create mode 100644 target/linux/gemini/patches-4.14/0008-pinctrl-gemini-Fix-missing-pad-descriptions.patch create mode 100644 target/linux/gemini/patches-4.14/0009-pinctrl-gemini-Add-two-missing-GPIO-groups.patch create mode 100644 target/linux/gemini/patches-4.14/0010-pinctrl-gemini-Fix-usage-of-3512-groups.patch create mode 100644 target/linux/gemini/patches-4.14/0011-pinctrl-gemini-Support-drive-strength-setting.patch create mode 100644 target/linux/gemini/patches-4.14/0012-ARM-dts-Add-ethernet-PHYs-to-the-a-bunch-of-Geminis.patch create mode 100644 target/linux/gemini/patches-4.14/0013-ARM-dts-Add-basic-devicetree-for-D-Link-DNS-313.patch create mode 100644 target/linux/gemini/patches-4.14/0014-ARM-dts-Flags-D-Link-DIR-685-I2C-bus-gpios.patch create mode 100644 target/linux/gemini/patches-4.14/0015-ARM-dts-Add-PCI-to-WBD111-and-WBD222.patch create mode 100644 target/linux/gemini/patches-4.14/0016-ARM-dts-Add-TVE-TVC-and-ILI9322-panel-to-DIR-685.patch create mode 100644 target/linux/gemini/patches-4.14/0017-watchdog-gemini-ftwdt010-rename-DT-bindings.patch create mode 100644 target/linux/gemini/patches-4.14/0018-watchdog-gemini-ftwdt010-rename-driver-and-symbols.patch create mode 100644 target/linux/gemini/patches-4.14/0019-watchdog-ftwdt010-Make-interrupt-optional.patch create mode 100644 target/linux/gemini/patches-4.14/0020-soc-Add-SoC-driver-for-Gemini.patch create mode 100644 target/linux/gemini/patches-4.14/0021-net-ethernet-Add-DT-bindings-for-the-Gemini-ethernet.patch create mode 100644 target/linux/gemini/patches-4.14/0022-net-ethernet-Add-a-driver-for-Gemini-gigabit-etherne.patch create mode 100644 target/linux/gemini/patches-4.14/0023-ARM-dts-Add-ethernet-to-the-Gemini-SoC.patch create mode 100644 target/linux/gemini/patches-4.14/0024-net-gemini-Depend-on-HAS_IOMEM.patch create mode 100644 target/linux/gemini/patches-4.14/0025-ARM-dts-Set-D-Link-DNS-313-SATA-to-muxmode-0.patch create mode 100644 target/linux/gemini/patches-4.14/0026-power-gemini-poweroff-Avoid-spurious-poweroff.patch create mode 100644 target/linux/gemini/patches-4.14/0027-usb-host-add-DT-bindings-for-faraday-fotg2.patch create mode 100644 target/linux/gemini/patches-4.14/0028-usb-host-fotg2-add-device-tree-probing.patch create mode 100644 target/linux/gemini/patches-4.14/0029-usb-host-fotg2-add-silicon-clock-handling.patch create mode 100644 target/linux/gemini/patches-4.14/0030-usb-host-fotg2-add-Gemini-specific-handling.patch create mode 100644 target/linux/gemini/patches-4.14/0031-ARM-dts-Add-the-FOTG210-USB-host-to-Gemini.patch delete mode 100644 target/linux/gemini/patches-4.4/050-gpio-to-irq.patch delete mode 100644 target/linux/gemini/patches-4.4/110-watchdog-add-gemini_wdt-driver.patch delete mode 100644 target/linux/gemini/patches-4.4/111-arm-gemini-add-watchdog-device.patch delete mode 100644 target/linux/gemini/patches-4.4/112-arm-gemini-register-watchdog-devices.patch delete mode 100644 target/linux/gemini/patches-4.4/120-net-add-gemini-gmac-driver.patch delete mode 100644 target/linux/gemini/patches-4.4/121-arm-gemini-add-gmac-device.patch delete mode 100644 target/linux/gemini/patches-4.4/122-arm-gemini-register-ethernet.patch delete mode 100644 target/linux/gemini/patches-4.4/130-usb-ehci-add-fot2g-driver.patch delete mode 100644 target/linux/gemini/patches-4.4/131-arm-gemini-add-usb-device.patch delete mode 100644 target/linux/gemini/patches-4.4/132-arm-gemini-register-usb.patch delete mode 100644 target/linux/gemini/patches-4.4/140-arm-gemini-add-pci-support.patch delete mode 100644 target/linux/gemini/patches-4.4/150-gemini-pata.patch delete mode 100644 target/linux/gemini/raidsonic/config-default delete mode 100644 target/linux/gemini/raidsonic/target.mk delete mode 100644 target/linux/gemini/wiligear/target.mk create mode 100644 tools/firmware-utils/src/dns313-header.c