This makes the ethernet and RTL8366RB come up on the
D-Link DIR-685.
Signed-off-by: Linus Walleij
---
...s-gemini-dlink-dir-685-add-rtl8366rb.patch | 71 ++-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git
a/target/linux/gemini/patches-4.14/0905-arm-dts-gemini-dlink
---
target/linux/gemini/image/Makefile | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
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
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
>>>
r 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
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
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
; 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
ter, 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 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 vari
This adds an interrim patch for v4.14 based on an
upstream commit to get ethernet working on D-Link DNS-313
(probably also on the Wiliboards)
Signed-off-by: Linus Walleij
---
...-dts-Add-ethernet-to-a-bunch-of-platforms.patch | 123 +
1 file changed, 123 insertions
t 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
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-
Image makefile: we should
pass this with the device tree bootargs instead, it works
much better.
Signed-off-by: Linus Walleij
---
target/linux/gemini/config-4.14| 2 +-
target/linux/gemini/image/Makefile | 6 ---
...ts-Fix-bootargs-for-Gemini-D-Link
ptraf" 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
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
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
&g
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 ind
n
> 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 RTL8366R
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 Op
The v4.14 kernel is what we should be using so get rid of those
old patches. The old patches doesn't even support using device
tree.
Signed-off-by: Linus Walleij
---
target/linux/gemini/config-4.4 | 165 ---
.../linux/gemini/patches-4.4/050-gpio-to-irq.
This tool is used to create headers on images for the
D-Link DNS-313.
Signed-off-by: Linus Walleij
---
tools/firmware-utils/Makefile| 1 +
tools/firmware-utils/src/dns313-header.c | 239 +++
2 files changed, 240 insertions(+)
create mode 100644 tools
rking
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/
On Wed, Feb 28, 2018 at 2:58 PM, Hauke Mehrtens wrote:
> On 02/27/2018 10:45 PM, Linus Walleij wrote:
>> On Tue, Feb 27, 2018 at 4:46 PM, Hauke Mehrtens wrote:
>>> And the also "make target/linux/{clean,refresh} V=99" to make the
>>> patches cleanly apply.
&
r all targets as well.
OK no problem, I'll update the (big) patch.
Yours,
Linus Walleij
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
support it any more, mostly because the binary gets too big.
I have no clue what is wrong here, but the binaries get corrupt
for Busybox. procd and a few others build and run fine.
Took me ages to figure out that just rebuilding the whole
thing with the 7.3.0 compiler made the problem go away...
Yours,
Linus Walleij
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
25 matches
Mail list logo
