Latest snapshot vs v19.07.x support for GliNet MT-1300 Beryl

After a few failed attempts, largely due to not enough resources on my build machine, I've managed to build the latest main snapshot and generate an image for the MT-1300

I've successfully flashed the device many times also.
Though I had to open it and use a serial port to recover from a few failed network configs. BTW the serial is 115200 8,n,1

I'm a bit concerned about stability, having seen changes in teh WiFi drivers, Glinet seem to have built their own drivers, device types and from using swconfig (in the GLiNet stock firmware) to dsa in the latest release. Also I'm not sure I've found any up to date info on DSA and VLANs (they are used in the swconfig setup on the stock openwrt + gli s/w).

The support for MT1300 was added in this snapshot, https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d89a7f0120db42d4fae1656e1860ef49523acabb
and looking at the date/time I wondered if it was going to be added to the upcoming v19.07.7 or if someone could advise how to go about adding it myself - happy to give it a go, and submit a pull request.
The changes in the commit seem to only affect 4 files and I've tried doing:
git checkout v19.07.6
git cherry-pick d89a7f0120db42d4fae1656e1860ef49523acabbgit add .
git cherry-pick --continue
etc.
and all seems to go well but when I do
make menuconfig, the device isn't listed.

Is this possible or are there other changes for the underlying chipset that are not in v19.07.x yet ?

If it should work, how do I get make menuconfig to recognise the device?

Is swconfig still supported in the latest snapshot (main ) or is DSA the only way forward?

Is swconfig still supported for v19.07.x ?

Where can I find any help about the DSA configs vs swconfig.

Thanks

Just received this device and would like to know what OpenWRT support looks like - information is thinner than for other Gl.inet devices. Is this simply because it's new?

I tried the latest snapshot, but WiFi didn't work normally. The signal was very weak and only 5GHz available.

Update: I missed some necessary packages and now WiFi also works normally on the latest snapshot(tested with Kernel 5.4). Default wireless config only let 5GHz work and needs to be fixed manually.

uci set wireless.radio0.disabled=0
uci set wireless.radio0.hwmode=11g
uci set wireless.radio0.htmode=HT20
uci set wireless.default_radio0.ssid='GL-iNet-MT1300-2.4'
uci set wireless.radio0.channel=3
uci set wireless.radio0.legacy_rates=0
uci commit wireless
wifi reload

This is promising! How has the device operated since your install? All working as expected?

If you use it as a wireless repeater, it is very unstable. Luci wireless configuration page is almost useless and many settings need to be modified by using uci commands. To connect to 2.4GHz network you need to manually set a new client through a series of uci commands.

Others work fine as my old MT7621 router. I have switched to Kernel 5.10.

I use this test device as a classic travel router with one AP (on radio1/5G) and multiple STAs (configured on radio0) ... works flawlessly, without any manual uci intervention (with travelmate 2.0.3).

Currently only the MMC/sdcard support seems to be broken. I think this is device unrelated and a problem of the underlying kmod-sdhci-mt7620 kernel driver. Tested with latest snapshot with kernel 5.4.x and 5.10.x

Sdcard support is OK on both of my MT7621 devices. What's the meaning of "broken"?

Maybe my sdcard is just broken. I'll doublecheck that and come back to you.

Tested with two sdcards, always with the same result:

sdcard will be detected correctly during boot, e.g.:

kernel log:
[...]
[ 2537.853564] mmc0: new high speed SDXC card at address aaaa
[ 2537.866275] mmcblk0: mmc0:aaaa SC128 119 GiB 
[ 2537.876072]  mmcblk0: p1
[...]

During sdcard access countless errors will be logged, e.g.:

Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.624210] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<24> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.638759] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<25> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.655143] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<25> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.668340] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<26> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.684612] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<26> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.697799] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<27> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.714062] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<27> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.727278] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<28> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.744400] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<28> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.757680] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<29> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.774082] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<29> MSDC_DAT_RDDLY0<0x1910100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.787255] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<30> MSDC_DAT_RDDLY0<0x1a10100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.803394] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<30> MSDC_DAT_RDDLY0<0x1a10100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.816580] msdc0 -> TUNE_BWRITE<FAIL> DSPL<1> DATWRDLY<31> MSDC_DAT_RDDLY0<0x1a10100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>
Thu Mar 11 19:06:56 2021 kern.err kernel: [  134.832825] msdc0 -> TUNE_BWRITE<FAIL> DSPL<0> DATWRDLY<31> MSDC_DAT_RDDLY0<0x1a10100f> <- msdc_tune_bwrite() : L<1546> PID<kworker/u8:2><0x23>

Tested with two sdcards (which are working fine with debian). The errors occurs independent of the used file system - tested with vfat and ext4.

still no support for the BERYL huh?

GL-MT1300 currently has snapshot support.

I actually installed the latest last night and have luci, device keeps losing wifi but so far so good, I haven't configured anything in luci, letting it bake today and see how it goes.

I am considering to buy this. How is the support? Better or worse than ar750(s)?

@dibdot @tmomas is it stable? vs ar750s?

The default firmware (fork of Openwrt with Luci support) is pretty stable, even as a repeater, but when I make my own firmware on the latest snapshot it's not so stable. connection loss so now and then on the STA.

Maybe something with the wifi drivers?