Thanks a lot. 460800 is a vaild baudrate. The download process took about 30s. I reverted it to Linksys stock firmware and flashed 22.03 installer. Everything works well now.
1 Like
My radio1 is not working.
OpenWrt:~# grep "(release)" /dev/mtd0ro
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
OpenWrt:~# cat /proc/modules
cls_flower 40960 0 - Live 0x0000000000000000
act_vlan 12288 0 - Live 0x0000000000000000
cls_bpf 20480 6 - Live 0x0000000000000000
act_bpf 16384 0 - Live 0x0000000000000000
sch_tbf 16384 0 - Live 0x0000000000000000
sch_ingress 12288 6 - Live 0x0000000000000000
sch_htb 24576 0 - Live 0x0000000000000000
sch_hfsc 20480 0 - Live 0x0000000000000000
em_u32 12288 0 - Live 0x0000000000000000
cls_u32 20480 0 - Live 0x0000000000000000
cls_route 16384 0 - Live 0x0000000000000000
cls_matchall 12288 0 - Live 0x0000000000000000
cls_fw 12288 0 - Live 0x0000000000000000
cls_flow 16384 0 - Live 0x0000000000000000
cls_basic 12288 0 - Live 0x0000000000000000
act_skbedit 12288 0 - Live 0x0000000000000000
act_mirred 16384 0 - Live 0x0000000000000000
act_gact 12288 0 - Live 0x0000000000000000
pppoe 24576 0 - Live 0x0000000000000000
ppp_async 20480 0 - Live 0x0000000000000000
nft_fib_inet 12288 0 - Live 0x0000000000000000
nf_flow_table_ipv6 12288 0 - Live 0x0000000000000000
nf_flow_table_ipv4 12288 0 - Live 0x0000000000000000
nf_flow_table_inet 12288 0 - Live 0x0000000000000000
pppox 16384 1 pppoe, Live 0x0000000000000000
ppp_generic 45056 3 pppoe,ppp_async,pppox, Live 0x0000000000000000
nft_reject_ipv6 12288 0 - Live 0x0000000000000000
nft_reject_ipv4 12288 0 - Live 0x0000000000000000
nft_reject_inet 12288 2 - Live 0x0000000000000000
nft_reject 12288 3 nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet, Live 0x0000000000000000
nft_redir 12288 0 - Live 0x0000000000000000
nft_quota 12288 0 - Live 0x0000000000000000
nft_objref 12288 0 - Live 0x0000000000000000
nft_numgen 12288 0 - Live 0x0000000000000000
nft_nat 12288 0 - Live 0x0000000000000000
nft_masq 12288 1 - Live 0x0000000000000000
nft_log 12288 0 - Live 0x0000000000000000
nft_limit 12288 5 - Live 0x0000000000000000
nft_hash 12288 0 - Live 0x0000000000000000
nft_flow_offload 12288 0 - Live 0x0000000000000000
nft_fib_ipv6 12288 1 nft_fib_inet, Live 0x0000000000000000
nft_fib_ipv4 12288 1 nft_fib_inet, Live 0x0000000000000000
nft_fib 12288 3 nft_fib_inet,nft_fib_ipv6,nft_fib_ipv4, Live 0x0000000000000000
nft_ct 16384 3 - Live 0x0000000000000000
nft_counter 12288 13 - Live 0x0000000000000000
nft_chain_nat 12288 2 - Live 0x0000000000000000
nf_tables 163840 153 nft_fib_inet,nf_flow_table_ipv6,nf_flow_table_ipv4,nf_flow_table_inet,nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet,nft_reject,nft_redir,nft_quota,nft_objref,nft_numgen,nft_nat,nft_masq,nft_log,nft_limit,nft_hash,nft_flow_offload,nft_fib_ipv6,nft_fib_ipv4,nft_fib,nft_ct,nft_counter,nft_chain_nat, Live 0x0000000000000000
nf_nat 36864 4 nft_redir,nft_nat,nft_masq,nft_chain_nat, Live 0x0000000000000000
nf_flow_table 28672 4 nf_flow_table_ipv6,nf_flow_table_ipv4,nf_flow_table_inet,nft_flow_offload, Live 0x0000000000000000
nf_conntrack 86016 7 nft_redir,nft_nat,nft_masq,nft_flow_offload,nft_ct,nf_nat,nf_flow_table, Live 0x0000000000000000
mt7915e 126976 0 - Live 0x0000000000000000
mt7615e 20480 0 - Live 0x0000000000000000
mt7615_common 81920 1 mt7615e, Live 0x0000000000000000
mt76_connac_lib 45056 3 mt7915e,mt7615e,mt7615_common, Live 0x0000000000000000
mt76 69632 4 mt7915e,mt7615e,mt7615_common,mt76_connac_lib, Live 0x0000000000000000
mac80211 540672 5 mt7915e,mt7615e,mt7615_common,mt76_connac_lib,mt76, Live 0x0000000000000000
cfg80211 278528 5 mt7915e,mt7615_common,mt76_connac_lib,mt76,mac80211, Live 0x0000000000000000
slhc 12288 1 ppp_generic, Live 0x0000000000000000
nfnetlink 16384 1 nf_tables, Live 0x0000000000000000
nf_reject_ipv6 12288 2 nft_reject_ipv6,nft_reject_inet, Live 0x0000000000000000
nf_reject_ipv4 12288 2 nft_reject_ipv4,nft_reject_inet, Live 0x0000000000000000
nf_log_syslog 16384 0 - Live 0x0000000000000000
nf_defrag_ipv6 16384 1 nf_conntrack, Live 0x0000000000000000
nf_defrag_ipv4 12288 1 nf_conntrack, Live 0x0000000000000000
libcrc32c 12288 1 nf_tables, Live 0x0000000000000000
hwmon 16384 2 mt7915e,mt7615_common, Live 0x0000000000000000
compat 12288 2 mac80211,cfg80211, Live 0x0000000000000000
seqiv 12288 0 - Live 0x0000000000000000
leds_gpio 12288 0 - Live 0x0000000000000000
xhci_plat_hcd 12288 0 - Live 0x0000000000000000
xhci_pci 16384 0 - Live 0x0000000000000000
xhci_mtk_hcd 20480 0 - Live 0x0000000000000000
xhci_hcd 131072 3 xhci_plat_hcd,xhci_pci,xhci_mtk_hcd, Live 0x0000000000000000
gpio_button_hotplug 12288 0 - Live 0x0000000000000000
usbcore 184320 4 xhci_plat_hcd,xhci_pci,xhci_mtk_hcd,xhci_hcd, Live 0x0000000000000000
usb_common 12288 4 xhci_plat_hcd,xhci_mtk_hcd,xhci_hcd,usbcore, Live 0x0000000000000000
Does this device support U-NII-4 bands? i.e. channels 169, 173, and 177.
iw reg get shows they are allowed for my location, but I cannot select them.
Did you set the correct country code the 5 GHz interface in wireless settings?
Yes, it's set to United States.
please consider rolling back the increase of current on nand pin drivers as 12mA should be totally overkill for driving one chip.
What could be the effect of such overkill if any?
ringing, electromagnetic noise, increased power usage, perfectionist frustration...
there is configurability becase less is more.
1 Like
How can we be sure what the power level should be? Won’t it vary from one chip to another?
According to previously posted documentation, the stock firmware uses 12mA drive current on the NFI chip. Although the direct cause of the OKD issue was determined to be a software bug, there's still concern that the frequency of appearance was greater due to the lower setting (8mA) used in OpenWRT.
The likelihood of introducing new problems by using 12mA is low given that this is the factory setting. Although the potential gains are still in the realm of theory, this looks like a situation where there is no added risk of harm (when compared against stock) and it has a potential benefit. At the very minimum, this change eliminates one more variable from all of the guesswork.
4 Likes
yes there is, more is not better. im an electronic engineer. there is a reason why hardware is made configurable in this way.
and it is not "safer" to increse the current. increased current turns a trace into a transmission line, requiring constant impedance throughout and termination at the ends: read "requires a different circuit". if u dont have such a circuit, you get ringing, which causes spurious transitions on the lines, breaking the data in the bus. so increase current = hardware misbehaves.
different drive currents support different bandwidths, which is a given here. there are tables, you use the lowest safe value. lower values also allow for larger circuits without concern for transmission line effects. (you can bet the hardware at hand does not consider those effects.)
in practical terms you can just use what is recommended and used for SPI elsewhere. or you test for the lower setting that works reliably, then increase it by a healthy safety margen. but you dont just use the max setting.
the high setting in stock might be part of mediatek engineers trying to find the bug that daniel found. highest currents are only used for signals requiring the highest frequencies, and they generate EM noise by antenna radiation and by power bus fluctuations. you will reduce the RF range of the device if you use unnecessarily high output currents.
1 Like
look for my first and longest post in this thread months ago, explainig exactly where the bug was and debunking the many other "suspicions" discussed in this thread (including drive current). your answer is there.
1 Like
the high setting in stock might be part of mediatek engineers trying to find the bug that daniel found. highest currents are only used for signals requiring the highest frequencies, and they generate EM noise by antenna radiation and by power bus fluctuations. you will reduce the RF range of the device if you use unnecessarily high output currents.
I don't think so as the bug in bl2 doesn't exist in the stock firmware,
and yet stock is applying 12mA (which btw also isn't the maximum) for a
bunch of specific flash chips. As touching pinctrl early during boot is
extra complexity and they even only do it for specific chips, I believe
there must have been an empirical reason for that.
tl;dr: applying 12mA drive predates the introduction of the bl2 bug we
called 'OKD' and even the use of TF-A as bl2 -- it is already present in
MediaTek's propretary legacy preloader.
3 Likes
As an Electronics Engineer myself, I understand what @Lanchon is saying. However, part of me also feels that it might not be wise to go against what the original hardware designers decided to set the drive current at.
The only way to know for sure is to do extensive testing on all the data lines with a scope looking at the ringing and rise/fall times under various drive levels. While this would scratch the inner anal retentive soul within an engineer, I'm not sure it would have a tangible real world effect. On the other hand, if we get it too low, then we can start to introduce data errors that we didn't have before.
Just my 2 cents, which isn't worth much these days...
5 Likes
Maybe a compromise of 10mA, between 8mA (before OpenWRT v23.05.x) and 12mA (factory default) could be a decent value.
But yeah, as an Engineer, I would try to save the more power as possible. Even with the governor there are different opinions here. The factory default is performance (always at 1.35GHz), and OpenWRT uses ondemand (from 437.5MHz most of the time, to 1.35GHz if there's load). But that governor sometimes makes my router to not boot on a reboot, but it lower my temps by up to 6C.
Anyway, I had to use schedutil that also has variable frequency and no more failures to boot. It's a bit more aggresive than odemand but it's not at max frequency as performance.
So, back to the drive current topic, maybe we can try to find a lower value, but not that low. That could save a bit of power and have other benefits while being stable. Like an undervolt on PC CPUs.
Cheers!
For kicks and grins, has anyone compared the measured power draw at the wall between 8mA drive and 12mA? It may not even be noticeable. I haven't pried the heatsink off to measure bus voltages, but assuming it's a 3.3V bus (it's probably less), the difference of 4mA is only 0.0132 watts per data line and that is assuming it is constantly pulling that extra current. In reality, it's only done during edge transitions which is a small fraction of the time.
IMHO, what maximum drive current is being configured via software is probably not going to matter. If 8mA is a problem, it would have caused widespread corruption (i.e. if driving current is insufficient) for folks using firmware with 8mA configured as the max driving current. We're not seeing that.
My understanding of the current-voltage-power relationship (from my electrical & electronic courses many many many ... zzz ... moons ago), current is a function of load and driving voltage. If the NAND flash circuitry doesn't need 12mA to drive a line, it doesn't matter if you set it to 12mA, it will not use 12mA. Your power circuity can supply up to 1A in fact, and if the load doesn't need that much, it will not use it. If it needs more than 8mA and the power circuitry cannot provide the current required, it will pull down the voltage, and that will cause data corruption, wrt to the NAND flash driving line.
So in short, IMHO, it doesn't matter whether it is 8mA or 12mA.
So I guess we can focus on other stuff I suppose.
3 Likes
Agreed.
As a small point of clarification, in a static system where the signals aren't changing, then yes the drive current will be mainly dependent upon the load resistance regardless of what the max drive current is configured as.
However, when the signals are switching on and off, the primary issue is the capacitance in the traces and load device. During a signal transition, the higher your max drive current, the faster this capacitance is overcome and the quicker the signal can change state making the signal closer to a square wave rather than a trapezoid. Once it reaches the new state, the current drops back to only what is needed to maintain that state (like the static example above).
This is a bit of a simplification, but I hope it gets the general concept across.
2 Likes
Yes, that is my understanding as well, tho. the context here is a relatively slow NAND flash device, and the circuit designer most definitely have designed the circuit to cater to the data signal steady state (for worst case scenario) before sampling.
I tend to think of the trace capacitance as load of the total "system" as well ... heh heh ... makes my thinking easier ... haha.
i was worried because i thought the current was just clamped at the maximum setting for testing (although it was clear that KOD symptoms were incompatible with a driver current issue), and that could cause noise and reduce RF performance.
as far as i'm concerned, i was convinced by and thumbed-up @daniel's response, in which he says:
- 12mA predates the bootloader bug
- 12mA is not the maximum current setting
my original comment suggesting reverting the 12mA is no longer valid, and i second @daniel in leaving stuff as it is.
now to those really interested in this...
you get the specs from the flash: for the inputs there should be guaranteed input levels, minimum slew rate or maximum transition time, and a maximum capacitance. you add the parasitic capacitance of the traces (or measure it), then you calculate the minimum drive current necessary to achieve the required slew rate or transition time between the appropriate levels. you might want to add a safety margin. (this is valid for "short traces": when propagation delay in the traces is much smaller than transition time as resulting from the drive current and total capacitance. under this condition, the whole trace can be modeled as a "point-like" simple node.)
testing is simpler: find the minimum that works, add a margin.
however using the stock value is a totally ok strategy that will not degrade robustness/reliability nor RF performance.
no difference, even if the flash is accessed. not only power involved is negligible, but the amount of energy required is constant (ignoring transistor losses) per level switch (more power used, but for shorter time). plus flash, in the steady state use of the router, should mostly be completely quiescent, as necessary data has already been cached in ram.
the concern was never power usage. it was signal integrity (possible ringing) and RF interference.
this is wrong. whatever current is selected controls the rate in which the parasitic line capacitance (trace + input) charges. which is to say, it controls the resulting output slew rate. which in turn controls the power spectrum of the signal, and how much of that spectrum gets emitted as RF from the trace acting as an antenna. it also affects the peak current drawn by the output stage, causing current peaks on the supply rails, which in turn cause RF effects elsewhere, and may even cause instability issues. there exists a per-pin configurable drive current setting because it is needed.
on the other hand, using too low a drive current would result in slow slew rate and extended transition time at the driven inputs. if signal transition time exceeds the required maximum at the input, the input may detect multiple transitions where one existed (think about the inevitable noise), or worse, cause internal metastability issues or undue power consumption and dissipation issues in the receiving circuit.
4 Likes