well, i took the patches in target/linux/mvebu/patches-4.4 from turris-os… the clearfog and buffer-management patches from LEDE made the kernel really unstable, additionally the dts file… oh, and the 734-phy_mvsw61xx-88e6176.patch from target/linux/generic/patches-4.4 might be needed (sadly the commit history of turris-os is not really helpful, so i had to compare the patches dirs by hand)
not sure if i should share a complete diff right now, it’s still really hack-`ish
Go ahead, everything is hackish here. My branch on github does not even build at the moment.
Sharing is caring 
That’s great news! 
Just to make it clear: We have only (with Uwe K-K and others) pushed Omnia DTS to upstream kernel. I have a lot of patches for U-Boot to send, but they need heavy cleaning. And the kernel upstreaming process is now stuck on DSA driver for switch which nobody (me, Uwe and few other kernel guys were unable to put into working state… so I hope to have some extra time for actually working on this when we solve/workaround the newly discovered problems).
Anyway, it won’t help with building OpenWRT/LEDE on your own. Our version diverged quite a bit and it contains few things that are highly unlikely to go to upstream. I have to admit that our OpenWRT fork is now really hard to build on ordinary system - special versions are needed etc. We are going to provide docker build environment. However longer-term plans calls for more cleanups and perhaps huge changes in the build system. @miska knows more about this.
thanks for the update @brill!
i think the most stuff doesn’t have to be upstreamed, but full hardware-support would be really great.
actually i was never interested in your custom software and bought because of the great hardware 
Same as @rotanid, bought Turris Omnia for the hardware, and I really would like to play with Lede master, for exemple to try latest wifi improvements
Anyways thanks for all your hardwork
I’m ok with a limited functionality, as long as I can build the image from the LEDE/OpenWRT trunk and lan and one of the wlans work. I don’t care about all of the proprietary stuff, even about the fast switch driver.
I think this is more a question for OpenWRT/LEDE developers. I’m pretty sure most drivers for hardware supported by OpenWRT/LEDE is not upstreamed and still they work.
There are already other distros running on Omnia, so it’s just a matter of will. Anybody can make it work with Vanilla OpenWRT/LEDE. I don’t see any value in doing this, but your mileage may vary.
I think its safe to say i am not the only one who bought the omnia for the powerfull hardware and the promise it would be ‘compatible’ with upstream openwrt.
From this point of view, foris, knot, autoupdater and the emphasis on nas/filesharing are fancy gadgets and not helping in the task to have a ‘stable’ ‘advanced’ netwoking appliance. ( your mileage may vary )
I strongly hope your sentiment of
besides being not helpfull, is not representative for the projects lack of will.
If upstreaming device support is beyond your influence/capability, creating a ‘bare’ openwrt-turrisomnia image and putting it online should certainly be feasible.
The medkit-minimal does not cut it.
thank you
Do you have source for such promise? Isn’t it actually OpenWRT devs’ decision whether they add support for Omnia or not? Besides, TurrisOS is still OpenWRT and all the fancy stuff is either necessary (like the btrfs root file system on the eMMC storage), or completely optional (like foris, autoupdater, etc) so they can be uninstalled. So in my opinion this is OpenWRT-compatible.
I don’t think upstreaming linux kernel would anyhow help in supporting Omnia in upstream OpenWRT/LEDE.
However, I think it’s actually a good idea to have a bare OpenWRT-like Medkit image, which would act more like a normal OpenWRT router, even though it would compromise few security features of TurrisOS, like no default password or DNSSEC validation.
was hoping not to be taken literally on this one 
But actually i was under the impression that this was a day-0 priority and any divergence from the upstream build process would be regarded as technical debt to be cleaned (eliminated to a point where Turris-OS is just a set of packages ontop default upstream openwrt images) before shipping.
So, it got rejected?
I meant upstreaming to openwrt/lede so i can build from the common tree.
Documentation on howto compile Linux-x/BSD for TO would certainly be apreciated.
Looking forward to it
Also: I respect and appreciate the work put into Turris-OS, i just care more for packets/second than (honeypot) logins/second or (nas) megabytes/second.
Please tell me straightaway if i backed the wrong horse 
Asked for help: https://forum.lede-project.org/t/need-help-with-upstreaming-turris-omnia/705
Generally, it doesn’t seem to be that hard, I have succeeded in building a trunk LEDE in a day, didn’t try flashing yet, though.
Hello,
I must say that @Ondrej_Caletka isn’t Turris developer.
They’re trying to push things to OpenWRT/LEDE first than into their own TurrisOS - here
I was playing around with integrating Omnia support into the LEDE project’s master branch and have thrown my current work up on GitHub here:
https://github.com/Xiche/lede-source/tree/turris-omnia
I’ve only been doing TFTP boots of the initramfs version so far, but I’ve also integrated the btrfs rootfs building support. I did not port the phy_select changes yet, so I fixed the WAN port to the SGMII option in the device tree for now. This is just a minimally working system so far; none of the Turris packages are included.
thank you!
I compiled it to a root-fs.tar.gz whith same structure as medkit’s ,
named it lede-omnia-medkit.tar.gz put on usb stick and tried to four-led-flash
but no gain …
did you manage eventually?
Sorry, I haven’t had a chance to play with it anymore since the holidays. I’m hoping to get a chance in the near future and at least clean up what I have to the point where it can be flashed with the existing Omnia rescue image (medkit format).
+1000 openwrt, please!
who can make a good tutorial if openwrt can be installed?
or who has a link
shameless plug