It seems wr902ac-v1 is broken now kernel 4.14 is default and 4.9 support has been removed. I get an 'os-image partition too big' error. Is there an easy work around for this?
I have a unit working with 18.06.1 -- I don't recall off hand what kernel that build uses, but I have had success and therefore would recommend using the stable release build unless you need snapshots for a specific reason (and/or if you're helping with the development -- in which case, thank you for your efforts!).
I was thinking more like a way to resize the kernel partition without a custom uboot. Or just how to revert that commit locally or something.
I'm not really sure why 4.9 support had to be removed entirely anyway. Are devices like this going to be dropped for 19.01? I assume so if 4.14 is going to be a requirement for the next release.
If you know how to poll the slider status on that model, I can add support for it to Slider-support package
I originally saw this when you posted it and meant to reply then, but forgot ....!!
Scroll back far enough in this thread, and you'll see something a couple of us worked on back in July 2017! it was a bit of a hack, but I assume the info you'd need would be in among this lot....
Share ETH:
root@lede:~# grep 'sw[12]' /sys/kernel/debug/gpio
gpio-14 ( |sw2 ) in lo
gpio-17 ( |sw1 ) in hiShare Hotspot:
root@lede:~# grep 'sw[12]' /sys/kernel/debug/gpio
gpio-14 ( |sw2 ) in hi
gpio-17 ( |sw1 ) in loAP/Rng Ext/Client
root@lede:~# grep 'sw[12]' /sys/kernel/debug/gpio
gpio-14 ( |sw2 ) in hi
gpio-17 ( |sw1 ) in hi
Hopefully, you'll include support for this router; I just had a good read up on your package (and travelmate) and think it would solve a couple of issues I'm experiencing!
Tony
I ended up using git checkout to go back to the commit before 4.9 support was removed. Reverting a commit was a bit over my head so guess it'll stay there for now.
Kernel 4.14 support is mandatory for all targets in 19.01 (and yes, that is difficult for many ar71xx devices and may be fatal for most 4 MB flash ones), with a little luck you may be able to resize the split between kernel and rootfs partitions - and ideally make it dynamic.
I was small enough when I first tried it in the days after 4.14 support was added so it's probably only slightly too big. I went back to 4.9 because the 5GHz interface wouldn't show up at the time (tried qca and ct).
Fingers crossed there will be a solution eventually. It works for now though so I'm not too fussed really. I was only trying 4.14 to see how much of a difference offloading made, I can only get about 15Mpbs through it as is.
Dynamic sounds like it would be handy, has that been implemented elsewhere in OpenWrt?
It's used by several ar71xx devices, those that only use a "firmware" partition instead of dedicated "kernel" and "rootfs" ones. You will also find a couple of devices migrating to that in the git commit history, but it depends on the hardware in question, kernel&rootfs need to be behind each other, in this order, without gaps inbetween - and the OEM bootloader mustn't puke when confronted with that. While the change itself is simple, it needs to be tested on the actual hardware, by someone who can recover it when it bricks.
I just pushed a kernel-size fix to master for ens202ext and koala
Building the generic profiles only revealed these 2 as broken.
Are you adding more kmods than the default ones?
Thanks
I'll have to check but won't be home for another few days. Off the top of my head probably just luci-app-sqm and luci-app-wireguard so whatever kmods depend on them (sched, cake and wireguard?).
Does that answer the question? I can post my config when I get back if you need more
Edit: By the way, it appears the buildbot failed again after the fix
The fix was only to address some of the failures.
I'm checking the others currently which @hnyman reported.
Ah OK. I figured you probably knew anyway.
One thing realised I should have clarified. When it fails it doesn't actually fail and stop. It just says 'os-image partition too big' during the image creation stage and that it is ignoring it. The end result is that it just doesn't create the sysupgrade and factory image. Without 'make V=s' and the lack of images you wouldn't notice.
@xback I tested an image built from your staging tree but it wouldn't boot. I used the sysupgrade image, should I have used factory?
I would have tried to get logs but the board doesn't have headers on serial (just pads). I've recovered it now so if I should have used factory let me know and I'll try again.
Hi,
Thanks for testing!
Please try the factory image.
Koen
Same result unfortunately.
tl-wr902ac-v1
Is that what you mean?
yes. thank you 
Hmz.
Partition sizes and offsets etc look fine. (my fixes doesn't touch this target also)
Any chance of providing any kind of bootlog?
I think it will be required here to figure it out what's going wrong here.
Thanks
I'll go buy some header pins on my way home this afternoon if I can find some. If I can't i'll be a few days in the post.
Unless there is someone who's already done this? @pepe2k ?