Using OpenWrt git master branch with 5.15 kernel, both the 10G SFP+ and the 2.5G RJ45 work fine in my test setup (SFP+ only tested using a DAC. I have not tried to use a fiber module yet).
4 Likes
Tnx!
Just curious; when flashing from ROS to OpenWrt does the current ROS version and active firmware have any effect ? So is there a need to downgrade to for instance 7.1 before flashing ?
I only flashed from the RouterOS version my RB5009UG+S+IN came with, but you can always try if you're on latest. RouterBOOT is pretty sturdy in my limited experience.
Are there any updates on this?
I saw this tool being added today to work with mikrotik nand devices:
1 Like
None, I did start again for a bit and then life got in the way
1 Like
Did you already published somewhere the preliminary result?
There isnt anything to publish
I'm still using the first image kindly provided by adron and your work and this post encouraged me to compile my own rb5009 image, use your patches and have easy access to all the precompiled external packages available for openWRT. As this will be my first self-compiled openWRT, I read through the wrt devel docs, but there are two things I'm not sure about.
-
Do I need to compile a release version, say 22.03.4, to use all the precompiled packages that complement the openWRT distribution, or are there compiled snapshot packages available for the development builds of openWRT? My understanding is that I have to compile every required package with my build process for non release builds, due to possible incompatibilities between the master and release versions. Is this correct?
-
As I have seen, 22.03.4 is still kernel 5.10, so does this mean that the patch sets people have provided here for the master 5.15 builds are not applicable? Do I only apply the first patch from adron? I wonder if I will miss some features like sfp+ or 2.5G port working if I stick with the 22.03.4 release, kernel 5.10 and only adron's first patch for 22.03.
Would be nice if someone here could clarify this.
Great to hear!
You're better off compiling a release version if you want package compatibility, but the 5.10 kernel used by 22.03 has a switch bug for our platform. So it's basically useless. I can provide you with a patch that adds kernel 5.15 on top of 22.03, though, if you'd like, but I switched to master with a 23.xx fork hopefully rather close. I'd recommend you do that as well. It might sound daunting, but unless security issues pop up (or showstopping bugs) there's no need to frequently upgrade, so you don't need to compile every week e.g.
Most required packages will already be included, and once you have your buildroot setup, it's not difficult to compile an extra package here and there (and ideally include it in your firmware image).
Only thing that requires 5.15 to function properly is the QCA8081 2.5G NIC.
Tanks @ Borromini!
I'd love to compile stock 22.03.4, as this little box is already my daily driver and I need a robust and flexible solution. But if I understand you correctly, 22.03.4 with kernel 5.10 has a switching grave bug and would be a bad choice to go with. But 22.03.04 with a 5.15 kernel and your patchset would
a) run correctly, as explained here in this thread, and
b) have full available release module support.
I think it makes sense to try both the master and 22.03.04 with your patchset and kernel 5.15.
Could you please point out which patchset I should apply in the case of
- rb5009@ owrt master (2023-04-24) branch (if not the three patches on the rb5009 description page)
- rb5009@ owrt release 22.03.04 with kernel 5.15
Thanks for your help with rb5009!
You can grab the pile of patches for RB5009UG with 5.15 on 22.03 here. It comes as-is - like I said I switched to master on mine. If you are referring to kernel modules with 'modules', keep in mind only the ones from your build will work.
Big fat warning: the commit below breaks RB5009UG support on master!
A master version prior to this commit will still work with the patch set linked on the wiki. I tried modifying the patches introduced in the commit above to apply cleanly on top of the QCA8081 backport that's part of the RB5009UG patchset, but that obviously does more harm than good. So it's back to the drawing board.
@tmomas Can this post be pinned so it's visible along with the opening post of this thread? Thanks.
1 Like
Why not add simply a comment to the devicepage?
I did. Not everyone will bother reading that though, I reckon.
Well, with YAFUT this thing has some chance of being usable without having to replace the bootloader, however, we kind of need to figure out a way to pass a DTB as well.
And that is not easy since ARM64 does not support any kind of appended DTB tricks since the start it required the bootloader to pass it and the DTB that MikroTik uses is just so wrong that its unusable.
4 Likes
This thread is so long. I still remember that you did some porting of the uboot, so that we can just replace all the RouterBOOT/OS components. What was the status of that porting?
Otherwise we could have just used append-dtb-elf? There is a patch that allows to append a device tree binary to the kernel on arm64. Can't we make use of that hack?
Well, U-boot works but there is a mismatch regarding OOB on NAND and its not really possible to update it currently once its been flashed.
I am aware of that ARM64 RFC, but that wont work in newer kernels, I have hacked something that maybe works that allows appending the DTB but it still needs to be tested.
3 Likes
Okay, so for now don't use Master for RB5009UG from april 22th 2023, with the patches mentioned on the wiki correct?
Thus 22.03 with your 5.15 patches as mentioned here should still work as expected ?
It should, but I haven't kept track of 22.03 for the past few weeks. Either way, recovery is trivial (I had my RB5009UG back on a functional master build in a jiffy).
Again, easiest way is to revert that offending commit in your local tree, but that is of course no long-term solution. It's what I've done for now, I haven't found any obvious culprits yet, and since I have no serial I'm just grasping at straws.
Well, happy times. My digging bore fruit. This patch restores the relevant 5.18 at803x fiber patches to their original state - the ones in the offending commit were modified to apply to 5.15 cleanly, but those modifications in turn broke the RB5009UG support (which requires at803x modifications from 5.16 to add support for the QCA8081 2.5 Gbps NIC) in the process.
2 Likes