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

ramips: add support for Cudy X6 #4582

Closed
wants to merge 1 commit into from

Conversation

alessioprescenzo
Copy link
Contributor

@alessioprescenzo alessioprescenzo commented Sep 21, 2021

Specifications:

  • SoC: MediaTek MT7621
  • RAM: 256 MB
  • Flash: 32 MB
  • WiFi: MediaTek MT7915E
  • Switch: 1 WAN, 4 LAN (Gigabit)
  • Ports: 1 USB 3.0
  • Buttons: Reset, WPS
  • LEDs: Power, System, Wan, Lan 1-4, WiFi 2.4G, WiFi 5G, WPS, USB
  • Power: DC 12V 1A tip positive

Installation:

Download and flash the manufacturer's built OpenWRT image available at
http://www.cudytech.com/openwrt_software_download
Install the new OpenWRT image via luci (System -> Backup/Flash firmware)
Be sure to NOT keep settings. The force upgrade may need to be checked
due to differences in router naming conventions.

Recovery:

  • Loads only signed manufacture firmware due to bootloader RSA verification
  • serve tftp-recovery image as /recovery.bin on 192.168.1.88/24
  • connect to any lan ethernet port
  • power on the device while holding the reset button
  • wait at least 8 seconds before releasing reset button for image to
    download

Signed-off-by: Alessio Prescenzo alessioprescenzo@gmail.com

};

&gmac0 {
mtd-mac-address = <&bdinfo 0xde00>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mtd-mac-address property was replaced to NVMEM implementation.
see 06bb4a5

status = "okay";
label = "wan";
mtd-mac-address = <&bdinfo 0xde00>;
mtd-mac-address-increment = <1>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mtd-mac-address-increment property was replaced to mac-address-increment.
see d284e6e

@@ -281,6 +281,16 @@ define Device/cudy_wr2100
endef
TARGET_DEVICES += cudy_wr2100

define Device/cudy_x6
$(Device/dsa-migration)
IMAGE_SIZE := 32448k
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

32256k (0x1F80000)?

Copy link
Contributor Author

@alessioprescenzo alessioprescenzo Sep 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made all the changes required except this, i don't get what i should do, sorry :(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, IMAGE_SIZE is defined as 32448k (= 0x1FB0000) but the size of "firmware" partition is defined as 0x1f80000 (= 32256k). IMAGE_SIZE basically needs to fit the size of "firmware" partition.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got that, thanks for the explanation ur saving my day :D

@alessioprescenzo
Copy link
Contributor Author

I have a small problem. With the changed dts file now my LAN mac-address is random at every boot. Did i do smth wrong?

@musashino205
Copy link
Contributor

Perhaps you need to use bdinfo instead of factory for MAC addresses.

ece9616#diff-2e939dd0265c59a983dfae2e08b6ab48a8ca0e37c772bd1cce2b88fef41d5af2L125-L129

@alessioprescenzo
Copy link
Contributor Author

For sure you are right, i've noticed and changed that partition name 10 minutes after my comment, tested and working, now with the correct mac :)

@alessioprescenzo
Copy link
Contributor Author

I've tested and committed every required changes, hope now it's applicable for merging :)

Comment on lines 171 to 176
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;

