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 Dlink DIR-878 A1 #2588

Open
wants to merge 1 commit into
base: master
from

Conversation

@Lucky1openwrt
Copy link

Lucky1openwrt commented Dec 4, 2019

Specifications:

  • SoC: MT7621AT
  • RAM: 128MB
  • Flash: 16MB NOR SPI flash
  • WiFi: MT7615N (2.4GHz) and MT7615N (5Ghz)
  • LAN: 5x1000M
  • Firmware layout is Uboot with extra 96 bytes in header
  • Base PCB is AP-MTKH7-0002
  • LEDs Power green,Power Orange,Internet green,Internet Orange
  • Buttons Reset,WPS,WIFI
  • LEDs "2.4G" green & "5G" green "not woking" connect directly to wifi module

Flash instruction:

Upload image via emergency recovery mode
Push and hold reset button (on the bottom of the device) until power led starts flashing (about 10 secs or so) while plugging in the power cable.
Give it ~30 seconds, to boot the recovery mode GUI
Connect your client computer to LAN1 of the device
Set your client IP address manually to 192.168.0.2 / 255.255.255.0.
Call the recovery page for the device at http://192.168.0.1
Use the provided emergency web GUI to upload and flash a new firmware to the device

MAC addresses:

lan factory 0xe000 *:55 (label)
wan factory 0xe006 *:58
2.4 GHz factory 0x0004 *:56
5.0 GHz factory 0x8004 *:57

Signed-off-by: Alan Luck luckyhome2008@gmail.com

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.

@ynezz ynezz added the target/ramips label Dec 4, 2019
@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch from e85d3c1 to c6026a1 Dec 5, 2019
@dengqf6

This comment has been minimized.

Copy link
Contributor

dengqf6 commented Dec 8, 2019

openwrt/mt76#330
Try the patch

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 9, 2019

openwrt/mt76#330
Try the patch

ok will try
I'll have to lean about compiling Packages sorry will take a wile for me

@dengqf6

This comment has been minimized.

Copy link
Contributor

dengqf6 commented Dec 9, 2019

LEDs "2.4G" green & "5G" green "not working" connect directly to wifi module

@LorenzoBianconi

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 11, 2019

using patch 509d058 & 5e5f115 it did work but led was inverse using settings

    option sysfs 'mt76-phy0'
    option default '0'
    option trigger 'netdev'
    list mode 'link'
    list mode 'tx'
    list mode 'rx'
    option dev 'wlan0'

showed correctly after swapping mask
from
#define MT_LED_STATUS_OFF_MASK GENMASK(31, 24)
#define MT_LED_STATUS_ON_MASK GENMASK(23, 16)
to
#define MT_LED_STATUS_OFF_MASK GENMASK(23, 16)
#define MT_LED_STATUS_ON_MASK GENMASK(31, 24)

@dengqf6

This comment has been minimized.

Copy link
Contributor

dengqf6 commented Dec 11, 2019

it did work but led was inverse

Then you need led-active-low in each mt76 node:

&pcie0 {
	wifi@0,0 {
		compatible = "mediatek,mt76";
		reg = <0x0000 0 0 0 0>;
		mediatek,mtd-eeprom = <&factory 0x0000>;
		ieee80211-freq-limit = <2400000 2500000>;
+
+		led {
+			led-active-low;
+		};
	};
};

&pcie1 {
	wifi@0,0 {
		compatible = "mediatek,mt76";
		reg = <0x0000 0 0 0 0>;
		mediatek,mtd-eeprom = <&factory 0x8000>;
		ieee80211-freq-limit = <5000000 6000000>;
+
+		led {
+			led-active-low;
+		};
	};
};
@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch 2 times, most recently from 68c7510 to ca34f91 Dec 12, 2019
@achterin

This comment has been minimized.

Copy link
Contributor

achterin commented Dec 12, 2019

@Lucky1openwrt are both radios working at the same time? i was under the impression that mt76 could not handle dual-radio on mt7615 right now. did i miss something?

