I HAVE THIS MESSAGE
{"token":"; nvram set ssh_en=1; nvram set uart_en=1; nvram set boot_wait=on; nvram commit; sed -i 's/channel=.*/channel=\u0022debug\u0022/g' /etc/init.d/dropbear; /etc/init.d/dropbear start;","code":0}
Thank you
I HAVE THIS MESSAGE
{"token":"; nvram set ssh_en=1; nvram set uart_en=1; nvram set boot_wait=on; nvram commit; sed -i 's/channel=.*/channel=\u0022debug\u0022/g' /etc/init.d/dropbear; /etc/init.d/dropbear start;","code":0}
Thank you
You are supposed to get that, great to see that it works for a lot of people and across models.
The Xiaomi AX6000 is the same method?
Yes, multiple users confirmed that it works on AX6000 as well
Very good job
@kirdes I finally added DTSI for HK CPU-s with higher clocks and more thermal trip points.
Voltages I got from a running AX9000 with all radios working are a bit different then those you read from another router model.
Great, thanks for all your work.
I saw you also added the ecm2305 driver, so we can later add some active cooling maps.
ECM2305 is in early development, all it does currently is read the tachometer.
And I am not trusting that measurement as doing it per the docs I get 127 with the FAN not spinning at all.
So, gotta implement PWM control first to see whats going on.
Yeah, I am planning to add it as a active cooling for the thermal trip instead of passive throttling.
Did you see that new driver implementation from the traverse guys?
I have not, but it looks like a modified version of the driver that was sent upstream last year.
But, it will be easier to figure some things out of it instead of the docs as docs are really not the best.
They overcomplicated the docs way too much, and the register layout docs are horribly written, TI and Microchip nowdays do way better.
I updated the fan driver to read the tachometer correctly and started work RPM based control.
Hello
I have firmware xiaomi router ax9000, you can try it this here xiaomifirmware.net/xiaomi-router-ax9000
thanks
@kirdes I finally figured out the PHY reset situation.
Basically the QCA8081 PHY is too slow to respond after reset is deasserted and a solution is to manually set the PHY ID in the DTS and declared the reset GPIO.
Now all PHY-s are working once flashed.
BTW, I would say that voltages that I set are too low for lover frequency ranges as I got couple of random reboots with memory issues which is clear indication of too low voltage.
What are you experiences?
Hi robimarko,
It's great that you figured out the PHY reset issue.
I'm busy at the moment, but i can check the random reboots later this week. Do you have some kind of a repro case?
Not really, It was doing almost nothing.
I have a feeling that 1GHz voltage is too low.
I would rather set the 1Ghz voltage to 704 (instead of 688)
Yeah, it was looking low to me
Ok, increased the voltage.
Ahh, it looks like sysupgrade broke recently as:
Tue Jun 22 10:54:09 UTC 2021 upgrade: Performing system upgrade...
Error opening lock file /var/lock/fw_printenv.lock
sh: out of range
Error opening lock file /var/lock/fw_printenv.lock
Error opening lock file /var/lock/fw_printenv.lock
Error opening lock file /var/lock/fw_printenv.lock
Error opening lock file /var/lock/fw_printenv.lock
So, I am guessing that is why rootfs newer changes after sysupgrade.
I believe this fw_printenv.lock file is only present, if fw_printenv / fw_setenv has been running at least once before sysupgrade.
Just adding the ax9000 to the bootcount file should be enough i think.
Other workaround would be a
touch /var/lock/fw_printenv.lock
in the platform.sh
Yeah, I forgot the bootcount completely.
That is why its not working.