ipq40xx: add MikroTik hAP ac2 support #3037
Conversation
adschm
added
core packages
|
@f00b4r0 Any remarks? |
|
@robimarko besides the fact that the rbcfg changes will soon no longer be necessary if #3032 is accepted, I'll bite the elephant in the room: Why do we need what looks like a nearly complete loader, most of which appears to be straight copy-paste from u-boot with a questionnable copyright slapped onto unchanged source code? I haven't yet taken a look at RouterOS image format, but from the quick look I took at the dump of a factory hap-ac2 flash content, it looks like yaffs (like for other routerboot-equipped devices)? If the matter is the kernel compression, why can't lzma-loader suffice (possibly with minor changes)? I think this is going to either require some in depth explanation of why so much extra code is needed (and frankly at the moment I doubt it is), along with a careful cleanup of the source to restore upstream copyright where applicable, if this new loader is pushed forward. Anyway, thanks a lot for your efforts, I will take a better look at all this ASAP. I also have a brand new hap-ac2 waiting for OpenWRT, so the incentive to get this clean and working is there 😉 |
|
Yeah, I know that rbcfg wont be necessary. Well, I did not really dig deep for reasons as bootloader predates my work on Mikrotik in IPQ40xx and was originally made for RB3011(IPQ8064) to not have to use U-boot. |
|
Hi @robimarko, #3032 has been merged, as well as the caldata patch. I've been lagging on looking at this PR but I'll get to it over the weekend hopefully. Stay tuned :) |
|
Great, I will then update this to drop rbcfg |
robimarko
force-pushed
the
hAP-ac2-cleanup
branch
from
a3f65d6
to
3fcabc6
Compare
|
@f00b4r0 I have rebased the PR to current master and dropped rbcfg. |
|
@robimarko 4K_SECTORS can be enabled with a sane 4K_SECTORS_LIMIT (4MB is the default IIRC). Then if everything works fine and partial erase still works, you should see 64K EB on large partitions and 4K EB on the small ones. I've heard reports that this no longer works with kernel after 4.17 (which implements a major rework of the mtd subsystem) but I haven't been able to test this myself yet. |
|
Yeah, I know about the size limit. |
robimarko
force-pushed
the
hAP-ac2-cleanup
branch
from
3fcabc6
to
12b1dcc
Compare
|
Cat you give the output of /proc/mtd? Thanks |
|
Sure, |
|
OK. Did you change |
|
No, its still at 4096K |
|
Then there's a bug. As you can see, all mtd partitions including the big ones have 4K EB, whereas with a 4MB LIMIT only the partitions smaller than 4MB should have 4K EB. Maybe @nbd168 can help us here? |
|
Hm, but how is then soft config still working normally? |
It's working because erasesize is 4K for soft_config (which is good). What's not good is that erasesize is 4K for all partitions. If you use larger than 4K, it won't work because the adjacent partition might be erased together with soft_config. |
|
Well, now it looks obvious. |
|
Just a quick update to let you know that I'm currently investigating #3026 and it might turn out that the intermediary loader may be completely unnecessary after all. I'll report back here once we've clarified things on ath79 (granted, different archs but I suspect routerboot behaves the same regardless). |
|
That would be awesome, getting rid of a bunch of code |
|
Is sysupgrade actually working for you? I've added support for the SXTsq 5 ac, largely based on this PR, and on my device it does not actually write anything to the "firmware" partition (even if I can correctly write to it with mtd/dd). I'm booting via TFTP and then performing sysupgrade. If I enter failsafe mode, sysupgrade works; if I go through the whole booting process and then perform sysupgrade, it fails (it does not even touch the flash). |
|
Yes, its working fine. Also, is your SPI NOR recognized properly |
|
OK, good to know. Yes, it's there, right after your device. And yes, SPI NOR is properly recognized, because I can flash from failsafe. Also files written to the flash overlay persist reboots. Cool then. Thanks, I don't want to hijack the PR :) Edit: fixed, I removed one of the items in the DTS which caused sysupgrade to fail. |
|
@robimarko do you have serial on your hapac2? If so, could you try tftp booting the bare ELF kernel that should be found in build_dir/target*/linux*_ipq40xx/vmlinux.elf ? |
|
@f00b4r0 Yes, I have serial enabled. Serial log: |
robimarko
force-pushed
the
hAP-ac2-cleanup
branch
from
12b1dcc
to
20f0909
Compare
|
Thanks! Both datapoints are helpful. The ARM kernel doesn't support (yet) an appended DTB with an ELF kernel, and routerboot will only boot an ELF binary. And in a DTS world we need to embed the DTB. Therefore it seems there are two options:
Either way, I think the current approach is clearly excessive: there is no need to handle DTB/FIT ourselves for instance. I don't think we're out to write a complete bootloader. What we want is to make an image that will work with RouterBoot, IMO. |
|
I should add that in any case if the limitation on the size of the bootable ELF binary are similar to those found on some MIPS routerboards, we will need to build a very small (as small as possible) install initramfs image, that will not contain all the stuff found on the main sysupgrade image. IIRC @jow- mentioned that currently the build system doesn't allow this, but I suspect it will be necessary for us (and maybe for other devices as the kernels keep growing). |
|
@f00b4r0 The only reason I can think of is if ath10k only loads the BDF once and not per each radio. |
|
@f00b4r0 Do you maybe have your old code for loading this during runtime somewhere? |
|
@robimarko luckily I do: f00b4r0@bd48e8f Note the commit message and the likely reason why this doesn't work. Considering the incoming ipq Mikrotik PRs (#4625 #4266 #4055 #3806) plus those which have already been merged, which are all likely to expose the same problem, I hope we can find a "fix". HTH |
|
Great, I just remembered this as I finally completed the hAP ac3 support after a couple of months and made a PR. But yeah, the commit message confirms what I was afraid of, it only loading BDF once, and that won't work as we have 2 radios. |
|
@robimarko my memory of my investigations back then is mostly gone, but IIRC the driver can only load 1 BDF from flat board.bin, and needs board2 to load multiple ones. If that assumption is correct, maybe we can improve the loading script to dynamically provide a board2.bin binary stream instead of the flat board.bin? Maybe that could work? Alternatively, maybe the driver can be fixed? I'm afraid I don't have much time on my hands right now to be more helpful, but I'll try to get another look at the code later. |
|
@f00b4r0 Hm, it looks like the driver actually does load everything twice as it should as the radios are a separate driver instance. So simply passing it via sysfs like is done for caldata should work just fine here as well |
|
@robimarko interesting. Maybe something changed then since my initial testing. You may want to thoroughly test this because I do remember it not working as intended. I wish I could remember more though, sorry :/ |
|
@f00b4r0 I see the potential issue here, you were serving the same BDF data for both radios as there is no way to differentiate for which radio is the sysfs call meant as it simply requests the same board.bin filename. It looks that the kernel actually passes the device to the sysfs helper as well, gotta find a way to utilize that. |
|
@f00b4r0 Ok, so instead of going down this rabbit hole I remembered that caldata is nicely formated in the So, it nows just looks for: |
Yes, that's it indeed. Now I remember :)
I might be able to help with that if it turns out to be necessary.
See |
|
@f00b4r0 Do you know how can I get the firmware hotplug script to print things? Ok, I made it print into a file, and that works weirdly. |
Print to a file in /tmp |
|
Now, this thing is just annoying me, it fetches the same BDF for both radios despite the full DEVPATH being a condition. I think that driver modification will be required as I can see it requesting the BDF with the same DEVPATH twice, so no wonder it loads the same one. |
|
That rings a bell. I kinda remember hitting this problem as well. |
|
Yeah, I already implemented trying to load I am just cleaning it up to send upstream as I can see that the CRC of the loaded BDF matches the one packaged in board-2.bin. |
|
Here is the current version ath10k-ct probably needs further clean up due to the stupid logic for copying the BDF name. @notr1ch Can you give it a go on your hAP ac2? |
|
@robimarko Thank you very much for working on this, I'm happy to report it works great! Both interfaces are now showing other APs with signal strengths equal to RouterOS during a scan, and running as an AP the signal also looks great on my phone. I will leave it running for a while to check stability, but it certainly seems like this was the fix. Kernel log if it's useful: If there's any other diagnostic info or commands that would help please don't hesitate to ping me. For anyone else following along, here's a pre-built initramfs of robimarko's tree for testing (config from OpenWRT 21.02): |
|
@notr1ch Awesome, thanks for testing. I have sent the patch already to linux-wireless, they deferred it for now(Whatever that means) |
|
@robimarko deferred is ok. It means their current merge window is closed (likely for upcoming rc). It'll move again later. |
|
Great, I thought it was like that. |
|
Unfortunately the stability testing didn't go as planned as it randomly rebooted overnight. Could I use a USB serial cable work to get console output or would I have to solder the board? Anything else I could do to get more information? |
|
You need to solder to the pads, there is a pinout somewhere on the forum. |
|
I was able to reproduce the crash, the device OOMs after enough traffic passed with both interfaces up. It seems like the config already uses ath10k-ct-smallbuffers, but perhaps something is wrong with my build. Is there a way to tell from kernel output if the smallbuffers firmware was loaded instead of regular ath10k-ct? |
|
Maybe debugfs has some limits displayed through which it can be figured out what variant it is though I see no point as small buffers is selected. |
Nice catch. There has very recently been an updated version of ath10k-ct added to OpenWrt, so we may as well retest with that: 1d2bc94 One quirk of the build system is that The firmware is the same in either case: When I started testing the per-device-boarddata PR on my hapac2 through initramfs (it was using ath10k-ct for my build settings), I also saw the device crash a number of hours after the Wi-Fi was brought up (without need for and traffic / clients connecting). But, I had made a number of other changes, and I had not compared this to the same settings without the per-device-boarddata patches. You can check the installed ath10k variant, and firmware on device through: You can check the dmesg ath10k firmware crc32 against the output provided by This example uses ath10k (not -ct), so the paths and crc32s are different to the ath10k-ct firmwares: |
Thanks for the detailed reply, this sounds like the problem. I had copied the build config from the 21.02 release as I wasn't sure how to configure it from scratch and that config has the I will try changing the ipq40xx Makefile to the smallbuffers variant and see how it goes. |
I am more suspicious of a problem with mac80211, hostapd, or ath10k-ct, as my device crashed after a few hours of wireless AP active with no stations / clients. A build I installed which was based on b519997 + the per-device-boarddata PR ran fine overnight, and there have been more minor hostapd fixes committed since.
For reference: remove any .config, then work through A minimal config like this can be generated from |
|
Even after changing the Makefile, opkg reported that |
|
initramfs does not account for DEVICE_PACKAGES AFAIK |
|
Just wanted to update, the device has been running great since using |
This commit adds support for the MikroTik RouterBOARD RBD52G-5HacD2HnD-TC
(hAP ac²), a indoor dual band, dual-radio 802.11ac
wireless AP with integrated omnidirectional antennae, USB port and five
10/100/1000 Mbps Ethernet ports.
See https://mikrotik.com/product/hap_ac2 for more info.
Specifications:
· Built-in IPQ4018 (SoC) 802.11b/g/n 2x2:2, 2.5 dBi antennae
· Built-in IPQ4018 (SoC) 802.11a/n/ac 2x2:2, 2.5 dBi antennae
Installation:
Boot the initramfs image via TFTP and then flash the sysupgrade
image using "sysupgrade -n"
Signed-off-by: Robert Marko robimarko@gmail.com