oh wow we are in the idea of making the crypto firmware work. Nice!
Well, I can tell you that it loads, but the benchmark tool will insta crash it.
Positive thing is that it happens on QSDK as well.
Thats the spirit 
And the negative thing is that they are not registering those algorithms in the kernel but rather only to NSS, so you cant use them to accelerate stuff other than NSS.
Though I am sure that this can be sorted out by somebody
I have this issue with previous build aswell. Sometimes wifi crashes and i have to restart the device. No log so far 
just curious how far is ax3600 from getting into the mainstream (even snapshot) openwrt? i see all the effort started over two years ago (Feb 2020) ... i presume ax9000 will be another two ! can't we get more openwrt developers to support than robimarko? @Ansuel any bandwith ? the price point for this device and ax9000 is such an attraction & potential is great.
By the way ... got seamless ax3600 (vs ax9000 
) setup without any need of uart etc so well done Robi & everyone we just need to get it to a proper router place ...
1 Like
extremely busy... doing my best to try to remove some side project and restart working on this new soc...
2 Likes
Well, it's not that far.
I am waiting on 5.15 support in OpenWrt, which should happen soon as 22.03 should be branched off around 20th of March.
AX9000 is working, but the concurrent radios are pretty much up to QCA to solve sometime when they feel like it.
Besides that, its time to switch to fixed parts and enlarge the rootfs, though that will mean not being able to flash without UART.
2 Likes
mhhh why ?
Because there would be one unified rootfs partition, thus the layout wont match the stock FW and you cant flash from it then
no criticism on the AX9000 pls (i have been on painful $ journey here) but ... I had to hack the dts bootargs + add a few more patches to be able to format rootfs partitions + use uart to force a functioning openwrt (still need to use bootipq + bootm ... )
?
But why?
mhhh wonder if we should create a migration image... why this idea was never used on openwrt? like a bare minimum image to just install a correct openwrt image?
2 Likes
Well, its quite simple cause its additional stuff to make, maintain and package.
I think something like that was floated for one of the Fritzboxes which has 2 SoC-s and requires a special image for flashing, but it went nowhere.
There isn't even basic infrastructure for doing something like that.
Option B is to used fixed-partitions but with it matching current SMEM provided table so that crashlogs and NVMEM can be used and extend sysupgrade/fstools to utilize the overlay partition for the RW overlay.
Option C: make new uboot with net console, that anyway must be done to support new fixed partition layout with recovery. So then new uboot can be patched into APPSBL, then after that follow using net console to re partition device, so no serial will be needed.
That is going to be 'fun' for xiaomi devices, for which no (u-boot) sources are available. Keep in mind, NAND flash, break the bootloader and your device is toast.
1 Like
testing the uboot firmware can be done by booting it on ram... actually the idea of an intermediate loader is not a bad idea for these xiaomi crap devices... tons of effort tho... (actually the common cause of the brick on ipq806x and i assume also other is the fact that they use special ecc values for the boot partitions and you end up writing garbage on replacing uboot)
(that's what the boot-layout patch does and i actually tested it with one guy that replaced uboot with his custom version succesfully)
but again... IMHO we first need to push this upstream so it gets more traction by the community and we finally get more devs working on this. Until now it's a miracle even robi is working on this.
2 Likes
Isn't there still a difference between RAM booted u-boot and flash-/ cold-booted u-booted in terms of (potentially critical) stuff being properly initialized?
sure but for the task we need we can ignore it if we really want...
Replacing the original uboot is a nono to me... too much brick potential... Flashing an intermediate uboot on the other hand.... (if the task is to facilitate any user interaction with uart install)
1 Like
Yeah, a ton of difference.
I am not in favor of new U-boot at all, the chance of a brick with NAND only is too high.
This wouldn't be the first or last to require UART to flash.
1 Like