@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch 2 times, most recently from afaeffc to 25355eb Dec 13, 2019
@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch from 25355eb to 3af5f2e Dec 14, 2019
@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 14, 2019

the changes in the mtdsplit_uimage.c
there is only one change between "uimage_fonfxc_parser" & "uimage_ubootpad96_parser"
it's an immediate value
"#define FONFXC_PAD_LEN 32" &
"#define ubootpad96_PAD_LEN 96"
I don't know a good way of doing this with out breaking the "uimage_fonfxc_parser"

@Borromini

This comment has been minimized.

Copy link

Borromini commented Dec 16, 2019

I have a DIR-878 on the way, thanks for your efforts already @Lucky1openwrt. Will test, anything I need to try let me know.

@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch from 3af5f2e to 9cb584c Dec 16, 2019
@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 16, 2019

I have a DIR-878 on the way, thanks for your efforts already @Lucky1openwrt. Will test, anything I need to try let me know.
HI thanks for testing
the last kernel: bump has broken something it crashes while booting but not always
& you need to add some commits for the wifi leds to work also

@Borromini

This comment has been minimized.

Copy link

Borromini commented Dec 17, 2019

the last kernel: bump has broken something it crashes while booting but not always

I assume you don't know yet what exactly?

& you need to add some commits for the wifi leds to work also

I assume you mean this patch which @dengqf6 got pointed to in the mt76 issue tracker?

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 17, 2019

yes to all above
problem seems to be switch related I think but random more likely on cold boot
[ 3.176483] libphy: Fixed MDIO Bus: probed
[ 3.185282] CPU 3 Unable to handle kernel paging request at virtual address 131312df, epc == 804a4140, ra == 804a48b8

[ 4.721628] 8021q: 802.1Q VLAN Support v1.8
[ 4.731450] CPU 3 Unable to handle kernel paging request at virtual address 00f2c004, epc == 8012f578, ra == 80121c08

[ 3.177485] libphy: Fixed MDIO Bus: probed
[ 3.254444] libphy: mdio: probed
[ 4.661819] mtk_soc_eth 1e100000.ethernet: loaded mt7530 driver
[ 4.674370] mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21
[ 4.693463] NET: Registered protocol family 10
[ 4.703889] Segment Routing with IPv6
[ 4.711252] NET: Registered protocol family 17
[ 4.720180] 8021q: 802.1Q VLAN Support v1.8
[ 4.729985] CPU 3 Unable to handle kernel paging request at virtual address 00f2c004, epc == 8012f578, ra == 8049841c
[ 4.732422] CPU 1 Unable to handle kernel paging request at virtual address 00000204, epc == 00000204, ra == 00000204
[ 4.732432] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000

@Borromini

This comment has been minimized.

Copy link

Borromini commented Dec 17, 2019

I have 4.14.158 running on my RT-AC57U (19.07 HEAD, mt7621 as well), no issues there it seems. Has been stable here for over a week (first build with 4.14.158 here flashed on December 7th, scheduled reboot on December 15th).

Going out on a limb here (no programming experience); is the kernel asking access for a memory range it has no access to? Might this have something to do with what's specified in the DTS?

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 19, 2019

at the moment i just know that update stopped it working the way it was & back dating it give me a working device again
I'm sure by it's randomness it's some sort of stack overflow or IRQ going bad but I'm still earning the language & environment so I'm no where near finding out ATM

@Borromini

This comment has been minimized.

Copy link

Borromini commented Dec 20, 2019

@Lucky1openwrt I think you can remove the kmod-usb3 package from DEVICE_PACKAGES := as well, since there are no USB ports on the DIR-878.

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Dec 20, 2019

@Lucky1openwrt I think you can remove the kmod-usb3 package from DEVICE_PACKAGES := as well, since there are no USB ports on the DIR-878.

I keep wondering about this 1st off the original firmware still set's up USB so I left it there as to be safe 2nd i keep wanting to add at lest one of the headers at lest the usb2.0 one
but then I could just use a version written for the dir-878 or MR2600
I'll take it out & hope there is no bad effects form it

