[FS#3471] Mikrotik RB911-5Hn propper nand detection failed

OpenWrt Bugs openwrt-bugs at lists.openwrt.org
Thu Nov 26 05:52:24 EST 2020


THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#3471 - Mikrotik RB911-5Hn propper nand detection failed
User who did this - rogerpueyo (rogerpueyo)

----------
Hi Alexandros,

I'll try to go through all the topics in order:

//  tftp booting openwrt-19.07.4-ar71xx-mikrotik-rb-nor-flash-16M-initramfs-kernel gets into:

FAILSAFE MODE

//

=> OK, this is an issue I'm also experiencing with the "real" SXT Lite5 I have. It seems that the RESET button polarity is reversed and the kernel understands that it is always pressed. Therefore, at boot time, when you are prompted to press "f" to enter failsafe mode (or, alteratively, to press the reset button), since the button is wrongly detected as always pressed, it enters in failsafe mode.

I tried to fix it in these images here: https://we.tl/t-sSD1Id4jnY . I wonder if you would be so kind to give it a try.


//  here are the contents you asked {empty} //

=> Sorry I didn't make myself clear. On point 2) I was asking you to boot the new **ath79** image for the sxt5n, which you can find at [[http://example.com|External Linkhttps://downloads.openwrt.org/snapshots/targets/ath79/mikrotik/openwrt-ath79-mikrotik-mikrotik_routerboard-sxt-5nd-r2-initramfs-kernel.bin]]. The ath79 has a new driver for MikroTik devices to expose the device information, calibration data, etc. under /sys/firmware/mikrotik/hard_config , which is not in ar71xx.


//  and here is my update on the target/linux/ar71xx/base-files/lib/ar71xx.sh

|-       *"911-5Hn")
|+       *"911"|\
|+       *"911L"|\
|+       *"911-5Hn"|\
|+       *"911-5HnD")
              name="rb-911-5hn"

though, disabling the CONFIG_ATH79_MACH_RBSXTLITE option, I am unable to successfully tftp boot the device (I have no serial access to it yet) //

=> In ar71xx, during boot process, the bootloader passes some commands to the kernel, including the device **hardware** model, which is different to the "commercial" model (RB911whatever). There are many cases of different MikroTik devices that have the same hardware, so the bootloader passes the same hardware model to the kernel. Your case might be this one: the RB911Lite5 and the SXT Lite5 have the same CPU/RAM/flash/Ethernet/Wifi, so it may make sense to use the same hardware model identifier (sxt5n). 

In any case, your bootloader **is** passing the sxt5n identifier, which under ar71xx OpenWrt corresponds to the SXT Lite5. Therefore, if you remove the support for the sxt5n device, OpenWrt might only partially boot, or might be unable to bring up some devices/resources (in your case, I understand, at least the serial interface). I would say this is expected.


//  looking at this commit (dated 2018):

Notes:
* Older versions of these boards might be equipped with a NAND
  flash chip instead of the SPI NOR device. Those boards are not
  supported (yet).

//

=> There we have it, MikroTik initially made the RB911Lite5 with NAND flash, and then switched to NOR flash for whatever reason. This means you probably have one of these old NAND boards, which are not supported as "normal RB911Lite5 NOR boards", but have exactly the same hardware as the SXT Lite5 (and so the bootloader is telling).

// probably the problem & the confusion is due to this earlier commit (dated 2014):

The new RB911L series is also supported as a result

//

=> You found it! This commit added support to the SXT Lite 5, and "accidentally" also added support to the early NAND-RB911Lite5, because they had the same exact hardware. Later, MikroTik switched to NOR-RB911Lite5, which has partially different hardware. Tricky ;)


//here is a picture of the nand-flash. it looks identical to the RB711-5Hn flash

here is a dmesg from an rb711 on an older patched lede trunk (my rb711 version has a 64MB nand, not an 128 MB as shown on the above product page).

Mikrotik has a tendency of mixing different peripheral hw under the exact same product model.
//

=> OK, this is a completely different model. Check the CPU, it's an old Atheros AR7241 ... But yes, you got it right, MikroTik does this quite often, which is inconvenient for OpenWrt. :( Sometimes they change the info on their webpage, but keep the old picture there.



//  thereof, I used openwrt-ar71xx-mikrotik-nand-large-initramfs-kernel.bin for tftp boot & openwrt-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin for the sysupgrade, and my board functions just fine.

it still insists that the board is:

MikroTik RouterBOARD SXT Lite5

and there is no wlan calibration data on:

/sys/firmware/mikrotik/

in fact the above directory is empty//

=> The "MikroTik RouterBOARD SXT Lite5" board name you are getting is because **ar71xx** OpenWrt gets "sxt5n" from the bootloader and translates it into the "commercial" name. If you had a NOR-RB911Lite5, the bootloader would be passing something like "911l" and you'd be reading "MikroTik RouterBoard 911L".

Also, you're not seeing the calibration data because you are in failsafe mode, could it be?

Just think that your NAND-RB911Lite 5 is hardware-identical to the SXT Lite 5 and don't worry anymore about it. :)



//
 tftp booting openwrt-18.06.9-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf on the device gives the following under the dir /sys/firmware/routerboot/

drwxr-xr-x    2 root     root             0 Nov 19 09:50 .
drwxr-xr-x    3 root     root             0 Nov 19 09:50 ..
-rw-------    1 root     root         65536 Nov 19 09:50 ext_wlan_data

so once again, it looks like "older" is "better".
in this case it's true for both hw & sw !
//

=> I would say that if you tftp boot the ar71xx-19.07.4 image I left at https://we.tl/t-sSD1Id4jnY the device won't enter in failsafe mode and you'll get the calibration data under /sys/firmware/routerboot.


//this bug report may well & shamefully close now as Invalid, although it does contain some valuable information & material on steps & procedures one has to take prior to rushing on filling BUG reports. 
//

No worries, now you know your board is disguised as another thing! :)

----------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3471#comment9040

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.



More information about the openwrt-bugs mailing list