so the problem is that the gpios of the sfp are reused with the uart to getting in the embedded system of the stick. vendors debian only ignores the pins so the tx-fault pin cannot trigger the sfp-framework
neither for mainline nor for openwrt disabling tx-fault pin is a correct solution…so we need a better way before apply to any repo.
i tried some years ago adding an own patch to openwrt and failed
i know that, but do anybody else know it too? imho it is necessary to separate these things
afaik there is no quirk yet…but imho this could be a good solution
i think too, but we are on it since 2 weeks now with no improvement, we just get non working firmware, fixing one problem creates 10 others that didn’t exist before…
i fixed this too, i did the test with the 3w limit. Now i can’t compile a fully working firmware from @dangowrt git, i’m not the only one
we are turning around…
@frank-w can’t you just compile (or use the latest firmware i compiled) and burn it on a sdcard and test it on your BPI-R3 ? You’ll find immediatly what’s wrong and what’s need to be fixed…
this will go way faster as you know what to do, and you understand what you do…That’s actualy 2 weeks since i first posted here about this ONT problem and we are still at the same point, maybe with more problems added…
Actually all topics i’m in are about “Do this”, “do that”, “post this”, “post that”.
Now the situation is that we can’t create a working image from @dangowrt git, and we are still asked to do things. 2 weeks that we are turning around. all logs are already posted.
if you want more logs, please fix the git firmware which is actualy totaly broken even for RJ45 ports.
I’m not experienced in openwrt and do not have such sfp. So testing will be hard…and i have many sdcards currently in use (2+ for each board i have here for testing).
You ran into revovery maybe write to sdcard was not finished (or pervious boot filling pstore with crash dump). Make sure all data is written to card not rely on gui saying copy is finished. I don’t think kernel is broken in this way after last commits.
yes this is development…and r3 is a development board there are only a few people here for getting things to work and doing support as far as possible. but we need some information on what is the exact problem…
you boot above shows only the tftp and nand detection…i guess abit more above there is a hint on which device is booted and maybe why tftp is done.
make sure the switches are really in the right position to boot from card. if uboot loads from card then kernel should too. but we experienced some read errors in uboot waiting for some guidance from vendor.
I do not know how openwrt do things,but hw offloading works with macs (eth0/eth1) and dsa interfaces (lanX,wan). Afaik no bridges or other (tun,…) can be bound to offloading driver
Have not done much with offloading as i have only 25mbit
I have another guess…which debian version is the image you have? Afair nft in buster does not have the code for controlling the hw flow offload. I had sent a patch for it.