@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch from 9cb584c to 4542606 Dec 20, 2019
@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch from b3878f7 to 46841ed Dec 27, 2019
@Borromini

This comment has been minimized.

Copy link

Borromini commented Jan 5, 2020

@adrianschmutzler Is this good to go? Works fine here.

@mjsir911

This comment has been minimized.

Copy link

mjsir911 commented Jan 11, 2020

of note is that this seems to partially break the original emergency recovery bootloader, which serves up an http page but as soon as you request any http page crashes and will not receive a new image.

I believe this is due to the differing entrypoints, on the original firmware image:

$ file DIR-878_A1_FW101B04.bin 
DIR-878_A1_FW101B04.bin: u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 9677352 bytes, Wed Jul 19 13:30:56 2017, Load Address: 0x81001000, Entry Point: 0x81611040, Header CRC: 0x7743E712, Data CRC: 0x7C1975D1

and on the openwrt firmware compiled from this branch:

t$ file bin/targets/ramips/mt7621/openwrt-ramips-mt7621-dlink_dir-878-a1-squashfs-factory.bin 
bin/targets/ramips/mt7621/openwrt-ramips-mt7621-dlink_dir-878-a1-squashfs-factory.bin: u-boot legacy uImage, MIPS OpenWrt Linux-4.14.160, Linux/MIPS, OS Kernel Image (lzma), 2010810 bytes, Fri Dec 27 22:12:33 2019, Load Address: 0x80001000, Entry Point: 0x80001000, Header CRC: 0x7123C377, Data CRC: 0xFBF1BB3F
@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 11, 2020

Hi Mjsir911
I'm aware someone having trouble upload firmware using Firefox on Linux
tho I have never had any issues using firefox windows
are you able to give me more information about your setup so I can try to reproduce
what you are seeing ?
what firmware is is the board ? & what you are trying to upload ?
are you saying the dlink firmware works but openwrt fails ?

@x86ln

This comment has been minimized.

Copy link

x86ln commented Jan 12, 2020

of note is that this seems to partially break the original emergency recovery bootloader, which serves up an http page but as soon as you request any http page crashes and will not receive a new image.

@mjsir911 This isn't related to this patch or even custom firmware in general. I have experienced this behaviour since day one on both my DIR-878 and DIR-882.

On the DD-WRT forums larkey explains the problem and a workaround he found, and loaded_scissors mentions the problem in response.

I have been using a Windows XP VM and IE6 with absolutely not issue since discovering this. A user in that thread claims to have tried using curl, but I can't find the post so I'm not sure how that went.