macaddr_bdinfo_de00: macaddr@de00 {
reg = <0xde00 0x6>;
Copy link
Contributor

@musashino205 musashino205 Sep 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please delete a space at the beginning of these lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on my end i don't see spaces at the beginning of those line, it's just a tab (/t)

macaddr_bdinfo_de00: macaddr@de00 {
reg = <0xde00 0x6>;
};
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a line break at the end of file.

@musashino205
Copy link
Contributor

You need to squash all commits to single commit.
see: https://openwrt.org/docs/guide-developer/working-with-github-pr#squashing_commits

@alessioprescenzo
Copy link
Contributor Author

I've messed up a lot those commits and i seriously don't know how to revert this, can i close this this pull request and create another clean on? Sorry to bother

@musashino205
Copy link
Contributor

musashino205 commented Sep 22, 2021

I will explain from the current state in GitHub:

  1. backup current development branch
    git branch Cudy-X6.back Cudy-X6
    this creates a branch "Cudy-X6.back" from "Cudy-X6"

  2. reset commits to before 19f1187689
    git reset --hard 19f1187689^

  3. add-back commit b6572e52a0
    git cherry-pick b6572e52a0

  4. add missing commit title
    git commit --amend
    and insert title to the first line: ramips: add support for Cudy X6

  5. push changes to GitHub
    git push -f

This PR will be updated automatically after the changes are pushed.

EDIT:

If you want to get changes from master, use git rebase instead of git pull or git merge.

git rebase master Cudy-X6

@alessioprescenzo
Copy link
Contributor Author

Thank you a lot, I've learned smth new thx to you today 👍 😄

@musashino205
Copy link
Contributor

Oops, there is a mistake in the commit title, rampis...

git commit --amend
# fix title and save/exit editor
git push -f

Specifications:

SoC: MediaTek MT7621
RAM: 256 MB
Flash: 32 MB
WiFi: MediaTek MT7915E
Switch: 1 WAN, 4 LAN (Gigabit)
Ports: 1 USB 3.0
Buttons: Reset, WPS
LEDs: Power, System, Wan, Lan 1-4, WiFi 2.4G, WiFi 5G, WPS, USB
Power: DC 12V 1A tip positive
Installation:

Download and flash the manufacturer's built OpenWRT image available at
http://www.cudytech.com/openwrt_software_download
Install the new OpenWRT image via luci (System -> Backup/Flash firmware)
Be sure to NOT keep settings. The force upgrade may need to be checked
due to differences in router naming conventions.

Recovery:

Loads only signed manufacture firmware due to bootloader RSA verification
serve tftp-recovery image as /recovery.bin on 192.168.1.88/24
connect to any lan ethernet port
power on the device while holding the reset button
wait at least 8 seconds before releasing reset button for image to
download

Signed-off-by: Alessio Prescenzo <alessioprescenzo@gmail.com>
@alessioprescenzo
Copy link
Contributor Author

Everything should be fine now :D

@pepe2k pepe2k added the target/ramips pull request/issue for ramips target label Sep 23, 2021
@adschm
Copy link
Member

adschm commented Sep 24, 2021

@musashino205 Thanks for helping me out here :-)


&state_default {
gpio {
groups = "wdt", "i2c", "jtag";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't see any GPIOs for i2c?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need a package to see them right? RN I'm cherry-picking my packages so there's a high probability that if this needs a package I don't have it installed (I'm saying that because I've seen the i2c section in menuconfig)

Copy link
Member

@adschm adschm Sep 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, essentially you just look which GPIOs you have used above and then put the corresponding groups here.
I've once compiled an Excel document for that.

You more or less have to extract the information from this file: https://github.com/torvalds/linux/blob/745ec436de7223fbe086be5123fe3014c4220611/drivers/pinctrl/ralink/pinctrl-mt7621.c or from the documentation on the board.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll look into it soon, meanwhile the manufacturer let you download this
image

idk if it's useful or not, just sharing my documentation.

@adschm
Copy link
Member

adschm commented Sep 24, 2021

All MAC addresses correct (i.e. matching vendor firmware) now?

@alessioprescenzo
Copy link
Contributor Author

All MAC addresses correct (i.e. matching vendor firmware) now?

Yes, now mac addresses are correct

@s-2
Copy link
Contributor

s-2 commented Sep 26, 2021

The force upgrade may need to be checked
due to differences in router naming conventions.

Since this device seems to be based on a previous version of OpenWrt, could the OEM model name be added to image metadata via SUPPORTED_DEVICES?

@rola25
Copy link

rola25 commented Oct 5, 2021

@alessioprescenzo Do you have a precompiled firmware for Cudy X6 somewhere lying around? I have two X6 - I could test it and give you information if something is not working as it should ...

@alessioprescenzo
Copy link
Contributor Author

@alessioprescenzo Do you have a precompiled firmware for Cudy X6 somewhere lying around? I have two X6 - I could test it and give you information if something is not working as it should ...

Hi, I do have a firmware that actually I regularly use on x6s (i also have two with one of them being 802.11r/k/v dumb AP) preinstalled with what I use (ip-full for VLANs, Adblock for well ad-blocking, and WireGuard VPN, and LuCi obv). I can share that if you want :)

@rola25
Copy link

rola25 commented Oct 5, 2021

@alessioprescenzo Yes that would be fine. Can you share it please?

@rola25
Copy link

rola25 commented Oct 6, 2021

@alessioprescenzo I managed to compile your Cudy-X6 branch by myself, thanks anyway, it works

@Nomorerd
Copy link

What's the process now? Is it official released?

@adschm
Copy link
Member

adschm commented Nov 1, 2021

All MAC addresses correct (i.e. matching vendor firmware) now?

Yes, now mac addresses are correct

Please add a table like this to commit message: https://openwrt.org/docs/guide-developer/device-support-policies#mac_addresses

And this i2c in state_default still needs to be treated ...

@brainchild0
Copy link

Thanks to everyone who contributed.

Since this work seems close to nearing completion (apparently pending a few housekeeping issues, and reviews), would anyone be able to post a clean build of the results of the efforts so far, for loading into my devices?

Copy link

@F5BJR F5BJR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Who could add the CUDY-6 (Wifi 6 AX) to snapshots?

I have had two of these boxes for a while and thanks to our friend now the mac addresses of the 2.4 GHz and 5GHz wifi are consistent

Test:
WIFI 2.4 Ghz & 5Ghz run fine
Lan port number match with the sticker & Wan +1
Wifi mac address are correct match with the sticker + 2 & 3 thanks ur friend blocktrron developer

dts file is correct

The additions are as follows:

add in file target/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
just after case "$board" in

cudy,x6)
		hw_mac_addr="$(mtd_get_mac_binary factory 0x4)"
		[ "$PHYNBR" = "0" ] && macaddr_add $hw_mac_addr "2" > /sys${DEVPATH}/macaddress
		[ "$PHYNBR" = "1" ] && macaddr_add $hw_mac_addr "3" > /sys${DEVPATH}/macaddress
		;; 

