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

[OpenWrt Bugs]

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 - Roger (rogerpueyo)

----------
Hi,

// edit: I just synced latest 19.07-trunk, compiled & flashed my device. it looks like the failsafe issue is NOT there anymore, so please discard the above request. 

still, I am unable to locate the patch/change that fixes this issue. I need this specific patch in order to be able to compile & test older 19.07-trunk 
//

**=>** No worries. It's weird, it just got "fixed" (???) Actually, I just recompiled the ar71xx image like you did, no changes. The setting is in file target/linux/ar71xx/files/arch/mips/ath79/mach-rbsxtlite.c, line #129 (active_low):


static struct gpio_keys_button rbsxtlite_gpio_keys[] __initdata = {
        {
                .desc           =       "Reset button",
                .type           =       EV_KEY,
                .code           =       KEY_RESTART,
                .debounce_interval      =       SXTLITE_KEYS_DEBOUNCE_INTERVAL,
                .gpio           =       SXTLITE_GPIO_BTN_RESET,
                .active_low     =       0,
        },
};


// Roger, sorry I've made you repeat your self so many times. FWIW, 19.07 trunk does look like though it has the new sysfs driver included since 2020-05-12 commit. I don't know if that commit is only ath79 specific & negates/breaks the old but working ar71xx relative functionality though //

**=>** Don't be sorry, you're right! My bad! :-)  The new driver was ported also to ar71xx, probably to deal with devices that were already supported that had their wlan_data, etc. format changed in new versions. I was not aware of it.

If the new sysfs driver is not working in ar71xx with your device and it was working before, this is a regression. Since this bug report has gotten very long, you may want to open a new one specifically for that. Otherwise, it will be a nightmare for Thibaut (or whoever can fix it) to understand what was going on here.

//  in my case, this file is 0 bytes

/sys/firmware/mikrotik/hard_config/wlan_data //

**=>** Mine is also 0 bytes, but if I run "hexdump wlan_data" it actually shows data, e.g.:

root at qMp-SXT5:/sys/firmware/mikrotik/hard_config# hexdump wlan_data | head -n5
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0001000 0202 0002 0304 0506 0000 0000 0000 0000
0001010 0000 0000 0000 0000 0000 0000 0000 1f00
0001020 3301 0000 0000 0400 1400 6d04 0300 08ff



// finally, I also try to understand what this option actually does, affect & offer to ath9k

apparently, the calibration data has nothing to do with the actual performance of the wifi card but rather with the reported numbers as far as signal strength, noise etc. am I correct ? though, still those values may affect the way ath9k selects speed rates etc. //

**=>** I'm not a kernel/drivers expert. As I understand it, some ath9k radios (e.g., on a PCI card) have the calibration data on the board (so you can move it from one PC to another) while other radios (e.g., those in a wireless router) have the calibration data embedded in the main memory of the device.

>From my experience, I once wiped the calibration data of an ath9k radio in a NanoStation and just copy&pasting the caldata from other NanoStations did not work well. The radio worked, but speeds and distance range were very low. Fortunately I found a backup of the flash chip and could recover it.
----------

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

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.