@Lucky1openwrt I am currently using your patch and building against MediaTek's mt_wifi source with lain's mt/* packages. My DIR-882 is getting more stable by the day. Thank you.

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 12, 2020

I can confirm at lest with "debian-10.2.0-amd64" & firefox the the recover page does not work
it won't work with the dlink firmware on the unit & uploading dlink firmware
so if this is it it's nothing to do with openwrt
thanks for the info x86ln

@Borromini

This comment has been minimized.

Copy link

Borromini commented Jan 12, 2020

@mjsir911

This comment has been minimized.

Copy link

mjsir911 commented Jan 12, 2020

The original upload of openwrt worked fine through the recovery page, I only started experiencing problems after that first flash of the new firmware.

I was using firefox for linux, but I also attempted to use curl on linux to the same problem. Although reading the proposed solutions, this should've worked. The last line the serial port was reporting was 'sending length xxxx, size xxxx' (trying to remember from memory), which after that didn't do anything.

The solution I found to flash new firmware through the bootloader was to connect to the serial console and select option 2 which allows to allow a new firmware to be downloaded from a tftp server.

I might try booting into a windows machine to see if I can reproduce it working there

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 14, 2020

sounds like bad coincidence but please do check with windows if you can.
It would be nice to find a way to get this to work on Linux. some thing for a future DIR-878 support page
I'm primarily a windows user & Linux is only secondary for me

@x86ln

This comment has been minimized.

Copy link

x86ln commented Jan 14, 2020

I had a bit of an idea about this and installed a Firefox add-on that allowed me to change my User-Agent request header. After switching to MSIE 6.0 I was able to use the D-LINK emergency recovery page without it crashing and requiring a reboot. It reliably crashes if I change the header back to default.

Could this be a solution? Can anyone else test this and report back? I'm spinning up a VM to test this on another Linux box. Could this situation be caused by something as silly as a buffer overrun?

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 14, 2020

Could this be a solution? Can anyone else test this and report back? I'm spinning up a VM to test this on another Linux box. Could this situation be caused by something as silly as a buffer overrun?

I had a go but no luck for me "debian-10.2.0-amd64" & firefox
tried the one at link & another user agent changer even changing it to the same user agent string that works on windows 7
It even seems to even have trouble getting a lookup in the ARP table but manually adding it didn't change anything

@mjsir911

This comment has been minimized.

Copy link

mjsir911 commented Jan 14, 2020

sounds like bad coincidence but please do check with windows if you can.

Can confirm that it worked for me perfectly fine in windows

@LeonardKoenig

This comment has been minimized.

Copy link

LeonardKoenig commented Jan 19, 2020

of note is that this seems to partially break the original emergency recovery bootloader, which serves up an http page but as soon as you request any http page crashes and will not receive a new image.

@mjsir911 This isn't related to this patch or even custom firmware in general. I have experienced this behaviour since day one on both my DIR-878 and DIR-882.

On the DD-WRT forums larkey explains the problem and a workaround he found, and loaded_scissors mentions the problem in response.

I have been using a Windows XP VM and IE6 with absolutely not issue since discovering this. A user in that thread claims to have tried using curl, but I can't find the post so I'm not sure how that went.

Hi, (larkey from the forums checking in :P), any Windows with IE should work, I've got a VM here running Win10 with IE11 on QEMU which has no problem flashing the router. To me it seems like a combination of user-agent and different timeouts, page-cache-handling. I'll probably write a small script based on nc or similar to flash the image for UNIX.

@Lucky1openwrt I am currently using your patch and building against MediaTek's mt_wifi source with lain's mt/* packages. My DIR-882 is getting more stable by the day. Thank you.

Hm, could you share your efforts? I'm building for DIR-882 as well but sometimes (after flashing the same image) it simply won't boot up. And if it is, I "only" get SSH and then complaints about the SQUASHFS being corrupt: https://pastebin.com/iTpBiVJg

This is w/o the official mt_wifi source yet and simply using this branch with one patch to add support for 882 in a similar vein -- maybe I'm missing something? I'm gonna rebase it on current master and adding the other patches mentioned here for testing now.

@Lucky1openwrt For reference, I've uploaded the official source drops in my Github and also added a small wiki documenting me trying to build this mess. Maybe we could improve the pad96 stuff to include more documentation why it's needed. Basically they've added another 0x60 bytes into the uImage header (cf. image.h) containing the kernel size, the product name, fw version and hardware revision. Actually they've even shortened the image name IH_NMLEN by four bytes to fit the kernel size in... . But as the router doesn't seem to check whether the checksum of the uImage header is correct, we can just pad it, as you did.

And kudos to everyone involved in getting this device up and running!

EDIT: @mjsir911 how did you setup the serial? I've used the through-hole connectors labeled J1 behind the WPS/WIFI/RESET buttons, using the following mapping (read from the 1 indicating the first pin):

  • 1 -- probably Vcc
  • 2 -- TX
  • 3 -- RX
  • 4 -- GND

Using 57600N8 for the serial console. However I cannot access the Bootmenu / stop it from autobooting and thus flash from TFTP or similar. How are you handling this?

EDIT2: It's likely that this script will work for this router as well, I can't test right now though.

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 19, 2020

RS232 port info
Pin1 I guess it's VCC so not connected "Noted by the 1 next to it"
Pin2 Data To Board " it's RX"
Pin3 Data From Board "it's TX"
Pin4 GND
and yes 57600 for PuTTY what I use
as for the boot menu just send it the option as it's booting
turn it on when you see data start to show hit 4 a few times & it will stop at the Command line Interface

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 20, 2020

off the top of my head "it's been a while now"
the board check the uboot header checksum with the 1st XX bytes to see if it's valid
the one in this board they have change to include more info this is where the +96 come's in
I did think about filling in the info but that fact that dlink change the format for there firmware updates would mean it would only work from the 1st few firmware versions & as it tend to update it self I saw no need as you would have to use the recovery interface to downgrade the firmware to use it & you may as well just put openwrt in there then

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 20, 2020

UBoot with +96 bytes "ubootpad96" didn't call it d-link cos there are motorolla versions as well
there is already a fonfxc "Fon(Foxconn)" that has a 32 byte pad Lenth
all I did was chnage it to 96 bytes from 32
I duplicated that code segments needed so it would not brake the current boards

there is a check sum that only check the kernal part of the firmware that on others "dd-wrt & dlink" check all of it
I did change this as one point to include the rootfs but it's broke the addressing for the rootfs_data partition
I have been trying to keep it all as simple as possible

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 20, 2020

should I add support for the 882
make another .dts files & a shared dtsi
or keep waiting form something to happen as it is ?

@Borromini

This comment has been minimized.

Copy link

Borromini commented Jan 20, 2020

@Lucky1openwrt DTSes will be split up anyway, if you don't mind you can split your DTS(I) already.

@adrianschmutzler

This comment has been minimized.

Copy link
Member

adrianschmutzler commented Jan 20, 2020

DTSes will be split up anyway, if you don't mind you can split your DTS(I) already.

Typically it's a good idea to split DTSes with the first device only if there is already a clear idea of what the second device's DTS will be like. Otherwise, frequent experience is that code has to be moved around anyway due to stuff that has been overlooked, and then it might be easier to have one DTS at the beginning and create the DTSI only with the second commit when it is clear what it has to contain.

Since this is a long story already, I would favor keeping one DTS for now, as introducing a DTSI will just make things more complicated.

@Borromini is invited to submit another PR for his device, and if there is duplicate code we will clean that up during merge eventually.

@Borromini

This comment has been minimized.

Copy link

Borromini commented Jan 20, 2020

@adrianschmutzler That would be either @x86ln or @LeonardKoenig I have a DIR-878 myself 😄 .

@adrianschmutzler

This comment has been minimized.

Copy link
Member

adrianschmutzler commented Jan 20, 2020

@adrianschmutzler That would be either @x86ln or @LeonardKoenig I have a DIR-878 myself .

Ah, sorry, I didn't read the whole history on this topic. But this shouldn't affect my general argumentation. :-)

@LeonardKoenig

This comment has been minimized.

Copy link

LeonardKoenig commented Jan 20, 2020

RS232 port info
Pin1 I guess it's VCC so not connected "Noted by the 1 next to it"
Pin2 Data To Board " it's RX"
Pin3 Data From Board "it's TX"
Pin4 GND
and yes 57600 for PuTTY what I use
as for the boot menu just send it the option as it's booting
turn it on when you see data start to show hit 4 a few times & it will stop at the Command line Interface

Hm, maybe I just didn't hit 4 fast enough :)

off the top of my head "it's been a while now"
the board check the uboot header checksum with the 1st XX bytes to see if it's valid
the one in this board they have change to include more info this is where the +96 come's in
I did think about filling in the info but that fact that dlink change the format for there firmware updates would mean it would only work from the 1st few firmware versions & as it tend to update it self I saw no need as you would have to use the recovery interface to downgrade the firmware to use it & you may as well just put openwrt in there then

Yeah, what's baffling me is that despite those 96 Bytes being added to the uImage header in D-Links custom mkimage, they apparently aren't used for the checksum, as otherwise the padding here would break the checksum.

UBoot with +96 bytes "ubootpad96" didn't call it d-link cos there are motorolla versions as well
there is already a fonfxc "Fon(Foxconn)" that has a 32 byte pad Lenth
all I did was chnage it to 96 bytes from 32
I duplicated that code segments needed so it would not brake the current boards

Maybe one could create a padN() function at some point, but I think that's for later.

@LeonardKoenig

This comment has been minimized.

Copy link

LeonardKoenig commented Jan 20, 2020

DTSes will be split up anyway, if you don't mind you can split your DTS(I) already.

Typically it's a good idea to split DTSes with the first device only if there is already a clear idea of what the second device's DTS will be like. Otherwise, frequent experience is that code has to be moved around anyway due to stuff that has been overlooked, and then it might be easier to have one DTS at the beginning and create the DTSI only with the second commit when it is clear what it has to contain.

Since this is a long story already, I would favor keeping one DTS for now, as introducing a DTSI will just make things more complicated.

@Borromini is invited to submit another PR for his device, and if there is duplicate code we will clean that up during merge eventually.

I'm currently running virtually the same DTS, but right now the device still complains about the SQUASHFS being corrupt (but seems to work fine despite this), but also doesn't receive any IP on the WAN port, so I can build a local LAN but don't have Internet access yet. In general though, the DTS should be fairly similar, but I'd also do that in a separate PR.

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 20, 2020

I do believe the only difference would be changing the 878 to 882 & adding the USB LED
but I won't do anything about 882 dts

the header size & checksum are used while using the recover page to upload the firmware
1st check is the 1st 4 bytes are "27051956"
2nd check is the header checksum if you zero out bytes 04-07 run a crc32 on the first 176 "0xB0" bytes it will equal the 4 bytes you just cleared
3rd byte is data checksum it's a crc32 from 0xB0 to image size "need to confirm this step only from memory"

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 20, 2020

I'm not sure why you are having problems with SQUASHFS
I'll update to the latest & see if i get any faults later
for me the WiFi stopped working after the December mt76 package updates
that's the only fault i know of ATM

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 20, 2020

ok i just updated my local copy up to the current master
and well yes something else is broken
I keep getting "jffs2: Erase at 0x00000000 failed immediately: -EROFS. Is the sector locked?"
each boot it's erasing the config this is a new bug

@Lucky1openwrt

This comment has been minimized.

Copy link
Author

Lucky1openwrt commented Jan 21, 2020

I removed the last kernel update
I'm now at 4.14.162 and it's work fine again now

Specifications:
* SoC: MT7621AT
* RAM: 128MB
* Flash: 16MB NOR SPI flash
* WiFi: MT7615N (2.4GHz) and MT7615N (5Ghz)
* LAN: 5x1000M
* Firmware layout is Uboot with extra 96 bytes in header
* Base PCB is AP-MTKH7-0002
* LEDs Power Green,Power Orange,Internet Green,Internet Orange
* LEDs "2.4G" Green & "5G" Green connected directly to wifi module
* Buttons Reset,WPS,WIFI

Flash instruction:

Upload image via emergency recovery mode via Windows "not working with Linux"
Push and hold reset button (on the bottom of the device) until power led starts flashing (about 10 secs or so) while plugging in the power cable.
Give it ~30 seconds, to boot the recovery mode GUI
Connect your client computer to LAN1 of the device
Set your client IP address manually to 192.168.0.2 / 255.255.255.0.
Call the recovery page for the device at http://192.168.0.1
Use the provided emergency web GUI to upload and flash a new firmware to the device

MAC addresses:

lan      factory 0xe000 *:55 (label)
wan      factory 0xe006 *:58
2.4 GHz  factory 0x0004 *:56
5.0 GHz  factory 0x8004 *:57

Signed-off-by: Alan Luck <luckyhome2008@gmail.com>
@Lucky1openwrt Lucky1openwrt force-pushed the Lucky1openwrt:master branch from 46841ed to a87f8fd Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.