And I finally figured out why the switch chip driver on the 5.10 kernel did not work correctly.
Its incorrect operation was expressed in the flood of all traffic(destined to the CPU port) to the other switch ports. The reason turned out to be the absence of static FDB records about the local MAC addresses of the CPU port. Further checking and debugging the switch driver led me to the conclusion that the reason is not in it. Events about adding local MAC addresses simply do not reach switch driver! In general, the fault was a partially applied patch in which the line was missing:
- if (test_bit(BR_FDB_LOCAL, &fdb->flags))
and because of this the DSA_NOTOFIER_FDB_ADD events did not work for local FDBs. And regardless of whether assisted_learning_on_cpu_port was enabled or not, assisted learning didn't work!
At now moment this BUG is affects all switch chip drivers that are use assisted cpu port learning !!!
And only in 5.13 kernel it was fixed!
Great work, was this introduced by the Topaz roaming patches?
Oh, I remember seeing that.
Vladimir did a lot of cleanups/improvements in the last 5 or 6 kernel releases.
DSA driver for switch chip Marvell 88E6393X(Amethyst), kernel 5.10 is ready.
Here is the list of patches You need for the latest version of OpenWRT.
I decided to check the version about packing the RouterBoot with the UCL NRV2B algorithm - without much hope for success!
But oddly enough, the first unpacking utility that I found: nrv2b was able to unpack it!
I took the RouterBoot file from RouterOS at /etc/70x0-7.2rc1.fwf and then do:
dd if=./70x0-7.2rc1.fwf of=./routerboot-7.2rc1.enc bs=4 skip=9
./nrv2b/nrv2b d routerboot-7.2rc1.enc ./routerboot-7.2rc1.dec
It remains to understand how this can be translated into assembly code ...
Awesome, I can tell you that it looks like Ghidra is able to decompile it into assembly just fine.
I tried it before the extraction a while ago and it failed miserably, but not decompiles fine.
We can actually see where their UART setting is broken in the bootargs function
Yes, the Ghidra with the indicated ARMv8 parses it quite well! Happy hacking for us!
That is, they have the printf function itself and the operation of writing to the UART! It looks like they just forget to initialize it!
Well, that is just great, it just keeps getting more and more broken.
I wouldn't be surprised if it was intentionally like that for the public versions, cause I find it hard to believe that they forgot it for their dev boards.
Has anybody found a suitable connector for their weird 10 pin SPI+UART and JTAG+I2C headers?
I have a J-Link EDU on the way and it would be way easier to use it to upload U-boot then having to use UART for testing, debugging would be way easier as well
According to wikipedia standard pitches are:
- 5.08 mm (0.200 in)
- 3.96 mm (0.156 in)
- 2.54 mm (0.100 in)
- 2.00 mm (0.079 in)
- 1.27 mm (0.050 in)
- 1.00 mm (0.0394 in)
By the pictures it seems a 2.00mm or a 1.27 one. If its one of those two you can find them online quite easily. (I've found them on aliexpress)
Yeah, it looks like the 2mm one as 1.27mm is too small.
Or they want to mess with everybody and use for example 1.8mm
I have been avoiding Aliexpress lately, its just too slow.
Should have ordered them from Mouser last week along with some other stuff
here it is the other way around now things come much faster.
Lets hope not!
With your NDA does you also have access to the documentation of the network accellerator?
You mean the ethernet controller?
As far as I know 7040 doesn't have any kind of a special "accelerator"/offloading
For waht I can understand in this presentation there should be some sort of packet processor:
The CPN110 should also have some sort of offloading capabilities. but who knows?
If thats the case and it have offload for some protocols this router might be even more interesting if it will implemented. (I'm interested due to my ISP is IPv4aaS so the CPEs that are able to do the translation are basically none on the market. I have Openwrt installed in a x86 VM since it is the only platform that support rfc7599 via SW)
The 8040 has some offloading in MVPP HW, but not the 7040.
@adron Pushed the current dummy DSA and the working MDIO driver for U-boot
Got it that is unfortunate! That interview is a bit misleading.
Well, I mean technically they are not lying as the ethernet controller is called MVPP aka Marvell Packet Processor, and it inherently does some HW offloading like other ethernet controllers but it doesn't have any kind of you know special offloading
Got It! I'll have to buy one of those once the port is done. And test nat46 performances with the SW pipe. On MTK7622 the throughput sucks so I think it will not be a lot different.
Well this one is a quad core at least compared to MT7622