You might have more success with a recent version of the mainline ag71xx driver, since that one has phylink support. Then SFPs are just Plug and Play, literally.
I don't know shit about these things, but I don't think you need those mdio and phy nodes. There's a MAC and an SFP slot. The sfp driver handles the slot, loads a phy driver if required (e.g for a copper SFP), and provides MII access to it for the MAC
Enabling the in-band-status option makes the eth1 interface appear, but it causes an early kernel error, when loading the driver and later, more crashes at a rate of once per second:
Disabling the in-band-status option avoids the crashes, but neither the eth1 interface appears.
Therefore, not working so far.
@xback, did you discover anything new? I tried reverting the patch you linked, but ended up with both eth0 and eth1not being loaded. It looked like if the ag71xx driver wasn't even loaded.
Some time ago on RB962 / hap ac (similar hardware) I tried to get SFP working:
I think that I worked out I needed to:
Avoid using the SFP tx-disable
use a fixed link in DTS
restart (power down other end, or unplug & replug) the optical link after OpenWrt was running.
Then I got a connection.
I decided I would wait for a newer kernel and ag71xx with phylink, as bmork suggested.
helped me to build kernel with CONFIG_KERNEL_DYNAMIC_DEBUG=y, and use echo -n 'file sfp.c +p' > /sys/kernel/debug/dynamic_debug/control
so that sfp phy driver shows the hardware events. cat /sys/kernel/debug/gpio | grep -E 'los|def0|tx' also helpful
On the other end, running RouterOS, I see there is a correct signal reception level, but no link is established:
.
However, unplugging/plugging the fiber cable or the whole SFP module on any of the ends makes no difference. Link is still down, and no traffic is received:
Also, I don't see any difference when setting/unsetting the pll-data values (I also tried other values for 1000 Mbps, to no avail).
Last thing, I tried compiling your image (stripping down all the nodes the rb922 doesn't have/need), and booted it. Unfortunately, I got the same exact results.
I guess we'll have to wait for a newer kernel/ag71xx driver. Anyway, thanks for your help!
Hi, if you do not mind, a silly question - I have a couple of the RB922 boards and I am having no luck getting them to boot openwrt. Which procedure did you use to get them to boot? I believe I tried everything (bootp, tftp, soldering serial port on and figuring out it is disabled, the works), and it does not seem to work at all. While I can manage to get it to download an image, it simply refuses to boot it. Given total lack of any debug options I am at a loss about how to proceed now. Any help is highly appreciated!
A DHCP/BOOTP/TFTP server running on your computer (I use dnsmasq as explained in the link above)
To make the device download the image via TFTP, you can configure RouterOS (System=>RouterBOARD=>Settings=>Boot Device=>try-ethernet-once-then-nand) so that next boot will try to fetch an image via TFTP instead of booting regularly from NAND. Otherwise, just press the reset button, and keep it pressed, while you power up the device. After 10~20 seconds the device will try to fetch the boot image via TFTP.
Unfortunately, the serial port is disabled for RouterBOOT and RouterOS, but once you start booting OpenWrt's kernel, it will start showing you the bootlog:
[ 0.000000] Linux version 5.4.113 (roger@builder) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16523-448e4279e5)) #0 Sun Apr 18 14:14:52 2021
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[ 0.000000] MIPS: machine is MikroTik RouterBOARD 922UAGS-5HPacD
root@OpenWrt:/# dmesg | head -n10
[ 0.000000] Linux version 5.4.113 (roger@7018) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16523-448e4279e5)) #0 Sun Apr 18 14:14:52 2021
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[ 0.000000] MIPS: machine is MikroTik RouterBOARD 922UAGS-5HPacD
[ 0.000000] SoC: Qualcomm Atheros QCA9558 ver 1 rev 0
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff]
Thanks! Got it to work! The trick with it was that network boot only works with TFTP, as per mikrotik instructions. Also booting via reset button is substantially more reliable.
Ok, small update on my experiments. While the release version appears to boot just fine, trying to build and boot snapshot does not (no signal on serialport, so it seems openwrt kernel does not even boot properly at all). The image gets fetched by the bootloader, but no signal on serial port is produced, so probably it does not even recoginze its format or kernel just panics out and reboots (reason may be that image that is produced by buildroot is .bin, while image in release 19.07 that actually does boot is .elf, but I have no idea how to make the buildroot produce .elf image).
Also there is no prebuilt binary for this board in snapshots directory (https://downloads.openwrt.org/snapshots/targets/ath79/mikrotik/), which is in itself sort of alarming. Thus, question becomes is there a way to build a snapshot of openwrt for that board that will at least boot?
This is weird, I built it this morning and it was working normally. I uploaded both sysupgrade and initramfs images to https://filetransfer.io/data-package/OHRKOIuE if you want to try them.
You can enable the buzzer (speaker/beeper, however is it called) so that it beeps when a valid image is booted. Sadly, it's the only indicator you'll have.
The .bin initramfs should be OK, it's actually an ELF binary:
binwalk openwrt-ath79-mikrotik-mikrotik_routerboard-922uags-5hpacd-initramfs-kernel.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit MSB MIPS64 executable, MIPS, version 1 (SYSV)
76960 0x12CA0 xz compressed data
77088 0x12D20 xz compressed data
5578608 0x551F70 device tree image (dtb)
This is intended. MikroTik devices with NAND flash also have a small SPI NOR flash where the bootloader, MAC address, license key, etc. live. This memory has very small partitions that can't be written to, because they are smaller than the minimum block erase size the driver uses. To avoid the risk of users breaking their devices accidentally, no images are generated by the buildbot.
See SFP support for MikroTik RB922UAGS-5HPacD - #19 by rogerpueyo
Please give the image I sen you a try, so we can know whether it's the current support status, your device, the image you compiled...
Well your image boots and runs correctly, sysupgrade and all, as one would expect. So the question becomes which .config are you using? Can you share the .config you used to build the binaries so I can try to build one using same config? I have a nagging suspicion that maybe there is something funky with the build host configuration I have...
In terms of users not bricking their devices I understand the intent, but then on the device page it should probably say there is no prebuilt image and why, else ignorant people like myself will keep looking for it all over the place and try booting with wrong images etc etc.
and ran make. I pasted the contents of the generated .config at https://pastebin.com/NHpMP8Yq, but it shouldn't be different from yours (please note I've got all the feeds installed).
I agree, I'll update it on the wiki when I have some minutes.
commit 9d96b6fb720d9cecc7bd50b4f16dabe1b337f9f2
Author: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Date: Sun Dec 27 20:33:57 2020 +0100
ath79/mikrotik: disable building NAND images
The current support for MikroTik NAND-based devices relies on a
gross hack that packs the kernel into a static YAFFS stub, as the
stock bootloader only supports booting a YAFFS-encapsulated kernel.
The problem with this approach is that since the kernel partition is
blindly overwritten without any kind of wear or badblock management
(due to lack of proper support for YAFFS in OpenWRT), the NAND flash
is not worn uniformly and eventually badblocks appear, leading to
unbootable devices.
This issue has been reported here [1] and discussed in more detail
here [2].
[1] https://forum.openwrt.org/t/rb433-bad-sector-cannot-start-openwrt/71519
[2] https://github.com/openwrt/openwrt/pull/3026#issuecomment-673597461
Until a proper fix is found (or the stock bootloader supports other
filesystems), we disable building these images to prevent unknowing
users from risking their devices.
Thanks to Thibaut Varène for summarizing the details above.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
.
