[OpenWrt-Devel] [PATCH] ramips: add support for Asus RT-AC85P

Birger Koblitz mail at birger-koblitz.de
Sun Jul 21 01:24:05 EDT 2019


Hi,

On 20.07.19 22:15, mail at adrianschmutzler.de wrote:
> Hi,
> 
>> -----Original Message-----

>> MAC:	The MAC address on the router-label matches the MAC of
>> 	the 2.4 GHz WiFi.
>> 	LAN and WAN MAC are identical: MAC_LABEL+4
>> 	5 GHz WiFi MAC: also MAC_LABEL+4
> 
> That's a nice idea. We should encourage adding similar description for other device support commits, too.
> 
> Question: So, LAN MAC, WAN MAC AND 5 GHz MAC are the same?
Yes, indeed, this is the setup of the original firmware. It is quite strange that the 3 addresses in between
are nowhere used.

> 
>> +	asus,rt-ac85p|\
>>  	dlink,dir-860l-b1|\
>>  	elecom,wrc-1167ghbk2-s|\
>>  	elecom,wrc-1900gst|\
> 
> Please move the block so sorting of blocks keep correct.
Will do.

> 
>> @@ -532,6 +533,9 @@ ramips_setup_macs()
>>  		lan_mac=$(macaddr_setbit_la "$lan_mac")
>>  		wan_mac=$(mtd_get_mac_binary factory 32772)
>>  		;;
>> +	asus,rt-ac85p)
>> +		wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
>> +		;;
> 
> This should be before asus,rt-n56u.
Will do.

> 
> Despite, if WAN_MAC and ethernet MAC address are really the same, you technically would not need to set eth0.2 (wan) MAC address again.
> However, if you completely remove the case here, you will fall into default and set wrong addresses.
> So, one could just set the wan_mac anyway or just add an "empty" case:
>> +	asus,rt-ac85p)
>> +		;;
I would prefer to keep this as is, since it allows to configure the MAC in the U-Boot environment.
Also Asus might discover in a later FW version they could make use of the 3 addresses they were assigned,
and do not currently use...


> 
> ...
> 
>> +	compatible = "asus,rt-ac85p", "mediatek,mt7621-soc";
>> +	model = "Asus RC-AC85P";
> 
> RT instead of RC?
Ooops.


> 
>> +	leds {
>> +		compatible = "gpio-leds";
> 
> Add an empty line here.
> 
Will do.

>> +&nand {
>> +	status = "okay";
>> +
>> +	partitions {
>> +		compatible = "fixed-partitions";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +
>> +		partition at 0 {
>> +			label = "u-boot";
>> +			reg = <0x0 0xe0000>;
>> +			read-only;
>> +		};
>> +
>> +		partition at e0000 {
>> +			label = "u-boot-env";
>> +			reg = <0xe0000 0x100000>;
>> +			read-only;
>> +		};
>> +
>> +		factory: partition at 1e0000 {
>> +			label = "factory";
>> +			reg = <0x1e0000 0x100000>;
>> +			read-only;
>> +		};
>> +
>> +		factory2: partition at 2e0000 {
>> +			label = "factory2";
>> +			reg = <0x2e0000 0x100000>;
>> +			read-only;
>> +		};
>> +
>> +		partition at 3e0000 {
>> +			label = "kernel";
>> +			reg = <0x3e0000 0x400000>;
>> +		};
>> +
>> +		partition at 7e0000 {
>> +			label = "ubi";
>> +			reg = <0x7e0000 0x2e00000>;
>> +		};
>> +
>> +		partition at 35e0000 {
>> +			label = "firmware2";
> 
> Where is firmware1? kernel+ubi?
Yes, indeed. The router uses an interesting setup.
Both the web-interface and the tftp in U-Boot always install the firmware twice into the partitions
firmware 1: 3e0000  - 35dffff
firmware 2: 35e0000 - 67e0000
During boot U-Boot verifies the checksums of both partitions. If one is not OK, the content of the other
is copied over. It then boots the first partition. The second partition never gets active and therefore
should not be made available to OpenWRT apart from this blob.
One idea I had would be for sysupgrade to clear the checksum of the firmware2 partition after a sysupgrade and
have U-Boot make a backup of firmware1 into firmware2 on the subsequent reboot. Alternatively, before a sysupgrade,
a backup from firmware 1 to firmware 2 is made.
However, the present setup also has its advantage: I did manage to have sysupgrade mess-up the first partition and
U-Boot happily corrected this...

>> +&pcie0 {
>> +	wifi at 0,0 {>
> Maybe add "wifi0:" here.
Will do.

> 
>> +		compatible = "pci14c3,7603";
>> +		reg = <0x0000 0 0 0 0>;
>> +		mediatek,mtd-eeprom = <&factory 0x0000>;
>> +		ieee80211-freq-limit = <2400000 2500000>;
>> +		mtd-mac-address = <&factory 0x4>;
>> +	};
>> +};
>> +
>> +&pcie1 {
>> +	wifi at 0,0 {
> 
> Maybe add "wifi1:" here.
Will do.

> 
>> +		compatible = "pci14c3,7662";
>> +		reg = <0x0000 0 0 0 0>;
>> +		mediatek,mtd-eeprom = <&factory 0x8000>;
>> +		ieee80211-freq-limit = <5000000 6000000>;
>> +		mtd-mac-address = <&factory 0x8004>;
>> +	};
>> +};
>> +
>> +&ethernet {
>> +	mtd-mac-address = <&factory 0xe000>;
> 
> So, this is the same as <&factory 0x8004>, but stored twice?
Yes:
birger at AMDDesktop:~/router/rt-ac85p$ hd backup-OpenWrt-factory-2019-07-10.bin|grep 00000000
00000000  15 76 a0 00 04 92 XX YY  ZZ 90 15 76 c3 14 00 00  |.v....&E...v....|
birger at AMDDesktop:~/router/rt-ac85p$ hd backup-OpenWrt-factory-2019-07-10.bin|grep 00008000
00008000  15 76 a0 00 04 92 XX YY  ZZ 94 15 76 c3 14 00 80  |.v....&E...v....|
birger at AMDDesktop:~/router/rt-ac85p$ hd backup-OpenWrt-factory-2019-07-10.bin|grep 0000e000
0000e000  04 92 XX YY ZZ 94 04 92  XX YY ZZ 90 ff ff ff ff  |..&E....&E......|

> 

>> +define Device/asus_rt-ac85p
>> +  MTK_SOC := mt7621
>> +  DEVICE_VENDOR := Asus
> 
> Use all caps as for the rt-ac57u.
Will do.

Cheers,
  Birger

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list