The prs_tag_mode_set() is called on driver setup inside mvpp2_open(): https://elixir.bootlin.com/linux/v6.6.5/source/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c#L4763
Currently, the tag mode seems to be fixed to MVPP2_TAG_TYPE_MH and can only be changed by recompiling the kernel.
From what I can understand, RB5009UG+S+IN is fully working now (including the 2.5GbE port) but it's not mainline because I'll have to use a hack to get OpenWRT installed. Is that accurate?
Once it's installed, will regular upgrades work?
Correct. Sysupgrade works, but you'll need to build your own images.
Kernel 6.1 works but there's a regression with the 2,5 Gbps NIC (more specifically the way the Marvell switch talks to it, apparently).
At present both 23.05 and main (with the for now still default 5.15 kernel) work fine. I have one here as my main router and a second at my brother's. No complaints.
Thanks. I hope there's a way to work around that. It won't be practical for me to build images for it.
The device page says (emphasis mine):
You can use your own sysupgrade image.
That makes it sound like regular images work but you can optionally build your own. I haven't built my own image before.
Do I need to build packages, too? Or can I use existing ones?
What about the sysupgrade image on the device page?
The wording refers to adron's original images. I'll clarify that later.
Kernel related packages always need to be built with your own image, but if you keep in step with stable e.g. you can use the official packages (as long as they are not kernel related, like drivers).
After commit 997acc7f, I have updated the patch set for main with 6.1. (As noted on the wiki, you cannot combine this with the 5.15 patch set.)
I am looking for a kind soul (or multiple) to test this patch set against current main, it compiles fine here, and I expect no regressions. I don't have the opportunity myself though to test. I expect the 2,5 GbE regression to be still there, would be nice to see that confirmed. Hopefully we can move on once the 6.1 PR gets approved.
git checkout -b rb5009 997acc7
git apply --whitespace=fix ../490384.txt
...
make defconfig
make IGNORE_ERRORS=m
After flash, there is always bootloop
Thanks for testing. No serial to see what's going on I suppose?
If you revert the AT803x/QCA8081 split and apply the previous 6.1 patch set, does that work? That should still work.
Without changes
How to connect a serial ?
What do you mean?
As for serial: you need soldering, from what I recall there's pads on both sides of the circuit board. E.g. 3V3 and GND are on one side of the board, e.g., and Rx/Tx are on the other side. Here you can see 3V3 & GND on one side (top right), and here Tx/Rx on the other (top left).
More pics here.
Well, GND could be nicked from a couple of other places.
Bound rate is 12500000 or 115200 ?
The DTS contains the serial settings, those should work for OpenWrt booting:
$ grep serial target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-7040-rb5009.dts
stdout-path = "serial0:115200n8";
Anyone built the 6.1 patch with openwrt master branch? I am obsessive with syncing to new kernel, but not confident to solder on the might-be broken board.
seems the only update of the new patch is "CONFIG_QCA808X_PHY=y" replaced "CONFIG_AT803X_PHY=y". and commit 997acc7f had really a huge changes.
The bootloader is pretty resistant, you only need serial if you want to see what's breaking. You can easily revert to a working build through the bootloader.
What the commit you linked to does is explained clearly in its commit message. It's not as huge a code change as it looks say first sight.
Thanks for this and all of those guide info, really helps!
I'm ready to build with you latest patch, just want to know that, how could I configure the boot config ( in /sys/firmware/mikrotik/soft_config/ ?) using my built initramfs-fit-uImage.elf to boot into ram for once?
This way if bad thing happens it would not be too bad. I don't have solder tools right now so I am really afraid of bad things like boot loop that friend went into.
I didn't use the latest, but just replaced with "CONFIG_QCA808X_PHY =y" in the patch of wiki.
Booted my built image by bootp into ram, no bad things happened, then sysupgraded into flash, seems so far so good.
Now I am on kernel 6.1.77. Thanks guys!
I'll have to look into that patch again then, thanks for testing. Wiki is still having issues, it looks like.
@njhsi Can you confirm you used the 2023-09-18 patch set with just the QCA808x symbol enabled instead of AT803x?