Not possible to change boot partitions from OpenWRT?
Only by changing u-boot env variable, fw_setenv can do that
1 Like
Something like:
fw_setenv boot_part 1
I really dont know on top of my head.
There should be a variable similar to that
Doesn't seem to be.
OpenWrt SNAPSHOT, r15037-48d4894357
-----------------------------------------------------
root@WAC510:~# fw_printenv
baudrate=115200
bootcmd=bootipq
bootdelay=2
bootpart=3800000
delenv=sf probe && sf erase 0x000e0000 +0x10000
ethact=eth0
fdt_high=0x87000000
fileaddr=84000000
filesize=90E15C
flash_type=0
fw_upgrade=0
install_cal_to_end_of_nor=sf probe && sf read 0x84000000 0x170000 0x10000 && sf erase 0x1f0000 +0x10000 && sf write 0x84000000 0x1f0000 0x10000
ipaddr=192.168.1.11
machid=8010100
nand_erasesize=20000
nand_oobsize=40
nand_writesize=800
primary=3800000
proceed_upgrade=0
product_id=WAC510
secondary=0
serverip=192.168.1.15
show_cal_at_end_of_nor=sf probe && sf read 0x84000000 0x1f0000 0x10000 && md.b 0x84001000 0x40
stderr=serial
stdin=serial
stdout=serial
Ok, they are using bootpart variable.
Set it to 0 to boot from rootfs or 3800000 for rootfs_1
1 Like
I tried changing the bootpart variable but it didn't switch boot partitions.
But I found out how to do it 
There are these two Uboot variables:
primary=3800000
secondary=0
By switching their values it changes the active partition.
fw_setenv primary 0
fw_setenv secondary 3800000
The only setback was that my OpenWRT config was lost not like when switching partitions on Netgear firmware.
Also I think that in the kernel log it shows you which boot partition is active:
[ 2.439050] ubi0: attached mtd9 (name "rootfs", size 56 MiB)
Thanks for your help and patience
Tested that patch but I get no RX traffic on WAN port once applied, TX seems unaffected.
Hm, then it's a weird bug.
Did you enable the kernel symbol from the PR or?
My new adapter finally arrived today, and it's working great. So I'm building an image to try on one of my units.
For reference I got this one from Ebay.
Edit: Got it flashed, and it looks good so far.
2 Likes
Nice.
Do you use VLANS on WAN?
If so, do you get good RX/TX throughput on the WAN port?
Sadly I do not have VLANs set up, but it's on my to-do list.
It was pretty late, so I didn't get a chance to test beyond getting it to connect on my phone, and that network access worked.
Figure I'll do a Flent test from my laptop to check the throughput and how the latency behaves under heavy load when I get the chance.
2 Likes
Testing these commits from Blocktrron's staging git to see if it solves the VLAN tagged WAN TX throughput bug.
The changes by Blocktrron seem to stop my RX traffic once I driver level VLAN tag WAN, the same happens with the port-isolation commit @robimarko linked futher up.
Not sure if I'm doing something wrong.
Using robimark's work rebased on latest trunk and tagging WAN works, only the throughput bug is there.
Thought I'd give an update as I've solved my problem thx to this post by @jeff and the recent ipq4xx switch driver reverts posted by @blocktrron in his staging tree.
The problem I had was that driver-level vlans don't seem to work after applying those commits and vlans needs to be setup as posted by @jeff in /etc/config/network.
OpenWRT default with wan port tagged setup in /etc/config/network :
root@Netgear_WAC510:~# swconfig dev switch0 show
VLAN 1:
vid: 1
ports: 0t 1 2 3 4
VLAN 2:
vid: 2
ports: 0t 5
Same setup after blocktrron reverts :
root@Netgear_WAC510:~# swconfig dev switch0 show
VLAN 1:
vid: 1
ports: 0t 1 2 3 4
VLAN 2:
vid: 2
ports: 0t 5
VLAN 20:
vid: 20
ports: 0t 5t
Should be able to do some testing over the Christmas break.
I did see some issues when selecting at least some channels on 802.11ac, in this case channel 144:
Nuked dmesg before changing and filtered on ath10 after: https://pastebin.com/Rk0qYPmw
I don't know what to look for here, so if there's anything else I should grab, let me know.
Edit:
Checked hostapd logs:
Tue Dec 22 00:10:12 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan1 wasn't started
Tue Dec 22 00:11:04 2020 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy1.conf (phy wlan1) --> new PHY
Tue Dec 22 00:11:06 2020 daemon.warn hostapd: wlan1: IEEE 802.11 Configured channel (144) or frequency (5720) not found from the channel list of the current mode (2) IEEE 802.11a
Tue Dec 22 00:11:06 2020 daemon.warn hostapd: wlan1: IEEE 802.11 Hardware does not support configured channel
Tue Dec 22 00:11:06 2020 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->DISABLED
Tue Dec 22 00:11:06 2020 daemon.notice hostapd: wlan1: AP-DISABLED
Tue Dec 22 00:11:06 2020 daemon.err hostapd: wlan1: Unable to setup interface
Is this a generic problem, or is it somehow related to the device support?
Do you remember if stock permitted selecting the same restricted channels?
https://forum.openwrt.org/t/can-not-use-some-wifi-channels/1876
I don't, but I didn't flash OpenWrt on the rest of the units. This is the supported 5Ghz channels I get on stock:
So it's not supported. Curiously, if I do set the country to Norway on OpenWrt I get even more channels that doesn't work
What channells do you get with: iw phy?
I would recommend first setting regulatory with: iw reg set