@brainchild0
Copy link

brainchild0 commented Jan 4, 2022

I am eager to begin operation on my device, and am looking for the most straightforward way to build.

I am new to the project, and hope I might ask for a bit of assistance, and that doing so in the current location is not objectionable.

What I have done is applied the revision of the current request over tag v21.02.1, the recent release. In this way I hoped to create an image representing a stable release, the same as would have been created had support for the device been added before the release. Following the same idea, I hoped to apply all of the default package selections, and other options.

I searched for a straightforward and clear way to achieve the effect I had described, hoping to bypass any interactive steps, where I might easily make mistakes, such as invoking menuconfig. I also searched for a way to utilize the new entry #define Device/cudy_x6, though was not much helped by the resources I found. Based on one source, I thought it might be correct to pass PROFILE=Device/cudy_x6 to the invocation of make, but this idea did not lead to any success. Instead, the build process broke near the end.

I was able to build without any options, or any invocation of menuconfig, which at least validates my build environment.

I did notice a warning, as follows, and wondered whether it expressed a problem, or rather was safe to ignore:

WARNING: your configuration is out of sync. Please run make menuconfig, oldconfig or defconfig!

What is the most straightforward way to build the target for the new device, Cudy x6, based on my steps so far?

@LiftedStarfish
Copy link

What's the status on this? How long should I expect it to take for this to actually be merged?

@blocktrron
Copy link
Member

Merged with changes, thanks!

@blocktrron blocktrron closed this May 9, 2022
@LiftedStarfish
Copy link

Is this good now? Can I install it on my router?

@waja
Copy link

waja commented May 11, 2022

It was included into master, but not into openwrt-22.03 branch. So it seems it will still be missing with the 22.03 release. :(

@brainchild0
Copy link

For someone running the current vendor image (e.g. OpenWrt 21.02-SNAPSHOT r15949-b2c9a8741f), what is the best path for upgrade?

Will the sysupgrade feature work correctly, even though the currently-installed image is not an official project build? Will settings be preserved for consistent operation before and after upgrade?

@tomck
Copy link

tomck commented Jul 25, 2022

According to @julyworlds https://github.com/julyworlds/openwrt-cudy-x6-firmware, @brainchild0, yes just upgrading to the snapshot will work. (I personally just upgraded to the stable version provided by their CI and it seems to work fine.)

For a link to the current snapshot bin, visit the wiki: https://openwrt.org/toh/hwdata/cudy/cudy_x6

(Note, there is no LuCi with the snapshots, you have to install it via SSH)

@brainchild0
Copy link

@tomck, So the settings will be lost, and I will need to install the web interface manually after the upgrade?

@tomck
Copy link

tomck commented Jul 25, 2022

@tomck, So the settings will be lost, and I will need to install the web interface manually after the upgrade?

Yes, always assume the settings will be lost, according to julyworlds you need to discard settings when upgrading from manufacturer OpenWRT to real OpenWRT.

@brainchild0
Copy link

@tomck May settings be saved effectively by capturing them in an external file that may be imported after booting from the replacement image?

@tomck
Copy link

tomck commented Jul 25, 2022

@brainchild0 Probably. I don't work with the OpenWRT team, was just sharing my experience, and can make no guarantees. If you are really worried, screenshot all your settings pages first so you have a reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs changes target/ramips pull request/issue for ramips target
Projects
None yet
Development

Successfully merging this pull request may close these issues.