Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Openwrt 19.07 cudy WR1300 support #3725

Closed
wants to merge 4 commits into from

Conversation

fermat2a
Copy link

Adding support for AC1200 Dual Band Wi-Fi Router WR1300 into Openwrt 19.07 (http://www.cudytech.com/productinfo/90088.html).

Integration into master is in progress.

jgora and others added 4 commits October 30, 2020 16:48
Signed-off-by: Sascha Effert <fermat@douglas2a.de>
Signed-off-by: Sascha Effert <fermat@douglas2a.de>
Currently it's not possible to tftpboot initramfs image on archer-c7-v5
as the image contains tplink-v1-header which leads to:

 ath> bootm
 ## Booting image at 81000000 ...
 Bad Magic Number

as U-Boot expects uImage wrapped image. This is caused by following
inheritance issue:

  define Device/Init
    KERNEL_INITRAMFS = $$(KERNEL)

  define Device/tplink-v1
    KERNEL := kernel-bin | append-dtb | lzma
    KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v1-header

  define Device/tplink-safeloader
    $(Device/tplink-v1)

  define Device/tplink-safeloader-uimage
    $(Device/tplink-safeloader)
    KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma

  define Device/tplink_archer-c7-v5
    $(Device/tplink-safeloader-uimage)

where tplink-v1 defines KERNEL_INITRAMFS with tplink-v1-header and it's
then used by all devices inheriting from tplink-safeloader. Fix this by
overriding KERNEL_INITRAMFS to KERNEL variable again.

Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit ceeece9)
Signed-off-by: Sascha Effert <fermat@douglas2a.de>
This brings in cudy WR-1300 support

Signed-off-by: Sascha Effert <fermat@douglas2a.de>
@musashino205
Copy link
Contributor

"Thus, device support typically is not backported."
https://openwrt.org/docs/guide-developer/device-support-policies#device_support_backports

@fermat2a
Copy link
Author

fermat2a commented Dec 27, 2020

"While feature backports still should be an exception, they typically are done for changes that are easy and well isolated. In contrast, requiring new drivers or patches to kernel subsystems etc. will drive your chances close to zero."
https://openwrt.org/docs/guide-developer/device-support-policies#device_support_backports

I hoped that this is the case here...

I signed off the commits now, I had forgotten to do this before.

@adschm
Copy link
Member

adschm commented Dec 27, 2020

This has several formal issues, and adding a full DTS file is not simple/trivial in the original idea of that text. Apart from that, 19.07 has become quite old now, so your chances are virtually zero, particularly since you cannot present a strong argument to support your case. I won't merge it, and I don't think anybody else will.

@adschm adschm added needs changes release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release target/ath79 pull request/issue for ath79 target target/ramips pull request/issue for ramips target and removed target/ath79 pull request/issue for ath79 target labels Dec 27, 2020
@fermat2a
Copy link
Author

fermat2a commented Dec 27, 2020 via email

@rotanid
Copy link
Contributor

rotanid commented Dec 27, 2020

@fermat2a i'm not sure if it's written down, but having support in the master branch is crucial, otherwise it won't ever be acceptable for stable branches. so you (or the guys working on the patches) did it in the wrong order.
The release branch for the 20 release will happen very soon, so it's not even guaranteed anymore you get this device into the next release or at least getting it there will also be a backport from master branch to 20.x release branch then.
maybe sad news, but reality is better than false hopes.

@fermat2a
Copy link
Author

fermat2a commented Dec 28, 2020 via email

@rotanid
Copy link
Contributor

rotanid commented Dec 28, 2020

no, as long as there is no branch, the work happens in master branch

@fermat2a fermat2a closed this Jan 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs changes release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release target/ramips pull request/issue for ramips target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants