ath79: add support for D-Link DIR-842 C1 by programmingisart · Pull Request #2276 · openwrt/openwrt

programmingisart · 2019-07-25T14:47:34Z

Hardware spec of DIR-842 C1:
SoC: QCA9563
DRAM: 128MB DDR2
Flash: 16MB SPI-NOR
Switch: QCA8337N
WiFi 5.8GHz: QCA9888
WiFi 2.4Ghz: QCA9563
USB: circuit onboard, but components are not soldered

Flash instructions:

Upgrade the factory.bin through the factory web interface or
the u-boot failsafe interface.
The firmware will boot up correctly for the first time.
Do not power off the device after OpenWrt has booted.
Otherwise the u-boot will enter failsafe mode as the checksum
of the firmware has been changed.
Upgrade the sysupgrade.bin in OpenWrt.
After upgrading completes the u-boot won't complain about the
firmware checksum and it's OK to use now.
If you powered off the device before upgrading the sysupgrade.bin,
just upgrade the factory.bin through the u-boot failsafe interface
and then goto step 2.

Signed-off-by: Jackson Lim [email protected]

Thanks for your contribution to OpenWrt!

To help keep the codebase consistent and readable,
and to help people review your contribution,
we ask you to follow the rules you find in the wiki at this link
https://openwrt.org/submitting-patches

Please remove this message before posting the pull request.

programmingisart · 2019-07-25T14:48:29Z

@blocktrron
Unfortunately I cant find C3 in my area (I believe they are not being sold here). So here is only the C1 support.
Thanks!

target/linux/ath79/image/generic.mk

target/linux/ath79/dts/qca9563_dlink_dir-842-c1.dts

blocktrron

Looks good! Two remarks left 👀

target/linux/ath79/dts/qca9563_dlink_dir-842-c.dtsi

target/linux/ath79/image/generic.mk

target/linux/ath79/dts/qca9563_dlink_dir-842.dtsi

adschm · 2019-07-25T17:36:53Z

What about 02_network?
(Just wanted to check for label_mac ...)

programmingisart · 2019-07-25T17:42:00Z

What about 02_network?
(Just wanted to check for label_mac ...)

Oops sorry for my mistake, fixed
Thanks!

adschm · 2019-07-25T17:45:27Z

label_mac is lan_mac as for C2?

programmingisart · 2019-07-25T17:46:17Z

label_mac is lan_mac as for C2?

Yes, for both C1 and C2

blocktrron · 2019-07-25T18:25:57Z

@jackcolentern

Your commits need to be squashed into one.

programmingisart · 2019-07-25T18:32:43Z

@blocktrron
Done, Thanks!

target/linux/ath79/dts/qca9563_dlink_dir-842-c2.dts

target/linux/ath79/dts/qca9563_dlink_dir-842-c1.dts

target/linux/ath79/base-files/etc/board.d/02_network

hanipouspilot · 2019-07-26T14:09:35Z

I hate to criticize, but don't we need to disable USB for C1?

programmingisart · 2019-07-26T14:12:00Z

I hate to criticize, but don't we need to disable USB for C1?

@blocktrron
@adrianschmutzler
How does you guys think? I can remove that if you guys agree with that

blocktrron · 2019-07-26T18:52:23Z

Yes, please. Move the reference to the USB node to the c2 devicetree.

hanipouspilot · 2019-07-26T18:55:59Z

Yes, please. Move the reference to the USB node to the c2 devicetree.

I suggest having the USB node in dtsi with disabled status. We can enable it in C2 dts and leave untouched in C1 and future C3 implementation. But either looks good.

programmingisart · 2019-07-26T19:45:37Z

Yes, please. Move the reference to the USB node to the c2 devicetree.

Done, thanks!

programmingisart · 2019-07-26T19:47:39Z

Yes, please. Move the reference to the USB node to the c2 devicetree.

