they already fixed the regdb problem... they just need to publish it...
Also if someone really wants the regdb can be updated but we really don't want to take that path...
the regdb is hardcoded only for ahb... for pci they supported external regdb from the start.
the regdb thing is a requirement of new law state to certify the device and don't permit user to have fun with them... but fun enough state people are not aware things change and regulatory domains are designed to change and adapt to the current year....
broadcom suffer from the same exact problem with one special difference nobody have a clue on how to tweak the regdomain since it's all set in eeprom or other thing...
Honestly i see you too much negative just because you want to have 160mhz wide channel that 99% of the device doesn't support and that is just marketing stuff...
Also again ARE WE REALLY SURE BROADCOM DRIVER WORKS AS EXPECTED AND CORRECTLY FOLLOW DFS? We are assuming too much stuff here.
Also consider that proprietary driver use proprietary stuff that deviate completely from the wifi standard... One example was Turbo QAM or whatever they called. that is just using VHT on 2.4Ghz with wifi n standard... something that deviate from standard wifi implementation but works on supported device.
I was reading all of his comments and feel exactly the same... all negative and expecting all things to be working on a still early development device that from my perspective is remarkably stable already for general (vanilla) use. I personally am extremely grateful for all the work and efforts people like you @Ansuel (and many others) are putting in to this. Seeing how well the ipq8065 platform matured over time, I forsee similar developments and stability coming from this platform over time as well. Especially with proactive & positive discussion, trial & error, and development from the users.
After waiting for the whole day (return home after work), the upgrade screen is still waiting, but at the same time, router is working normally. I closed the browser without further issues.
I open another session of Web admin, connection OK. ssh access is also ok.
Now having read your post, I am a little bit hesitate to manually reboot my router.
Thanks for replying and I don't aim my criticism on developers, more on the overall situation with drivers.
Re regdb: They have their own, signed/proprietary regdb blob, right? I don't see how externalizing it makes overall situation much better. Robimarco's request is basically ignored for 1.5+ months now. What makes you think it will ever change? Also, in that new regdb when/if it arrives they still keep higher 5mhz channels blocked, right?
Externalizing it makes it possible to detach it from the boad-2 data and permit to use something updating... Fixing any type of bs OEM may have applied to lock the wifi to their region (case of Xiaomi devies)
The main problem with regdb is not permit to run wifi at illegal channel but align to current regulation and use channel that got unlocked in the mean time...
I'm talking about perfectly legal channels 167-177 which could be used to create another (non DFS, btw) 80 or 160mhz channel.
And 160mhz wide channel is not a proprietary gimmick either, all my productivity devices have at least 2x2 160 radio and do benefit (+ ~50% measurable throuput) from it.
Again what makes you think they want to be evil and lock the channel? It's all handled by the regdomain database... if it's old... then you have these channel locked... as simple as that...
I didn't say 160mhz is proprietary... I said it's just marketing of big numbers and most of the time you can't use it due to DFS channels in the middle... (as you discover)
Also about the fact that qcom won't ever publish them... they are just slow... just that...
If used new driver will ignore any strange value so winkwink even if you provide an unlocked one probably will be ignored
bold and random move... remember that 3 weeks ago you didn't even had a firmware...
possible but not 100% true
But anyway I will stop answer question since to me it seems the target of this conversation is to became toxic and say "THE OEM FIRMWARE IS BETTER AHHHHH 1?!?!?!??!?!"
You may not be intending to aim negative criticism, but you are. I’ll say it again - I am VERY impressed with this unit, its current capabilities, and the stability it is already exhibiting. Based on my current experiences with now three of these units, I would recommend them for the average user looking for an AX OpenWRT capable router with future proof capabilities and hardware. You are choosing to fixate on one specific item (160mhz), and even more on super specific channels that aren’t even important to the mass majority of people that will utilize this router. You have made it abundantly clear this is important to you, and that is okay. If this model does not currently meet your needs, that is okay too. Life is full of choices, and you have plenty of them in this case.
Sorry newbie question ahead - help really welcome.
Got my WRX36 today and attempted a flash trough USB/initramfs.. everything went fine until the last reboot with a led staying solid magenta.
Checked everything again and seen the mistake, I did everything as documented but I stupidly forgot a step : fw_setenv mtdids 'nand0=nand0'
I should not have attempted it overnight after receiving the unit, you can imagine the facepalm.
Seen that @sampson had a typo in the past on the same command and recovered through serial and I guess I need now to unscrew and attempt the same, but there stops my know how. Seen I needed "4-pin JST-PH with 2 mm pin spacing" connector cable and use "115200, 8N1, 3.3V" but if I know how to use a serial console, I don't have such a cable nor know where to buy / how to make one.
you don't need the header... it's enough to use whatever you have to connect to the tx rx or gnd pin to your serial adapter... remember to NEVER USE THE VCC PIN.
the connection itself is important not what you use...
Thanks Ansuel. Your feedback helped me make sense of the serial dedicated page - seems a simple adapter and jumper cable are OK. Will order.
Let's say I will soon have that serial access, could you please help with what would be the recovery given my mistake? i.e. what should I expect seeing in serial / should attempt to correct?
Oem firmware is plagued with the same problems (see my cr1000a reference). But I'm pretty sure people should be aware that despite all the great latest achevements the wifi will not be better on OpenWrt. And should avoid this platform in general, at least for now, if they need more-than-vanilla wifi. Im seeing people are emotionally attached to this hardware, so I stop. Peace .
Not emotionally attached to this (or any) hardware, but rather emotionally attached to the devs that chose to put in their time and efforts at levels I simply cannot. Instead of complaining about things not yet sorted, I try to bring helpful feedback where I can, ask questions for things I do not understand, and simply say “thank you” to those that have skills and knowledge that I do not. If a piece of hardware ends up not meeting my needs, I move on to find hardware that does… not get into a back-and-forth with one of the best devs in the community. But yes - stopping would be ideal.
I can see that sooner or later, one needs to recover their router by using serial connection. I am thinking to buy an adapter, just in case. I have never used serial UART, so this is something new for me.
Can someone help me choose the right adapter to connect to the router between these three models?
.
But yes - stopping would be ideal.