Knock knock....
Thanks very much. I was able to boot into diagnostics and flashed the image successfully.
I'm a bit confused how I move to bcm53xx on my non-A0 MX64. I've managed to install the bcm5862x image supplied by zerg91 but any image using bcm53xx, linked in this thread or compiled myself (using Leo-PL's fork), gives me a bad bootkernel magic error. It's not an issue with u-boot, I gather?
I would also like to know if there are certain features that I should or should not use when compiling an image. This is my first time doing any OpenWRT building so it's fun to mess around with, but I don't know if unsupported features are automatically unavailable in the make menu, for instance.
edit: so I'm guessing it is in fact due to uboot now, as that looks for a bcm5862x initramfs and simply renaming them obviously does not work 
Now I've tried to perform the same steps of copying mtd-rw.ko, mtd and uboot_mx64 as found in clayface's U-boot-MX64-20190430_MX64 repo but this does not seem to be a viable step anymore?
If I use the insmod command it simply ignores the i_want_a_brick=1 argument and running the mtd update gives me a permission denied error.
Hii @Leo-PL
Any hope for the kernel 6.6 support for MX64/MX65? Thanks a lot.
I still have plenty of stuff to do before that. I plan to do this eventually.
4 Likes
I'll belive in You! You can do this!
1 Like
I've stumbled on xdp-tools build issue, but since it's optional, I built the images. Haven't tested yet on my devices, so proceed with caution. Strangely, the rebase to 6.6 went without hitch.
https://drive.google.com/drive/folders/1sq2kuuHpL4ylq3zJKcKXXG2a0BRrdE4N?usp=sharing
5 Likes
Thank you, I’ll be testing them soon.
the update works on my MX64(A0).
will be testing it further.
Thanks for the kernel 6.6 images. I've installed them on both my MX64 and MX65 and that worked fine. Is there anything that can be done to help get this device officially supported?
I need to review the LED config and open a PR. Otherwise the support is pretty much complete. I plan to do this in the coming week, because I'd finally like to use this device in production environment.
2 Likes
Thanks for further work with this devices, did You play with crypto accelerator to make it useful? It also have some hw nat engine i belive.
Not yet. Let's get it upstream first.
I think that both the main Broadcom chip has some HW NAT (gl hf supporting that, 'cause Broadcom gonna Broadcom) and both QCA8337 switches do have their own accelerators. They're basically full L3 switches.
Ok, firtst things first, i have two mx64, both need u-boot update, i like very much this type of case design.
Yesterday in the evening I found another issue that needs fixing, in addition to LED mapping: failsafe mode network configuration. Device is unreachable if failsafe is enabled, possibly because qca8k isn't loaded in that case. I need to open my unit up and get a boot log of such case.
Sounds similar to some of the early initramfs images for installation that needed one of the 2 wan ports reconfiguring to be able to upload the sysupgrade image. Not sure how difficult it is to fix but I guess a workaround could be to change the network config with a single wan port and make the 2nd one a lan port such that it doesn't rely on the switch. However I am not sure if something like that is acceptable when submitting a PR for the device.
As for the failsafe, I need to figure out, how that's done in the userspace, because, apparently, the logic doesn't handle this case indeed. When DSA transition happened for ipq40xx, I remember fixing similar issue with MR33 (I did conversion for this one) but I can't remember what I had to alter for the userspace to treat the new "lan" interface as the primary.
And this one is likely due to both qca8k and at24 missing the "autoload at boot" flag - so even if loaded, network setup would have happened already, and failed. This one is already fixed on my branch, but failsafe still doesn't work. Not loading at24 at boot caused a chain of -EPROBE_DEFER errors - because in failsafe it would not load at all, until done manually.
That at24 autoload thing is quite possibly the root cause for MR33 random MAC addres woes, too.
In the meantime, I tried fixing LEDs - I've set up proper aliases, however, upgrade and failsafe LEDs are never selected, too - something in userspace logic is at play, despite get_dt_led function reporting correct values for LEDs I've chosen.
Edit: Found that, both for preinit network interfaces (the failsafe thing); the deferred probe handling of Ethernet port for MR33 (which apparently was dropped during DSA conversion somehow) and the LED handling thing (bcm53xx target has its own diag.sh which handles that. And everything is here: https://github.com/openwrt/openwrt/pull/4721#issuecomment-995180731 - glad I kept this branch.
1 Like