I suggest having the USB node in dtsi with disabled status. We can enable it in C2 dts and leave untouched in C1 and future C3 implementation. But either looks good.

@blocktrron I can change to this also if you prefer this. Thanks!

pmelange · 2019-07-30T11:03:05Z

I have a C3, and tested it with the C2 firmware. It works fine. The C3, like the C1, has USB internally but without an interface soldered onto the board.

The Forum thread is https://forum.openwrt.org/t/support-for-d-link-dir842-rev-c3-maybe-eu-version/41654

blocktrron

One (maybe last? 😄 ) improvement suggestion from my side. I will leave this open for a bit more for everyone to voice their opinion on the topic @pmelange outlined.

blocktrron · 2019-07-30T12:36:54Z

target/linux/ath79/dts/qca9563_dlink_dir-842-c.dtsi

Please move the aliases node to the respective boards dts.

It should work the way you have done it, but you are referencing a handle which has to be created in the DT inheriting this dtsi, which might not be obvious on first sight.

done, thanks!

Hardware spec of DIR-842 C1: SoC: QCA9563 DRAM: 128MB DDR2 Flash: 16MB SPI-NOR Switch: QCA8337N WiFi 5.8GHz: QCA9888 WiFi 2.4Ghz: QCA9563 USB: circuit onboard, but components are not soldered Flash instructions: 1. Upgrade the factory.bin through the factory web interface or the u-boot failsafe interface. The firmware will boot up correctly for the first time. Do not power off the device after OpenWrt has booted. Otherwise the u-boot will enter failsafe mode as the checksum of the firmware has been changed. 2. Upgrade the sysupgrade.bin in OpenWrt. After upgrading completes the u-boot won't complain about the firmware checksum and it's OK to use now. 3. If you powered off the device before upgrading the sysupgrade.bin, just upgrade the factory.bin through the u-boot failsafe interface and then goto step 2. Signed-off-by: Jackson Lim <[email protected]>

programmingisart · 2019-07-31T12:15:04Z

@blocktron
For now we can't seems to find any notable difference between C1 and C3
In your opinion should we have separate C1 and C3 images or we can combine them together?

blocktrron · 2019-07-31T12:25:16Z

@jackcolentern I would go for seperate images in this case here, like it's done for many similar cases (e.g. WDR3600/WDR4300 and some Tl-WR841N).

I will merge this PR later, someone with a C3 can then open one for this device.

pmelange · 2019-07-31T13:45:48Z

The changes to support Rev C3 seem to be straight forward. I can do it as soon as this PR is merged.

As a side note, after digging around on the German D-Link site, there are a couple FAQ's which are interesting.

https://eu.dlink.com/de/de/support/faq/routers/dir-842/de_dir842_revc_kann-ich-die-eu_firmware-in-die-revc1-installieren Can I install the EU Firmware (for the C3) on the C1 (short answer, yes)
https://eu.dlink.com/de/de/support/faq/routers/dir-842/de_dir842_revc_kann-ich-die-nicht_eu_firmware-wieder-in-die-revc1-installieren I installed the EU firmware on the C1, can I install the non-EU firmware (short answer, yes).

Obviously, the so-called data-sheet is just marketing jargon without any specifics. Delightful.

Maybe the EU firmware just has support for more languages? I guess the differences between C1 and C3 will remain a mystery.

pmelange · 2019-07-31T14:40:40Z

After reading a forum thread on lowyat.net I might have found a difference between C1 and C3. The C3 has a reset button on the bottom of the router. @blocktrron, can you confirm that the C1 uses the WPS button as reset?

adschm · 2019-08-01T13:30:20Z

I supposed then also C3 has label_mac=$lan_mac ?

hanipouspilot · 2019-08-01T13:31:02Z

as this will prevent confusing the user about which version to choose.

In this specific case the user can install the C2 image on all three.

adschm · 2019-08-01T13:46:36Z

Just had another look at the DTSes:
Even the LEDs are similar, so why are they set up twice (C1 and C2 DTS)?
With the LEDs moved to parent DTSI, the only difference remaining would be enabling USB for one, while the other one has it disabled. Depending on how vital it is to disable it on C1, and concerning that we are talking about sub-versions here (C1, C2, C3), I would seriously consider just having on variant "C" or "Cx" for this device. At the moment, it just looks to me like we are creating three equal sub-versions...

hanipouspilot · 2019-08-01T13:50:42Z

Depending on how vital it is to disable it on C1

I don't think it is vital. Shame on me that I was the one who suggested to disable it.
The USB is onboard on all three devices. But it's not soldered on 1 and 3.
The only problem will be wasted space occupied by kmod-usb- on C1 and 3.

adschm · 2019-08-01T14:02:27Z

The only problem will be wasted space occupied by kmod-usb- on C1 and 3.

If it's only that, I would not bother on a 16M device.

hanipouspilot · 2019-08-01T14:06:13Z

I suggest having C1 then with enabled USB. It will work on C1-3, that can be added to wiki.
As an example see DIR-825 B1. I actually added it having B2. It is mentioned that the B1 image can be installed on both.
Or do C1-3, if you like it better.

adschm · 2019-08-01T14:10:14Z

I would just rename dlink_dir-842-c2 to dlink_dir-842-c and have it for all sub-variants. This will also be easily understood by a user just looking at the image names. Like TP-Link version "v1" is for "v1.3" as well as for "v1.7".

hanipouspilot · 2019-08-01T14:12:00Z

I would just rename dlink_dir-842-c2 to dlink_dir-842-c and have it for all sub-variants.

It is reasonable, but what if C4 pops up with something really different?

bobafetthotmail · 2019-08-01T14:13:37Z

I would just rename dlink_dir-842-c2 to dlink_dir-842-c and have it for all sub-variants.

Same issue as dropping the version when we discussed that for the Kirkwood NAS. If a new version comes out how do you know it is supported or not?

I would just add all versions to the name of the file to install.
Like
dlink_dir-842-c1_c2_c3_whatever

So the versions supported are all there.

Having discussed several similar cases recently, I would also prefer having separate images, as this will prevent confusing the user about which version to choose.

Reducing space usage in the servers seems to be a thing, if latest mailing list discussions are anything to come by.

At the very least you can have it hardlink/symlink or something so that people will download the same file but with different names, and it will only use space once.

hanipouspilot · 2019-08-01T14:16:38Z

Anyway the bottom line is instead of merging this one, rename C2 some way or another.

adschm · 2019-08-01T14:20:18Z

It is reasonable, but what if C4 pops up with something really different?

Is that probable with D-Link devices (to have differences between sub-versions)?
If yes, I would prefer splitting now. If no, I would keep "C" variant and then split later for those devices where we actually have different sub-versions.

dlink_dir-842-c1_c2_c3_whatever

I do not like this. Having different versions in the image name will look like a different name. Besides, for my personal taste it looks ugly.

Also note that my opinions expressed here are just my personal view, I'm discussing here with no authority of any kind.

adschm · 2019-08-01T14:24:22Z

@hanipouspilot

Well, if the LEDs are moved to the DTSI, too, this commit will effectively just copy c2 to c1 anyway.

The question now is mainly whether other people (and you, obviously) see it as I do and go for the "rename", or whether separate images are desired (in which case the PR would mostly stay).

hanipouspilot · 2019-08-01T14:32:11Z

I see no practical reason to have 3 images. Even the vendor seems to have one.
https://support.dlink.com/ProductInfo.aspx?m=DIR-842

programmingisart · 2019-08-01T17:21:40Z

I don't think having Cx (or C) is a good idea, it is so hard for keep track of every devices released. If we have a C4 with huge changes in the future I don't want people bricking it by installing the Cx images.

However, Dlink seems to have a good track record keeping the same core components (Soc, flash, RAM, Switch, Wifi chip) on the same [Alphabet] revision, but we can't be sure sure about the coming devices.

IMHO, I think we can have a C1_C3 image and a separate C2 image with enabled USB

programmingisart · 2019-08-01T17:35:13Z

@hanipouspilot
The vendor image is only for C1 and C3 and do not have USB support.
It is flashable on C2 but USB won't work

adschm · 2019-08-01T18:21:54Z

@jackcolentern
But am I right that the LEDs can be moved to common DTSI?

programmingisart · 2019-08-01T19:05:18Z

@jackcolentern
But am I right that the LEDs can be moved to common DTSI?

yes but do we have rules about two different devices sharing the same led name?

adschm · 2019-08-01T19:16:49Z

yes but do we have rules about two different devices sharing the same led name?

Ah, I overlooked that, since I'm used to vendor named led names like "tplink:green:usb".

I'm not sure what's the best way to solve this.

jeffsf · 2019-08-01T19:56:22Z

You can define the majority of the LED config in a common DTSI, then override just the label property (only) if needed in the higher-level/outer/including DTS(I).

With the caveat that I'm not a core developer by any stretch, in my personal, likely uninformed opinion, I wouldn't see a problem with shared naming, especially with devices that are so much the same that one might want to share config across them.

programmingisart · 2019-08-03T06:24:35Z

You can define the majority of the LED config in a common DTSI, then override just the label property (only) if needed in the higher-level/outer/including DTS(I).

With the caveat that I'm not a core developer by any stretch, in my personal, likely uninformed opinion, I wouldn't see a problem with shared naming, especially with devices that are so much the same that one might want to share config across them.

Thanks very much for your opinion!

So maybe we use this pull request first and @pmelange can add C3 support by combining it with C1?

adschm · 2019-08-03T22:47:19Z

I think one could have either of "dir-842-c1", "dir-842-c" or "dir-842" for the shared leds ...

blocktrron · 2019-08-03T23:05:58Z

Shared LED naming is something that should be avoided. I was told some time ago, the only exception are TP-Link boards, which use tp-link:<color>:<name>.

Regarding sharing of the LED definitions and adding the labels in the inheriting dts files: I think this has a big toll on readability which i would like to avoid (personally).

adschm · 2019-08-03T23:11:59Z

@blocktrron

Shared LED naming is something that should be avoided. I was told some time ago, the only exception are TP-Link boards, which use tp-link::.

Okay, noted.

Regarding sharing of the LED definitions and adding the labels in the inheriting dts files: I think this has a big toll on readability which i would like to avoid (personally).

I agree on this one.

@jackcolentern

So keep LEDs as they are. Sorry for the confusion.

blocktrron · 2019-08-04T23:29:44Z

Thanks! Merged to my staging tree: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=summary

pmelange · 2019-08-07T13:27:16Z

support for C3 is now in PR #2307

minhdanh · 2019-08-26T14:02:50Z

@pmelange I'm running into the situation where I can't install openwrt for my DIR-842 C1.
I tried to upgrade the firmware from the web UI but it always says "Firmware upgrade failed": https://www.dropbox.com/s/i47pq5tgci9y7ad/Screenshot%202019-08-26%2020.58.48.png?dl=0

I tried to upgrade the firmware to 3.11. Then tried again with openwrt firmware (c1) but didn't succeed either.
Also tried with openwrt c2 and c3 and still the same error.
I see you mention the failsafe-uboot method. I'm quite new to that. Can you point me to the right direction to start with that method?

minhdanh · 2019-08-27T01:57:07Z

Never mind, I followed the instructions here: https://forum.openwrt.org/t/d-link-dir-842-c3-installation/43094/7
And could flash the firmware.

pmelange · 2019-08-27T14:29:15Z

@minhdanh It's great news that you found those instructions. It would be really great if someone were to add them to https://openwrt.org/toh/d-link/d-link_dir-842

Unfortunately I don't have an account to update the wiki.

hanipouspilot · 2019-08-27T15:24:27Z

Unfortunately I don't have an account to update the wiki.

It takes a couple of minutes to make an account.

blocktrron reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/image/generic.mk Outdated Show resolved Hide resolved

blocktrron added the target/ath79 pull request/issue for ath79 target label Jul 25, 2019

adschm reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/dts/qca9563_dlink_dir-842-c1.dts Outdated Show resolved Hide resolved

blocktrron reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/dts/qca9563_dlink_dir-842-c.dtsi Outdated Show resolved Hide resolved

target/linux/ath79/image/generic.mk Outdated Show resolved Hide resolved

adschm reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/dts/qca9563_dlink_dir-842.dtsi Outdated Show resolved Hide resolved

adschm mentioned this pull request Jul 25, 2019

treewide: Provide label MAC address #2159

Closed

adschm reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/dts/qca9563_dlink_dir-842-c2.dts Outdated Show resolved Hide resolved

adschm reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/dts/qca9563_dlink_dir-842-c1.dts Outdated Show resolved Hide resolved

blocktrron reviewed Jul 25, 2019

View reviewed changes

target/linux/ath79/base-files/etc/board.d/02_network Outdated Show resolved Hide resolved

blocktrron reviewed Jul 30, 2019

View reviewed changes

blocktrron mentioned this pull request Jul 31, 2019

ramips: Add support for Netgear EX6130 #2286

Closed

blocktrron closed this Aug 4, 2019

Uh oh!

Conversation

programmingisart commented Jul 25, 2019

Uh oh!

programmingisart commented Jul 25, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

blocktrron left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adschm commented Jul 25, 2019

Uh oh!

programmingisart commented Jul 25, 2019

Uh oh!

adschm commented Jul 25, 2019

Uh oh!

programmingisart commented Jul 25, 2019

Uh oh!

blocktrron commented Jul 25, 2019

Uh oh!

programmingisart commented Jul 25, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hanipouspilot commented Jul 26, 2019

Uh oh!

programmingisart commented Jul 26, 2019

Uh oh!

blocktrron commented Jul 26, 2019

Uh oh!

hanipouspilot commented Jul 26, 2019

Uh oh!

programmingisart commented Jul 26, 2019

Uh oh!

programmingisart commented Jul 26, 2019

Uh oh!

pmelange commented Jul 30, 2019

Uh oh!

blocktrron left a comment

Choose a reason for hiding this comment

Uh oh!

blocktrron Jul 30, 2019

Choose a reason for hiding this comment

Uh oh!

programmingisart Jul 30, 2019

Choose a reason for hiding this comment

Uh oh!

programmingisart commented Jul 31, 2019

Uh oh!

blocktrron commented Jul 31, 2019

Uh oh!

pmelange commented Jul 31, 2019

Uh oh!

pmelange commented Jul 31, 2019

Uh oh!

adschm commented Aug 1, 2019

Uh oh!

hanipouspilot commented Aug 1, 2019

Uh oh!

adschm commented Aug 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hanipouspilot commented Aug 1, 2019

Uh oh!

adschm commented Aug 1, 2019

Uh oh!

hanipouspilot commented Aug 1, 2019

Uh oh!

adschm commented Aug 1, 2019

Uh oh!

hanipouspilot commented Aug 1, 2019

Uh oh!

bobafetthotmail commented Aug 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

programmingisart commented Jul 25, 2019 •

edited

Loading

adschm commented Aug 1, 2019 •

edited

Loading

bobafetthotmail commented Aug 1, 2019 •

edited

Loading

hanipouspilot commented Aug 1, 2019 •

edited

Loading

adschm commented Aug 1, 2019 •

edited

Loading

hanipouspilot commented Aug 1, 2019 •

edited

Loading

programmingisart commented Aug 1, 2019 •

edited

Loading

programmingisart commented Aug 1, 2019 •

edited

Loading